Преимущества Hybrid Data Lake. Как сочетать Data Warehouse с Data Lake

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Привет! Я — Илья Кальченко, Data Engineer в NIX, фанат обработки данных больших и маленьких, поклонник Python. В этой статье я расскажу о преимуществах Hybrid data lakes для эффективной и безопасной организации данных.

Для начала предлагаю разобраться с понятиями Data Warehouses и Data Lake, покопаться в юз кейсах и разграничить зоны ответственности.

Data Warehouse

Это корпоративные хранилища обработанных и готовых «‎к употреблению» данных. DWH характерны несколько свойств классических реляционных баз данных:

  • структурированные данные;
  • схема определена заранее (schema-on-write);
  • SQL (иногда могут быть исключения).

Несмотря на то, что DWH обладают похожими с базами данных характеристиками, таковыми они не являются. Главное различие проявляется, когда необходимо подготовить аналитику на основе большой выборки данных. Data Warehouses хранят операционные и транзакционные данные оптимизированных для агрегации и извлечения больших массивов данных. Именно такие хранилища используют для выполнения подобного рода задач.

Хранилища данных зачастую следуют OLAP принципам — OnLine Analytical Processing. У этого подхода есть свои особенности в отличии от OLTP — OnLine Transaction Processing, а именно:

  • скорость выполнения аналитических запросов на больших объемах данных выше;
  • запросы сложные с использованием агрегаций;
  • данные часто денормализованы;
  • данные организованы в виде схем "‎звезды"(start) или "снежинки«(snowflake).

При использовании хранилищ данных чаще выбирают ETL подход (Extract, Transform, Load) для получения определенной информации. Например, для загрузки данных из продакшен БД, преобразования их в удобный формат и выгрузке в DWH. Это типичный сценарий в проектах Business Intelligence.

Основными источниками для DWH являются операционные БД и транзакционные системы. Самые популярные системы хранилища данных:

  • Amazon Redshift;
  • Snowflake;
  • Google BigQuery;
  • IBM DB2;
  • Azure Synapse Analytics.

Data Lake

Это хранилища «‎сырых» данных в масштабах компании. Нет четких правил построения таких хранилищ. Выделим их основные характеристики:

  • схема определяется при чтении (schema-on-read);
  • наличие «сырых‎» данных;
  • NoSQL;
  • структурированные и неструктурированные данные.

В такие хранилища данные в основном попадают в своем первоначальном виде, то есть этап трансформации не обязательный. В этом случае используется подход EL(T). Затем эти данные возьмут Data Scientists для создания моделей, Data Engineers — для построения DWH и Data Analysts — для поиска инсайтов и прогнозирования развития бизнеса.

Типичными решениями для формирования Data Lake являются:

  • Amazon S3;
  • Google Cloud Storage;
  • Apache Hadoop HDFS.

Hybrid Data Lake

Это и есть объединение Data Lake и Data Warehouse в единую систему. Такое решение должно покрывать все потребности компании в хранении данных и быстрого доступа к ним стейкхолдеров. Типичный workflow для Hybrid Data Lake представлен на схеме:

Данные из нескольких источников загружаются, выгружаются в Data Lake и при необходимости меняются. Из этой среды данные берут Data Scientists и Data Analysts. Специалисты используют их для решения аналитических задач и в тасках, связанных с machine learning. Возможен и другой путь: когда данные загружают, преобразуют и выгружают в хранилище для построения Data Marts. На этом этапе данные пригодятся BI Developers при создании дашбордов.

В качестве примера по этой схеме можем использовать такие технологии:

  • как источники данных — PostgreSQL, S3, Google Analytics;
  • для процессов ELT и ETL — AWS Glue, Google Dataflow, talend, Pantaho;
  • как Data Lake — S3, HDFS, GCS;
  • в качестве DWH — Snowflake, Amazon Redshift или Google BigQuery.

Рассмотрим пользу Hybrid Data Lake на примере Amazon Web Services.

AWS предоставляет большое количество сервисов, ориентированных на обработку и хранение данных. Как организовать Data Lake на платформе AWS? В качестве источников данных выступают независимые от вендора хранилища, например:

  • PostgreSQL;
  • MongoDB;
  • Events in json format.

Далее нужно эти данные переправить в наш Data Lake. В нашем случае — это S3. Переправлять будем с помощью AWS DMS (Database Migration Service) для БД и AWS Kinesis для потока событий. Как только данные попали в Data Lake, их могут использовать специалисты. Затем с помощью AWS Glue загружаем необходимые данные, обрабатываем и сохраняем их в заранее настроенном Redshift. Теперь информация доступна всей компании в организованном формате и подходит как для аналитики и ML, так и для BI.

Это классический пример. Конечный набор сервисов/инструментов скорее всего определит выбранная вами платформа.

Поскольку объем данных во всех организациях продолжает расти, важно постараться оптимизировать расходы на их хранение. Локальная инфраструктура часто подвергается большой нагрузке. В результате увеличивается ее общая стоимость. Если данные будут хранится в дешевом и быстром на запись Data Lake, а часть данных для аналитики — в производительном и надежном DWH, вы сможете получить лучшее из обоих вариантов и всегда будете готовы к неожиданным рабочим нагрузкам.

Hybrid data lake не является чем-то кардинально новым. Это удачное совмещение двух давно известных и привычных Data-инженерам «‎сущностей» в одном флаконе. Такое решение позволяет хранить все корпоративные исторические данные в общей системе и по необходимости получать их для выполнения аналитических, ML и любых других задач, связанных с данными.

Лично я убедился на практике, что именно объединяя эти технологии, вы устраняете их недостатки и получаете весомое преимущество в виде поддержки системы одной командой. Выберете ли в своем проекте Hybrid data lake или воспользуетесь Data Warehouses и Data Lake по отдельности зависит от требований ваших конечных пользователей и данных, которые вы собираете. Но все же сочетание этих архитектур может стать хорошим опытом для вас и оптимальный решением для организации всей информации в одной системе крупной компании. Ваша команда сможет поддерживать и улучшать все, что связано с данными. По сути это один из самых грамотных подходов к организации данных.

👍НравитсяПонравилось2
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Очень много ошибок и неточностей как в описании стека технологий так и просто описании софта. А так ничо. Задумался может и мне книгу написать. ?

Ну и еще на последок. работать в облаке с таким это каждый могет. Даешь реализацию на бер метал)))

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

Самые популярные системы хранилища данных:
Amazon Redshift;
Snowflake;
Google BigQuery;
IBM DB2;
Azure Synapse Analytics.

что в списке среди Cloud Data Warehouse делает IBM Db2?
если речь про какой-нибудь конкретный продукт в клауде, например — IBM Db2 Warehouse on Cloud, то тогда у меня большие сомнения в его популярности
если речь о DWH вообще, то вряд ли продукты лидеров этого рынка, таких как Oracle, SAP, MS, Teradata — непопулярны

А в чем смысл? External sources -> Data Lake -> ETL -> DWH. Самый обычный флоу. В чем заключается hybrid и что вообще описано в статье?

Так Snowflake storage стоит ровно столько же, сколько и S3 например. Мы используем S3 только для архивного хранения «сырых» данных, а так все с минимальным ETL и Data Validation улетает в Snowflake и оттуда уже аналитики и дата саентисты развлекаются, трансформируют и тд. Если нужны потом трансформации посложнее чем SQL (например с помощью какой-то NLP модели сделать sentiment analysis что будет входными данным уже для другой модели), можно легко замапить snowflake table в spark (там и query pushdown есть) и работать со сноуфлейком по факту как с s3.

для МЛ рекомендую гугл. там все делается в разы проще и человечней. на авс увы без девопсов норм МЛ не поднять, на ажуре еще и девы понадобяться что бы закрыть проебы самого облака.

У нас в датабриксе крутиться, пока хватает. Но так да, TPU очень даже.

не только ТПУ но и инфраструктура конкретно упрощающая деплой и маштабирование. Взять хотябы автопило у кубера.

Гуглятся бэнчмарки JSONB in PostgreSQL vs Mongo где первый быстрее. Не могу знать что в вашем кейсе, но я бы попробовал обойтись одним PostgreSQL.

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

Тут нужно внимательно читать jepsen.io очень может оказаться что отказавшись от реляционности получите только головные.

реляционки вымирающий вид, так как их принцип идет в разрез тем обьемам данных которые сейчас крутятся в риалтайме. а за каждую секунду простоя компании платят лямами баксов с ушедших клиентов.
Посему все двигается в сторону адекватно построенного DL+DWH который способен обеспечивать как скорость, так и обьем проходящих данных, так и глубокую тяжелую аналитику.
И весь DWH это колоночные БД, бо иначе никак.

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

Ну и не путайте типаж базы и какието конкретные баги в конкретном софте.

Но так же потом очень просто из-за таких решений просрать всю компанию, что тоже видел ни раз.

А можно примеры, какие компании были просраны из-за реляционных БД?

они были просраны не из-за реляционных БД а из-за использования их не по месту.
Какие компании я вам сказать не могу так как NDA.

Snowflake and auto derived schema (per 16MB batch of data) solves this problem out of the box.

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

Схема есть) вопрос авто выведения и произвольной вложенности

ну если схема авто то это не схема а метаданные. ну и по сути это одно и тоже что и типа нет схемы. потому как это просто расхождение в речи имеющие под собой один и тот же алгоритм.

А в сторону ClickHouse не смотрели? Очень рекомендую

Подписаться на комментарии