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

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

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

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

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

Технический каталог (metastore) отвечает за маршрутизацию пользовательских запросов к нужным файлам с данными. Например, когда пользователь выполняет запрос «SELECT SUM (amount) FROM sales WHERE year = 2025», технический каталог определяет, в каких именно файлах хранятся необходимые данные. В классических СУБД за это отвечают внутренние компоненты, скрытые и от пользователей, и от администраторов. В lakehouse технический каталог — это отдельный компонент.

Система авторизации отвечает за разграничение доступа к данным на основе ролей и атрибутов пользователей и объектов. Аналогично техническому каталогу, в классических СУБД данный компонент интегрирован, тогда как в lakehouse для него предусмотрена отдельная система авторизации.

Система оптимизации отвечает за непрерывную оптимизацию физической структуры данных по мере их изменения, а также накопление вспомогательной информации, необходимой вычислительному движку для оптимального выполнения запросов. В традиционных СУБД за оптимизацию отвечают встроенные механизмы (например, VACUUM в Greenplum). В lakehouse администраторы вынуждены использовать сторонние решения.

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

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

Рис. 1. Традиционный стек технологий реализации инфраструктуры lakehouse

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

  1. технический каталог — Hive Metastore;
  2. система авторизации — Apache Ranger;
  3. система оптимизации — оркестраторы (например, 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. Вендоры создают инфраструктурные продукты, которые реализуют данный протокол, а пользователи подключают к этим сервисам свои вычислительные движки. Использование открытых спецификаций позволяет без написания кода менять движки и инфраструктурные сервисы.

Рис. 2. Ключевые компоненты сервиса CedrusData Catalog для управления инфраструктурой 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.

Владимир Озеров (vozerov@querifylabs.com) — генеральный директор, «Кверифай Лабс» (Москва). Статья подготовлена на основе материалов выступления на форуме «Управление данными 2024».