Каталог данных: зачем нужен и как выбрать

17 сентября 2026 г.

Елена Шпрингер

Автор статьи

Каталог данных редко выбирают как самостоятельный продукт. Обычно он появляется в проекте Lakehouse вместе с вопросами попроще и важнее: где хранить метаданные Iceberg-таблиц, как дать Trino и Spark доступ к одной структуре, как фиксировать изменения без конфликтов и не раздавать постоянные ключи к S3 всем сервисам.

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

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

Статья подготовлена с экспертом

Павел Савченко, архитектор предпродажных решений

Зачем нужен каталог данных

В Lakehouse каталог данных — это реестр таблиц. Он хранит схему, расположение файлов в объектном хранилище, партиции и снапшоты, но не сами данные. Движок запросов обращается к каталогу при выполнении запроса и фиксирует через него изменения. Без каталога Trino или Spark не знают, что таблица существует.

Таблицу от набора файлов в S3 отличает указатель на актуальный снапшот. В объектном хранилище лежат Parquet-файлы и служебные метаданные формата, но каталог определяет, какая их комбинация соответствует текущей версии таблицы. Когда данные меняются, каталог атомарно переключает указатель на новый снапшот. Поэтому параллельные записи не портят таблицу, а разрешаются на уровне протокола коммита.

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

Управление метаданными

Технический каталог закрывает три задачи.

Поиск

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

В Iceberg REST для этого есть операции листинга пространств имён и таблиц:

GET /v1/{prefix}/namespaces
GET /v1/{prefix}/namespaces/{namespace}/tables

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

Схема

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

Доступ

Каталог может выдавать временные учётные данные для доступа к конкретной таблице:

GET .../tables/{table}/credentials

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

Технический каталог хранит структурные метаданные:

имена таблиц и колонок;
типы данных;
расположение файлов;
партиции;
снапшоты;
права доступа.

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

Time travel и эволюция схемы — свойства формата Apache Iceberg, а не конкретного каталога. Они работают и через Hive Metastore. Каталоги различаются протоколом, моделью доступа и эксплуатационными возможностями.

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

Прежде чем выбирать продукт, нужно понять, какой слой требуется. Технический каталог обслуживает машину, бизнес-каталог — человека. Общее у них только название.

Параметр сравнения	Технический каталог, metastore	Бизнес-каталог, governance
Кто использует	Trino, Spark, Flink, дата-инженер при настройке	Аналитик, data steward, владелец данных, комплаенс
Главный вопрос	Где таблица, какая у неё схема, какой снапшот актуален?	Что это за данные, кто владелец, откуда они пришли и можно ли им доверять?
Что хранит	Схему, расположение в объектном хранилище, партиции, снапшоты, указатели на файлы метаданных	Бизнес-глоссарий, владельцев, описания, теги чувствительности, метрики качества, lineage
Участвует в запросе	Да. Движок обращается к нему на каждом запросе, каталог участвует в коммитах	Нет. Работает рядом с конвейером и не входит в критический путь запроса
Протокол и интерфейс	Iceberg REST API, Thrift, JDBC	Веб-интерфейс, поиск, REST API для интеграций, сканеры источников
Цена ошибки	Запросы не выполняются, запись не фиксируется, смена движка усложняется	Данные не находят или им не доверяют
Примеры	Hive Metastore, реализации Iceberg REST, AWS Glue	DataHub, OpenMetadata, Amundsen
Чем не является	Не хранит глоссарий, владельцев и бизнес-описания	Не участвует в транзакциях и не даёт движку доступ к таблице

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

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

Iceberg REST и метаданные

Iceberg REST Catalog — открытая спецификация каталожных операций поверх HTTP. Она описывает работу с пространствами имён, таблицами, представлениями, коммитами, планированием сканирования и временным доступом к хранилищу.

Перед выбором каталога стоит проверить несколько возможностей протокола.

Коммиты входят в протокол

Изменения в таблице фиксируются запросом к каталогу. Для мультитабличной транзакции предусмотрена отдельная операция:

POST /v1/{prefix}/transactions/commit

Это часть спецификации Iceberg REST, а не отдельная функция конкретного вендора.

Доступ к хранилищу можно выдавать временно

Помимо временных учётных данных каталог может подписывать запросы к объектному хранилищу:

POST .../tables/{table}/sign

В этом режиме движку не нужны постоянные S3-ключи.

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

У views есть собственный набор операций: регистрация, загрузка метаданных, обновление и переименование.

Каталог может планировать чтение

Операции планирования сканирования возвращают движку готовый план чтения:

POST .../tables/{table}/plan

Зачем нужен открытый протокол

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

Iceberg REST задаёт общий HTTP-протокол. Движок реализует клиент один раз, каталог — серверную часть. После этого совместимые компоненты могут работать друг с другом без отдельной интеграции.

Поэтому к Lakehouse проще подключать сервисы на Python, Rust и Go, которым раньше приходилось использовать Thrift-клиенты, прокси или JVM-прослойку.

Iceberg REST в Trino и Spark

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

iceberg.catalog.type=rest
iceberg.rest-catalog.uri=https://catalog.example.internal
iceberg.rest-catalog.warehouse=analytics
iceberg.rest-catalog.security=OAUTH2
iceberg.rest-catalog.vended-credentials-enabled=true

Обязателен только iceberg.rest-catalog.uri — адрес REST-эндпоинта каталога.

Параметр warehouse задаёт идентификатор склада. Для iceberg.rest-catalog.security доступны режимы:

NONE — используется по умолчанию;
SIGV4;
GOOGLE;
OAUTH2.

Параметр vended-credentials-enabled включает доступ к хранилищу через учётные данные, которые выдаёт каталог.

В Spark каталог задаётся похожим образом:

spark.sql.catalog.rest_prod = org.apache.iceberg.spark.SparkCatalog
spark.sql.catalog.rest_prod.type = rest
spark.sql.catalog.rest_prod.uri = http://localhost:8080
spark.sql.catalog.rest_prod.warehouse = analytics

Значение uri зависит от типа каталога. Для hive это Thrift-адрес Hive Metastore, а для rest — HTTP-адрес каталога.

Spark поддерживает типы:

hive;
hadoop;
rest;
glue;
jdbc;
nessie.

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

Надпись «поддерживает Iceberg REST» тоже ничего не гарантирует сама по себе. У каталога может не быть части нужных операций или они могут работать иначе. Перед выбором проверьте конкретные эндпоинты, которые вызывает ваш движок.

Сравнение решений

Большинство современных технических каталогов поддерживает Iceberg REST: Polaris, Nessie, Unity Catalog OSS, Lakekeeper и CedrusData Catalog. Поэтому при выборе важнее смотреть не на саму поддержку Iceberg, а на эксплуатацию, модель управления проектом и дополнительные возможности.

Решение	Протокол каталога	Отличительные возможности	Когда уместен
Hive Metastore	Thrift, JDBC	Унаследованный стандарт, метаданные в реляционной БД	Миграция с Hadoop, если Hive Metastore уже используется
Apache Nessie	Iceberg REST с расширениями	Git-семантика: ветки, теги, merge, атомарные транзакции между таблицами и пространствами имён	Эксперименты над продовыми данными, изолированные ветки ETL
Apache Polaris	Iceberg REST	Вендор-нейтральный проект Apache Software Foundation	Нужен независимый каталог с открытой моделью развития
Unity Catalog OSS	Iceberg REST и Hive Metastore API	Работа с Delta Lake, Iceberg и Hudi через UniForm	Смешанный парк форматов и постепенный уход от HMS
Lakekeeper	Iceberg REST	Реализация на Rust, выдача временных учётных данных, удалённая подпись запросов, события изменений	Лёгкий self-hosted-каталог без JVM-стека
CedrusData Catalog	Iceberg REST	Java 21, кэширование метаданных, Web UI, RBAC, обслуживание Iceberg-таблиц	Российский контур, self-hosted, бесплатная лицензия

Hive Metastore

Hive Metastore хранит метаданные в реляционной базе, а клиенты обращаются к нему через Thrift. Его стек исторически ориентирован на JVM. Python-клиенты, Go-сервисы и cloud-native-приложения обычно подключаются через сторонние Thrift-клиенты или прокси.

При большом количестве таблиц и партиций могут возникать дополнительные задержки на листинге, а база метаданных получает заметную нагрузку. У HMS нет штатной выдачи временных учётных данных, а возможности RBAC ограничены экосистемой Hadoop.

При этом заменять Hive Metastore имеет смысл не всегда. Если весь парк движков уже читает таблицы через HMS, миграция станет самостоятельным проектом. Без конкретной задачи она может не дать быстрой пользы.

Apache Polaris, Nessie и Unity Catalog OSS

Apache Polaris — каталог Iceberg REST под управлением Apache Software Foundation. Он подходит для команд, которым важна вендор-нейтральная модель развития и совместимость с разными движками и клиентами Iceberg.

Project Nessie добавляет Git-подобную модель работы с данными: ветки, теги, merge и транзакции между несколькими таблицами. Это удобно для экспериментов и изолированных изменений в ETL, но добавляет отдельный слой в эксплуатацию.

Unity Catalog OSS поддерживает и Hive Metastore API, и Iceberg REST. Он пригодится в смешанном ландшафте, где одновременно используются Delta Lake, Iceberg и Hudi. Управляемая версия Unity Catalog в Databricks и открытая версия отличаются по набору возможностей.

Публичных данных о долях рынка Polaris, Nessie, Unity Catalog и Lakekeeper нет, поэтому выбирать по популярности здесь не из чего. Подробное сравнение решений есть в обзоре рынка технических каталогов данных.

Бизнес-каталоги

Бизнес-каталоги находятся в другом классе продуктов. Среди open-source-решений есть DataHub, OpenMetadata и Amundsen.

В России для задач Data Governance используется Arenadata Catalog: он объединяет каталог метаданных, бизнес-глоссарий, поиск, профилирование и lineage. В enterprise-сегменте также встречаются Atlan, Collibra и Alation.

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

Критерии выбора

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

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

Какой каталог нужен

Технический и бизнес-каталоги решают разные задачи. Обычно они дополняют друг друга. Ошибка на старте — смешать в одном требовании протокол коммита таблиц и бизнес-глоссарий.

Вопрос вендору: продукт участвует в протоколе коммита таблиц или только читает метаданные?

Поддержка Iceberg REST

Открытый REST-протокол упрощает смену движка и каталога. Но важно проверить полноту поддержки.

Вопрос вендору: какие эндпоинты Iceberg REST реализованы, проходит ли продукт REST Compatibility Kit и с какими особенностями?

Доступ к объектному хранилищу

Проверьте, умеет ли каталог выдавать временные учётные данные и подписывать запросы к S3-совместимому хранилищу. Постоянные ключи S3 у каждого клиента плохо масштабируются и усложняют аудит.

Вопрос вендору: поддерживаются ли операции /credentials и /sign?

Масштаб метаданных

Оцените количество таблиц и партиций, а также частоту коммитов. HMS может упираться в Thrift и нагрузку на реляционную БД. REST-каталоги обычно масштабируют репликами, а состояние хранят во внешней базе.

Вопрос вендору: как меняется время ответа при вашем количестве таблиц, партиций и одновременных запросов?

RBAC и мультиарендность

Проверьте, нужны ли пользователи, группы, гранулярные права и аудит на уровне самого каталога.

Вопрос вендору: на каком уровне задаются права — каталог, namespace или таблица?

Git-семантика

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

Вопрос вендору: как ветки каталога соотносятся с вашим процессом разработки и релизов витрин?

Эксплуатация

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

Вопрос вендору: кто запускает обслуживание — сам каталог, движок или внешний планировщик?

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

Для on-premise-развёртываний могут быть важны реестр отечественного ПО, сертификация, совместимость с локальными объектными хранилищами и поддержка на русском языке.

Вопрос вендору: есть ли запись в реестре и с какими S3-совместимыми хранилищами продукт проверен?

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

CedrusData Catalog

CedrusData Catalog — технический каталог метаданных для Lakehouse и озера данных с Iceberg REST API. Метаданные хранятся в PostgreSQL или SQLite, а сами данные могут находиться в S3 или HDFS.

Базовая версия распространяется бесплатно по открытой лицензии. Коммерческая версия включает техническую поддержку.

Технический каталог Iceberg REST

CedrusData Catalog написан на Java 21. Сервер кэширует метаданные в памяти, чтобы реже обращаться к внешним системам.

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

Нативный рантайм на Rust относится к CedrusData Engine, а не к Catalog. Архитектура самого каталога остаётся плагинной, как у Engine и Trino.

Для эксплуатации доступны:

Catalog Web UI;
RBAC с пользователями и группами;
управление обслуживанием Iceberg-таблиц;
навигатор объектов.

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

CedrusData Catalog и CedrusData Engine — разные продукты. Их не стоит путать при проверке записи в реестре и требований к лицензированию.

FAQ

Зачем нужен метастор?

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

Чем технический каталог отличается от бизнес-каталога?

Технический каталог нужен движку запросов. Он отвечает на вопрос, где находится таблица и какая у неё структура.

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

Это не конкурирующие продукты, а два слоя одной платформы.

Что такое Iceberg REST?

Iceberg REST Catalog — открытая HTTP-спецификация для работы с пространствами имён, таблицами, представлениями, коммитами, мультитабличными транзакциями, планированием сканирования и временным доступом к хранилищу.

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

Как выбрать каталог?

Проверьте протокол, полноту поддержки Iceberg REST, модель доступа к объектному хранилищу, RBAC, требования к рантайму и обслуживание Iceberg-таблиц.

Поддержка REST не бинарна. Важно проверить, какие операции реализованы и совместимы ли они с вашим движком.

Что предлагает CedrusData Catalog?

CedrusData Catalog — технический каталог с Iceberg REST API. Он хранит метаданные в PostgreSQL или SQLite, использует кэширование в памяти и работает с S3 или HDFS.

В каталоге есть Web UI, RBAC с пользователями и группами, управление обслуживанием Iceberg-таблиц и навигатор объектов. Базовая версия распространяется по открытой лицензии.

Заключение

Технический каталог — часть рабочего контура Lakehouse. Через него движки находят Iceberg-таблицы, читают актуальные метаданные и фиксируют изменения. Если каталог недоступен, запросы и запись в таблицы могут остановиться, поэтому при выборе важны не только совместимость с движками и список API, но и эксплуатация: резервирование, мониторинг, обновления, аудит и обслуживание таблиц.

Iceberg REST уменьшает зависимость от конкретного продукта. Trino, Spark и другие совместимые клиенты подключаются к каталогу через общий HTTP-протокол, а смена реализации на уровне соединения часто сводится к настройке нового endpoint. Но это не отменяет проверки: у каталогов различаются поддерживаемые операции, RBAC, выдача временных учётных данных, механизмы аудита и обслуживания Iceberg-таблиц.

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

Выбирать каталог лучше от конкретного сценария. Сначала определить, какие операции должен выполнять движок, как будут выдаваться доступы к объектному хранилищу, нужны ли ветки и мультитабличные транзакции, кто будет обслуживать каталог и какие требования действуют для on-premise-контура. После этого список подходящих решений заметно сократится.