Инфраструктура платформ данных на основе Lakehouse

Анализ больших массивов данных остается важнейшим приоритетом бизнеса, позволяя существенно повысить операционную эффективность компаний. Сегодня стремительно набирают популярность платформы данных на основе архитектуры Lakehouse, предусматривающей отделение слоя вычислений (compute) от слоя хранения (storage), что позволяет получить гибкую масштабируемость и повышенную производительность при одновременном снижении общей стоимости владения. Однако большинство публикаций по Lakehouse традиционно акцентируют внимание на аспекты вычислений и хранения, однако эта архитектура также предполагает наличие слоя инфраструктуры, отвечающего за безопасность и интеграцию вычислительных движков со слоем хранения.

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

Инфраструктура Lakehouse

Классические аналитические СУБД (Greenplum, Teradata, Vertica) — это интегрированные решения, которые управляют всем циклом обработки данных. Они обеспечивают не только хранение и вычисления, но и безопасный доступ, а также фоновые процессы для высокой производительности запросов. Их ключевой недостаток — отсутствие гибкого масштабирования вычислительных мощностей под новые бизнес-задачи, что ведет к росту стоимости владения и замедляет внедрение новых аналитических сценариев.

Архитектура Lakehouse предполагает разделение монолитной аналитической системы на независимые компоненты – для вычислений могут быть использованы различные массивно-параллельные движки, например Trino, а за хранение отвечают технологии на основе протокола S3.

Что из себя представляет инфраструктурный слой архитектуры Lakehouse и какие технологии необходимы для его реализации?

Инфраструктура Lakehouse состоит из нескольких компонентов:

1. Технический каталог (metastore) отвечает за маршрутизацию пользовательских запросов к нужным файлам с данными. Например, когда пользователь выполняет запрос “SELECT SUM(amount) FROM sales WHERE year = 2025”, технический каталог определяет, в каких именно файлах хранятся необходимые данные. В классических СУБД за это отвечают внутренние компоненты, скрытые и от пользователей, и от администраторов. В Lakehouse технический каталог — это отдельный компонент.
2. Система авторизации отвечает за разграничение доступа к данным на основе ролей и атрибутов пользователей и объектов. Аналогично техническому каталогу, в классических СУБД данный компонент интегрирован, тогда как в Lakehouse для него предусмотрена отдельная система авторизации.‍
3. Система оптимизации отвечает за непрерывную оптимизацию физической структуры данных по мере их изменения, а также накопление вспомогательной информации, необходимой вычислительному движку для оптимального выполнения запросов. В традиционных СУБД за оптимизацию отвечают встроенные механизмы (например, VACUUM в Greenplum). В Lakehouse администраторы вынуждены использовать сторонние решения.

Таким образом, стек технологий Lakehouse платформы выходит далеко за рамки compute и storage. Рассмотрим теперь, какие технологии могут быть использованы для реализации данных компонентов.

Традиционный стек технологий

Многие российские компании используют следующий набор технологий для реализации инфраструктуры Lakehouse (рис. 1):

• технический каталог — Hive Metastore;
• система авторизации — Apache Ranger;
• система оптимизации — оркестраторы (например, Airflow) и/или, самописные скрипты.

Hive Metastore — зрелая технология экосистемы Hadoop предназначенная для хранения метаданных о файлах, из которых состоят пользовательские таблицы. Данная технология была создана как часть движка Apache Hive и не адаптирована под нагрузки, характерные для Lakehouse. Из-за своих архитектурных особенностей (например, отсутствия кэширования) Hive Metastore имеет низкую производительность и быстро становится узким местом при попытке масштабировать аналитику, существенно замедляя, а порой даже блокируя пользовательские запросы.

Apache Ranger — популярная система контроля доступа, традиционно используемая для авторизации пользовательских действий в закрытом контуре Hadoop. По аналогии с Hive Metastore, у многих компаний возникло естественное желание использовать возможности Apache Ranger при переходе на Lakehouse, однако архитектура Apache Ranger для этого совсем не предназначена. Так, Apache Ranger по своей сути — это хранилище политик доступа и предполагает, что за применение политик отвечает только вычислительный движок, но архитектура Lakehouse обеспечивает демократизацию доступа за счет использования множества движков.

Например, инфраструктурный инженер может запускать задачи ETL на Apache Spark, аналитик — выполнять интерактивные запросы в Trino или CedrusData, а data scientist — строить ML-модели в Python с помощью встроенных движков Polars или DuckDB. Кроме этого, архитектура Apache Ranger предполагает, что каждый движок должен иметь плагин, который получит политики доступа из Apache Ranger и применит их. Однако это означает, что пользователи лишаются гибкости в выборе вычислительных движков для решения своих задач. При этом значительно увеличивается площадь атаки на инфраструктуру – компрометация любого движка компании приводит к потенциально неограниченному доступу злоумышленников к данным. Немаловажно, что Apache Ranger зависит от ряда уязвимых библиотек, выпущенных 5-10 лет назад.

Для оптимизации запросов традиционные аналитические СУБД выполняют ряд фоновых процессов, в надежде увеличить скорость обработки данных, например: 

• сбор статистик для выбора наилучшего плана выполнения запроса;
• удаление устаревших версий данных;
• изменение физической структуры хранения данных для ускорения запросов.

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

Сегодня нет устоявшихся решений для автоматической оптимизации Lakehouse — администраторы платформ вынуждены самостоятельно программировать процесс оптимизации инфраструктуры.

Современный стек

Традиционный инфраструктурный стек Lakehouse не позволяет в должной мере раскрыть потенциал платформы: Hive Metastore и Apache Ranger — устаревшие технологии, созданные под другие задачи и на волне роста популярности таких технологий, как Apache Iceberg лишь незначительно адаптированы под потребности Lakehouse. Поэтому сообщество разработчиков продуктов для анализа больших данных пришло к консенсусу, что требуется разработка отдельных инфраструктурных сервисов, с которыми вычислительные движки могут общаться по протоколам с открытой спецификацией.

Пример такого протокола — спецификация “REST Catalog” для Apache Iceberg, определяющая набор сетевых команд, посредством которых вычислительный движок может получить доступ к инфраструктурным сервисам Lakehouse. Вендоры создают инфраструктурные продукты, которые реализуют данный протокол, а пользователи подключают к этим сервисам свои вычислительные движки. Использование открытых спецификаций позволяет без написания кода менять движки и инфраструктурные сервисы.

Рассмотрим пример реализации данного подхода на примере продукта CedrusData Catalog — сервиса для управления инфраструктурой Lakehouse, состоящего из следующих ключевых компонентов (Рис. 2):

• хранение метаданных Iceberg. Данный компонент имеет схожий с Hive Metastore функционал, но за счет активного кэширования метаданных в памяти обеспечивает высокую производительность;
• управление доступом. В CedrusData Catalog реализована ролевая модель доступа (RBAC) к объектам lakehouse. В отличие от Apache Ranger, не требуется изменение движков, и принудительно применяются политики доступа для любых продуктов и приложений, взаимодействующих с данными. Такой подход упрощает управление доступом, снимает ограничения на используемые движки и повышает безопасность – применение правил доступа не нужно делегировать другим системам;
• сервис оптимизации. В CedrusData Catalog автоматически оптимизируются данные Apache Iceberg без установки дополнительных сервисов. Кроме того, имеется возможность ускорения работы внешних движков за счет хранения дополнительных метаданных. Так, при работе с движком CedrusData (на основе Trino), CedrusData Catalog добавляет возможность повторного использования промежуточных вычислений между различными пользовательскими запросами, что кратно снижает потребление ресурсов по сравнению с другими решениями.

Среди других примеров современных технических каталогов со схожим функционалом можно назвать продукты Apache Polaris и Lakekeeper, которые, в отличие от CedrusData Catalog, ориентированы для работы только с западными облачными сервисами (например, Amazon S3).

Резюме

Выбор технологий для инфраструктурного стека Lakehouse — важнейшая задача, от решения которой зависит успех внедрения новых платформ данных. Использование таких устаревших технологий, как Hive Metastore и Apache Ranger, иногда позволяет компаниями быстро закрыть инфраструктурные потребности, однако стратегически ограничивает развитие и масштабирование платформы данных и снижает безопасность.

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