Когда озер и хранилищ данных недостаточно.

Введение

Впервые я услышал термин "Lakehouse" в 2019 году, когда пролистывал документ Dremio. Будучи по своей натуре консервативным человеком, я предположил, что это просто очередной маркетинговый термин. Но пять лет спустя, кажется, уже все говорят о Lakehouse (после того, как наговорятся об ИИ :d); все крупные облачные хранилища данных теперь поддерживают чтение форматов Hudi, Iceberge или Delta Lake непосредственно в хранилище объектов, и даже BigQuery имеет специальный механизм запросов для этой задачи. На этом инновации не заканчиваются: Apache XTable (ранее OneTable) предоставляет абстракции и инструменты для трансляции метаданных формата таблиц Lakehouse. Недавно компания Confluent объявила о выпуске TableFlow, которая передает данные из Apache Kafka непосредственно в озеро данных, хранилище или аналитический движок в виде таблиц Apache Iceberg. Это заставило меня пересмотреть свои прежние предположения: так был ли Lakehouse просто маркетинговым термином?

На этой неделе мы ответим на этот вопрос в виде моей заметки из статьи Lakehouse: Новое поколение открытых платформ, объединяющих хранилища данных и расширенную аналитику.

Проблемы и контекст

Впечатление от созерцания потока данных из озер данных в хранилище данных заставило меня подумать, что концепция озер данных существовала раньше концепции хранилища. Но это не так. Термин "озера данных" (Data Lakes) был введен в обиход в 2011 году, а "хранилище данных" (Data Warehouse) появилось уже достаточно давно.

Изначально хранилища данных были созданы для того, чтобы помочь бизнес-пользователям получить аналитические данные путем консолидации данных из оперативных баз данных в централизованном хранилище. Пользователи-аналитики используют эти данные для принятия бизнес-решений. Данные записывались с применением “схемы на запись” (schema-on-write), чтобы убедиться, что модель данных оптимизирована для использования в BI. Это платформа анализа данных первого поколения.

В прошлом организации обычно объединяли вычислительные системы и системы хранения данных для создания локальных хранилищ данных. Это вынуждало предприятия платить за дополнительное оборудование, когда потребность в аналитике и объеме данных возрастала. Кроме того, данные теперь поступают не только в табличном формате; это могут быть видео, аудио или текстовые документы. Неструктурированные данные создавали массу проблем для системы хранения, которая была разработана для работы со структурированными данными.

На помощь пришли платформы для анализа данных второго поколения. Люди начали складировать все сырые данные в "озерах данных" — недорогих системы хранения с файловым интерфейсом, в которых хранятся данные в открытых форматах, таких как Apache Parquet, CSV или ORC. Этот подход зародился с появлением Apache Hadoop, который использовал для хранения данных HDFS. В отличие от хранилищ данных, озеро данных использовало архитектуру "схема на чтение" (schema-on-read), которая позволяла гибко подходить к хранению данных. Тем не менее, она создавала определенные проблемы с качеством данных и управлением. Был предложен подход, который предполагает перемещение подмножества данных из озера в хранилище (ETL). Процесс перемещения данных гарантирует, что пользователь-аналитик сможет использовать возможности хранилища данных для получения ценных сведений. С 2015 года облачные объектные хранилища, такие как S3 или GCS, начали вытеснять HDFS. Они обладают превосходной долговечностью и доступностью, а также чрезвычайно низкой стоимостью. В эпоху облачных вычислений остальная часть архитектуры для платформы второго поколения в основном такая же, как и в случае с хранилищем данных, например Redshift, Snowflake или BigQuery. Эта двухуровневая архитектура "озеро данных + хранилище" доминировала в отрасли на момент написания статьи (думаю, она доминирует и по сей день). Но несмотря на успех, эта архитектура сталкивается со следующими проблемами:

• Надежность: Консолидация озера и хранилища данных — сложная и дорогостоящая задача, требующая значительных инженерных усилий для ETL данных между двумя системами.

• Застой данных: Данные в хранилище не такие свежие по сравнению с данными в озере. Это шаг назад по сравнению с системами первого поколения, где новые оперативные данные были сразу же доступны для аналитики.

• Ограниченная поддержка расширенной аналитики: Системы машинного обучения, такие как TensorFlow или XGBoost, должны обрабатывать большие массивы данных с помощью сложного программного кода. Чтение этих данных через ODBC/JDBC — не самая лучшая идея, и нет возможности получить прямой доступ к внутренним форматам данных хранилища. Поставщики хранилищ рекомендуют экспортировать данные в файлы, что еще больше увеличивает сложность всей этой системы. Вместо этого пользователи могут запускать эти системы на данных озера в открытых форматах. Однако при таком подходе придется отказаться от замечательных функций управления, предоставляемых хранилищами данных, таких как ACID-транзакции или версионирование данных.

• Общая стоимость: Помимо оплаты ETL-конвейеров, пользователям выставляются счета, вдвое превышающие стоимость хранения данных, из-за их дублирования в озере и хранилище данных.

Примечание: Пункт "Ограниченная поддержка расширенной аналитики"  уже не отражает реальное положение вещей на данный момент благодаря интенсивной поддержке машинного обучения крупными облачными хранилищами данных, такими как BigQuery, Snowflake или Redshift. Не стесняйтесь спорить со мной в комментариях, если вы так не считаете.

Основываясь на этих наблюдениях, Databricks сформировало следующий технический запрос: "Можно ли превратить озера данных, основанные на стандартных открытых форматах данных, таких как Parquet и ORC, в высокопроизводительные системы, способные обеспечить как производительность и все нужные функции управления хранилищами данных, так и быстрый прямой ввод-вывод из рабочих нагрузок расширенной аналитики?"

Они утверждают, что парадигма, называемая Lakehouse, может решить некоторые проблемы, связанные с хранением данных. Databricks считает, что Lakehouse привлечет к себе больше внимания благодаря недавним инновациям, которые решают ее фундаментальные проблемы:

• Надежное управление данными в озерах данных: Как и озера данных, Lakehouse должно быть способно хранить сырые данные и поддерживать ETL/ELT процессы. Изначально озера данных представляли собой просто "кучу файлов" в различных форматах, что не позволяло реализовать некоторые ключевые функции управления хранилищами данных, такие как транзакции или откат к старым версиям таблиц. Однако такие системы, как Delta Lake или Apache Iceberg, предоставляют транзакционный слой для озер данных и позволяют реализовать эти функции управления. В этом случае количество этапов ETL сокращается, и аналитики при необходимости могут быстро выполнять запросы к таблицам с исходными данными, как в аналитических платформах первого поколения.

• Поддержка машинного обучения и data science: Поддержка системами машинного обучения прямого чтения из форматов озера данных позволяет им получить эффективный доступ к данным в Lakehouse.

• Производительность SQL: Lakehous’ы должны обеспечивать современную производительность SQL на огромных массивах данных в озере. Databricks показывает, что для обеспечения производительности можно использовать различные техники для поддержания вспомогательных данных и оптимизации их расположения в существующих форматах.

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

Мотивация

Ниже приведены несколько причин, по которым в Databricks считают, что архитектура Lakehouse может устранить недостатки хранилища данных:

• Качество и надежность данных — главные проблемы, с которыми сталкиваются корпоративные пользователи. Внедрить эффективные конвейеры обработки данных непросто, а доминирующие архитектуры данных, разделяющие озеро и хранилище, еще больше усложняют эту проблему.

• Все больше бизнес-приложений требуют актуальных данных. Тем не менее, двухуровневые архитектуры увеличивают застойность данных за счет наличия отдельной области для входящих данных перед их загрузкой в хранилище с помощью периодических ETL/ELT-задач.

• Большое количество данных сейчас неструктурировано.

• Хранилища и озера данных плохо обслуживают сценарии машинного обучения и data science.

Некоторые современные тенденции в отрасли еще раз подтверждают, что клиенты недовольны двухуровневой моделью:

• Все хранилища больших данных добавили поддержку внешних таблиц в формате Parquet и ORC.

• На создание SQL-движков, работающих непосредственно с озером данных, таких как Spark SQL или Presto, направлены серьезные инвестиции. 

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

Архитектура Lakehouse

Databricks определяет Lakehouse как систему управления данными на базе недорогих хранилищ, которая расширяет функции управления и производительности традиционных аналитических СУБД, таких как ACID-транзакции, версионирование, кэширование и оптимизация запросов. Таким образом, Lakehouse сочетает в себе преимущества обоих миров. В следующих разделах мы познакомимся с возможным дизайном Lakehouse, предложенным Databicks.

Реализация

Первая идея, которую они предлагают для реализации Lakehouse — хранить данные в недорогом объектном хранилище (например, Google Cloud storage), используя стандартный формат файлов, такой как Apache Parquet, с дополнительным транзакционным слоем метаданных поверх него, чтобы определить, какие объекты принадлежат той или иной таблице. Слой метаданных позволяет реализовать такие функции управления, как ACID-транзакции, и при этом получить преимущество объектного хранилища по низкой стоимости. В качестве кандидатов на реализацию слоя метаданных можно назвать Delta Lake, Apache Iceberg или Apache Hudi. Кроме того, Lakehous’ы могут повысить производительность рабочих нагрузок расширенной аналитики и помочь им лучше управлять данными, предоставляя декларативные DataFrame API. Многие фреймворки машинного обучения, такие как TensorFlow и Spark MLlib, могут читать такие форматы файлов озер данных, как Parquet. Это означает, что самый простой способ интегрировать их с Lakehouse — запросить слой метаданных, чтобы выяснить, какие файлы Parquet являются частью таблицы, и передать эту информацию библиотеке машинного обучения.

Слой метаданных

Такие системы хранения данных на основе озер, как S3 или HDFS, предоставляют только низкоуровневый интерфейс объектного хранилища или файловой системы. С годами возникла потребность в уровнях управления данными, начиная с Apache Hive, который отслеживает, какие файлы данных входят в таблицу Hive для конкретной таблицы.

В 2016 году компания Databricks начала разработку Delta Lake, которая хранит информацию о том, какие объекты принадлежат какой таблице в объектном хранилище, в виде журнала транзакций в формате Parquet. Apache Iceberg, впервые представленный в Netflix, использует похожий дизайн. Apache Hudi, созданная в Uber, — еще одна система, ориентированная на потоковое добавление в озера данных. По мнению Databricks, эти системы обеспечивают производительность, аналогичную или более высокую, чем у озер данных в формате Parquet/ORC, при этом улучшая управление данными, например, транзакциями, нулевым копированием или перемещением во времени.

Следует отметить, что их легко внедрить в организациях, уже имеющих озеро данных: например, Delta Lake может организовать существующий каталог файлов Parquet в таблицу Delta Lake без перемещения данных, построив журнал транзакций над всеми существующими файлами. Кроме того, слои метаданных могут помочь реализовать ограничения качества данных. Например, API ограничений Delta Lake позволяют пользователям накладывать ограничения на новые данные (например, список допустимых значений для определенного столбца). Клиентские библиотеки Delta будут отклонять все записи, которые нарушают эти ограничения. Наконец, уровни метаданных помогают реализовать такие функции управления, как контроль доступа, например, проверить, может ли клиент получить доступ к таблице, прежде чем предоставить ему полномочия на чтение исходных данных таблицы.

Производительность SQL

Хоть слой метаданных и добавляет возможности управления, для достижения возможностей хранилища необходимо большее. Производительность SQL, при которой движок работает непосредственно с необработанными данными, может быть самым значительным техническим вопросом при использовании подхода Lakehouse. Databricks предлагает несколько методов оптимизации производительности SQL в Lakehouse. Эти методы не зависят от выбранного формата данных. К таким оптимизациям относятся:

• Кэширование: при использовании уровня метаданных система Lakehouse может кэшировать файлы из облачного объектного хранилища на более быстрых устройствах, таких как SSD и RAM.

• Вспомогательные данные: Lakehouse может поддерживать другие вспомогательные файлы данных для оптимизации запросов. В Delta Lake и Delta Engine Databricks поддерживает min-max информацию о столбцах для каждого файла данных, сохраняя ее в том же файле журнала транзакций Parquet. Это позволяет движку пропускать ненужные данные на этапе сканирования. Кроме того, для пропуска данных используется фильтр Блума.

• Компоновка данных: Lakehouse может оптимизировать множество решений по компоновке данных. Первое из них — упорядочивание записей, при котором записи группируются рядом; так движку проще читать их вместе. Delta Lake поддерживает упорядочивание записей с помощью отдельных измерений или кривых заполнения пространства, таких как кривая Z-order, чтобы обеспечить локальность в более чем в одном измерении.

Эти оптимизации хорошо сочетаются с типичными шаблонами доступа в аналитических системах. Типичные запросы фокусируются на "горячем" подмножестве данных в аналитической нагрузке, которое может выиграть от оптимизации кэша. Критическим фактором производительности для "холодных" данных в облачном хранилище объектов является объем сканирования для каждого запроса. Сочетание оптимизаций компоновки данных и вспомогательных структур данных позволяет системе Lakehouse эффективно минимизировать ввод-вывод.

Эффективный доступ для расширенной аналитики

Один из подходов — предложить декларативную версию DataFrame API, используемую в библиотеках машинного обучения, которая отображает вычисления по подготовке данных в планы запросов Spark SQL и может воспользоваться оптимизациями Delta Lake. Таким образом, при реализации источника данных Delta Lake используются описанные выше оптимизации кэширования, пропуска и компоновки данных для ускорения чтения данных из Delta Lake и ускорения рабочих нагрузок машинного обучения и data science.

Заключение

Если решение способно решить реальную проблему, то это не просто клишированный термин. Изначально Lakehouse была представлена для того, чтобы решить проблему двухуровневой архитектуры: поддерживать две отдельные системы для хранения (озера) и аналитики (хранилища). Перенося аналитическую мощь непосредственно в озера, парадигма Lakehouse должна решить самую сложную проблему: производительность запросов; выполнение аналитики непосредственно на сырых данных означает, что движок не знает многого о данных заранее, что может вызвать проблемы в процессе оптимизации. Благодаря инновациям последних лет в области открытых табличных форматов, таких как Hudi, Iceberge или Delta Lake, Lakeshouse, похоже, не отстает от традиционных хранилищ в соревновании по производительности. В будущем нам предстоит наблюдать за развитием Lakehouse, сосуществованием с парадигмой "озеро-хранилище" или полной заменой двухуровневой архитектуры; кто знает?

Ссылки

[1] Databricks, Lakehouse: Новое поколение открытых платформ, объединяющих хранилища данных и расширенную аналитику (2020).

Airflow представляет собой краткое и информативное введение в Apache Airflow — инструмент для планирования, мониторинга и управления рабочими процессами. Приглашаем всех желающих на открытый урок, на котором вы узнаете основные концепции и возможности Airflow: задачи, потоки данных, DAGs (Directed Acyclic Graphs), операторы, планировщик и мониторинг выполнения задач.

Преподаватель проведет обзор основных компонентов Airflow, покажет, как создавать и настраивать DAGs, как запускать задачи, контролировать их выполнение и мониторить состояние рабочих процессов. Лекция также охватит практические примеры использования Airflow для автоматизации рабочих процессов и управления данными.

В результате участники урока получат понимание основных принципов работы Apache Airflow и смогут начать использовать его для организации и оптимизации своих рабочих процессов. Урок пройдёт уже 20 июня в 20:00. Записаться бесплатно можно по ссылке.