Ещё один любопытный ETL продукт VectorETL [1] с открытым кодом под MIT лицензией. Необычен тем что:
a) Включает AI в паплайны обработки данных
б) Изначально ориентирован на векторные (NoSQL) базы данных

Опубликован стартапом Context Data которые предоставляют облачную платформу для задач которые с помощью этого ETL решаются.

Документации немного, но сам продукт любопытный. И попробовать, и почерпнуть идеи.

Ссылки:
[1] https://github.com/ContextData/VectorETL

#opensource #dataengineering

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

И здесь не последнюю роль играет выбор итогового технического стека который, в свою очередь, ограничен спецификой проекта, данных, их источников и тд.

Вот некоторые важные особенности:
1. Почти все первичные данные в Dateno - это JSON, JSON lines, и сильно реже CSV, которые тоже преобразуются в JSON. Отсюда и хранение первичных данных в MongoDB как наиболее естественно подходящем хранилище. Хотя уже можно рассматривать альтернативы. В любом случае сейчас в проекте нет SQL, за исключением DuckDB для аналитики и экспериментов.

2. В отличии от корпоративной дата инженерии тут огромное число неуправляемых внешних источников метаданных. Их более 10 тысяч всего из которых 5 тысяч уже подключено и индексируются. Вместе с отсутствием SQL это делает малопригодными классические оркестраторы задач и ETL/ELT инструменты.

3. Другая особенность в итеративности задач и в работе с первичными данными. Логика сбора построена на постобработке первичных данных. Вначале они собираются AS IS из первоисточников и далее, отдельными процессами, преобразуются в эталонную схему и финальную базу данных (поисковый индекс). При этом все первичные данные хранятся и используются для аналитической работы когда надо построить новый фильтр, то вначале проверяется есть ли опора для него в первичных метаданных.

4. Конвееры данных могут оперировать как очень большими, так и очень малыми данными. Число датасетов из каталога данных Всемирного банка может быть более 6 миллионов за раз, а из ряда малых каталогов данных это может быть всего 2-3 датасета.

5. Если рассмотреть инструменты для оркестрации и ETL/ELT в контексте этих особенностей то вылезает следующее:
- Meltano - ключевая фишка в большом числе коннекторов которые надо писать под каждый источник данных. Потенциальный ETL/ELT инструмент в связке с инструментом оркестрации.
- Dagster - выглядит симпатично на небольшом числе конвееров, нет результатов экспериментов на большом их числе, условно на тысячах.
- Kestra - внешне выглядит неплохо, но написан полностью на Java что заранее накладывает сомнения применимости в Python-only инфраструктуре.
- Airflow - чистый оркестратор, может быть применён в связке с собственной или донастроенным внешним ETL/ELT
- Prefect - хорошо выглядящий оркестратор на Python, но с заложенными ограничениями в бесплатной версии.

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

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

8. Поэтому один из путей решения - это условное разделение источников поступления эталонных данных. Неважно как именно отработал пайплайн, оркестратором, ad-hoc скриптами или пушем из другого сервиса, главное что он соответствует заданной схеме и проходит валидацию. Поступающие данные идут в staging (промежуточную) базу данных, а уже в ней работает конвеер по преобразованию данных в эталонные.

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

#dateno #thoughts #dataengineering #elt #etl #datapipelines

Пока я рассуждал о том что новые инструменты data wrangling'а (манипуляция и трансформация данных) появятся уже на базе движков вроде DuckDB или Clickhouse, они начали появляться. Свежее видео выступления Hannes Mühleisen - Data Wrangling [for Python or R] Like a Boss With DuckDB [1] ровно про это и слайды к нему же [2].

Автор/докладчик там сравнивает DuckDB в загрузке файлов и упоминает duckplyr [3] очень производительный заменитель популярной библиотеки Dplyr [4] для языка R.

Всю презентацию можно свести к утверждению что DuckDB - это круто для манипуляции данными и я склонен с этим согласиться.

Я бы ещё добавил что хорошо и правильно сравнивать и с интерактивными инструментами вроде OpenRefine, Talend, Trifacta и ещё рядом других. Собственно только отсутствие UI поверх движка DuckDB или Clickhouse ограничивает их популярность.

Если бы, к примеру, OpenRefine авторы переделали на движок DuckDB то цены бы ему не было и возможность работать с большими данными стала бы естественной. Но OpenRefine так просто не переделать, так что больше надежды что это создаст кто-то другой.

Я какое-то время назад проектировал такой движок и могу сказать что это не так сложно. Если бы не прорыв в индексации каталогов данных превратившийся в Dateno, я может быть такой data wrangling инструмент бы даже попробовал сделать, но сейчас просто мало времени на такое, тоже интересное занятие.

P.S. Кстати, для Python есть аналог dplyr под названием dplython [5], но попроще.

Ссылки:
[1] https://www.youtube.com/watch?v=GELhdezYmP0&list=PL9HYL-VRX0oSFkdF4fJeY63eGDvgofcbn&index=66
[2] https://blobs.duckdb.org/posit-conf-2024-keynote-hannes-muehleisen-data-wrangling-duckdb.pdf
[3] https://github.com/tidyverse/duckplyr?tab=readme-ov-file
[4] https://dplyr.tidyverse.org/
[5] https://github.com/dodger487/dplython

#opensource #data #datatools #rdbms #duckdb #dataengineering

В рубрике полезных инструментов с открытым кодом docling [1] от IBM Open Source и конкретнее их команды Deep Search. Утилита и библиотека для Python по преобразованию условно любых документов в Markdown. Умеет работать с (PDF, DOCX, PPTX, Images, HTML, AsciiDoc, Markdown и преобразует их в Markdown или JSON.

При этом распознает сканированные документы, извлекает таблицы и поддерживает множество движков распознавания. Интегрируется с LangChain и LllamaIndex, значительно быстрее работает при наличии CUDA.

Я проверял без графического процессора, поэтому было небыстро, но результирующий Markdown текст вполне приличный.

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

Ссылки:
[1] https://ds4sd.github.io/docling/

#opensource #pdf #dataengineering

Тем временем французы на национальном портале открытых данных Франции data.gouv.fr добавили возможность получать данные в формате Parquet [1]

Какие молодцы!

Ссылки:
[1] https://www.data.gouv.fr/fr/posts/telecharger-des-donnees-massives-au-format-parquet/

#opendata #parquet #france #dataengineering

Ещё один симпатичный движок для индексирования и поиска текста SeekStorm [1] умеет искать по тексту на разных языках, по скорости сравним с MeiliSearch, обещают многоязычность и внутри всё написано на Rust.

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

Можно попробовать с его помощью проиндексировать много миллионов документов. Десятки миллионов документов!

Но надо тестировать чтобы понять как он умеет инкрементально обрабатывать документов, сколько потребляет ресурсов и тд.

Ссылки:
[1] https://github.com/SeekStorm/SeekStorm
[2] https://deephn.org/?q=Data+indexing

#opensource #dataengineering

Я тут думал было запилить гайд по сжатию данных для дата инженеров, но понял что он сведётся в итоге к формуле: сжимай всё в Parquet с компрессией Zstd

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

Тем не менее несколько лайфхаков:
1. Сжимать CSV файлы с булевыми значениями в виде 0/1 эффективнее чем преобразовывать в Parquet потому что по умолчанию эти значения распознаются как числа int64 и даже сжатый parquet файл крупнее чем архивный.
2. Распространять файлы в унаследованных архиваторах типа ARJ - это жуткий моветон, они крайне неэффективны в потоковой обработке.
3. Большая часть инструментов загрузки датафреймов поддерживают сжатые csv файлы, но по разному. Pandas умеет открывать .xz,.gz,.zip,.zst,.bz2, а вот duckdb умеет только .gz и .zst, а остальные придётся распаковывать промежуточно куда-то ещё. Polars тоже умеет работать с .gz, а для остальных форматов сжатия надо прикладывать доп усилия.
4. Всё сводится в итоге к балансу между объёмов хранения данных, поддержкой основными инструментами аналитика и скоростью чтения данных. По этим категориям Parquet оказывается на первом месте потому что данные сжаты лучше чем большинством способов сжатия данных, чтение происходит чуть ли не быстрее чем читать файлы CSV и поддерживается он большинством современных инструментов.
5. Небольшие трюки с Parquet связаны с его колоночным сжатием данных. Уровень сжатия может зависеть и от формы представления данных. Например, если у Вас датасет с ежемесячными показаниями, то если период записывать как отдельные поля year и month, а не как дату начала месяца типа "2024-12-01", только на сжатии этой колонки можно сэкономить до 25%, потому что колонки year и month сожмутся куда лучше.
6. Аналогично с полями с булевыми значениями. Для сжатия лучше если это родное булевое поле в parquet, а не число или строка. И если булевые значения в CSV описаны как True/False, то при преобразовании/распознавании они идентифицируются как таковые. А если записаны как 0/1 или Yes/No и тд., то нет

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

В итоге если хотите опубликовать большой набор данных - публикуйте в Parquet с внутренним сжатием, не ошибётесь.

#dataformats #dataengineering