Классическая модель работы с данными предполагает использование 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 – общий термин для всех процессов миграции данных из одного источника в другой (другие связанные с…
Я не так давно писал про ETL выделенную из Datacrafter'а для данных в NoSQL форматах JSONlines и BSON [1]. Это кусок кода отделенный в рамках "техдолга", то что надо было сделать давно и только недавно до этого дошли руки.
Но есть задача для которой точно нет подходящего простого ETL/ELT/data pipeline engine - это как раз цифровая архивация для создания тематических коллекций архивируемых сайтов, аккаунтов в соцсетях и тд.
Задачи по цифровой / веб архивации можно разделить на несколько видов, но в части сбора данных, основных всего два.
Массовый сбор и сфокусированные коллекции.
Массовый сбор - это когда роботы вроде краулеров Archive.org обходят условно неограниченное число цифровых ресурсов и делают слепки и актуализируют ранее собранные материалы.
Сфокусированные коллекции - это когда собирается не всё а по перечню: сайтов, разделов на сайтах, отдельных файлов, каналов в телеграм, аккаунтов в соцсетях и тд.
Для массового сбора есть своя экосистема инструментов, а вот для сфокуированных коллекций категорически нехватает ETL инструментария. Причём скорее ETL чем ELT потому что много двоичных данных которые можно поместить в озеро данных и сложно хранить в хранилище данных.
Логика та что что у классических ELT продуктов.
Извлечение данных с помощью разных инструментов и стратегий, преобразование для долгосрочного сохранения и загрузка в Internet Archive, какое-то постоянное хранилище и ещё куда-то, по необходимости.
Эта логика дополняется ещё одной стадией D - Discovery. Это когда движок получает на вход набор ссылок и на их основе автоматически определяет стратегию в зависимости от типа ресурса. В итоге получается DELT (Discover Extract Transform Load).
Недостаток такого движка в узкой применимости и в больше значимости этапа Extract, поскольку извлечение и сбор данных наиболее длительны и ресурсоёмки.
В принципе развитие дата инженерии давно уже достигло той стадии когда нужны специализированные решения. В основном они сейчас строятся на готовых продуктах, но иногда функций готовых продуктов недостаточно.
#digitalpreservation #etl #dataengineering
Но есть задача для которой точно нет подходящего простого ETL/ELT/data pipeline engine - это как раз цифровая архивация для создания тематических коллекций архивируемых сайтов, аккаунтов в соцсетях и тд.
Задачи по цифровой / веб архивации можно разделить на несколько видов, но в части сбора данных, основных всего два.
Массовый сбор и сфокусированные коллекции.
Массовый сбор - это когда роботы вроде краулеров Archive.org обходят условно неограниченное число цифровых ресурсов и делают слепки и актуализируют ранее собранные материалы.
Сфокусированные коллекции - это когда собирается не всё а по перечню: сайтов, разделов на сайтах, отдельных файлов, каналов в телеграм, аккаунтов в соцсетях и тд.
Для массового сбора есть своя экосистема инструментов, а вот для сфокуированных коллекций категорически нехватает ETL инструментария. Причём скорее ETL чем ELT потому что много двоичных данных которые можно поместить в озеро данных и сложно хранить в хранилище данных.
Логика та что что у классических ELT продуктов.
Извлечение данных с помощью разных инструментов и стратегий, преобразование для долгосрочного сохранения и загрузка в Internet Archive, какое-то постоянное хранилище и ещё куда-то, по необходимости.
Эта логика дополняется ещё одной стадией D - Discovery. Это когда движок получает на вход набор ссылок и на их основе автоматически определяет стратегию в зависимости от типа ресурса. В итоге получается DELT (Discover Extract Transform Load).
Недостаток такого движка в узкой применимости и в больше значимости этапа Extract, поскольку извлечение и сбор данных наиболее длительны и ресурсоёмки.
В принципе развитие дата инженерии давно уже достигло той стадии когда нужны специализированные решения. В основном они сейчас строятся на готовых продуктах, но иногда функций готовых продуктов недостаточно.
#digitalpreservation #etl #dataengineering
Написал заметку про DELT (Discover, Extract, Load, Transform) на английском языке [1] на Medium.
Ссылки:
[1] https://medium.com/@ibegtin/delt-discover-extract-load-transform-are-we-ready-for-etl-for-digital-preservation-ced3a08727a
#datadiscovery #digitalpreservation #etl #data
Ссылки:
[1] https://medium.com/@ibegtin/delt-discover-extract-load-transform-are-we-ready-for-etl-for-digital-preservation-ced3a08727a
#datadiscovery #digitalpreservation #etl #data
Medium
DELT (Discover, Extract, Load, Transform). Are we ready for ETL for digital preservation?
For years I’ve been working on a digital preservation project. Outside of civil and commercial data projects, our team invested much of…
Вышла версия 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.
Для тех кто регулярно пользуется ETL/ELT инструментами, обновился Apache Hop, визуальный ETL движок с большим числом встроенных трансформаций над данными [1]. В новой версии 2.0 осуществили переход на Java 11 и кучу новых плагинов [2].
Лично я не отношу себя к фанатам Hop да и других ETL продуктов из экосистемы Apache, всё таки продукты вроде Meltano, Dagster, Prefect и др. написанные на Python, Go и тд. представляются мне куда более практичными, но для ряда задач инструменты вроде Hop могут быть полезны. Например, когда изначально инфраструктура построена на других продуктах из экосистемы Apache и основной язык разработки Java.
Ссылки:
[1] https://hop.apache.org/
[2] https://hop.apache.org/blog/2022/06/hop-2.0.0/
#datatools #etl #opensource
Лично я не отношу себя к фанатам Hop да и других ETL продуктов из экосистемы Apache, всё таки продукты вроде Meltano, Dagster, Prefect и др. написанные на Python, Go и тд. представляются мне куда более практичными, но для ряда задач инструменты вроде Hop могут быть полезны. Например, когда изначально инфраструктура построена на других продуктах из экосистемы Apache и основной язык разработки Java.
Ссылки:
[1] https://hop.apache.org/
[2] https://hop.apache.org/blog/2022/06/hop-2.0.0/
#datatools #etl #opensource
hop.apache.org
Apache Hop
Apache Hop - The Hop Orchestration Platform aims to facilitate all aspects of data and metadata orchestration.
В рубрике интересных продуктов для работы с данными SteamPipe. Это фреймворк для доступа к более чем 200+ источникам данных через SQL запросы [1].
Идея проста - любые данные должны иметь SQL интерфейс для этого у StreamPipe 78 плагинов [2] для доступа к большинству известных СУБД и к разного рода онлайн сервисам и протоколам.
Например, доступ к почтовому ящику IMAP через SQL [3] или доступ к сетевой информации сертификатов, доменов, IP адресов через SQL [4].
Сама идея подкупает своей универсальностью и реализация вполне рабочая. Скорее всего там есть существенные ограничения в работе с рядом иерархических данных, но, с другой стороны преимущества универсального доступа велики.
Проект написан на Go командой стартапа Turbot [5], доступен с открытым кодом и активно развивается [7].
Проект должен хорошо вписываться в любой ELT/ETL инструмент и стоит ожидать новых ETL продуктов на Go с его поддержкой.
Ссылки:
[1] https://steampipe.io/
[2] https://hub.steampipe.io/plugins
[3] https://hub.steampipe.io/plugins/turbot/imap
[4] https://hub.steampipe.io/plugins/turbot/net
[5] https://turbot.com/
[6] https://github.com/turbot/steampipe
#opensource #datatools #etl
Идея проста - любые данные должны иметь SQL интерфейс для этого у StreamPipe 78 плагинов [2] для доступа к большинству известных СУБД и к разного рода онлайн сервисам и протоколам.
Например, доступ к почтовому ящику IMAP через SQL [3] или доступ к сетевой информации сертификатов, доменов, IP адресов через SQL [4].
Сама идея подкупает своей универсальностью и реализация вполне рабочая. Скорее всего там есть существенные ограничения в работе с рядом иерархических данных, но, с другой стороны преимущества универсального доступа велики.
Проект написан на Go командой стартапа Turbot [5], доступен с открытым кодом и активно развивается [7].
Проект должен хорошо вписываться в любой ELT/ETL инструмент и стоит ожидать новых ETL продуктов на Go с его поддержкой.
Ссылки:
[1] https://steampipe.io/
[2] https://hub.steampipe.io/plugins
[3] https://hub.steampipe.io/plugins/turbot/imap
[4] https://hub.steampipe.io/plugins/turbot/net
[5] https://turbot.com/
[6] https://github.com/turbot/steampipe
#opensource #datatools #etl
Steampipe
Steampipe | select * from cloud;
Steampipe is an open source tool to instantly query your cloud services (e.g. AWS, Azure, GCP and more) with SQL. No DB required.
Полезное чтение про данные, технологии и не только։
- NormConf: Selected talks and lessons learned [1] в блоге Prefect про конференцию Normconf и избранные выступления про машинное обучение. Там же ссылки на все выступления и, в принципе, интересная конференция с разными докладами про данные и ML
- List of AI and ML Conferences in 2023 [2] большая подборка конференций по ИИ и машинному обучению в 2023 году. Большая часть в США и Европе, несколько в Восточной Азии.
- Uber’s Facial Recognition Is Locking Indian Drivers Out of Their Accounts [3] о том как алгоритмы блокировали доступ водителей в Индии к их аккаунтам в Uber из-за невозможности их идентифицировать после изменения стрижки, к примеру. Обзор влияния применения распознавания по лицам для "gig workers" (курьеров, водителей и иных схожих уберизированных профессий).
- Updating dbt Cloud pricing to support long-term community growth [4] команда продукта dbt обновила его ценовую модель, как бы красиво они не подавали изменения в ценах, в реальности для небольших команд цена вырастает в 100%, если пользоваться их онлайн облаком и IDE. Это важно поскольку dbt превратился в один из ключевых инфраструктурных проектов в современных стеках работы с данными.
- A Zero ETL Future [5] о будущем ETL продуктов и о том что вероятна весьма скорая их замена владельцами крупнейших онлайн хранилищ. Об этом давно идут разговоры, что если Snowflake и AWS добавят ETL функции в их продукты, то весь рынок облачных ETL быстро развалится.
- Daath AI Parser [6] необычный парсер HTML который на вход получает HTML код и с помощью OpenAI разбирает видимые элементы и возвращает данные. Я уже думал о подобной штуке, а тут автор напрямую начал её реализовывать. Для многих задач у неё хороший потенциал.
Ссылки։
[1] https://medium.com/the-prefect-blog/what-i-learned-from-normconf-2022-f8b3c88f0de7
[2] https://tryolabs.com/blog/machine-learning-deep-learning-conferences
[3] https://pulitzercenter.org/stories/ubers-facial-recognition-locking-indian-drivers-out-their-accounts
[4] https://www.getdbt.com/blog/dbt-cloud-package-update/
[5] https://seattledataguy.substack.com/p/a-zero-etl-future
[6] https://github.com/kagermanov27/daath-ai-parser
#opensource #ai #machinelearning #dbt #dataengineering #etl
- NormConf: Selected talks and lessons learned [1] в блоге Prefect про конференцию Normconf и избранные выступления про машинное обучение. Там же ссылки на все выступления и, в принципе, интересная конференция с разными докладами про данные и ML
- List of AI and ML Conferences in 2023 [2] большая подборка конференций по ИИ и машинному обучению в 2023 году. Большая часть в США и Европе, несколько в Восточной Азии.
- Uber’s Facial Recognition Is Locking Indian Drivers Out of Their Accounts [3] о том как алгоритмы блокировали доступ водителей в Индии к их аккаунтам в Uber из-за невозможности их идентифицировать после изменения стрижки, к примеру. Обзор влияния применения распознавания по лицам для "gig workers" (курьеров, водителей и иных схожих уберизированных профессий).
- Updating dbt Cloud pricing to support long-term community growth [4] команда продукта dbt обновила его ценовую модель, как бы красиво они не подавали изменения в ценах, в реальности для небольших команд цена вырастает в 100%, если пользоваться их онлайн облаком и IDE. Это важно поскольку dbt превратился в один из ключевых инфраструктурных проектов в современных стеках работы с данными.
- A Zero ETL Future [5] о будущем ETL продуктов и о том что вероятна весьма скорая их замена владельцами крупнейших онлайн хранилищ. Об этом давно идут разговоры, что если Snowflake и AWS добавят ETL функции в их продукты, то весь рынок облачных ETL быстро развалится.
- Daath AI Parser [6] необычный парсер HTML который на вход получает HTML код и с помощью OpenAI разбирает видимые элементы и возвращает данные. Я уже думал о подобной штуке, а тут автор напрямую начал её реализовывать. Для многих задач у неё хороший потенциал.
Ссылки։
[1] https://medium.com/the-prefect-blog/what-i-learned-from-normconf-2022-f8b3c88f0de7
[2] https://tryolabs.com/blog/machine-learning-deep-learning-conferences
[3] https://pulitzercenter.org/stories/ubers-facial-recognition-locking-indian-drivers-out-their-accounts
[4] https://www.getdbt.com/blog/dbt-cloud-package-update/
[5] https://seattledataguy.substack.com/p/a-zero-etl-future
[6] https://github.com/kagermanov27/daath-ai-parser
#opensource #ai #machinelearning #dbt #dataengineering #etl
Medium
What I learned from NormConf 2022
Summary of selected talks and lessons learned
Open Data Fabric - открытый протокол/спецификации по обработке данных с использованием Web 3.0 и умных контрактов. Малоизвестно широкой публике и большинству дата-инженеров, разработано компанией Kamu в 2020 г. [1] как часть их платформы по работе с корпоративными данными в среде распределённых реестров. Любопытно детальностью проработки спецификации, наличием инструмента для работы и то что продукт и спецификация развиваются. За пределами экосистем вокруг блокчейна всё это выглядит экзотикой, особенно обработка данных на IPFS, всё это далеко от Modern Data Stack, но внимания всё же стоит, тут могут быть интересные идеи как минимум.
Поэтому из плюсов - хорошо проработанная спецификация. Из минусов - абсолютная ориентация на плоские простые таблицы и схемы и SQL для реконструкции наборов данных. Никакие иные данные кроме табличных не рассматриваются.
И туда же ещё ряд похожих проектов։
- Holium [2] - движок по обработке данных поверх IPFS
- Bacalhau [3] платформа для выполнения задач по обработке данных поверх IPFS по модели Compute Over Data [4]
Про Compute Over Data отдельный разговор, это явление из Protocol Labs почти полностью закольцованное на экосистему Web 3.0, блокчейна и тд. Лично я не видел до сих пор ни одного применения продуктов из этой среды коммерческими компаниями за пределами мира "крипты" что доверия им не добавляет.
Но, возвращаясь к спецификации и Open Data Fabric, сама по себе она может быть интересной.
Ссылки։
[1] https://docs.kamu.dev/odf/
[2] https://docs.holium.org/
[3] https://docs.bacalhau.org/
[4] https://www.cod.cloud/
#openprotocols #openspecifications #data #etl
Поэтому из плюсов - хорошо проработанная спецификация. Из минусов - абсолютная ориентация на плоские простые таблицы и схемы и SQL для реконструкции наборов данных. Никакие иные данные кроме табличных не рассматриваются.
И туда же ещё ряд похожих проектов։
- Holium [2] - движок по обработке данных поверх IPFS
- Bacalhau [3] платформа для выполнения задач по обработке данных поверх IPFS по модели Compute Over Data [4]
Про Compute Over Data отдельный разговор, это явление из Protocol Labs почти полностью закольцованное на экосистему Web 3.0, блокчейна и тд. Лично я не видел до сих пор ни одного применения продуктов из этой среды коммерческими компаниями за пределами мира "крипты" что доверия им не добавляет.
Но, возвращаясь к спецификации и Open Data Fabric, сама по себе она может быть интересной.
Ссылки։
[1] https://docs.kamu.dev/odf/
[2] https://docs.holium.org/
[3] https://docs.bacalhau.org/
[4] https://www.cod.cloud/
#openprotocols #openspecifications #data #etl
Команда 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
В рубрике полезного чтения про данные, технологии и не только:
- Zero ELT could be the death of the Modern Data Stack [1] о том как вендоры крупнейших SaaS платформ могут в короткий срок убить всю экосистему Modern Data Stack реализовав достаточно простые инструмент для загрузки данных. Zero ETL - это, по сути, "убиение" ETL, например, в этот подход склоняются Amazon и Snowflake. Вообще процесс можно описать таким образом. Вначале появляется потребность в работе с данными в облачных сервисах, в первую очередь эта потребность у тех кто и так держит данные в облаках и многочисленными провайдерами разных сервисов, вроде платежных, и вынужден объединять данные. Потом появляются нишевые стартапы хорошо решающие конкретные задачи автоматизации работы с данными (всё как по учебнику), такие как Fivetran, Dbt, Hightouch и другие. Они оказываются основой Modern data stack, объединяющего понятия хорошо интегрированных сервисов работы с данными и, наконец, оказывается что клиентам управление сложностью возникшей конфигурации может быть более затратно, чем более простые инструменты, но интегрированные в платформу базового провайдера. Поэтому Zero ETL действительно имеет хорошие перспективы.
- We need to talk about Excel [2] автор и критикует и хвалит Excel и приводит в пример несколько стартапов которые не то чтобы его заменяют, но дают некоторые близкие возможности, при этом самому Excel как продукту до сих пор замены нет. Размышления вполне структурированы и аргументированы. Я лично когда думал про Excel понял что для меня всегда главной нелюбовью к нему был язык VBA. При том что когда-то, много лет назад, я на нём даже мог писать сложные макросы и отлаживать непростой код, тем не менее он до сих пор ощущается как крайне неудобный. Будь в MS Excel нативная поддержка, например, Python. Может быть когда-нибудь Microsoft поглотит PyXLL [3] и такая поддержка появится.
- Polars – Laziness and SQL Context. [4] автор пишет о том что Polars это не только более производительный инструмент для аналитики чем Pandas, но и обладает несколькими полезными функциями такими как ленивая загрузка файлов позволяющая обрабатывать файлы размером больше чем объём памяти и SQL контекст с помощью которого можно делать SQL запросы, например, к таким лениво загруженным файлам. Возможности полезные когда работаешь с данными относительно большого объёма.
Ссылки:
[1] https://medium.com/@hugolu87/zero-elt-could-be-the-death-of-the-modern-data-stack-cfdd56c9246d
[2] https://davidsj.substack.com/p/we-need-to-talk-about-excel
[3] https://www.pyxll.com
[4] https://www.confessionsofadataguy.com/polars-laziness-and-sql-context/
#data #datatools #readings #etl
- Zero ELT could be the death of the Modern Data Stack [1] о том как вендоры крупнейших SaaS платформ могут в короткий срок убить всю экосистему Modern Data Stack реализовав достаточно простые инструмент для загрузки данных. Zero ETL - это, по сути, "убиение" ETL, например, в этот подход склоняются Amazon и Snowflake. Вообще процесс можно описать таким образом. Вначале появляется потребность в работе с данными в облачных сервисах, в первую очередь эта потребность у тех кто и так держит данные в облаках и многочисленными провайдерами разных сервисов, вроде платежных, и вынужден объединять данные. Потом появляются нишевые стартапы хорошо решающие конкретные задачи автоматизации работы с данными (всё как по учебнику), такие как Fivetran, Dbt, Hightouch и другие. Они оказываются основой Modern data stack, объединяющего понятия хорошо интегрированных сервисов работы с данными и, наконец, оказывается что клиентам управление сложностью возникшей конфигурации может быть более затратно, чем более простые инструменты, но интегрированные в платформу базового провайдера. Поэтому Zero ETL действительно имеет хорошие перспективы.
- We need to talk about Excel [2] автор и критикует и хвалит Excel и приводит в пример несколько стартапов которые не то чтобы его заменяют, но дают некоторые близкие возможности, при этом самому Excel как продукту до сих пор замены нет. Размышления вполне структурированы и аргументированы. Я лично когда думал про Excel понял что для меня всегда главной нелюбовью к нему был язык VBA. При том что когда-то, много лет назад, я на нём даже мог писать сложные макросы и отлаживать непростой код, тем не менее он до сих пор ощущается как крайне неудобный. Будь в MS Excel нативная поддержка, например, Python. Может быть когда-нибудь Microsoft поглотит PyXLL [3] и такая поддержка появится.
- Polars – Laziness and SQL Context. [4] автор пишет о том что Polars это не только более производительный инструмент для аналитики чем Pandas, но и обладает несколькими полезными функциями такими как ленивая загрузка файлов позволяющая обрабатывать файлы размером больше чем объём памяти и SQL контекст с помощью которого можно делать SQL запросы, например, к таким лениво загруженным файлам. Возможности полезные когда работаешь с данными относительно большого объёма.
Ссылки:
[1] https://medium.com/@hugolu87/zero-elt-could-be-the-death-of-the-modern-data-stack-cfdd56c9246d
[2] https://davidsj.substack.com/p/we-need-to-talk-about-excel
[3] https://www.pyxll.com
[4] https://www.confessionsofadataguy.com/polars-laziness-and-sql-context/
#data #datatools #readings #etl
Medium
Zero ELT could be the death of the Modern Data Stack
Zero-ELT is getting a fair bit of press at the moment despite the fact that, as data professionals, we probably don’t do a lot of it. In…