Unity Catalog, Apache Polaris, Nessie, CedrusData Catalog: сравниваем Iceberg-каталоги

Поменять Iceberg-каталог проще, чем кажется, пока речь идёт только о данных. Parquet-файлы остаются в объектном хранилище, Iceberg-метаданные читаются через открытый протокол, а новый endpoint добавляется в конфигурацию Trino или Spark несколькими строками. Сложности начинаются вокруг таблиц: права доступа, аудит, lineage, пользователи, правила обслуживания и привычные для команды сценарии работы.

Поэтому Unity Catalog, Apache Polaris, Nessie и CedrusData Catalog сравнивают не только по API и списку поддерживаемых форматов. Unity Catalog собирает governance вокруг Databricks. Polaris даёт нейтральный REST-каталог для нескольких движков и временные доступы к объектному хранилищу. Nessie нужен там, где важны ветки, теги и согласованные изменения набора таблиц. CedrusData Catalog рассчитан на self-hosted-развёртывание в российском контуре, с RBAC и поддержкой на русском языке.

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

Зачем нужен Iceberg-каталог

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

Коммит в Iceberg не перезаписывает данные. Он атомарно переключает этот указатель на новую версию метаданных.

Если второй движок начал работу с v3 и пытается закоммитить изменения после первого, каталог отклонит операцию: указатель уже ведёт на v4. Движок перечитает метаданные и повторит коммит поверх новой версии. Так Iceberg защищает таблицу от конфликтующих записей.

В HDFS состояние таблицы можно было обновить атомарным переименованием каталога. В объектном хранилище это не работает: переименование превращается в копирование файлов с последующим удалением и не даёт атомарности.

Iceberg решает эту задачу через каталог. Он хранит указатель на актуальный metadata-файл и переключает его при коммите. Поэтому каталог участвует в записи, а не только хранит схемы таблиц.

Что даёт каталог поверх коммита

Атомарный коммит — базовая функция. Дальше каталоги различаются возможностями вокруг него:

• Namespace и мультитенантность. Логическая иерархия каталогов, схем и таблиц, которая разделяет данные разных команд.
• Управление доступом. Права на namespace и таблицы, а в более развитых реализациях — на колонки и строки.
• Credential vending. Каталог выдаёт движку временные права на чтение конкретных файлов вместо постоянного ключа от бакета.
• Lineage и аудит. История изменений, происхождение данных, пользователи и выполненные операции.
• Федерация. Внешние каталоги подключаются как источники и становятся доступны через единую точку входа.
• Обслуживание таблиц. Компакция файлов, очистка осиротевших объектов, истечение снапшотов и другие операции жизненного цикла Iceberg.

Iceberg REST Catalog

Iceberg REST Catalog — открытая HTTP-спецификация для работы с namespace, таблицами, представлениями, метаданными, коммитами и снапшотами.

Раньше каждый движок приходилось отдельно интегрировать с каждым metastore. Для каждой пары «движок — каталог» нужен был свой коннектор и набор библиотек.

Iceberg REST задаёт общий протокол: движок реализует клиентскую часть, каталог — серверную. После этого Trino, Spark, Flink и другие совместимые клиенты могут работать с любым REST-совместимым каталогом по HTTP. Это упрощает подключение сервисов на Python, Rust и Go. Им не нужны Thrift-клиенты, прокси и JVM-прослойка. При смене REST-совместимого каталога файлы данных остаются в объектном хранилище. В конфигурации движка меняется endpoint, а Parquet-файлы и Iceberg-метаданные остаются на месте. Такой подход хорошо ложится на архитектуру с разделением compute и storage.

Но REST решает только задачу подключения. Пользователей, RBAC, аудит, lineage, правила обслуживания таблиц и внутренние настройки каталога придётся переносить отдельно.

Unity Catalog

Unity Catalog создавался как единый governance-слой Databricks. В одной модели он объединяет каталоги, схемы, таблицы, доступы, аудит, lineage и AI-объекты.

В 2024 году Databricks открыл исходный код Unity Catalog под лицензией Apache 2.0 и передал проект в LF AI & Data. Открытая и управляемая версии развиваются отдельно. По возможностям governance OSS-редакция заметно уступает управляемой версии Databricks.

Управляемые Iceberg-таблицы в Unity Catalog доступны в GA. Внешние движки могут создавать, читать и записывать их через UC Iceberg REST API.

Сильные стороны:

• Одна модель для Delta Lake и Iceberg. Таблицы обоих форматов используют общие права, политики и аудит.
• Развитая модель доступа. Права можно задавать через роли и атрибуты объектов.
• Lineage внутри Databricks. Система отслеживает происхождение данных вплоть до колонок.
• Поддержка AI-объектов. Модели, признаки и ноутбуки получают те же механизмы governance, что и таблицы.
• Поиск наборов данных. Unity Catalog выступает не только техническим каталогом, но и витриной данных для пользователей внутри организации.

Ограничения:

• Federated, или foreign, таблицы из внешних систем остаются read-only. Unity Catalog может выдать временные credentials для чтения, но не позволяет записывать в такие таблицы через каталог.
• Управляемый Unity Catalog работает в облаках Databricks: AWS, Azure и GCP. Для on-premise и российского контура остаётся OSS-редакция, в которой меньше governance-возможностей.
• В открытой версии нет встроенного lineage. Iceberg Views не отдаются внешним движкам через REST API. Управляемая и открытая редакции похожи названием и протоколом, но не равны по функциональности.
• При уходе с Unity Catalog данные можно перенести, но история governance остаётся внутри платформы. Аудит, lineage и накопленные политики доступа нужно переносить или строить заново.

Unity Catalog подходит командам, которые уже используют Databricks как основную платформу данных и хотят управлять Delta Lake, Iceberg, ML-активами и доступами в одной модели.

Apache Polaris

Apache Polaris появился в Snowflake, а затем был передан в Apache Software Foundation. В феврале 2026 года проект вышел из инкубатора и получил статус проекта верхнего уровня ASF.

Polaris больше не является каталогом Snowflake в организационном смысле. Проект развивается по правилам Apache, а исходный код и управление находятся вне одного вендора.

Polaris — stateless REST-сервис на JVM. Его состояние хранится во внешнем бэкенде. Для этого используются реляционные базы через JDBC или NoSQL-хранилища. Сервис можно масштабировать горизонтально: запустить несколько реплик за балансировщиком и вынести состояние в базу.

Credential vending

Одна из ключевых функций Polaris — credential vending. Движок не хранит постоянный ключ от бакета. Каталог проверяет права пользователя и выдаёт короткоживущие учётные данные только для нужной таблицы.

1. Trino → Polaris: «Нужны метаданные db.orders»

2. Polaris: Проверяет права пользователя в RBAC-модели

3. Polaris → IAM: Запрашивает временные credentials Scope: s3://lake/db/orders/* Права: чтение TTL: 1 час

4. Polaris → Trino: Возвращает metadata.json и временные credentials

5. Trino → S3: Читает только файлы db.orders и только в пределах TTL

У движка нет постоянного доступа ко всему бакету. Чтобы отозвать права, достаточно снять grant в каталоге, а не менять ключи во всех сервисах.

Polaris поддерживает S3, GCS и ADLS.

Generic Tables

Polaris умеет регистрировать не только Iceberg-таблицы. Через Generic Tables можно описывать Delta Lake, Hudi и CSV как внешние таблицы общего вида.

Это помогает в переходных сценариях, когда Lakehouse содержит несколько форматов. Generic Tables уже вышли из статуса beta, но в релизных материалах проекта не обозначены как GA.

Сильные стороны:

• Проект верхнего уровня Apache Software Foundation.
• Полноценная RBAC-модель и credential vending.
• Подходит для multi-engine-сценариев: Spark, Trino, Flink, Snowflake и PyIceberg.
• Поддерживает федерацию внешних каталогов, включая Hive, Hadoop и BigQuery.
• Есть управляемый вариант Snowflake Open Catalog.

Ограничения:

• В Polaris нет Git-ветвления на уровне каталога. Если нужны ветки, теги и merge для набора таблиц, придётся использовать другой слой, например Nessie.
• Polaris не выполняет обслуживание таблиц самостоятельно. Он хранит политики для компакции, очистки осиротевших файлов и истечения снапшотов, но запускает эти операции внешний движок или планировщик.
• Самостоятельная эксплуатация требует JVM-сервиса, внешней базы, мониторинга, обновлений и резервирования. Управляемый Snowflake Open Catalog упрощает эксплуатацию, но возвращает зависимость от Snowflake как оператора сервиса.

Polaris подходит командам, которым нужен нейтральный REST-каталог с RBAC, временными доступами к объектному хранилищу и поддержкой нескольких движков.

Project Nessie

Nessie появился в Dremio и решает задачу, которую другие каталоги обычно не закрывают: он версионирует состояние всего каталога.

Каждый коммит Nessie фиксирует набор metadata-указателей всех таблиц. Поэтому ветки, теги, слияния и откаты работают не для одной таблицы, а для согласованного набора.

main ──●─────●──────────────────────●──► Прод видит это состояние
         \                         /
          ●────●────●─────────────┘ Merge одним коммитом
       etl_2026_08 │
                   └── orders v7
                       customers v4
                       payments v9

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

Откат означает переключение main на предыдущий коммит. Все связанные таблицы возвращаются к согласованной версии одновременно.

Что даёт ветвление:

• Мультитабличные изменения. Набор таблиц можно переключить на новую версию одним merge, а не коммитить изменения по одной.
• Изолированные ETL-прогоны. Для эксперимента, теста или разбора инцидента создаётся отдельная ветка без копирования данных.
• Воспроизводимость ML. Обучающая выборка фиксируется тегом, а не отдельной выгрузкой в новый бакет.
• Согласованный rollback. После неудачной загрузки можно вернуть состояние нескольких таблиц одним действием.

Time travel и ветвление — разные механизмы. Time travel возвращает состояние одной Iceberg-таблицы по снапшоту. Это свойство формата Iceberg, которое доступно с разными каталогами. Nessie версионирует весь каталог и сохраняет согласованность между таблицами.

Ограничения: Nessie не даёт развитую гранулярную RBAC-модель. Для продуктивного контура права обычно закрывают внешним слоем авторизации или отдельным каталогом с RBAC.

• Nessie работает с Iceberg, включая Iceberg Views. Для других табличных форматов он не предназначен.
• История коммитов Nessie не заменяет lineage. Она показывает, какое состояние каталога было в конкретный момент, но не объясняет происхождение данных и преобразования между источником и витриной.
• Обслуживание вынесено в Nessie GC. Он умеет находить и удалять устаревшие объекты, но не выполняет компакцию данных.
• Nessie остаётся отдельным JVM-сервисом с JDBC-бэкендом, который нужно сопровождать.

В 2024 году Dremio заявляла о планах сблизить Nessie с Polaris. На август 2026 года Nessie остаётся активным проектом с собственными релизами. Планировать миграцию исходя из будущего слияния не стоит, но за роадмапом имеет смысл следить.

Nessie и Polaris вместе

Nessie и Polaris можно использовать вместе. Nessie хранит историю, ветки и теги, а Polaris выступает входной точкой с RBAC и credential vending.

Такой стек даёт Git-семантику данных и управляемый доступ, но добавляет второй сервис в эксплуатацию.

CedrusData Catalog

CedrusData Catalog — технический каталог, который реализует Iceberg REST Catalog API и подключается к совместимым движкам. Его можно использовать с CedrusData Engine, Spark или открытым Trino.

Каталог и CedrusData Engine развиваются одной командой, но Catalog не привязан к этому движку. Через REST-протокол он подключается к Spark и vanilla Trino так же, как другие реализации.

Помимо REST-режима, для CedrusData Engine доступен нативный режим. Он работает быстрее REST-подключения и открывает materialized views.

CedrusData Catalog бесплатен для разработки, тестирования и промышленной эксплуатации. Коммерческая подписка включает техническую поддержку. С марта 2026 года команда CedrusData входит в VK Tech.

Возможности каталога

На 13 августа 2026 года CedrusData Catalog поддерживает:

• Iceberg REST API;
• нативный режим для CedrusData Engine;
• materialized views в нативном режиме;
• RBAC с пользователями и группами;
• Web UI и навигатор объектов;
• pluggable-архитектуру для горизонтального масштабирования;
• global time travel для нескольких таблиц каталога;
• управление обслуживанием Iceberg-таблиц.

Каталог написан на Java 21. Метаданные хранятся в PostgreSQL или SQLite.

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

Российский контур

CedrusData Catalog работает с S3-совместимыми объектными хранилищами. В типовом стеке CedrusData Engine выполняет запросы, S3-хранилище содержит файлы, а Catalog хранит метаданные и правила доступа.

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

Развёртывание каталога и данных в российском контуре может упростить работу с инфраструктурными требованиями. Но применимость 152-ФЗ к конкретной системе определяется её назначением, моделью угроз и юридической оценкой, а не только выбором каталога.

Чем CedrusData Catalog отличается от Polaris и Nessie

У CedrusData Catalog другой набор компромиссов. Credential vending в продукте публично не заявлен: движок получает доступ к хранилищу через собственную конфигурацию, а не через короткоживущие токены, выданные каталогом.

Ветвления каталога тоже нет. Global time travel позволяет получить согласованное состояние таблиц на определённый момент, но не создаёт отдельную ветку, в которую можно записывать изменения и затем сливать их в основную. Для сценариев с изолированными ETL-прогонами, merge и откатом набора таблиц нужен Nessie или другой каталог с Git-семантикой.

Взамен CedrusData Catalog не требует собирать отдельную связку из каталога и внешнего слоя прав. В базовой поставке есть ролевая модель, пользователи, группы и Web UI. Для российского контура важны self-hosted-развёртывание, поддержка на русском языке и запись в реестре отечественного ПО.

Полная сравнительная таблица

Таблица отражает состояние продуктов на 13 августа 2026 года. Это важно: за последний год запись Iceberg внешними движками в Unity Catalog прошла путь от превью до GA, Polaris выпустил несколько новых версий, а заявленное в 2024 году объединение Nessie и Polaris до сих пор не завершено.

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

Как выбрать

Стек уже построен вокруг Databricks

Выбирайте Unity Catalog. Он нативно связан с платформой Databricks, даёт наиболее полный набор governance-возможностей, lineage и управление AI-объектами. С мая 2026 года внешние движки могут писать в управляемые Iceberg-таблицы через REST API.

Если поверх Databricks требуется нейтральный multi-engine-слой, Polaris разумнее рассматривать как дополнительный федеративный слой, а не прямую замену Unity Catalog.

Нужен multi-engine Lakehouse

Apache Polaris подходит для стеков, где нужно работать с несколькими движками и не привязываться к одной платформе. Он даёт RBAC, credential vending и федерацию внешних каталогов.

За это придётся платить эксплуатацией: в self-hosted-варианте нужно поддерживать JVM-сервис, внешнюю базу метаданных, резервирование, мониторинг и обновления. Snowflake Open Catalog снимает часть этой нагрузки, но становится управляемой точкой зависимости от Snowflake.

Нужны ветки и согласованные изменения таблиц

Nessie нужен для сценариев, где важны ветки данных, изолированные ETL-прогоны, воспроизводимые ML-эксперименты и атомарное переключение набора таблиц.

Права придётся закрывать отдельным уровнем. Это может быть внешний сервис авторизации или связка Nessie с каталогом, который умеет RBAC и credential vending. Также стоит следить за дальнейшим развитием отношений Nessie и Polaris, но не строить архитектурный план на обещанном, но не завершённом слиянии.

Нужен российский контур

Если важны self-hosted-развёртывание, запись в реестре отечественного ПО, поддержка на русском языке и поставка в собственный контур, подходит CedrusData Catalog.

Он работает как Iceberg REST-каталог, содержит ролевую модель и Web UI, а в связке с CedrusData Engine даёт нативный режим и materialized views. Для закупки используется запись в реестре № 27155.

Где остаётся lock-in

При смене Iceberg-каталога обычно не нужно переносить терабайты данных. Parquet-файлы и Iceberg-метаданные остаются в объектном хранилище. Таблицы нужно перерегистрировать, а движки — направить на новый endpoint.

Сложнее переносить то, что появилось вокруг таблиц:

• Аудит и lineage. У каждого каталога своя модель событий и происхождения данных. Полностью перенести эту историю обычно нельзя.
• Политики доступа. Роли, гранты и исключения приходится создавать заново. Здесь особенно легко потерять часть прежних ограничений.
• Подключения движков. Endpoint меняется быстро, но проверить придётся Trino, Spark, Flink, BI-инструменты, сервисные учётные записи и фоновые job.
• Рабочие привычки команды. Скрипты, дашборды, runbook и внутренняя документация часто привязаны к конкретному каталогу.

Реальный lock-in живёт в governance-слое, а не в Parquet-файлах. Данные можно перенести, а историю доступа, аудита и lineage — нет или только частично.

Если Lakehouse строится с нуля, лучше сразу выбрать REST-совместимый каталог. Права полезно хранить декларативно: в репозитории, в виде манифестов или инфраструктурного кода, а не только в настройках интерфейса. Тогда миграция RBAC превращается в применение конфигурации, а не в восстановление прав вручную.

Заключение

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

Unity Catalog удобен внутри Databricks, где governance, lineage, AI-объекты и данные уже живут в одной платформе. Apache Polaris подходит для нейтрального multi-engine Lakehouse с RBAC и временными правами к объектному хранилищу. Nessie нужен там, где важна Git-модель: ветки, теги, merge и согласованное состояние нескольких таблиц. CedrusData Catalog ориентирован на российский контур с self-hosted-развёртыванием, записью в реестре и поддержкой на русском языке.

Начинать стоит с REST-совместимого каталога и декларативной модели прав. Дальше решение зависит от того, нужна ли команде глубокая интеграция с Databricks, нейтральный multi-engine-слой, ветвление данных или поставка в российский контур.