Классическая модель работы с данными предполагает использование ETL инструментов где ETL - это Extract, Transform, Load [1], комплексный процесс описанный ещё в 70-е годы 20-го столетия исходящий из данные последовательно извлекаются, преобразуются и далее уже только загружаются в очищенном/преобразованном виде в базу данных, как правило, являющуюся часть хранилища данных (Data Warehouse) и используемую для аналитических расчётов, систем BI и так далее.
ETL инструментов существует бессчетное количество, как в поставке вместе с движками баз данных крупнейшими вендорами, так и как самостоятельные продукты. Главным достоинством ETL всегда было то же что является его же главным недостатком - необходимость тщательного проектирования, понимания итогового результата что требовало, зачастую, довольно кропотливой подготовительной работы. Другой недостаток в том что в случае ETL из-за стадии преобразования время загрузки данных всегда было значительным. Это затрудняло работу с потоками данных.
Важное изменение в последние годы - это появление нового подхода, ELT. ELT - это Extract, Load and Transform [2], модель построенная на потоковой обработке данных и замену стадий L и T. При ELT данные вначале извлекаются, но ещё до их обработки они загружаются в финальное хранилище и уже инструментами предоставляемыми этим хранилищем они обрабатываются и превращаются очищенные/обработанные данные. Преобразование может производится самыми разными способами, от процедур в SQL, до внешних инструментов по преобразованию данных (data wrangling) и специализированных платформ.
Такой подход резко сокращает время загрузки данных и даёт возможность создавать на базе собранных первичных данных разные итоговые продукты, это могут быть:
- базы для аналитической работы и BI
- базы эталонных (золотых) записей
- срезы данных для использования в data science
и иные продукты.
При этом, для ELT хранилище данных - это не обязательно data warehouse с тщательно прописанными метаданными и тд. Зачастую это озёра данных с куда как менее тщательными требованиями по интеграции данных между собой.
Это не значит что у ELT нет недостатков.
Как минимум можно говорить о том ELT:
1. Требует хранения большего объёма первичных данных.
2. Требует значительных процессорных мощностей в хранилище необходимых для обработки данных.
3. Требует значительного более внимательного отношения к персональным и чувствительным данным, потому что в ETL процессе они, как правило, вычищаются на стадии трансформации и не попадают в целевую систему. А в ELT данные уже в системе и на неё накладываются ограничения связанные с обработкой данных и их хранением в определённой юрисдикции.
Подход ELT активно пропагандируется и продвигается облачными сервисами, что и понятно, они обеспечивают практически неограниченные аппаратные возможности, для хранения и обработки данных, зависящие только от бюджета тех кто обрабатывает на них свои данные.
ELT неразрывно связано с концепцией data pipelines и его отличия подробно разобраны во многих источниках компаний создающие свои продукты по этой концепции:
- блог XPlenty [3]
- блог Panoply [4]
- блог Talend [5]
- блог OpenBridge [6]
- блог DataForm [7]
Спросить чем отличаются ELT от ETL или попросить привести в пример несколько продуктов обоего типа - это хорошие вопросы на собеседовании инженера по работе с данными (дата инженера). ELT применимо не для всех задач, но уже настолько распространено, что нельзя не знать о том что это такое и как устроено.
Ссылки:
[1] https://ru.wikipedia.org/wiki/ETL
[2] https://en.wikipedia.org/wiki/Extract,_load,_transform
[3] https://www.xplenty.com/blog/etl-vs-elt/
[4] https://blog.panoply.io/etl-vs-elt-the-difference-is-in-the-how
[5] https://www.talend.com/resources/elt-vs-etl/
[6] https://blog.openbridge.com/etl-tools-elt-vs-etl-process-89bb1f71c7b3
[7] https://dataform.co/blog/etl-vs-elt
#etl #elt #data #datalakes #datawarehouse
ETL инструментов существует бессчетное количество, как в поставке вместе с движками баз данных крупнейшими вендорами, так и как самостоятельные продукты. Главным достоинством ETL всегда было то же что является его же главным недостатком - необходимость тщательного проектирования, понимания итогового результата что требовало, зачастую, довольно кропотливой подготовительной работы. Другой недостаток в том что в случае ETL из-за стадии преобразования время загрузки данных всегда было значительным. Это затрудняло работу с потоками данных.
Важное изменение в последние годы - это появление нового подхода, ELT. ELT - это Extract, Load and Transform [2], модель построенная на потоковой обработке данных и замену стадий L и T. При ELT данные вначале извлекаются, но ещё до их обработки они загружаются в финальное хранилище и уже инструментами предоставляемыми этим хранилищем они обрабатываются и превращаются очищенные/обработанные данные. Преобразование может производится самыми разными способами, от процедур в SQL, до внешних инструментов по преобразованию данных (data wrangling) и специализированных платформ.
Такой подход резко сокращает время загрузки данных и даёт возможность создавать на базе собранных первичных данных разные итоговые продукты, это могут быть:
- базы для аналитической работы и BI
- базы эталонных (золотых) записей
- срезы данных для использования в data science
и иные продукты.
При этом, для ELT хранилище данных - это не обязательно data warehouse с тщательно прописанными метаданными и тд. Зачастую это озёра данных с куда как менее тщательными требованиями по интеграции данных между собой.
Это не значит что у ELT нет недостатков.
Как минимум можно говорить о том ELT:
1. Требует хранения большего объёма первичных данных.
2. Требует значительных процессорных мощностей в хранилище необходимых для обработки данных.
3. Требует значительного более внимательного отношения к персональным и чувствительным данным, потому что в ETL процессе они, как правило, вычищаются на стадии трансформации и не попадают в целевую систему. А в ELT данные уже в системе и на неё накладываются ограничения связанные с обработкой данных и их хранением в определённой юрисдикции.
Подход ELT активно пропагандируется и продвигается облачными сервисами, что и понятно, они обеспечивают практически неограниченные аппаратные возможности, для хранения и обработки данных, зависящие только от бюджета тех кто обрабатывает на них свои данные.
ELT неразрывно связано с концепцией data pipelines и его отличия подробно разобраны во многих источниках компаний создающие свои продукты по этой концепции:
- блог XPlenty [3]
- блог Panoply [4]
- блог Talend [5]
- блог OpenBridge [6]
- блог DataForm [7]
Спросить чем отличаются ELT от ETL или попросить привести в пример несколько продуктов обоего типа - это хорошие вопросы на собеседовании инженера по работе с данными (дата инженера). ELT применимо не для всех задач, но уже настолько распространено, что нельзя не знать о том что это такое и как устроено.
Ссылки:
[1] https://ru.wikipedia.org/wiki/ETL
[2] https://en.wikipedia.org/wiki/Extract,_load,_transform
[3] https://www.xplenty.com/blog/etl-vs-elt/
[4] https://blog.panoply.io/etl-vs-elt-the-difference-is-in-the-how
[5] https://www.talend.com/resources/elt-vs-etl/
[6] https://blog.openbridge.com/etl-tools-elt-vs-etl-process-89bb1f71c7b3
[7] https://dataform.co/blog/etl-vs-elt
#etl #elt #data #datalakes #datawarehouse
Wikipedia
ETL
ETL (от англ. Extract, Transform, Load — дословно «извлечение, преобразование, загрузка») — один из основных процессов в управлении хранилищами данных, ETL – общий термин для всех процессов миграции данных из одного источника в другой (другие связанные с…
Вышла версия 2.0 Meltano [1] ELT движка интегрированного в Modern Data Stack, все изменения как раз про эту интеграцию. В частности там поддерживается:
- dbt для трансформации данных
- Great Expectations для качества данных
- Airflow для управления потоками данных
- Superset для аналитики
И ещё много чего. На поляне ELT у Meltano сейчас возможно наилучший потенциал, растущее сообщество и хорошее развитие продукта. Если думать с каким ELT движком интегрировать свои продукты то Meltano - это хороший вариант.
Ссылки:
[1] https://meltano.com/blog/meet-meltano-2-0/
#opensource #datatools #etl #elt #moderndatastack
- dbt для трансформации данных
- Great Expectations для качества данных
- Airflow для управления потоками данных
- Superset для аналитики
И ещё много чего. На поляне ELT у Meltano сейчас возможно наилучший потенциал, растущее сообщество и хорошее развитие продукта. Если думать с каким ELT движком интегрировать свои продукты то Meltano - это хороший вариант.
Ссылки:
[1] https://meltano.com/blog/meet-meltano-2-0/
#opensource #datatools #etl #elt #moderndatastack
Meltano
Meet Meltano 2.0: Your End-to-end, Open Source DataOps Platform Infrastructure | Meltano
Meltano 2.0 represents a major step toward our vision of becoming the foundation of every team’s ideal data stack.
Команда Meltano, ETL/ELT продукта вышедшего из инженерной команды Gitlab, преданонсировали запуск Meltano Cloud [1], облачной версии их продукта, пока без цен, что чуть ли не самое важное, так что ждём.
А также они полностью обновили интерфейс хаба коннекторов Meltano Hub [2] где можно подобрать коннектор для специфичных сервисов и подключить его в свой экземпляр Meltano.
Облачные продукты на базе open source довольно распространены, это чуть ли не основная бизнес модель сейчас для новых СУБД и инфраструктурных продуктов. В этом смысле Meltano один из продуктов за которыми я давно слежу, от активного использования их ETL лично меня сдерживают те же ограничения что у большинства ETL/ELT продуктов - это ориентация на модель SQL-only и преимущественно на работу с плоскими таблицами. Не для всех задач с которыми лично я сталкиваюсь это годится.
В остальном, Meltano один из продуктов и стартапов по работе с данными за которыми я лично наблюдаю. Как-нибудь сделаю список из всех о которых я писал и за которыми слежу. Они преимущественно с открытым кодом, таких дата продуктов немало.
Ссылки:
[1] https://meltano.com/cloud/
[2] https://hub.meltano.com/
#opensource #etl #startups #data #elt
А также они полностью обновили интерфейс хаба коннекторов Meltano Hub [2] где можно подобрать коннектор для специфичных сервисов и подключить его в свой экземпляр Meltano.
Облачные продукты на базе open source довольно распространены, это чуть ли не основная бизнес модель сейчас для новых СУБД и инфраструктурных продуктов. В этом смысле Meltano один из продуктов за которыми я давно слежу, от активного использования их ETL лично меня сдерживают те же ограничения что у большинства ETL/ELT продуктов - это ориентация на модель SQL-only и преимущественно на работу с плоскими таблицами. Не для всех задач с которыми лично я сталкиваюсь это годится.
В остальном, Meltano один из продуктов и стартапов по работе с данными за которыми я лично наблюдаю. Как-нибудь сделаю список из всех о которых я писал и за которыми слежу. Они преимущественно с открытым кодом, таких дата продуктов немало.
Ссылки:
[1] https://meltano.com/cloud/
[2] https://hub.meltano.com/
#opensource #etl #startups #data #elt
arch.dev
Arch: the bridge between your customers' data & your code
Arch is the bridge between your customers' data & your code. Stop wasting time on your own OAuth flows, API integrations, and embeddings pipelines. Instantly access all your customers’ data sources; raw, mapped, or as vector embeddings
К вопросу о дата-инженерии и 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
И здесь не последнюю роль играет выбор итогового технического стека который, в свою очередь, ограничен спецификой проекта, данных, их источников и тд.
Вот некоторые важные особенности:
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