Классическая модель работы с данными предполагает использование 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