Очень часто приходится слышать термины Data Warehouse, Data Lake, Data Hub, при этом часто произносящие их не задумываются о реальных отличиях этих понятий. В блоге The Startup на Medium хороший обзор на английском [1] об отличии и сходствах таких понятий как:
- Data Lake
- Data Hub
- Data Virtualization / Data Federation
- Data Warehouse
- Operational Data Store

Все отличия объяснены на редкость доходчиво, я как-нибудь найду время перевести этот текст на русский язык.
Краткий ликбез такой:
- Data Lake (Озеро данных) - это несвязанные данные удобные для data science и аналитической работы. Работает в ситуации возникновения задач и адаптации данных под конкретные задачи.

- Data Hub - это данные собранные в одно хранилище с некоторой работой по преобразованию и обработке. Больше форматирования, контроля и управления по сравнениею с озером данных.

- Data Virtualization/Data Federation - это пробрасывание виртуальных связей между источниками, иногда уже начало ведение общих справочников. Больше ориентировано на данные реального времени и интеграцию

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

- Operational Data Store - это, как правила, зеркала для хранения транзакционных баз данных чтобы не затрагивать сами базы данных работающих в режиме реального времени.

Ссылки:
[1] https://medium.com/swlh/the-5-data-store-patterns-data-lakes-data-hubs-data-virtualization-data-federation-data-27fd75486e2c

#opendata #data #datalakes #datamanagement #datagovernance

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

За время коронавируса появляются новые отраслевые озёра данных (data lakes) для исследователей, многие с коммерческим уклоном. Например, CVID data lake [1] в рамках продукта Cortelis Research Intelligence от Clarivate [2] аналитического агентства с широким спектром продуктов для исследователей. Они анонсировали это облако, буквально, 5 дней назад, 20 августа [3] и, пока, без подробностей того что находится внутри него.

Существует и другое, бесплатное озеро данных, C3.ai COVID-19 Data Lake [4] от C3.ai соответственно. Подробностей чуть больше, есть демо и описание доступа к озеру через REST API с примерами в Jupiter Notebook и других научных записных книжках. О них была заметка в Forbes [5] ещё в мае 2020 года.

Чуть более простое и, также, бесплатное озеро данных по COVID-19 есть в Amazon AWS [6], включая базы данных и наборы данных особенно большого размера. Например, CORD19 [7], база исследований по коронавирусу для которой на базе AWS существует, в том числе, поисковик cord19.aws [8]

Несколько меньшее по объёму озеро данных есть и в облаке Microsoft Azure [9].

Озера данных это не единственный способ работы исследователей с данными связанными с коронавирусом. Офис стратегии по науке работы с данными при National Institutes of Health в США ведет реестр открытых (open access) ресурсов для исследователей [10] работающих с данных.

В целом складывается ощущение что формирование озер данных в отраслевом применении становится трендом и, в зависимости от выбранной стратегии, здесь большую роль могут сыграть крупнейшие игроки облачных сервисов. Фактически, постепенное развитие Azure Open Datasets, Google BigQuery и Open Data on AWS и показывает что большие общедоступные наборы данных - это хорошая приманка для пользователей облачных сервисов. Некоторые наборы и базы данных давно существуют, только, в облаках. Например, база поискового индекса Commoncrawl существует по умолчанию на Amazon AWS [11]

Для этого у Amazon есть Open Data Sponsorship program [12], у Microsoft есть Open Data Initiative [13], у Google нет отдельной программы, но есть рассказ о том как они работают над открытостью кода и данных [14]

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

Ссылки:
[1] https://clarivate.com/cortellis/solutions/cvid-data-lake/
[2] https://en.wikipedia.org/wiki/Clarivate
[3] https://finance.yahoo.com/news/clarivate-launches-coronavirus-virology-infectious-140300688.html
[4] https://c3.ai/products/c3-ai-covid-19-data-lake/
[5] https://www.forbes.com/sites/adrianbridgwater/2020/05/27/tom-siebels-c3ai-charts-new-data-lake-for-covid-19-research/
[6] https://aws.amazon.com/ru/covid-19-data-lake/
[7] https://www.semanticscholar.org/cord19
[8] https://cord19.aws
[9] https://azure.microsoft.com/ru-ru/services/open-datasets/catalog/covid-19-data-lake/
[10] https://datascience.nih.gov/covid-19-open-access-resources
[11] https://registry.opendata.aws/commoncrawl/
[12] https://aws.amazon.com/ru/opendata/open-data-sponsorship-program/
[13] https://www.microsoft.com/en-us/open-data-initiative
[14] https://www.blog.google/technology/research/open-source-and-open-data/

#datalakes #data #opendata #covid19 #research

Хороший обзор платформы данных в Financial Times [1] вернее продолжение предыдущей их же публикации от мая 2020 г. [2] о том как внутри издания построена полноценная платформа сбора данных, с озером данных, обработкой, разными командами загружающими и обрабатывающими данные. Интересно не только с точки зрения технологий, но и с точки зрения погружения в data-driven культуру современных зарабатывающих медиа. Не знаю с какими российскими проектами можно было бы сравнить FT.com, но кто знает, может однажды спрос на полноценную инфраструктуру данных появится и в российских СМИ.

Ссылки:
[1] https://medium.com/ft-product-technology/financial-times-data-platform-from-zero-to-hero-143156bffb1d
[2] https://medium.com/ft-product-technology/enabling-data-driven-decisions-564359b79788

#data #dataplatforms #datalakes #media