Выбор каталога для Iceberg на своём железе

Lakekeeper и Apache Polaris решают одну и ту же задачу: хранят указатели на актуальные версии таблиц Iceberg, выполняют коммиты и проверяют права доступа. Без надёжного каталога даже правильно записанные parquet-файлы быстро теряют целостность при параллельной работе Spark, Trino и ClickHouse. Выбор каталога по весу сравним с выбором самой СУБД, потому что именно он определяет, можно ли безопасно менять схему и кто получит доступ к свежим данным. Iceberg здесь выступает как формат таблиц, который отделяет сами данные от метаданных и позволяет нескольким аналитическим системам работать с одними и теми же файлами без конфликтов. Каталог же становится центральной точкой, где фиксируются версии таблиц и правила доступа, поэтому его отказ или ошибка сразу отражаются на всей экосистеме.

Оба проекта реализуют REST-каталог, но отличаются стеком, моделью прав и возможностями встраивания проверок. REST-каталог — это стандартный способ взаимодействия через HTTP-запросы, который поддерживают большинство движков обработки данных и не требует установки клиентских библиотек под конкретный язык. Lakekeeper поставляется одним бинарником на Rust и использует обычный Postgres для хранения метаданных. Apache Polaris написан на Java, содержит встроенный RBAC в два уровня и умеет федеративно подключать внешние каталоги. RBAC (Role-Based Access Control) означает назначение прав через роли, а двухуровневая модель позволяет задавать политики как для всего каталога целиком, так и для отдельных таблиц. Федерация даёт возможность подключать уже существующие каталоги как источники данных без их миграции.

Lakekeeper добавляет механизм ContractVerification. Перед коммитом он может проверить, что новая версия таблицы не нарушает заранее заданные контракты данных. Это позволяет отклонить изменение, которое ломает downstream-отчёты или схему, без написания отдельного слоя валидации. Контракты данных здесь — это заранее описанные правила о структуре таблиц, типах полей и допустимых значениях, которые защищают потребителей от неожиданных изменений. Права доступа описываются через OpenFGA и хранятся в отдельной таблице Postgres, что упрощает аудит. OpenFGA — это система управления доступом на основе отношений, которая позволяет задавать сложные политики в виде графов и легко проверять, кто и к каким таблицам имеет доступ.

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

В российском контуре важнее всего возможность развернуть всё на своём железе без внешних зависимостей. Lakekeeper с Postgres и OpenFGA укладывается в типичный банковский стек: RustFS для объектного хранилища, SeaTunnel и NiFi для загрузки, Trino и ClickHouse для чтения. Такой набор удалось поднять за три дня и через три недели вывести в тестовую эксплуатацию. Polaris требует больше ресурсов на Java-машину и сложнее интегрируется с Postgres-окружением, поэтому чаще выбирают Lakekeeper, когда критична простота и скорость запуска. При выборе важно учитывать, что Rust-бинарник проще в сопровождении и потребляет меньше памяти, тогда как Java-решение требует настройки JVM и мониторинга сборки мусора.

Ограничения и риски при выборе

Lakekeeper пока моложе Polaris и имеет меньшее сообщество. При высокой нагрузке на коммиты стоит проверить, как Postgres справляется с блокировками, и предусмотреть реплику для отказоустойчивости. ContractVerification требует явного описания контрактов, иначе механизм просто не сработает. Маленькое сообщество означает меньше готовых интеграций и примеров, поэтому часть работы по адаптации придётся делать самостоятельно.

Polaris даёт более зрелую модель прав, но требует настройки Java-окружения и мониторинга потребления памяти. Федерация внешних каталогов полезна только при наличии нескольких уже работающих систем; в зелёном проекте она добавляет лишнюю сложность. Двухуровневый RBAC даёт больше гибкости, однако его настройка занимает больше времени и требует глубокого понимания ролевой модели.

Что важно проверить перед внедрением

Перед выбором стоит протестировать оба каталога на реальном потоке коммитов из Spark и Trino. Особое внимание уделить времени отклика на commit и поведению при одновременных изменениях одной таблицы. Также нужно оценить, насколько легко интегрировать существующие политики доступа в OpenFGA или RBAC Polaris. Тестирование на реальных нагрузках помогает понять, выдержит ли каталог пиковые моменты и не возникнут ли блокировки, которые остановят работу аналитиков.

Ещё один момент — резервное копирование метаданных. Postgres в случае Lakekeeper резервируется стандартными средствами, а в Polaris придётся настраивать бэкап встроенного хранилища. Эти детали часто определяют, какой вариант быстрее пройдёт внутреннее security review. Security review обычно включает проверку аудита доступа, возможности шифрования и соответствия внутренним политикам хранения данных.

Итог по применимости

Lakekeeper удобнее, когда нужна быстрая установка на своём железе и возможность встроить проверки контрактов без дополнительных сервисов. Apache Polaris имеет смысл рассматривать, если уже есть опыт работы с Java-стеком и требуется двухуровневая модель прав с федерацией. В обоих случаях данные остаются в parquet-файлах, а каталог лишь управляет метаданными, поэтому переход между решениями возможен при наличии миграционного плана. При оценке стоит взвесить скорость развёртывания против зрелости правовой модели и объём ресурсов, которые придётся выделить на поддержку.

Источник

Это краткий разбор материала Habr. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: Выбор каталога для Iceberg на своём железе.

Курс по теме — Построение DWH на ClickHouse