Apache Iceberg. Каталоги
Адресная книга для ваших таблиц
Содержание
Данные vs метаданные: кто где живёт
Мы уже знаем, что Iceberg делит файлы на два слоя: данные (ваши записи в Parquet, ORC или Avro) и метаданные (манифесты, списки манифестов и файлы метаданных, которые следят за тем, что и где лежит).
Допустим, вы хотите выполнить запрос к таблице sales. Как Spark, Trino или Dremio узнают, где искать файл метаданных? Прописывать в каждом запросе путь вида s3://my-bucket/data/sales/metadata/00001-1234567890.metadata.json? Это было бы смешно, больно и вообще никому не нужно. Тем более, что этот путь меняется с каждым новым снапшотом.
Зачем Iceberg нужен каталог?
Нет, вы просто напишете select * from sales (хотя, надеюсь, не буквально select * против даталейка, вы поняли идею). Вот здесь и появляется каталог.
Каталог хранит простую карту: имя таблицы → расположение файла метаданных в вашем blob-хранилище. Что происходит дальше?
- Движок запросов спрашивает: «Эй, каталог, где
sales?» - Каталог отвечает: «А, файл метаданных — вот такой‑то путь в S3.»
- Движок читает метаданные, спускается по дереву (список манифестов → манифесты → файлы данных) — и готово.
После каждого коммита (новые данные, изменение схемы, обновление партиций) каталог атомарно обновляет указатель на актуальный файл метаданных. Хранить этот указатель — первая обязанность каталога.
Каталог — как дирижёр оркестра: сам не играет ни на одном инструменте, но точно знает, кто и когда должен вступить.
Атомарность и конкурентные записи
Каталог не просто хранит ссылку на метаданные — он гарантирует атомарность операций. Когда вы обновляете таблицу (добавляете данные, меняете схему), каталог атомарно переключает указатель со старого файла метаданных на новый. Это значит, что переключение происходит целиком или не происходит вообще — читатели никогда не увидят «полуобновлённое» состояние таблицы.
Именно атомарность даёт вам консистентные чтения (все читатели видят одинаковую версию данных) и безопасные параллельные записи (два писателя не испортят данные друг другу).
Если два писателя пытаются закоммитить изменения одновременно, победит только один. Второй писатель увидит конфликт и повторит попытку с актуальным состоянием таблицы.
Важно помнить: каталог координирует, но не пишет данные. Он не создаёт файлы данных, манифесты или метаданные — это делает ваш движок (Spark, Flink и т.д.). Каталог лишь отслеживает, какая версия сейчас текущая, и следит, чтобы коммиты не наступали друг другу на ноги.
Единый стандарт: REST Catalog
«А есть ли стандартный способ работы каталогов? Что‑то вроде общего API?» — спросите вы. Отличные новости: есть. Это спецификация Iceberg REST Catalog.
Сама спецификация — это не готовый продукт, а описание, как должен выглядеть REST‑интерфейс каталога. Iceberg предоставляет reference‑реализацию, но любой может сделать свою.
Среди open‑source реализаций можно назвать Apache Polaris, Nessie, Unity Catalog, Lakekeeper, Apache Gravitino . Одни ограничиваются базовыми функциями: отслеживание таблиц и указание на метаданные. Другие реализуют полную спецификацию и добавляют фичи управления: контроль доступа, lineage, аудит.
Спецификация также даёт переносимость: вы можете сменить реализацию каталога, не меняя формат таблиц, не переписывая запросы и не трогая данные.
Мультиформатные каталоги и тренды
Сейчас у вас, скорее всего, несколько каталогов: один для Iceberg, другой для Delta, третий для сырых Parquet‑файлов. Это неудобно. Новое поколение каталогов умеет работать со всеми форматами сразу.
Кроме того, каталоги обзаводятся продвинутыми возможностями:
- Git‑подобное версионирование метаданных — можно ветвить и мержить схемы таблиц, как код.
- Кросс‑регионовая репликация, синхронизация метаданных в реальном времени.
- Автоматическое обслуживание таблиц — компактизация файлов, очистка старых снапшотов.
Каталоги эволюционируют из простых «указателей» в мини‑центры управления для всего даталейка.
Что выбрать: облачные, REST или legacy?
Если вы уже используете облако, у каждого провайдера есть свои решения:
- AWS Glue (Amazon)
- Google BigLake (Google Cloud)
- Microsoft Purview (Azure)
Они работают с Iceberg, но на момент записи этого курса (конец 2025) ещё не полностью реализуют REST Catalog API.
Если у вас уже есть готовая инфраструктура — Iceberg может работать и с ней:
- Hive Metastore (классика, но без атомарных коммитов при конкурентных записях)
- JDBC‑базы данных
- Hadoop
Они не создавались специально для Iceberg, поэтому могут не поддерживать все фичи, зато дают быструю интеграцию.
Как принять решение?
Каталог не является опциональным — это обязательная часть Iceberg. Хорошая новость: вариантов много.
Выбирайте исходя из потребностей:
- REST Catalog — для гибкости и переносимости.
- Облачные каталоги — для удобства, если вы полностью в экосистеме провайдера.
- Hive Metastore — если вы до сих пор используете Hive и не готовы к миграции.
Нужны конкурентные записи? Ищите каталог с поддержкой атомарных коммитов. Нужна мультирегионность? Проверяйте репликацию. Как всегда — смотрите на матрицу возможностей на момент принятия решения, оценивайте свои потребности и идите на компромиссы.
Выбор каталога напоминает выбор квартиры: от него зависит, насколько комфортно вы будете жить в своём даталейке. Можно поселиться в хрущёвке (Hive Metastore), можно в smart‑house с умными замками (REST Catalog), а можно построить свой дворец (кастомная реализация). Главное — чтобы крыша не текла.
Что дальше?
В следующем уроке мы перейдём к практическому упражнению: создадим первую таблицу Iceberg, вставим данные и изучим снапшоты.