Из интересного про YTsaurus от Яндекса
- полноценный продукт для операций MapReduce, замена Hadoop'а для тех кто ещё его использовал
- внутри работа с ClickHouse, YDB и Apache Spark, ИМХО, интереснее всего использование ClickHouse, хотя и было бы интересно посмотреть на бенчмарки
- собственный аналог виртуальной файловой системы и хранилища метаданных Cypress
- собственные форматы хранения данных YSON и Skiff. YSON как замена JSON с несколькими дополнительными типами данных и Skiff как бинарный формат похожий на Protobuff.
- в опубликованном коде нет UI кроме командной строки и примеров кода, потенциальная возможность для стартапов по созданию онлайн сервисов с веб уи и настройкой под себя, как это со многими другими опен сорс продуктами по модели։ открытый код + облачная подписка? просто предположение
- особенность в том что он реально про данные большого объёма, условно от десятков терабайт, хотя в Success Stories приведены примеры с сотнями терабайт. Если работа идёт с меньшим объёмом данных, то скорее всего это будет overkill, а вот если объём и инфраструктура разумно велики, то надо пробовать.

По всем ощущениям продукт очень интересный, хочется в будущем увидеть более подробные его разборы на конкретных кейсах применения и сравнениями.

#opensource #datatools #dataops #dataengineering

Полезное чтение про данные, технологии и не только:
- Microsoft Intelligence platform data integration plan [1] план обновлений сервисов в Microsoft Intelligence platform на апрель-сентябрь 2023 года. Там много изменений полезных для тех кто пользуется их платформой

- Life after orchestrators [2] автор делится мыслями о том как работать с оркестраторами данных и без них. Автор рекламирует сервис Popsink [3], но сам пост содержит и вполне здравые мысли (не рекламу). Действительно оркестраторы нужны не везде и не всегда.

- Introducing Segment Anything: Working toward the first foundation model for image segmentation [4] - модель и данные по сегментации изображений от Meta AI, набор данных, кстати большой, более 11 миллионов изображений

- Datasets for Advancing AI Research [5] другие наборы данных для машинного обучения от Facebook. С ручной разметкой, большого объёма и тд. Не полноценный каталог данных, а интегрировано в их сайт по ИИ, но в целом оформлено неплохо и, главное!, это содержание.

- Data Modeling – The Unsung Hero of Data Engineering: An Introduction to Data Modeling (Part 1) [6] про моделирование данных в блоге Airbyte, хороший текст как вводный и явно с продолжением.

- Vicuna: An Open-Source Chatbot Impressing GPT-4 with 90%* ChatGPT Quality [7] просто какая-то эпидемия (шутка) языковых моделей которые делаются маленькими ресурсами и приближающимися по качеству к ChatGPT и GPT-4. Вот и свежий открытый продукт. Похож на Alpaca, обучали его ещё дешевле, всего за $300.


Ссылки:
[1] https://learn.microsoft.com/en-us/power-platform/release-plan/2023wave1/data-integration/
[2] https://stkbailey.substack.com/p/life-after-orchestrators
[3] https://www.popsink.com/
[4] https://ai.facebook.com/blog/segment-anything-foundation-model-image-segmentation/
[5] https://ai.facebook.com/datasets/
[6] https://airbyte.com/blog/data-modeling-unsung-hero-data-engineering-introduction
[7] https://vicuna.lmsys.org/

#readings #data #ai #datatools #machinelearning #dataengineering

Полезное чтение про данные, технологии и не только:
- 🌶 Hot Takes on the Modern Data Stack [1] - несколько интересных мыслей про современный стек данных, особенно актуально для тех кто работает с этими сервисами регулярно

- 🗄 How we made our reporting engine 17x faster [2] про ускорение системы отчётов в 17 раз через миграцию на движок BigQuery (облачный сервис Google). Любопытно, технические подробгости

- 💭 The new philosophers. How the modern data stack falls out of fashion. [3] у Benn Stancil размышления о том что развитие ИИ изменит существующий ландшафт продуктов по работе с данными и что к этому надо быть готовыми. Он же о том что Modern Data Stack и Generative AI плохо совместимые идеологии.

- 🗂 Using DuckDB with Polars [4] автор пишет про комбинацию этих двух новых инструментов, комбинация хорошая, надо брать

- 💰 Announcing Cybersyn’s $62.9M Series A [5] стартап Cybersyn по предоставлению доступа к открытым госданным через Snowflake поднял $62.9 инвестиций. Можно им только позавидовать, я для нашего сервиса Datacrafter всё ещё ищу инвестиции. Видимо надо делать сразу на маркетплейсы и не в России;) А Cybersyn стартап интересный, инвестиции для этого рынка большие.

Ссылки:
[1] https://mattpalmer.io/posts/hot-takes/
[2] https://medium.com/teads-engineering/how-we-made-our-reporting-engine-17x-faster-652b9e316ca4
[3] https://benn.substack.com/p/the-new-philosophers
[4] https://towardsdatascience.com/using-duckdb-with-polars-e15a865e48a3
[5] https://www.cybersyn.com/blog-series-a/

#opensource #startups #readings #data #dataengineering

Пока мы тут обсуждаем кого ИИ лишит профессии, спешу сказать что разработчикам и инженерам не стоит надеяться на скорое исчезновение их профессий (что хорошо) и даже на то что ИИ очень сильно облегчит жизнь (что не так хорошо). Почему? Потому что большую часть инженеров и разработчиков что я знаю на реальных продуктах и проектах - это отладка и legacy, это разгребание накопленного непотребства, создание кривых подпорок из кривых подпорок и ещё много чего. За исключением очень редких уникальных случаев когда это не так. ИИ может лишить интересной работы по созданию чего-то абсолютно с нуля и ещё сильнее усложнить переход разработчиков из джунов в миддлы, потому что чуть ли не главные их отличия - это умение работать самостоятельно и самостоятельно вести отладку.

#ai #profession #dataengineering

Про сжатие данных и о том почему я регулярно пишу что Parquet - это реально значимый формат хранения и обмена данными, важнее довольно многих.

Я приведу в пример данные с которыми я лично работал в аналитических задачах. У меня есть выгрузка слепка данных из российского реестра юридических лиц ЕГРЮЛ в виде 11 миллионов записей в которых 12 полей-признаков места организации, её типа, кода окопф, оквэд, кладр, статус ликвидации и тд. Без названий и без идентификаторов, данные нужны только для аналитической работы и построения кубов и срезов для BI. В общеё сложности - это 4.07ГБ. Не очень много когда один файл и много когда таких файлов десятки. С файлом нужно иметь возможность работать, загружать в СУБД или библиотеку вроде Pandas. Как сжать эти данные?

Самое очевидное - это сжать классическими архиваторами и хранить так. Gzip даёт сжатие до 337 МБ это примерно 8.3%, альтернативный Gzip'у архиватор LZ4 для быстрого сжатия и разжатия даёт компрессию до 340МБ это тоже примерно 8.3%, а LMA-архивация с помощь. XZ даёт 136МБ это примерно 3%, но она работает значительно медленнее. Все архиваторы проверялись в режиме максимального сжатия (ключ -9).

Так вот, а если этот же CSV файл преобразовать в parquet формат со сжатием, то итоговый файл получается размером в 109МБ, это примерно 2.7% от оригинального и, при этом, с ним весьма удобно работать с инструментами вроде Pandas при том что скорость преобразования значительно быстрее чем сжатие с помощью xz, к примеру. Во многом, похоже, это происходит из-заавтоматической идентификации типов полей и их преобразования.

Причём даже если повторить используемый в parquet трюк с колоночным сжатием, так просто такой результат повторить непросто. Например, у меня есть код который из CSV файла создаёт пучёк одноколоночных CSV файлов сжатие которых по отдельности должно быть лучше чем сжатие оригинального файла. Сжатые одноколоночные файлы дают дополнительное сжатие. GZIP файлы таких файлов занимают 221 МБ вместо 337 МБ. Аналогично для lz4 и только для xz размер общий файлов увеличивается до 139 МБ.

Конечно никто такие одноколочные файлы не делает, это трюк из давнего прошлого, я привожу его исключительно как иллюстрацию. Речь о том что Parquet файл значительно меньше и практичнее в общим случаях.

Отдельная история про сжатие данных для долгосрочного хранения и для сохранения интеграции с унаследованными системами. Тем не менее, имея выбор формата для хранения данных - Parquet это хороший выбор.

Для того чтобы он стал отличным ему нехватает только некоторых опций работы стандартными инструментами. Чтобы его можно было открыть в Excel, в браузере, в чтобы были аналоги grep/cat/awk/sed или csvkit и ещё много разных других инструментов. Тем не менее и сейчас его уже можно использовать.

#dataengineering #data #compression #parquet

Benn Stancil наиболее точно описал новый продукт от Microsoft как Microsoft builds the bomb [1] про их новый продукт Fabric. Для всех кто пользуется стеком Microsoft повседневно, особенно для компаний сидящих на их облачных продуктах - это находка. Причём я согласен с Беном что продукты у Microsoft могут быть очень далеки от идеала, но благодаря критической массе корпоративных клиентов и тому что именно у таких клиентов есть деньги и предпочтение унифицированным платформам, то у Fabric хорошее будущее. Остальные платформы (Google, AWS) могут пойти таким же путём и начать добивать Modern Data Stack состоящий из очень хороших, но фрагментированных инструментов.

Неспроста многие в последнее время говорят и пишут о том что профессия инженера-данных превращается в профессию инженера платформ работы с данными. Всё это, разумеется, не про российские реалии, а про мировую тенденцию.

Ссылки:
[1] https://benn.substack.com/p/microsoft-builds-the-bomb

#dataengineering

Свежий State of Data Engineering report 2023 от LakeFS [1].

Не очень детальный, на мой взгляд, не тянущий на полноценный State of ... доклад, но содержащий полезные факты и тезисы и упоминания некоторых продуктов про которые я лично не слышал или когда-то видел, но не впечатлившись отложил на потом.

Отчет короткий поэтому прочитать его несложно в любом случае.

Ссылки:
[1] https://lakefs.io/blog/the-state-of-data-engineering-2023

#dataengineering #startups #reports

Я давно не писал про то дата-инженерные задачи которые приходится решать. Вот, к примеру, нетипичная-типичная задача - это построение поискового индекса по открытым данным - это то для чего начинался Common Data Index. Чтобы построить поисковый индекс надо
а) Собрать оригинальные опубликованные каталоги метаданных, чаще всего это REST API возвращающее JSON или JSON каталоги по стандарту DCAT
б) Проанализировать и подготовить схемы/структуру собранных данных
в) Преобразовать собранные первичные данные в общий поисковый индекс, соответственно преобразовав первичные данные в унифицированную структуру.

Типовых API и вариантов экспорта данных которые есть уже сейчас 9 штук, то что может быть сведено к типовому API ещё примерно 10 разных типов API и вариантов экспорта данных, а также есть огромное число произвольных API или даже сайтов без API, из которых самые значимые это большие онлайн каталоги открытых данных где публикуется их, условно, от 100 тысяч наборов данных.

Все собираемые данные через API из этих каталогов - это JSON или XML и природа данных такова что преобразовывать их в плоские таблицы - это потратить много сил на проектирование структур данных, с каждого API данные преобразуются от 1 до 10 таблиц и, также, одна из задач в сохранении всех первичных данных чтобы с ними можно было бы удобно работать в будущем.

Всё это пока что нельзя отнести к большим данным или данным реального времени, тут нет пока что большого технического челленжа, но есть челленж аналитический и решение задачи по интеграции и преобразовании данных. Большие данные тоже будут, но позже, когда уже начнётся сбор не только описаний наборов данных, но и самих файлов, а там уже данных очень много, петабайты если не больше, если обрабатывать всё.

А пока с построением поискового индекса возникает резонный вопрос как всё собирать и обрабатывать и это то почему я постоянно сетую что не хватает ETL/ELT инструментов с поддержкой NoSQL. Потому что поисковый индекс это тоже не плоские таблицы, это хранилище, тоже NoSQL, например, Elasticsearch.

Итого, на входе тысячи источников данных, с данными в JSON, не менее чем 9 разных схем, хранением первичных данных, преобразованием этих данных в унифицированный формат и итоговый поисковый индекс. И для всего этого хочется ещё и observability, управляемые конвейеры для обработки (pipelines), контроль качества и ELT/ETL для трансформации первичных данных в унифицированный формат, а инструментов для этого из коробки просто нет.

Но решать надо и я позже расскажу как эта задача сейчас решается, а пока мысли вслух о какими данными приходится работать.

#opendata #dataengineering #datarchitecture

Через месяц, 29 июня, закрывается проект bit.io [1] в связи с тем что их команду купил DataBricks. Для тех кто не помнит, bit.io - это был сервис облачного хостинга PostgreSQL с возможностью ручной загрузки данных, API, дистанционного подключения к СУБД, наличия большого числа опубликованных баз данных.

DataBricks такой сервис не нужен, а нужна только команда. Поэтому сервис закрывают.

Ссылки:
[1] https://bit.io

#startups #data #rdbms #databases #dataengineering

Один из активно обсуждаемых вопросов в современной дата-инженерии о том как можно применить ИИ для решения задач работы с данными, как можно улучшить имеющиеся продукты, что может быть нового и тд. Я в последние месяцы много каких дискуссий послушал на эту тему и, честно говоря, не то чтобы пока впечатлился. Большая часть направлений мысли в том как делать ИИ продукты на данных, а не на том как ИИ помогает в работе с данными. Оно и понятно, большая часть стартапов с ИИ в последнее время думают про продукты для массового потребителя, а ИИ для дата-инженерии - это не массовое, а корпоративное потребление скорее.

Тем не менее тема эта интересная и, на мой взгляд, будет развиваться, хотя и не все идеи кажутся реалистичными. Я собрал пока следующие идеи:
- запросы к базам данных на естественном языке
- запросы на автоматическое построение визуализации на естественном языке
- автоматизация написания SQL запросов или запросов на других языках (text2sql)
- автоматическое проектирование баз данных из ТЗ написанного на естественном языке (вместе с извлечение бизнес логики и тд.)
- автоматическое обнаружение неработающих дашбордов, отсутствующих данных, сбоев в конвейерах данных (Monte Carlo data)
* обогащение данных и метаданных
* генерация идей для аналитики на основе данных
* поиск аномалий, автоматизированный контроль качества данных

Но пока ни одна из этих идей не несёт того критически значимого преимущества после которого можно было бы сказать что какой-то продукт стал резко лучше или новый продукт обходит предыдущие.

#dataengineering #ai #ideas #thoughts

Написал текст в рассылку на тему того зачем создаются корпоративные каталоги данных [1]. Это часть скорее теоретическая чем практическая, в неё мало практических примеров, зато много подробностей о том зачем и в какой ситуации компании, в принципе, задумываются о внедрении каталогов данных. В следующих текстах я уже подробнее разберу случаи когда точно не надо усложнять себе жизнь и заводить каталог данных который бы перестал быть актуальным и расскажу о выборе инструментов, там уже много особенностей технологических и разные инструменты решают разные задачи. А ещё точнее с разным качеством решают одни и те же задачи.

Ссылки:
[1] https://begtin.substack.com/p/corporate-data-discovery-1

#data #datacatalogs #dataengineering #dataanalytics #compliance

Полезное чтение про данные, технологии и не только:
- Google News Is Boosting Garbage AI-Generated Articles [1] статья о том что Google News бустят новости не с оригинальных сайтов, а с тех что рерайтят оригинал с помощью ИИ. Статья под пэйволом, но, в общем, всё сказано в заголовке. Непонятно только что с этим делать.
- Paper on Sleeping Agents [2] о том как помещать бэкдоры в языковые модели которые бы могли проходить проверки безопасности. Отдельное новое направление для команд занимающихся инфобезом.
- It's time to build [3] свежая заметка от Benn Stancil о том что для того чтобы создавать дата-стартапы (инструментальные стартапы) не надо новых идей, надо старые идеи/продукты сделать современными.
Не могу с этим не согласится и примеры он приводит релевантные.
- Python Packaging, One Year Later: A Look Back at 2023 in Python Packaging [4] о том как устроены пакеты в Python, технический и прикладной обзор за 2023 год. Может показаться сугубо технической темой, но она актуальна для всех кто создаёт или распространяет пакеты для Python. От себя добавлю что пакеты для Python уже давно стали одним из отражений качества любого продукта или сервиса. Уже не просто API предоставляется, а сразу пакет для Python для доступа к API.
- SQLMesh [5] - open-source движок для преобразования данных близкий и сравнимый с dbt по идеологии и авторы которого продвигают концепцию Virtual Data Environment (VDE) [6]. Концепт как минимум интересный. Кстати, эти же ребята авторы python библиотеки SQLGlot [7], парсера и оптимизатора SQL запросов
- Omni [8] свежий стартап по BI, упомянутый недавно Benn Stancil, делают то же что и все просто проще и симпатичнее. У меня в списке продуктов на потестить визуализацию разным образом. Главное удобство - это комбинация SQL запросов и визуализации данных.
- DataHem odyssey - the evolution of a data platform, part 2 [9] подробный рассказ о эволюции аналитической платформы в Mathem со множеством подробностей про использование dbt и не только.

Ссылки:
[1] https://www.404media.co/google-news-is-boosting-garbage-ai-generated-articles/
[2] https://arxiv.org/pdf/2401.05566.pdf
[3] https://benn.substack.com/p/its-time-to-build
[4] https://chriswarrick.com/blog/2024/01/15/python-packaging-one-year-later/
[5] https://sqlmesh.com
[6] https://tobikodata.com/virtual-data-environments.html
[7] https://github.com/tobymao/sqlglot
[8] https://omni.co
[9] https://robertsahlin.substack.com/p/datahem-odyssey-the-evolution-of-95f

#readings #data #datatools #opensource #dataengineering #ai

Я давно не писал про некоторые базовые принципы работы с данными, хотя регулярно о них задумываюсь в практическом контексте применения концепций и принципов инженерии данных к открытым и общедоступным данным. Например, про data lineage, которое на русский язык коллеги переводят как генеалогию данных. Я буду использовать термин data lineage, как более употребимое.

Так вот интересное тут то что в корпоративном мире с густой аналитикой (когда аналитические команды есть и они сильные, и запрос на аналитику есть), так вот в корпоративном мире data lineage - это понятное явление, если не привычное, то активно обсуждаемое и применяемое. Потому что decision maker'ы часто задают вопросы о том как та или иная цифра вышла и надо иметь ответ о том, а как же это оно есть. А вот в мире общедоступных данных, статистики и, отчасти, науки, с data lineage всё, скажем там, плоховато или очень специфично.

В случае научных данных общего типа, происхождение данных, обычно, описано текстом, неструктурировано и, частично, выявляется из ссылок на данные которые использовались. Иногда по этим ссылкам можно определить быстро первоисточник и способы обработки, иногда сложнее. Для хорошо структурированных научных областей вроде биоинформатики это должно быть проще, для других наук сложнее и тд.

В других случаях это сложнее, иногда реально сложно. Ещё сложнее со статистикой, при том что там источники данных указываются практически всегда, но это указание может быть не на первоисточник, а на глобальный источник. Простой пример, какой-нибудь агрегатор данных статистики вроде портала данных ООН (data.un.org) может собирать данные из портала данных Международного валютного фонда (IMF) data.imf.org, а тот из первоисточника, страницы раскрытия данных на сайте резервного банка или статслужбы страны. А кто-то коммерческий может, опять же, собирать данные с портала ООН и выдавать в своём сервисе.
Будем ли он при этом рисовать полноценный data lineage от портала данных ООН до сайта статслужбы ? Вообще-то нет, источником будет указан портал ООН.

С открытыми данными данными ещё хуже, там даже приближения к генеалогии данных нет, даже если в первоисточнике базы из которой создан датасет он есть.

Потому что есть огромное немаловажное явление - это технологический разрыв между порталами раскрытия и системами управления данными.
Он особенно остро ощущается теми кто работает в обоих мирах, с корпоративными данными, и с общедоступными данными.

Лично я его ощущаю довольно сильно и проекты и инициативы которые создаются дата инженерами и, условно, идеологами и активистами отличаются очень сильно.

Первые продвинуты технологически и сразу ориентированы на разработчиков (API, структурированное хранилище, преобразование данных в удобные форматы JSON, Parquet и др.), но, часто, забывая про базовые принципы открытости.

Вторые, наоборот, ориентированы на государственную или корпоративную прозрачность, но технологическая реализация всегда оставляет ощущение архаики.

Как выглядят идеальные порталы/сайты индикаторов или порталы публикации геоданных? Лично я считаю что главное в них это максимальная ориентация на использование дата-инженерами и дата-аналитиками владеющими современными инструментами. Даже, если не суперсовременными, но хотя бы актуальными.

Это реализация data lineage, это проектирование по принципу API First, это современные форматы предоставления данных для data science, это _всегда_ наличие bulk download, это концепция в основе что data as a product, а не данные как производный продукт от чего то ещё.

#opendata #data #dataengineering #thoughts

Свежие и полезные инструменты с открытым кодом для загрузки и обработки данных:
- PyAirbyte [1] библиотека для Python от команды Airbyte для того чтобы перенести логику этого движка по сбору данных в Python. Поддерживает все коннекторы Airbyte ранее написанные на Python
- dlt [2] Data Load Tool, явно созвучное dbt, библиотека для Python для реализации принципа Extract-Load-Transform. Выглядит довольно целостно, стоит изучить внимательнее
- ingestr [3] утилита командной строки по переносу баз данных из одного источника в другой. Поддерживает основные SQL СУБД
- sling [4] инструмент для выгрузки/загрузки данных с большинства основных СУБД включая облачные, файловых систем и различных дата файлов. Реализован на Go, важное ограничение GPL 2 лицензия (для сравнения у dlt лицензия Apache 2, а у ingestr MIT).

И конечно остаются такие инструменты как Meltano, Dagster, CloudQuery и многие другие

Ссылки:
[1] https://airbyte.com/blog/announcing-pyairbyte
[2] https://dlthub.com
[3] https://github.com/bruin-data/ingestr
[4] https://github.com/slingdata-io/sling-cli

#opensource #dataengineering

Фразы которыми можно пугать дата инженеров на собеседованиях и не только:
- данные у нас в CSV и Excel на FTP сервере
- наши Excel файлы обновляются в реальном времени на сетевом диске
- требуется работать с большим числом серверов и таблиц из SAP/1С/Oracle Application (нужное тяжелое легаси подставить)
- данные в личных папках пользователей в Sharepoint, надо их синхронизировать
- мы хотим сделать наше озеро данных на Hadoop'е
- большая часть данных у нас в PDF, мы не знаем тексты там или сканы
- требуется 10-летний опыт с dbt cloud

А чем Вы пугаете, чем пугают Вас ?

#humor #dataengineering

Свежий доклад State of Data Engineering 2024 от команды LakeFS.

Подмечают три ключевых тренда:
1. Генеративный ИИ влияет на инструментарий в Modern Data Stack
2. Конкуренция дата продуктов растёт и, соответственно, моё дополнение, цена выхода на рынок с новым продуктом.
3. Открытые форматы создают закрытые заборы. В центре конфликт между Databricks и Snowflake.

Последнее утверждение спорное, скорее речь о том что есть такой конфликт на рынке, а уж каким образом и что используется при нем - не это в его основе.

Что характерно в таких обзорах State of ... так то что от 75 до 95 процентов инструментов, по разным категориям, это облачные продукты. К российским реалиям, к примеру, они не применимы. Как и ко многим особо закрытым не-российским стекам данных.

И, кстати, чтобы не забыть, составители таких State of продолжают путать открытые данные и каталоги открытых данных и корпоративные каталоги. А это очень разные продукты под очень разные задачи.

А если бы я выпускал свой State of data ... то делал бы два отдельных. Один для облака, а другой для корп оффлайна. А может быть даже и три. Ещё один для корп оффлайна открытого кода.

#datatools #opensource #stateof #dataengineering #moderndatastack #readings

Хорошая статья [1] о том как добиться высокой производительности Python при обработке очень больших файлов с данными на примере данных конкурса One Billion Row Challenge [2].

Ключевое что можно из статьи вынести:
- да, по умолчанию Python медленный, но есть много способов его очень сильно ускорить
- Polars и DuckDB дают сильнейшее ускорение, буквально 30кратное и делают обработку данных особенно быстрой
- Pandas - это медленно, пора отказываться от него где возможно
- замена CPython на PyPy заметно ускоряет процесс
- всё это без использования GPU, на ноутбуке

А я не могу не вспомнить что уже есть One Trillion Rows Challenge [3] где Dask претендуют на лучшую скорость обработки данных [4]

Больше соревнований хороших и разных!

Ссылки:
[1] https://towardsdatascience.com/python-one-billion-row-challenge-from-10-minutes-to-4-seconds-0718662b303e
[2] https://1brc.dev
[3] https://t.me/begtin/5529
[4] https://docs.coiled.io/blog/1trc.html

#data #dataengineering #contests #python

Разное, дата инженерное:
1. При работе с JSON lines (NDJSON) по прежнему MongoDB поглощает любой скормленный файл, DuckDB лучше умеет считывать схемы и Clickhouse включая Clickhouse-local оказался самым "капризным". Для ситуаций данных с большим числом NoSQL данных и множеством схем clickhouse применим ограниченно и надо делать специальный инструментарий/надстройку чтобы иvмпортировать уже по предраспознанным схемам, что сильно замедлит импорт на больших файлах. По прежнему очень не хватает высокопроизводительного инструмента для работы с NoSQL.
2. DuckDB примечателен в плане й удобства разработчика, доступных примеров и документации, расширяемости и тд. DuckDB - это очень крутой инструмент. Причём можно смотреть на него как на вещь в себе и подспорье для аналитика, а можно как один из компонентов создаваемого дата-продукта.
3. Ценность Parquet'а начинаешь понимать когда взаимодействуешь с командами публикующими плохо документированные CSV файлы с кучей ошибок из-за того что они в CSV файлы упихивают иерархические структуры из первоисточника. Такие файлы или очень неудобно или совсем нормально не импортируются стандартными средствами. Parquet должен быть форматом для данных по умолчанию, остальное производится из него быстро.
4. Clickhouse или DuckDB были бы хорошими инструментами для замены движка внутри OpenRefine. Но, похоже, этого не дождаться. Разве что, сделать всё же, инструмент для headless data refine, я такой когда-то смастерил для MongoDB, но скорость там оставляет желать лучшего. Скорее это был прототип для оценки возможности реализации.
5. Классические ETL/ELT инструменты для геоданных не то чтобы совсем непригодны, но не заточены ни разу. Создавать / адаптировать существующие ETL движки под них? Или использовать что-то целенаправленно созданное в этой области? Пока не очень впечатляет всё что я видел.

#notes #dataengineering #data #datatools

Собрал свои публичные презентации по нескольким темам и понял что получится большой пост если перечислять все. Вот тут самые основные:

Открытые данные
- Раскрытие данных о госфинансах как часть государственной политики - про проекты открытости госфинансов и их значимости
- Открытые данные как основа госполитики - о том как устроены открытые данные в мире
- Как искать данные с помощью каталогов данных. Проект Datacatalogs.ru - об одном из первых каталогов-каталогов данных
- Sharing Data for Disaster Response and Recovery Programs - об открытых данных в вопросах чрезвычайных ситуаций и восстановления
- Открытость информационных систем нормотворчества - об открытости/закрытости систем нормотворчества в России

Data engineering
- Dateno. Global Data Discovery search engine - презентация проекта поиска по данным Dateno
- Datacrafter. Каталог и озеро данных на базе MongoDB - презентация для выступления на конференции SmartData, о внутренностях продукта Datacrafter и куча технических подробностей

Open Data Armenia
- Open Finances. International and Armenia overview - обзор проектов по открытости госфинансов в мире и в Армении
- Open Data, Open Code, Open Licenses - о разных компонентах открытости

Открытый код
- Открытый код в других странах - Как и в каком объёме и кто именно публикует открытый код, почему это важно и почему это становится всё более популярным

Приватность
- Слежка через государственные мобильные приложения - о том как государственные органы следят за гражданами с помощью мобильных приложений и сливают информацию о их передвижении и действиях коммерческим компаниям
- Термины и объекты регулирования: ADM-системы - о том что такое системы для автоматического принятия решения и как они описываются в разных странах
- О необходимости контроля и аудита ADM- систем - о том как регулировать ИИ используемый для автоматического принятия решений

Веб архивация
- Организация веб-архивов - о том как устроены современные интернет архивы и Национальный цифровой архив (ruarxive.org)
- Дата инженерия и цифровая гуманитаристика - о том какие большие цифровые гуманитарные проекты есть в мире и про Национальный цифровой архив

Понятный язык
- Простой и понятный русский язык - о простоте русского языка и её измерении
- Простота нормативно-правового языка - о подходах к оценке нормативно-правовых текстов

P.S. Всего у меня 200+ неразобранных презентаций за последние 15 лет, в онлайне не больше 30. Что-то устаревает, что-то нельзя публиковать, что-то бессмысленно без самого выступления, но, по мере разбора завалов, буду выкладывать дальше.

#opendata #opensource #plainlanguage #webarchives #digitalpreservation #dataengineering #armenia