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

n8n [1] бесплатный движок с открытым кодом [2] позволяющий автоматизировать исполняемые потоки задач с помощью хорошо спроектированного веб интерфейса и интеграции с более чем 90 API и приложениями.

За продуктом находится берлинский стартап с одноименным названием поднявший $1.5 миллиона инвестиций в прошлом году [3] явно под будущую облачную платную версию их продукта.

Это довольно удобный инструмент для тех кто любит No-Code платформы, простой в развертывании или в облачном использовании. Для полноты картины не хватает только потестить его на обработке больших данных, например, погонять его на извлечении и обработке десятков гигабайт, но даже в текущем виде есть много задач которые можно с его помощью автоматизировать.

Из интересного, авторы декларируют подход Fair Code [4] в котором определяют что их продукт открыт и бесплатен, но ограничен для коммерческого применения, аргументируя это тем кто крупные корпорации (big tech) паразитируют на открытых проектах.

Ссылки:
[1] https://n8n.io/
[2] https://github.com/n8n-io/n8n
[3] https://www.crunchbase.com/organization/n8n-io
[4] https://faircode.io

#workflow #opensource #tools #datapipelines

OpenLineage [1] - это относительно новый стандарт прослеживаемости данных, введенный в оборот в январе 2021 года и развиваемый The Linux Foundation в привязке к Apache Airflow и Apache Spark.

Основная идея в стандартизированном API для запуска задач, хранения данных, доступа к SQL и в том чтобы все это охватывалось универсальными метаданными.

Много подробностей в репозитории стандарта [2] и примеры продуктов таких как Marquez и Egeria которые OpenLineage поддерживают.

Ссылки:
[1] https://openlineage.io/
[2] https://github.com/OpenLineage/OpenLineage

#data #datapipelines #metadata

Netflix опубликовали открытый код Metaflow UI [1], веб интерфейса для разработанного ими движка Metaflow [2] по моделированию потоков данных/труб данных (data pipelines) в целях data science. Для тех кто регулярно работает с задачами по машинному обучению инструмент может быть полезен. Подробнее в блоге Netflix [3], с рассказом о том почему и кому этот GUI может быть полезен.

Ссылки:
[1] https://github.com/Netflix/metaflow-ui
[2] https://metaflow.org/
[3] https://netflixtechblog.com/open-sourcing-a-monitoring-gui-for-metaflow-75ff465f0d60

#data #datatools #datapipelines #opensource

Подборка свежих, новых или интересных open source инструментов по работе с данными.
- Tapestry Pipeline [1] - система управления данными с открытым кодом. Управления не в смысле management, а в смысле orchestration. Более точным переводом будет оркестровка, но по русски это звучит немного странно. Сам же движок. Выполняет те же задачи что и другие data orchestration frameworks [2] такие как Flyte, Prefect, Dagster и др. Интегрируется в dbt, Airbyte и другими инструментами.
- Prefect Orion [3] как пишут сами авторы the second-generation workflow orchestration engine. А то есть система управления потоками данных второго поколения. О нем же в блоге Prefect [4] с акцентом на то что можно не разделять обработку данных пачками и потоками.
- Prefect Artifact API [5] те же Prefect добавили Artifact API в последний open-source релиз. Это API для визуализации данных проходящих оркестровку и с демо использования Great Expectations как движка по контролю качества данных.
- Guardian [6] система управления доступом к базам данным и инструментам их обработки. Сейчас поддерживает Google BigQuery, Metabase, Airflow и облачные хранилища. Нет UI, но есть продвинутая командная строка и управление через yaml конфигурационные файлы. Проект делает команда ODPF (Open DataOps Foundation) из Индии и у них же большая подборка проектов на open source для разных аспектов работы с данными [7]
- Optimus [8] ещё один проект по оркестровке данных, от той же команды ODPF. Без UI, всё с командной строки. Сосредоточено вокруг Google Big Query, полезно тем кто создает продукты в этой среде. Но, находится в состоянии "глубокой разработки", API может часто меняться. Надо отдать должное, в ODPF любят и умеют документировать продукты.
- DataX [9] инструмент от команды Alibaba по синхронизации данных между разными СУБД, в том числе принципиально разными SQL и NoSQL. Такими как Postgres, Oracle, MongoDB, TSDB и другие. Почти всё на китайском языке. А также AddaX [10] построенный на DataX и чуть более развитый, как обещает автор. Тоже почти всё на китайском. Все учим китайский!

Ссылки:
[1] https://tapestry-pipeline.github.io
[2] https://www.moderndatastack.xyz/companies/Data-Orchestration
[3] https://orion-docs.prefect.io
[4] https://medium.com/the-prefect-blog/you-no-longer-need-two-separate-systems-for-batch-processing-and-streaming-88b3b9c1a203
[5] https://medium.com/the-prefect-blog/introducing-the-artifacts-api-b9e5972db043
[6] https://github.com/odpf/guardian
[7] https://github.com/odpf
[8] https://github.com/odpf/optimus
[9] https://github.com/alibaba/DataX
[10] https://github.com/wgzhao/Addax

#data #datatools #opensource #datapipelines #moderndatastack

В блоге Pinterest история про то как они выбирали и в итоге настроили оркестратор задач на базе Airflow [1]. Пост интересный, про сложную архитектуру, реально большие данные, сложные процессы и тд.

А также там же много интересных цифр про Pinterest:
- 500 петабайт данных всего
- 600 терабайт данных ежесуточно
- 4000 workflows
- 10 000 data flows
- 38 000 ежесуточных задач в среднем

Достоинство больших проектов и крупных команд как раз в таких масштабах и решениях возникающих от сложностей подобного объема данных.

А в случае Pinterest'а ещё и интересна их архитектура связки потоков данных, развертывания кода и кластеров Kubernetes.

Ссылки:
[1] https://medium.com/pinterest-engineering/spinner-pinterests-workflow-platform-c5bbe190ba5

#opensource #bigdata #datarchitecture #datapipelines

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

В качестве интересной новости - новой большой тренд в виде инвестиций в платформы обработки данных в реальном времени. Decodable [1] и Red Panda [2], стартапы в этой области, привлекли $20M и $50M соответственно. Большие инвестиции и интересные проекты.

Red Panda - это заменитель Kafka, позиционируют себя как более быстрый и продвинутый продукт, к тому же с открытым кодом и не связанный с JVM, но с Kafka совместимый.

Decodable - это движок по созданию труб данных программируемых как SQL запросы. Лично по мне так это весьма экзотичный подход, но, видимо, он работает. Kafka он не заменяет, но интегрируется.

Ссылки:
[1] https://www.decodable.co/blog/decodable-closes-20m-round
[2] https://redpanda.com/blog/redpanda-series-b-funding-future-of-streaming-data/

#datatools #datapipelines #realtimedata #startups #opensource

Ещё один инструмент по оркестрации (всё никак не могу подобрать более точное и благозвучное название) данных Kestra [1], у них в блоге история кейса использования в Leroy Merlin [2]. Точнее всего было бы его сравнить с Meltano, Dagster и Airflow. Поддерживает несколько десятков источников данных, написан на Java и доступен с открытым кодом [3].

Официальный анонс продукта был 3 недели назад [4], хотя разработка началась ещё в 2019 году.

На что стоит обратить внимание:
- внутри всё работает на Kafka
- интеграция с Terraform
- для хранения данных используется Minio или GCS Storage

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

Ссылки:
[1] https://kestra.io/
[2] https://medium.com/@kestra-io/how-leroy-merlin-managed-their-cloud-data-pipelines-with-kestra-9932ea66b517
[3] https://github.com/kestra-io/kestra
[4] https://kestra.io/blogs/2022-02-01-kestra-opensource.html

#opensource #datapipelines #dataorchestration

О том как собирать и загружать данные, я хочу напомнить про один из важнейших проектов в этой области - Singer [1]. Singer - это open source стандарт по перемещению данных и работающий с командной строки.
Основными концепциями в Singer являются tap (на русский язык можно перевести как вентиль) и target (по-русски это будет цель).

Основная идея в том что процессы извлечения данных (extraction) и загрузки (load) являются довольно типовыми и укладываются стандартные файловые потоки. А то есть можно перенаправлять ввод вывод как между приложениями командной строки и получать результат.

Пример вызова команд в Singer выглядят примерно так: tap-exchangeratesapi | target-csv

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

Но используют Singer не только Stitch, его используют многие другие коммерческие и open source решения. Например, Singer лежит в основе Meltano [3] и ещё ряда инструментов. Хотя вот в случае Airbyte, другого инструмент для ETL, его создатели пишут что у Singer много недостатков и поэтому они его не используют [4].

Конечное решение можно принять самостоятельно. Лично я вижу пока ключевым недостатком Singer - в разном качестве вентилей и уровне их поддержки. А также почти полным отсутствием российские сервисов - Яндекс.Метрики, к примеру. Впрочем не факт что эти недостатки затмевают возможности.

Ссылки:
[1] https://www.singer.io/
[2] https://www.stitchdata.com
[3] https://hub.meltano.com/singer/taps/
[4] https://airbyte.com/blog/why-you-should-not-build-your-data-pipeline-on-top-of-singer

#datatools #opensource #datapipelines

В блоге Spotify краткий пост о том как в компании команды переходят на систему управления потоками данных на базе Flyte [1], заменяя на него использовавшиеся ранее системы Luigi [2] и Flo [3]. В отличие от них Flyte [4] создавался с акцентом на задачи ML/Data science и с некоторыми особенностями которые отличают его от других движков.

1. Flyte построен на принципах что конфигурация это код. Вместо файлов YAML задачи описываются в коде на Python
2. Изначально разработан под расширение через код на Python
3. Автоматически отслеживает происхождение данных (data lineage)

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

А для тех кто ещё не определился на каком движке строить управление потоками данных, неплохая подборка в Awesome workflow engines [5]

Ссылки:
[1] https://engineering.atspotify.com/2022/03/why-we-switched-our-data-orchestration-service/
[2] https://github.com/spotify/luigi
[3] https://github.com/spotify/flo
[4] https://flyte.org/
[5] http://meirwah.github.io/awesome-workflow-engines/

#data #datatools #opensource #datapipelines

7 Best Practices for Data Ingestion

Полезная заметка для тех кто занимается сбором и обработкой данных [1]. Автор собрал несколько практик используемых при загрузке данных.

Если кратко их пересказать:
1. Отслеживайте ошибки в первоисточнике (настраивайте предупреждения).
2. Сохраняйте копию первичных данных до преобразования.
3. Заранее устанавливайте сроки и ожидания пользователей. Загрузка данных не так уж проста.
4. Автоматизируйте трубы данных, устанавливайте SLA используйте системы оркестрации.
5. Трубы загрузки данных должны быть идемпотентны (результат их работы должен повторяться)
6. Создавайте шаблоны, используйте их повторно
7. Документируйте Ваши трубы данных.

Всё кажется очень очевидным и ни с чем не поспоришь. Я бы только добавил что 7-й пункт документируйте Ваши трубы данных должен быть 1-м пунктом. Сколько я не сталкиваюсь с продуктами на данных, вокруг данных, связанных с работой с данными и др. все формы data product недостаток документации есть у всех.

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

Ссылки:
[1] https://medium.com/codex/7-best-practices-for-data-ingestion-f336c6b5128c

#data #datapipelines

К вопросу о дата-инженерии и 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