В предыдущей статье мы рассказывали про наш новый на тот момент продукт — CedrusData Catalog. С тех пор прошел уже почти год, и нам есть чем поделиться. Чтобы лучше понять контекст, для начала обратимся к обзору рынка и определим ключевые требования к современному техническому каталогу.
Определимся с терминами:
- Каталог — технический каталог метаданных, также часто называемый метастором. Не путать с корпоративными/бизнес каталогами данных, такими как Open Metadata и DataHub.
- Движок — один из вариантов для compute-слоя (Trino, Flink, Spark, и пр.), работающий с данными через каталог.
Среди критериев отбора выделим следующие:
- Поддерживаемые табличные форматы и протоколы. Рассматривать будем каталоги с ориентацией на Iceberg и Delta Lake, как лидеров рынка.
- On-prem или cloud. Учитывая специфику РФ, где чисто облачные сервисы могут быть стоп-фактором, для сравнения мы выбрали только продукты, которые можно самостоятельно развернуть on-prem.
- Поддерживаемые файловые системы. Наиболее популярны на российском рынке сейчас S3-совместимые и HDFS. Некоторые смотрят в сторону Ozone. Полезной может быть возможность использования локальной файловой системы.
Это базовый набор критериев. Однако не менее важны и другие аспекты, такие как безопасность, управление таблицами Iceberg/Delta Lake и удобный интерфейс. Рассмотрим ключевые из них подробнее.
Поддерживаемые табличные форматы и протоколы
В настоящий момент лидирующим форматом является Iceberg. Delta Lake где-то может быть более распространен для уже существующих решений, но постепенно отходит на второй план. Hudi — менее популярен и больше ориентирован на потоковые сценарии. Для Iceberg существует протокол Iceberg Catalog REST API, поддерживаемый многими каталогами. Для Delta Lake есть свой API только в каталоге Unity, а Hudi собственного протокола под каталог не имеет, ориентируясь на работу с Hive Metastore (далее HMS) или аналогичными.
Важно также отметить, как именно каталог поддерживает тот или иной формат и протокол. Некоторые каталоги умеют полноценно работать с Iceberg, но таблицы Delta Lake — только читать.
Из протоколов, кроме Iceberg нам известен еще и Hive Thrift API, который используется в HMS и его преемниках. Как пример, каталог может поддерживать протокол, но не хранить сами метаданные у себя, а проксировать все запросы к какому то внешнему каталогу, например тому же HMS. Если внешних каталогов несколько — такое поведение называется федеративным метадата каталогом (примерно так же как, например, Trino является федеративным SQL движком), что позволяет обращаться и управлять сразу несколькими каталогами одновременно, через единый инструмент.
Другой важный момент — это сам API, через который каталог взаимодействует с движком. Помимо перечисленных Iceberg Catalog API и HMS Thrift API, некоторые каталоги пошли по пути создания собственного Catalog API, расширяющий возможности стандартных. Но как с таким API взаимодействовать сторонним движкам? Вопрос риторический. Поэтому такие каталоги вынуждены выпускать собственные плагины/расширения для движков, поддерживающие этот API.
Безопасность
В типичном Data Lake/Lakehouse может быть много разных движков, которые применяются в зависимости от характера вашей рабочей нагрузки. Но как обеспечить единую модель доступа ко всем данным (например, популярную Role-Based Access Control)?
Вы можете воспользоваться одной из доступной на рынке систем авторизации, например Apache Ranger, Open Policy Agent (OPA), Open FGA или другие. Но несмотря на некоторые удобства данных систем, у них есть общие недостатки:
- Нужно чтобы движок или внешняя система авторизации могли интегрироваться друг с другом. У Ranger обычно есть соответствующие Ranger plugins под тот или иной движок, а для OPA или FGA требуется плагин/поддержка со стороны движка. Конечно же не везде такие плагины есть, или имеются ограничения.
- Нужно чтобы все элементы экосистемы опирались на единый Identity Provider, IdP (включая привязку к группам доступа), это тоже не везде доступно. Например, типичный сценарий для крупных компаний — синхронизация пользователей и групп из LDAP, и далее использование их в политиках авторизации.
- Нужно чтобы политики были единые для разных движков. Особенно актуально для Ranger.
Одним из ответов на данные вопросы является наличие внутри каталога функционала авторизации доступа к данным Lakehouse, и по этому пути как раз и идут многие современные решения. Т.к. именно каталог часто является объединяющим элементов в разрозненном ландшафте движков от разных вендоров и избавляет от проблем наличия совместимых плагинов и синхронизации правил. Единственное, что следует в этом случае учитывать, — это возможность проброса identity от движка к каталогу (или аналогичного механизма), т.е. чтобы каталог узнал о конкретном подключившемся пользователе со стороны движка и смог применить соответствующие политики доступа.
Обслуживание таблиц
Еще одной важной особенность работы в Lakehouse является обслуживание таблиц, а именно их компакция и оптимизация (нечто близкое по смыслу с housekeeping). При работе с открытыми табличными форматами, все изменения, которые применяются к данным, выполняются через добавление инкрементов/векторов или новых версий файлов к существующим данным. Чем чаще у вас будут приходить изменения, тем более фрагментированные таблицы вы получаете на выходе, а запросы к таким таблицам будут работать медленней (особенно в режиме MOR — Merge on Read).
Как следствие, такие данные нужно укрупнять/мержить с существующими, удалить неиспользуемые ссылки на устаревшие файлы, иногда упорядочивать, и т.п. Все это обеспечивается процедурами обслуживания (maintenance), доступными в библиотеках открытых табличных форматов. И здесь всегда возникает компромисс между частотой обслуживания, и стоимостью ресурсов, на нее затраченную. Где-то достаточно проводить maintenance раз в неделю без заметной потери производительности, а где-то и раз в несколько часов будет недостаточно и производительность запросов страдает. Но в большом хранилище у вас тысячи таблиц, и настроить правильный порядок обслуживания может потребовать значительного времени.
Современные каталоги часто берут работу по обслуживанию таблиц на себя, или хотя бы управление/координацию этим процессом. Тем более что:
- Они знают кто, когда и где изменял данные (вне зависимости от движка);
- Знают, как часто происходило изменение данных;
- Каталог может реагировать на события изменения данных;
- У каталога есть информация об используемых движках и таблицах.
Как следствие, каталог может достаточно оптимально запланировать момент выполнения операций обслуживания, где участие человека может быть сведено только к первоначальной настройке политик.
Теперь перейдем к обзору существующих на рынке решений. Специально везде указываю актуальную на момент выхода статьи версию продукта—
Hive Metastore (4.2.0)
Самый популярный и распространенный на текущий момент каталог. Разработан Facebook* (признан в РФ террористической организацией) в 2010 под экосистему Hadoop, и поэтому во многом тесно с ней связан. Архитектура построена на Hive Thrift API, а UI не предусмотрен.
Из интересностей можно отметить что в ноябре 2025 вышла версия 4.2.0 с имплементацией (ну наконец!) Iceberg Catalog REST API. В остальном расписывать кажется нет смысла, если вы читаете данную статью, то наверняка это был ваш первый каталог с которым приходилось работать.
У HMS много cloud-only форков, таких как AWS Glue Data Catalog, Google Cloud Dataproc Metastore, Microsoft Azure Hive Metastore и пр. У них функционал может быть значительно шире и богаче, но в силу своей природы — нас они не интересуют.
Преимущества:
- Все еще остается наиболее популярным на рынке;
- Широкая поддержка (движками, другими каталогами и прочими приложениями).
Недостатки:
- Отсутствие возможности создания нескольких каталогов или endpoint файловых систем одновременно;
- Производительность при большом числе объектов ограничена;
- Отсутствие авторизации;
- Отсутствие функционала обслуживания таблиц;
- Содержит много ненужного и устаревшего функционала;
- Медленное развитие;
- Плохая/разрозненная документация.
Project Nessie 0.105.6
Один из наиболее популярных после HMS. Первый релиз вышел в 2020, основной разработчик — Dremio, язык — Java. Интересен каталог тем, что позволяет создавать git-подобные ветвления для данных Lakehouse и реализовывать ставший уже популярным паттерн WAP (Write-Audit-Publish). WAP позволяет вам писать одну ветку, а читать в это время другую (предыдущее состояние данных). А после готовности загруженных данных, можно выполнить fast-forward merge с целевой актуальной веткой (это происходит уже без физического перемещения данных, аналог многотабличного commit). Причем сделать это можно сразу для всей схемы, в отличие от возможностей Iceberg, который умеет работать с ветками только в пределах одной таблицы. У Nessie есть простой web UI, который позволяет просматривать ветки/теги/их содержимое (без управления).
Единственный поддерживаемый формат — Iceberg, работа производится через собственный Nessie API. Также доступен Iceberg Catalog API, но он заявлен как экспериментальный и соответственно его использование не дает описанных преимуществ. Хранение метаданных — внешняя СУБД (JDBC). Аутентификация возможна через OIDC (библиотека Quarkus). Авторизация настраивается через CEL-правила (Common Expression Language), и позволяет реализовать RBAC модель доступа. У Nessie есть старший облачный брат — Dremio Arctic (managed-сервис), который добавляет автоматическое обслуживание таблиц, улучшенный UI и авторизацию.
Вероятно, Nessie мог бы стать лидером рынка, но в 2024 сперва появилась информация о том, что Dremio будет внедрять полезные функции Nessie в проект Polaris, а позже Dremio сообщила что Apache Polaris теперь станет стандартом сообщества для каталогов Lakehouse. И хотя Nessie остаётся OSS проектом, где продолжают выходить новые релизы, становится очевидно что весь фокус и инвестиции Dremio и Snowflake будут направлены на проект Polaris.
Преимущества:
- Git-подобные ветки данных (+UI для их визуализации);
- RBAC-модель доступа данных (включая доступ к веткам);
- Поддержка кэширования метаданных (list/get).
Недостатки:
- Отсутствие поддержки HDFS (для Nessie API);
- Нет поддержки LDAP;
- Отсутствие функционала обслуживания таблиц Iceberg;
- Дальнейшая дорожная карта проекта неясна, а темпы развития существенно снизились.
Apache Polaris 1.2.0
Первый релиз каталога вышел в 2024 году, основным разработчиком является компания Snowflake, основной язык — Java. Каталог реализует Iceberg REST API, включая хранение метаданных в Postgres. При этом каталог может также быть федеративным (прокси) каталогом для других каталогов Iceberg и HMS (но в этом режиме работает только на чтение). Аутентификация может быть двух видов: internal — с использованием JWT-токенов и external — через OIDC (Quarkus). Настройка авторизации осуществляется через CLI или специальный management REST API, где можно создавать roles, principals и grants, что в совокупности это позволяет реализовать модель авторизации RBAC.
Для обслуживания Iceberg таблиц можно задавать политики, причем исполнение для “тяжелых” оптимизаций выполняется с помощью Policy API. Но далее вам нужно самостоятельно делать polling Policy API и применять оптимизацию. Поддерживается возможность создания нескольких каталогов в рамках одного экземпляра. Еще из интересного: поддержка S3 credentials vending, что позволяет реализовать авторизацию в S3 под временным токеном доступа и только по конкретному префиксу пути. Как следствие, в этом случае мы получаем более защищенный и прозрачный доступ в S3. Также Polaris развивает поддержку Genetic Table для non-Iceberg таблиц (Delta, csv etc), реализованный через отдельные endpoints (Polaris Catalog API). Но пока это экспериментальный функционал.
Преимущества:
- В свете событий c Nessie (см. выше), будущее выглядит многообещающе;
- Федерация (проксирование) в каталоги Iceberg и HMS (но только на чтение);
- RBAC, credential vending.
- Поддержка кэша метаданных (list/get).
Недостатки:
- Отсутствие поддержки LDAP;
- Отсутствие поддержки HDFS;
- Для обслуживания Iceberg таблиц существуют только описательные политики, все остальное вы делаете сами (поллинг политик + вызов обслуживающих процедур);
- Отсутствие Web UI.
Unity Catalog 0.3.0
Каталог был анонсирован Databricks в 2021 г. (код — преимущественно Java), а первый релиз вышел в 2022. Как вы знаете, Databricks является разработчиком формата Delta Lake, соответственно каталог нацелен на родной формат (для работы используется протокол Unity REST API). При этом так же имплементирована поддержка Iceberg REST API для совместимости со сторонними движками (это обеспечивается через UniForm — специальное расширение для Delta Lake таблиц, которое позволяет их читать как будто это Iceberg или Hudi-таблицы. Но только читать, запись возможна только через Delta Lake). У Unity Catalog есть UI для просмотра списка каталогов и моделей. Для аутентификации поддерживаются либо локальные пользователи, либо протокол OIDC/OAuth2. Поддерживается возможность создания нескольких каталогов в рамках одного инстанса.
У каталога есть enterprise-версия, которая ориентирована, в первую очередь, на работу с облачными сервисами Databricks, содержит расширенный UI, функции бизнес каталога (включая функции Data Governance & Data Lineage), улучшенную модель доступа и пр.
Преимущества:
- Поддержка UniForm (но стоит понимать, что такой подход всегда будет иметь много ограничений).
Недостатки:
- Отсутствие поддержки VIEW;
- LDAP не поддерживается;
- Работа с HDFS не поддерживается;
- Примитивная модель привилегий (без групп/ролей);
- Отсутствие кэша метаданных (list/get);
- Отсутствие процедур обслуживания таблиц (нет и в roadmap).
Apache Amoro 0.8.1
Проект изначально появился в 2019 году в компании NetEase под названием Arctic. Написан также на Java. В 2022 вышел в OpenSource, и в 2023 был переименован в Amoro. Каталог уникален тем, что изначально создавался на идее оптимизации обслуживания и хранения, и балансе скорости чтения-записи (для открытых табличных форматов в целом, в первую очередь для Iceberg). Каталог имеет собственный протокол Amoro Thrift API (основной), также может работать как классический Iceberg REST API каталог, а также поддерживает external-каталоги (HMS-совместимые).
Для аутентификации в Trifft API в настоящий момент доступны только simple (из файла) и Kerberos. Встроенных возможностей авторизации доступа нет.
В качестве хранения поддерживаются форматы Iceberg, Paimon, Mixed-Iceberg и Mixed-Hive. Последние 2 — отличительная особенность Amoro. Рассмотрим Mixed формат на примере Iceberg. Формат содержит 2 слоя (или 3 — для потоковых ingestion):
- BaseStore – основная, холодная часть таблицы, физически хранится как отдельная Iceberg-таблица (base);
- ChangeStore — горячая инкрементальная часть (changelog), физически тоже отдельная Iceberg-таблица (change);
- LogStore — (для потоковых) — быстрый кеш для ChangeStore, обычно хранимый в Kafka или файлах.
При работе с Amoro через Thrift API вы увидите только единую таблицу (Amoro выполнит “merge-on-read” данных слоев), а на уровне Hive или Iceberg REST — увидите две таблицы (“base” и “change”).
Обслуживанием и оптимизацией хранения управляет AMS (Amoro Management Service), который выявляет, планирует и диспечерезирует эти задачи. Состояние таблиц оценивается по заданным в параметрах порогам, и оптимизация запускается автоматически (параметры можно задавать на уровне таблицы, группы или каталога). Для выполнения оптимизаций можно использовать различные движки (“Optimizer containers”) — Spark, Flink, Kubernetes или Local (последний для простых оптимизаций или в целях демо). Еще из полезных возможностей — поддержка HDFS.
У каталога есть достаточно мощный UI, который позволяет производить общий мониторинг работы (dashboard, параметры сервера), создание и конфигурацию каталогов, есть браузер таблиц, просмотр и редактор и их параметров, просмотр статистик файлов, настройки и журнал оптимизаций, консоль для выполнения SQL-запросов и отображения табличных результатов.
Преимущества:
- Автоматическое обслуживание таблиц;
- Поддержка Mixed-форматов и Paimon;
- Многофункциональный UI;
- Поддержка HDFS.
Ограничения:
- Отсутствие современных методов аутентификации (доступны только simple и Kerberos);
- Отсутствие авторизации доступа/RBAC;
- Отсутствие кэша.
Gravitino 1.0.1
Первый релиз каталога вышел в 2023, основным разработчиком является компания Datastrato, язык — Java. Gravitino позиционирует себя как федеративный metadata lake, что по сути подразумевает федеративный доступ к другим внешним каталогам. Но при этом так же может выступать как сервер Iceberg REST Catalog, c собственным хранилищем метаданных каталога. Внешними каталогами тут могут выступать Iceberg REST или HMS (Iceberg, Hudi, Hive, Paimon) каталоги. Также для реляционных источников доступны каталоги: MySQL, Postgres, StarRocks, Doris, OceanBase.
Одной из интересных особенностей Gravitino является наличие коннектора Gravitino Trino (т.е. коннектора для Trino), который позволяет динамически создавать в Trino каталоги, определенные внутри Gravitino, и далее использовать единые политики доступа, единый аудит и прочие возможности управления.
Возможные методы аутентификации в Gravitino: OIDC и Kerberos. Авторизация возможна по моделям RBAC+DAC, с использованием внутренних настраиваемых правил (правила управляются через SDK/REST API). Поддерживается S3 credential vending.
Для обслуживания таблиц Iceberg применяется примерно следующий алгоритм: можно создавать статистики, политики и job templates, далее на основании первых двух некий внешний оркестратор регулярно их проверяет (polling) и принимает решение о том когда запускать компакцию таблиц (что именно запускать — задается в job template). Т.е. во многом этот механизм похож на аналогичный в Polaris.
Преимущества:
- Федеративный каталог метаданных;
- Gravitino Trino коннектор (динамическое управление каталогами Trino);
- Поддержка RBAC;
- S3 Credentials Vending;
- Поддерживается в Spark, Trino, Flink.
Недостатки:
- Концептуальных вроде нет, разве что позиционирование и технические сценарии совсем совсем не описаны, складывается ощущение что разработчики сами не до конца понимают, зачем такого зверя сделали;
- Отсутствие поддержки LDAP;
- Отсутствие поддержки HDFS;
- Концепт обслуживания таблиц кажется не самым удачным;
- Отсутствие кеша.
Lakekeeper 0.10.1
Первый релиз вышел в 2024 году, основной контрибьютор — небольшой стартап Vakamo, язык разработки — Rust. Каталог реализует Iceberg REST API, хранение метаданных в БД Postgres. Каталог имеет UI, где можно определить проекты, хранилища, роли и параметры сервера, управлять профилем пользователя. Аутентификация реализуется через OIDC. Для авторизации по умолчанию используется OpenFGA (это отдельный инструмент для авторизации), также доступен OPA-bridge (для использования политик из инструмента Open Policy Agent). Соответственно оба могут закрыть вопрос организации RBAC. В UI можно задавать только роли и грантовать их пользователям, остальные настройки придется делать через API. В части ФС поддерживаются S3-совместимые хранилища с возможностью credentials vending. Поддерживается возможность создавать несколько warehouse и projects, т.е. нескольких каталогов и ФС.
Преимущества:
- Поддержка RBAC через OpenFGA или OPA.
Ограничения:
- Отсутствие поддержки LDAP;
- Отсутствие поддержки HDFS;
- Отсутствие процедур обслуживания таблиц (но есть в roadmap);
- Отсутствие кэширования.
Roadmap:
- maintenance дата файлов;
- интеграция с HMS.
DataHub Iceberg Catalog 1.0.0
Данный каталог является частью более крупного проекта Data Hub (корпоративный каталог), и при этом является полноценной имплементацией Iceberg REST Catalog. В качестве backend используется та же БД, что и DataHub — MySQL/Postgres или MariaDB. Поддерживаются разные виды аутентификации (Bearer token, JWT, JaaS). Поддерживает единую с DataHub RBAC-модель доступа, привилегии можно настраивать в DataHub UI. Поддерживаемые ФС — только S3-совместимые, так же поддерживается S3 credentials vending.
Преимущества:
- Тесная интеграция с DataHub и соответствующий синергетический эффект;
- Полноценный RBAC;
- Богатый Web UI.
Недостатки:
- Отсутствие развитых функций каталога (обслуживание Iceberg, кеширование);
- Нет поддержки HDFS;
- Проект пока имеет пометку “beta”.
Итоги
Мы рассмотрели наиболее заметные решения, которые представлены в настоящий момент на рынке. Какие тенденции мы видим в современных каталогах, что можно отметить, и одновременно какие недостатки?
Основной вывод: современный каталог — это гораздо больше, чем просто хранение метаданных таблиц. Как минимум это наличие современных подходов к безопасности (аутентификации и авторизации), особенности работы с различными форматами и протоколами, особенности обслуживания таблиц и возможность подключения внешних compute-движков для решения данных задач, доступность и удобство управления и мониторинга данными процессами, наличие Web UI.
Из недостатков, которые присутствуют во многих каталогах можно отметить:
- Отсутствие поддержки HDFS и LDAP, которые активно используются многими участниками российского рынка (пусть даже и как legacy компоненты).
- Не все каталоги поддерживают авторизацию доступа, не везде данный имеет необходимый уровень зрелости или удобства. К примеру, управлять сложной моделью RBAC в гетерогенном миксе compute-движков, в большинстве каталогов будет проблематично. В лучшей степени здесь преуспели Polaris, Gravitino и Lakekeeper.
- Обслуживание таблиц либо отсутствует, либо сам подход недостаточно проработан или ограничен. Наибольших успехов тут добился каталог Amoro.
- Часто отсутствует кэширование.
CedrusData Catalog
Наконец, рассмотрим отличительные особенности каталога от CedrusData. Первая публичная версия каталога появилась в 2024 году, каталог разработан с нуля командой CedrusData и ориентирован на российский рынок, решение находится в Реестре российского и евразийского ПО. Решение распространяется бесплатно, коммерциализация осуществляется через услуги поддержки.
Каталог реализует Iceberg REST API, данные на backend хранятся в Postgres. В качестве аутентификации поддерживается LDAP, Keycloak и локальные токены OAuth (client credentials flow). Авторизация реализуется через внутренние политики доступа (на основе ролей). Каталог имеет UI, который в настоящий момент позволяет:
- управлять пользователями (добавление/редактирование/удаление);
- управлять ролями (редактирование объектов доступа, привязка пользователей к роли);
- управлять ключами доступа (добавление/удаление);
- управлять файловыми системами (добавление/редактирование/удаление; доступны ФС: S3, HDFS, Ozone, локальная ФС);
- управлять каталогами, привязывать каталог к ФС(добавление/редактирование/удаление);
- просматривать журнал обслуживания таблиц.
Каталог поддерживает управление через CLI, который дублирует основные функции, доступные в UI, и дополнительно к этому позволяет:
- управлять группами объектов (используется в maintenance);
- управлять задачами обслуживания Iceberg;
- управлять конфигурацией каталога.
Каталог разработан как pluggable, и использует схожий с Trino SPI подход для быстрого расширения функционала, без пересборки/изменений кода ядра.
Поддерживается глобальный Time travel, т.е. можно обращаться к определенному срезу данных по временной метке. При использовании в связке с CedrusData Engine данную метку можно задать на уровне сессии Trino, а для Spark или других движков — через HTTP-заголовки.
При работе с CedrusData Engine также будет доступно переиспользование материализаций CTE между запросами (напомню что сама материализация CTE включается в CedrusData Engine и может выполняться как автоматически, так и явно).
Для общего мониторинга работы можно использовать JMX, OpenMetrics и OpenTelemetry.
Каталог активно совершенствуется, и в самых ближайших релизах мы добавим:
- Синхронизацию пользователей и групп из LDAP
- Поддержку аутентификации OAuth Authentication code flow
- Поддержку аутентификации Kerberos
- Продвинутый Iceberg maintenance (автономные политики и внешние движки — Spark, Flink и пр.)
- Аудит событий безопасности (доступ к объектам, изменение политик доступа).
Путь к современным, эффективным и безопасным данным в России требует особых решений. Существующие международные инструменты зачастую не учитывают реалии российского рынка: приоритет on-premises-развертывания, работу с HDFS и необходимость интеграции с локальными системами безопасности.
CedrusData Catalog был создан, чтобы заполнить эту нишу. Мы не адаптировали чужой продукт, а разработали каталог с нуля, сделав его естественной частью технологического стека российских компаний. Поддержка спецификации Iceberg REST API — это наш ответ на запрос рынка о переходе к архитектуре lakehouse. Мы видим CedrusData Catalog как центральный узел для управления, защиты и оптимизации данных в будущих аналитических платформах.
Присоединяйтесь к развитию каталога. Скачайте CedrusData Catalog, протестируйте в своих проектах. Если вы столкнетесь с неожиданным поведением каталога, пишите нам в Telegram-чат, — поможем, улучшим или починим.