Технические каталоги данных для Lakehouse: сравнение Hive Metastore, Polaris, Nessie, Unity Catalog и других в 2026 году

Технический каталог данных определяет, насколько дорого обойдётся смена Lakehouse-стека. Война табличных форматов закончилась: Apache Iceberg читают и пишут Snowflake, Databricks, Google Cloud и дистрибутивы Trino. Поэтому переносимость самих данных перестала быть главным аргументом при выборе стека. Файлы Parquet и метаданные Iceberg остаются в объектном хранилище при смене движка. Переносить приходится политики доступа, историю аудита, правила обслуживания таблиц и механизм координации параллельных записей. Всё это хранится в каталоге.

При выборе инструмента часто путают два класса продуктов. Технический каталог, или метастор, обслуживает движки: хранит схемы, указатели на файлы и версии таблиц, координирует атомарные коммиты. Бизнес-каталог вроде DataHub или OpenMetadata нужен людям: в нём описывают владельцев, глоссарий и происхождение данных для аналитиков.

В обзор вошли технические каталоги, которые можно развернуть в собственном контуре и использовать поверх S3 или HDFS. Управляемые сервисы, привязанные к одному публичному облаку, для российского рынка не подходят, поэтому AWS Glue, BigLake и Azure-варианты Hive Metastore остались за рамками.

Рассмотрены девять продуктов. Для каждого приведены версия и ключевые свойства, в конце — таблица по 14 критериям и четыре сценария выбора. Все статусы актуальны на 18 августа 2026 года: рынок каталогов меняется быстро, и за квартал половина такой таблицы может устареть.

Что такое технический каталог данных и зачем он нужен

Apache Iceberg не хранит таблицу как директорию с файлами. Её состояние описывает цепочка версионированных metadata-файлов, а каталог хранит указатель на текущий metadata.json. Коммит в Iceberg меняет этот указатель атомарно, а не переписывает данные. Без такой точки атомарности два движка могут записать метаданные поверх друг друга, и состояние таблицы разойдётся.

Технический каталог данных координирует транзакции файлового слоя, а не просто хранит схемы.

Технический каталог против бизнес-каталога

Эти классы продуктов решают разные задачи и не заменяют друг друга.

Путаница начинается, когда продукт умеет выполнять обе роли. DataHub известен как бизнес-каталог, но включает технический Iceberg-каталог. Это разные подсистемы в одном развёртывании, с разными требованиями к надёжности и эксплуатации.

Продукты сравниваются по трём группам критериев.

• Протоколы, форматы и файловые системы: что каталог отдаёт движкам и с какими хранилищами работает. Здесь возникает vendor lock-in.
• Безопасность: есть ли ролевая модель внутри каталога и умеет ли он выдавать временные учётные данные для доступа к хранилищу.
• Обслуживание таблиц: участвует ли каталог в компакции, истечении снапшотов и удалении осиротевших файлов.

Поддерживаемые форматы, протоколы и файловые системы

Iceberg закрепился как открытый формат таблиц, вокруг него выстраивается совместимость движков. Delta Lake остаётся родным форматом для экосистемы Databricks и читается внешними системами через слой совместимости. Hudi сохраняет позиции в потоковых сценариях.

Для технического каталога важнее протокол, чем табличный формат. Формат описывает размещение файлов, протокол — взаимодействие движка с каталогом. Iceberg REST Catalog — открытая спецификация HTTP API для каталожных операций. REST-совместимый движок подключается к любой совместимой реализации заменой адреса в конфигурации.

Hive Thrift API пришёл из Hadoop-эпохи и поддерживается ограниченным набором движков. Проприетарные REST-диалекты работают в пределах экосистемы конкретного вендора. При смене каталога через два года данные останутся в хранилище, но потребуется перенести регистрацию таблиц, настройки движков и политики доступа.

Критерии отбора: on-prem, S3 и HDFS

Все девять продуктов поддерживают S3-совместимые хранилища, но с разными ограничениями. Часть каталогов тестируется только с AWS S3 и MinIO. DataHub Iceberg Catalog прямо ограничен AWS S3.

HDFS для российского рынка остаётся важным legacy-слоем. Из девяти продуктов HDFS документирован у трёх: Apache Amoro, Apache Gravitino и CedrusData Catalog. У Lakekeeper HDFS нет ни в списке поддерживаемых хранилищ основной ветки, ни в актуальном релизе. Polaris ограничен S3, Azure и GCS.

Federation-коннекторы Polaris к Hive и Hadoop подключают внешние каталоги, но не добавляют поддержку HDFS как хранилища данных. Эти сценарии не стоит смешивать.

Безопасность в Lakehouse-каталоге: единая модель против распределённой

В Hadoop-мире права доступа часто выносят за пределы технического каталога — в Apache Ranger или движок политик вроде OPA. Такая схема работает, но в гетерогенном Lakehouse у неё есть слабые места.

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

Большинство новых каталогов переносят авторизацию внутрь продукта. Каталог видит клиентов и таблицы, поэтому применяет единую модель прав в одной точке. Встроенная ролевая модель есть в Polaris, Lakekeeper, Gravitino и DataHub Iceberg Catalog.

Credential vending и remote signing

Ролевая модель отвечает на вопрос, кому доступен объект. Отдельно нужно решить, как движок получит доступ к файлам в хранилище.

Credential vending. Каталог проверяет права и выдаёт короткоживущие учётные данные с доступом только к путям конкретной таблицы. Постоянного ключа от бакета у движка нет. Polaris поддерживает AWS, Azure и GCS. Gravitino работает с теми же провайдерами и с OSS.

Remote signing. Движок не получает даже временный ключ. Он формирует запрос к объектному хранилищу, отправляет заголовки каталогу, а каталог проверяет операцию и подписывает запрос своими учётными данными. В обзоре такую модель реализует только Lakekeeper.

Обслуживание таблиц Iceberg: зачем каталогу знать о компакции

Почему таблицы деградируют

Iceberg применяет изменения двумя способами. Copy-on-Write переписывает файлы данных при каждом обновлении: чтение остаётся быстрым, но запись обходится дорого. Merge-on-Read создаёт отдельные файлы удалений, которые движок учитывает во время чтения. Запись дешевле, но со временем чтение замедляется.

При частых обновлениях накапливаются мелкие файлы, delete-файлы, старые снапшоты и осиротевшие объекты. Для обслуживания нужны компакция, истечение снапшотов, удаление осиротевших файлов и переупорядочивание данных. Эти операции требуют вычислительных ресурсов, поэтому важен не сам факт их запуска, а система, которая определяет момент запуска.

Каталог видит изменения таблицы целиком: кто и когда записывал данные, как часто приходят коммиты, сколько накопилось снапшотов и файлов удалений. Движки в платформе могут меняться, каталог обычно остаётся. Поэтому ему удобно хранить правила и координировать обслуживание.

Продукты из обзора делятся на три группы.

• Apache Amoro с сервисом AMS, Gravitino и Lakekeeper сами исполняют обслуживание таблиц.
• Polaris хранит правила, но не запускает задачи сам. С версии 1.0.0 в нём есть четыре предопределённые политики обслуживания, а исполняет их внешняя система.
• Hive Metastore, открытая редакция Unity Catalog, DataHub и Nessie не участвуют в полноценном обслуживании. У Nessie для очистки есть отдельный Nessie GC, но компакции он не выполняет.

Hive Metastore 4.2.0: legacy-стандарт с REST-каталогом

Метастор вырос из Hadoop. Первый коммит будущего Hive появился в репозитории Apache 2 сентября 2008 года: это был contrib-модуль с описанием a sql-like query processing tool, добавленный Ashish Thusoo из Facebook. В число проектов верхнего уровня ASF Hive вошёл позже, и эти две даты часто смешивают.

Метастор хранит схемы, разделы и адреса файлов, взаимодействует с клиентами по Thrift. Веб-интерфейса в нём нет. В конфигурации версии 4.2.0 отсутствуют ключи для UI.

Главное изменение последних двух лет — собственный Iceberg REST Catalog. Модуль standalone-metastore/metastore-rest-catalog появился в версии 4.1.0 от 30 июля 2025 года, а не в 4.2.0. В тегах 4.0.0 и 4.0.1 его нет, в 4.1.0 и 4.2.0 он присутствует.

Модуль входит в стандартную сборку, но по умолчанию отключён: порт сервлета metastore.catalog.servlet.port равен -1, а отрицательное значение выключает сервлет. Для аутентификации доступны none, simple, jwt и oauth2. По умолчанию используется JWT.

Официальный статус зрелости реализации не указан. В релизных заметках и описаниях конфигурации нет ни пометки experimental, ни заявления о готовности для production. В версии 4.2.0 добавили OAuth 2, ViewCatalog через Iceberg REST и docker-compose для проверки совместимости REST-каталога с Gravitino и Polaris.

Когда Hive Metastore остаётся оправданным

Если инфраструктура строится вокруг Hadoop, Spark и Hive, а переход к Lakehouse не планируется, менять метастор может быть дороже, чем сохранить его. Ролевой модели внутри Hive Metastore нет, поэтому права приходят извне — из Apache Ranger или слоя HiveServer2.

Аутентификация остаётся гибкой: доступны Kerberos через SASL, LDAP, JWT и подключаемый пользовательский класс. Для нового Lakehouse Hive Metastore выглядит слабым кандидатом, но как исходная точка миграции он вполне пригоден.

Project Nessie 0.108.4: git-семантика для набора таблиц

Nessie версионирует каталог целиком. Один коммит меняет состояние нескольких объектов, а последовательность изменений на ветке становится доступна остальным после одной операции слияния. Это подходит для веток под ETL-прогоны, тегов для воспроизводимости обучающих выборок и отката группы витрин одним действием.

С термином WAP нужна осторожность. Write-Audit-Publish в документации Nessie не используется. Механика для такого паттерна есть: ветка, ревью, слияние и мультитабличный коммит. Но сам ярлык пришёл из сторонних материалов.

Слово «транзакции» тоже требует уточнения. Проект отдельно оговаривает, что полноценные кросс-табличные транзакции в смысле классического хранилища ещё находятся в разработке. Коммит Nessie не стоит приравнивать к транзакции базы данных.

Nessie поддерживает выразительные правила доступа на CEL с детализацией до ветки и пути. Например, можно разрешить чтение определённого объекта только на ветке prod пользователям с конкретными ролями.

Ограничение встроенной авторизации известно: она контролирует доступ к метаданным, но не защищает данные от прямого обращения к объектному хранилищу в обход Nessie. Для production-контура нужен внешний слой прав на уровне хранилища.

Репозиторий остаётся активным: с февраля по июль 2026 года вышло десять релизов, примерно 1,7 в месяц. При этом Dremio ещё в 2024 году сообщала о переносе усилий в Polaris. Полного объединения проектов пока нет: Nessie сохраняет собственный релизный цикл и не упоминается в документации федерации Polaris.

Nessie можно подключить к Polaris как пользовательскую реализацию Iceberg REST через общую REST-федерацию. Но эта связка опирается на два незавершённых компонента: экспериментальный REST-эндпоинт Nessie и обобщённую федерацию Polaris.

Apache Polaris 1.7.0: нейтральный каталог под управлением ASF

Главным событием 2026 года для Polaris стал выход из инкубатора Apache. Проект перешёл в статус Top-Level Project. Это важно для управления: Polaris больше не воспринимается только как проект Snowflake и развивается по правилам ASF.

Сравнения, где Polaris указан в версиях 1.2.0 или 1.3.0, уже описывают состояние полугодовой давности. Актуальная версия на 18 августа 2026 года — 1.7.0, выпущенная 2 августа.

Credential vending и Generic Tables

Выдача временных учётных данных — сильная сторона Polaris. Функция работает в AWS, Azure и GCS. Клиент запрашивает делегирование через заголовок X-Iceberg-Access-Delegation.

Generic Tables расширяют каталог за пределы Iceberg: в нём можно зарегистрировать Delta, CSV и другие форматы как таблицы общего вида. В версии 1.7.0 функция остаётся в статусе beta.

Ограничения существенные. Для generic-таблиц нет спецификации схемы и партиционирования, Polaris не координирует их коммиты, а обновление выполняется удалением и повторным созданием. Credential vending для таких таблиц тоже недоступен. Для второго формата не работает основная функция безопасности каталога.

Эксплуатация и ограничения

Self-hosted Polaris — приложение на Quarkus и JVM, которому нужно внешнее хранилище состояния: реляционный backend через JDBC или MongoDB в статусе beta. Поддерживается Kubernetes 1.33 и новее.

Рекомендуемые размеры pod и параметры production-развёртывания стоит дополнительно сверить с актуальной документацией Polaris. Управляемый вариант представлен Snowflake Open Catalog. Статус тарификации REST API также требует проверки: заявленный ранее срок запуска уже прошёл.

В Polaris нет интеграции с LDAP напрямую: внешняя идентичность подключается через OIDC-провайдера. HDFS в качестве хранилища данных не поддерживается. Каталог хранит четыре политики обслуживания таблиц, но не запускает задачи сам. Механизм polling ему приписывать не стоит.

Unity Catalog 0.5.1: открытая редакция как витрина, а не каталог записи

Открытую редакцию Unity Catalog ведёт LF AI & Data. Проект находится в статусе sandbox, а API продолжают меняться и не считаются стабильными.

Совместимость с Iceberg строится через UniForm. Таблица остаётся Delta-таблицей, но содержит метаданные обоих форматов. Внешние движки читают её через Iceberg REST Catalog по адресу /api/2.1/unity-catalog/iceberg/.

В документации нет прямой формулировки «только чтение», но это видно по набору маршрутов сервиса. Реализованы получение конфигурации, пространств имён и таблиц. Маршрутов для создания, обновления, коммита и удаления таблиц нет. Запрос представления завершается исключением this is not supported yet.

Roadmap подтверждает это ограничение. Нативные Iceberg-таблицы с чтением и записью запланированы для версии 0.7 и выше, поддержка Iceberg-представлений — для 0.8 и выше.

Разрыв между открытой и управляемой версиями

По governance открытая редакция Unity Catalog заметно отстаёт от управляемой версии. Ролевой модели нет: привилегии выдаются напрямую конкретному принципалу, а пользователей администратор создаёт через CLI.

RBAC, фильтры на уровне строк, маски колонок и происхождение данных заявлены в roadmap для версий 0.8 и выше. Аудит также остаётся в планах. Поддержка S3-совместимых хранилищ указана для 0.8+, поэтому работа с не-AWS S3 пока не заявлена как готовая.

Веб-интерфейс в открытой редакции есть и запускается отдельным приложением. В нём можно создавать и удалять каталоги и схемы, просматривать метаданные и редактировать описания таблиц и функций. Обслуживания Iceberg-таблиц нет ни в текущем продукте, ни в roadmap.

Apache Amoro (incubating) 0.8.1: обслуживание таблиц как основная функция

Продукт остаётся в инкубаторе Apache и не входит в число проектов верхнего уровня. Файл DISCLAIMER есть и в теге релиза, и в основной ветке на 18 августа 2026 года. Каноническое название — Apache Amoro (incubating), без скобок его лучше не писать.

Mixed-формат: оптимизация на уровне архитектуры хранения

В основе Mixed-формата лежит разделение таблицы на два хранилища одного формата. BaseStore держит основную массу данных, обычно сформированную batch-вычислениями или оптимизационными процессами. ChangeStore принимает поток изменений в реальном времени и служит источником для CDC.

Опциональный LogStore работает как кэш поверх ChangeStore на базе очередей Kafka или Pulsar. Основные хранилища используют Iceberg с одинаковой раскладкой файлов. При чтении данные объединяются по схеме Merge-on-Read, а минорная оптимизация поддерживает свежесть BaseStore примерно на минутном уровне. В сценариях с частыми обновлениями это снижает write amplification.

Помимо Mixed-Iceberg, AMS работает с Iceberg, Mixed-Hive и Paimon.

AMS: диспетчеризация оптимизаций

Amoro Management Service по заданным порогам определяет, какие объекты требуют оптимизации, и запускает задания в контейнерах оптимизаторов: локальном, Kubernetes, Flink, Spark или внешнем. Документация противоречит сама себе: во вводном абзаце названы четыре типа, ниже описан пятый. Поэтому лучше перечислять поддерживаемые типы, не указывая их количество.

Amoro можно использовать рядом с другим Lakehouse-стеком. AMS отдаёт Iceberg REST API и подключает внешние REST-каталоги, включая Nessie.

Ограничение: аутентификация без ролевой модели

Amoro поддерживает режимы аутентификации SIMPLE, KERBEROS, AK/SK и CUSTOM, но многопользовательской модели прав в документации нет. Сервис управляется одной административной учётной записью.

Термин RBAC в документации Amoro встречается, но относится к Kubernetes RBAC для сервисного аккаунта в Helm-чарте. При беглом чтении это легко принять за ролевую модель самого каталога.

Для единого governance-слоя в гетерогенной среде Amoro не подходит. Зато он хорошо выглядит как сервис обслуживания Iceberg-таблиц рядом с отдельным каталогом, который отвечает за доступ и управление метаданными.

Apache Gravitino 1.3.0: federated metadata lake поверх разнородных источников

Gravitino позиционируется как federated metadata lake: он управляет метаданными в разных источниках и регионах, предоставляя единую точку доступа. Под источниками понимаются Hive, MySQL, MariaDB, HDFS и S3. Поверх них каталог добавляет управление доступом, аудит и обнаружение данных.

Так устроен класс metadata lake: Gravitino не заменяет существующие метасторы, а федерирует их. Одновременно он предоставляет нативный сервис Iceberg REST.

Лучше всего проработана интеграция с Trino. Коннектор автоматически загружает каталоги из Gravitino через динамические каталоги. На координаторе для этого нужен режим catalog.management=dynamic. У Spark и Flink покрытие уже.

Выдача учётных данных и обслуживание таблиц

Credential vending у Gravitino развит довольно подробно. Встроенные провайдеры есть для S3, GCS, ADLS и OSS. Поддерживаются выдача прав для IRSA и генерация IAM-политики для пути конкретной таблицы по заголовку X-Iceberg-Access-Delegation.

Начиная с версии 1.3.0 коннекторы Spark, Flink и Trino используют выданные учётные данные без ручной настройки.

В версии 1.2.0 появились не только описательные политики. Документация включает политику компакции Iceberg со стратегией iceberg-data-compaction, шаблоном задания, триггерами по метрикам файлов данных и delete-файлов, а также целевым размером файла 128 МиБ. В тегах 1.0.1 и 1.1.0 такого документа ещё не было.

Честная оценка зрелости

Gravitino вышел из инкубатора и стал проектом верхнего уровня ASF. DISCLAIMER.txt удалён из репозитория 22 мая 2025 года и отсутствует в тегах 1.0.0 и 1.3.0.

Ролевая модель заявлена в двух вариантах: RBAC с назначением привилегий ролям и DAC с владельцем объекта. Также заявлена передача прав в нижележащие системы, например Apache Ranger. Но в том же документе есть блок с противоположным утверждением: Gravitino «won't check the privileges» при получении запроса.

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

Если нужен только Iceberg-каталог, federated-слой Gravitino может оказаться избыточным.

Lakekeeper 0.13.3: Rust, remote signing и вложенные роли

Lakekeeper — единственный каталог в обзоре, написанный на Rust. Он поставляется одним бинарным файлом и не требует JVM или Python-окружения.

Для хранения метаданных и секретов нужен PostgreSQL 15 или новее. На этом внешние зависимости заканчиваются. На фоне JVM-сервисов, которым приходится подбирать heap-настройки, Lakekeeper выглядит более простой эксплуатационной единицей.

Линия 0.13 отстоит от 0.10.1 на три минорных версии и примерно на десять месяцев.

Что появилось в линии 0.13

Remote signing. Механика связана со свойствами signer.uri и signer.endpoint из Iceberg 1.11. Она покрывает листинги префиксов и generic-таблицы.

Вложенные роли. Роли можно включать друг в друга. Глубина вложенности настраивается и по умолчанию составляет 10 уровней. Пользователями и вложенными ролями управляют через единый API. Права выдаются на восьми уровнях: от сервера и проекта до отдельной таблицы и определения тега.

Generic Table API. С версии 0.13.0 Lakekeeper управляет не-Iceberg объектами. В документации прямо названы Lance, CSV и Parquet, Delta встречается в примерах консоли. API заявлен как формат-агностичный. При этом для функции нет пометки beta или GA, поэтому считать её полностью стабилизированной пока рано.

Ограничения и коммерческая редакция

LDAP поддерживается не как способ прямой аутентификации, а как источник ролей и групп. Можно настроить провайдеры, три режима разрешения групп, периодическую синхронизацию и кэширование в памяти. Сам каталог аутентифицирует пользователей через OIDC- или OAuth2-провайдера и сервисные аккаунты Kubernetes.

Для контура с Active Directory такая схема рабочая, но понадобится OIDC-прослойка.

В открытой редакции есть обслуживание таблиц: настраиваемое истечение снапшотов, удаление осиротевших файлов и устаревших metadata-файлов. Компакции нет ни среди готовых возможностей, ни в планах, опубликованных в документации.

Коммерческая редакция Lakekeeper Plus от Vakamo добавляет Cedar-авторизацию, аудит и SLA. По вторичным источникам, в ней также заявлено автоматическое обслуживание таблиц. Сертификацию Red Hat OpenShift проходит образ Plus, а не открытая сборка.

DataHub Iceberg Catalog: технический каталог внутри бизнес-каталога

Версия 1.0.0 в обзорах часто ошибочно подаётся как версия Iceberg-каталога. На деле это минимальная версия платформы DataHub, в которой доступна функция.

Ценность DataHub — в совмещении двух ролей. Он одновременно работает как технический каталог и как витрина данных для людей. Iceberg-таблица регистрируется в техническом каталоге, а затем становится обычным dataset в DataHub. Свойства, заданные через DDL, попадают в свойства датасета с префиксом TBLPROPERTIES.

Дальше вступает в работу слой бизнес-каталога: владельцы, теги, домены, поиск и та же ролевая модель. Политики настраиваются в интерфейсе DataHub и ограничиваются по складам, датасетам, контейнерам, тегам и доменам. Аутентификация строится на access token DataHub в Bearer-режиме, для публичных данных возможен анонимный доступ.

Ограничения собраны в документации отдельным списком. Для российского контура одно из них критично: поддерживается только AWS S3, а корневой путь хранилища должен начинаться с_ s3://_. Речь идёт не о S3-совместимых системах, а именно об AWS.

Мультитабличные транзакции не поддерживаются, операция очистки не реализована. Сбор метрик и обновление выданных учётных данных находятся в разработке. Credential vending уже есть, срок жизни выданных данных настраивается при создании склада.

CedrusData Catalog: Iceberg REST для российского контура

CedrusData Catalog реализует спецификацию Iceberg REST Catalog и подключается к совместимым движкам. Заявлены CedrusData, Trino, Apache Spark и Apache Flink. В нативном режиме с CedrusData Engine добавляются материализованные представления.

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

• Три класса файловых систем: S3 со статическими или временными STS-ключами, HDFS с core-site.xml, hdfs-site.xml, Kerberos и имперсонацией, а также локальная файловая система, включая tmpfs, NFS и FUSE.
• Аутентификацию постоянными и временными access token, логином и паролем, OAuth 2.0 Client Credentials, а также Bearer-аутентификацию для Iceberg REST. Kerberos отвечает за доступ к HDFS, а не за аутентификацию пользователя.
• Истечение снапшотов и удаление осиротевших файлов вручную или по cron-расписанию. Запуск по расписанию появился в релизе 458-12 от 8 июля 2025 года.
• Глобальный time travel, Web UI с навигатором объектов, CLI поверх Management REST API и метрики через JMX, OpenMetrics и OpenTelemetry.
• Агрессивное кэширование, которое, по заявлению вендора, убирает обращения к S3, HDFS и PostgreSQL с горячего пути.

Связка с российским стеком и VK Tech

26 марта 2026 года команда CedrusData вошла в VK Tech. CedrusData Engine и CedrusData Catalog названы частью усиления VK Data Platform, которую строят поверх S3-совместимого VK Object Storage и колоночной базы Tarantool Column Store.

Каталог рассчитан на S3-совместимые хранилища. VK Object Storage относится к этому классу, а совместимость с ним ранее заявлялась для CedrusData Engine. При этом публичного подтверждения нативной интеграции именно CedrusData Catalog с объектным хранилищем VK Cloud пока нет. Этот момент лучше сверить перед публикацией.

Для российского контура важен и реестровый статус. CedrusData Catalog внесён в реестр отечественного ПО под номером 27155 от 19 марта 2025 года, правообладатель — ООО «Кверифай Лабс». Запись № 15789 от 5 декабря 2022 года относится к CedrusData Engine, и для закупок эти номера важно не перепутать.

Продукт бесплатен для разработки, тестирования и промышленной эксплуатации, коммерческая поставка добавляет поддержку. Тип лицензии стоит уточнить по актуальному EULA: доступные формулировки источников расходятся.

Итоговая таблица: девять технических каталогов данных по 14 критериям

Таблица отражает состояние продуктов на 18 августа 2026 года. За предыдущий год Polaris сменил статус и пять версий, Lakekeeper прошёл три минорные линии, а у Gravitino появилось обслуживание таблиц. Сравнение без даты быстро вводит в заблуждение.

Пометки «нет» и «не заявлено» означают разное. «Нет» означает, что функция отсутствует и это подтверждено документацией, включая отрицательные свидетельства. «Не заявлено» означает, что публичного подтверждения нет. Это повод уточнить детали у вендора, а не дополнять картину догадками.

Как выбрать: четыре сценария

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

Заключение

Технический каталог в Lakehouse давно перестал быть реестром таблиц. Iceberg REST API есть почти у всех кандидатов, а Parquet-файлы и метаданные Iceberg переживут смену движка. Сложности начинаются вокруг прав доступа, учётных данных к хранилищу, обслуживания таблиц и координации параллельных записей. Hive Metastore остаётся рабочим выбором для привычного Hadoop-стека, но для нового Lakehouse быстро упирается в внешние системы прав и старый Thrift-контур. Polaris подходит для нейтрального multi-engine Lakehouse с RBAC и credential vending, Lakekeeper интересен remote signing и более простой Rust-эксплуатацией, а Nessie остаётся единственным вариантом, если действительно нужны ветки, теги и слияния состояния набора таблиц.

Amoro разумнее воспринимать как машину обслуживания Iceberg-таблиц, а не как единый центр governance: он особенно полезен там, где потоковые обновления превращают таблицы в склад мелких файлов и delete-файлов. Gravitino пригодится в неоднородной инфраструктуре, где нужно собрать под одним слоем Hive, HDFS, S3 и реляционные источники. Открытая редакция Unity Catalog пока выглядит скорее как витрина совместимости, DataHub Iceberg Catalog хорош связкой технического и бизнес-каталога, но ограничен AWS S3. CedrusData Catalog рассчитан на российский on-prem-контур с HDFS, VK Object Storage, S3-совместимым хранилищем того же вендора, что даёт бесшовную интеграцию без дополнительной настройки совместимости, — с русскоязычной документацией и поддержкой, но LDAP, автоматическое обслуживание и отдельные детали модели прав стоит проверять на пилоте, а не засчитывать по roadmap.

Выбирать каталог по числу галочек в таблице — примерно как выбирать базу данных по цвету логотипа. Сначала стоит зафиксировать неснимаемые ограничения: нужен ли HDFS, обязателен ли S3-совместимый on-prem, допустимы ли постоянные ключи от бакетов, нужны ли ветки данных, встроенная компакция и единая модель прав. Затем кандидатов надо проверить на стенде с реальными Trino, Spark, Flink, объектным хранилищем и SSO: выполнить параллельные коммиты, отозвать доступ, накопить мелкие файлы и посмотреть, кто будет разбираться с последствиями в три часа ночи.