Lakehouse-каталоги: governance-плоскость для Iceberg/Delta
Введение
В уроке 02 мы рассмотрели data catalog платформы (OpenMetadata, DataHub, Amundsen, Collibra) — каталоги бизнес-метаданных, описывающие что есть в организации. Но в эру lakehouse появился второй слой каталогов: lakehouse-каталоги или table catalogs — Apache Polaris, Unity Catalog OSS, Lakekeeper, Apache Gravitino, Nessie. Это совсем другой уровень абстракции.
Lakehouse-каталог — это runtime governance plane для Iceberg/Delta таблиц. Он отвечает не на вопрос “что есть в нашей компании”, а на вопрос “может ли этот пользователь / engine / job прочитать эту таблицу прямо сейчас, и где её физически найти на S3”. В нём живут: namespace structure, table metadata locations, RBAC/ABAC/ReBAC правила, credential vending (выдача коротких scoped-credentials), lineage между snapshot-ами.
Без lakehouse-каталога Iceberg/Delta таблицы — просто Parquet файлы на S3 без governance. С каталогом они становятся управляемой data platform.
В этом уроке: пять major OSS каталогов 2026 года, что они различают, как выбрать, как мигрировать с Hive Metastore.
Что делает lakehouse-каталог
В отличие от data catalog (метаданные для поиска), lakehouse-каталог отвечает за операционные аспекты Iceberg/Delta таблиц:
| Функция | Описание | Зачем для governance |
|---|---|---|
| Namespace structure | Иерархия catalog → namespace → table | Логическое разделение domains, ownership |
| Metadata resolution | Engine спрашивает “где metadata для warehouse.orders” → catalog возвращает s3://path/metadata.json | Single source of truth для current snapshot |
| Atomic commits | Catalog атомарно меняет указатель на новый metadata.json | ACID гарантии для concurrent writers |
| RBAC / ABAC / ReBAC | Правила доступа к catalog/namespace/table | Кто может SELECT, INSERT, ALTER |
| Credential vending | Catalog выдаёт scoped STS credentials для S3 | Engine не знает root credentials, только short-lived |
| Lineage / audit | Журнал commits, snapshot history | Compliance trail, time-travel |
| Federation | Unified view над Hive Metastore + Glue + REST | Migration без big-bang |
Без каталога: engine читает path на S3 напрямую, никакого governance. Hive Metastore — старый каталог, не поддерживает Iceberg snapshot semantics корректно. Iceberg REST Catalog API — стандарт 2024-2026, который реализуют все современные каталоги.
Apache Polaris
Происхождение: разработан Snowflake, передан в Apache Software Foundation в 2024, top-level project в 2025. Версия 1.0 выпущена в 2025.
Тип: Open source (Apache 2.0), vendor-neutral.
Что реализует:
- Полный Iceberg REST Catalog API.
- RBAC: principal → role → privilege → securable hierarchy.
- Credential vending: short-lived AWS STS / Azure SAS / GCP signed URLs, scoped к конкретной таблице.
- Multi-engine interoperability: Spark, Flink, Trino, Dremio, StarRocks, Doris.
- External identity providers: Okta, Google, через OIDC.
- Поддержка Delta Lake (помимо Iceberg) — Polaris 1.x.
Используется: Snowflake Horizon Catalog построен поверх Polaris (та же кодовая база, anyone can self-host). AWS, Apple, Netflix — контрибуторы.
Deployment: Self-hosted (Docker / Kubernetes) или managed (Snowflake Horizon). Resources: Java service (Quarkus), PostgreSQL для metadata. Лицензия: Apache 2.0.
Сильные стороны:
- Vendor-neutral, контрибьюторы из Snowflake, AWS, Apple, Netflix.
- Полный REST Catalog spec compliance.
- Production-grade RBAC.
- Credential vending.
Ограничения:
- RBAC — не ABAC и не ReBAC.
- Lineage минимальный (commit history, не граф).
Когда выбирать: vendor-neutral путь, multi-engine, Snowflake-совместимость нужна.
Unity Catalog OSS
Происхождение: Databricks открыл Unity Catalog как OSS в 2024 (Apache 2.0). Имеет два релиза: managed Databricks Unity Catalog (полный feature set) и Unity Catalog OSS (subset).
Что реализует:
- Iceberg REST Catalog API + Hive Metastore API (compat layer).
- Multi-modal: tables, volumes (unstructured files), models (ML model registry), functions, AI agents.
- ANSI SQL GRANT/REVOKE для access control.
- Lineage column-level (managed Databricks; OSS — subset).
- Интеграция с MLflow для model lineage.
Сильные стороны:
- Multi-modal — единый каталог для tables, files, ML models, agents. Это уникальная позиция для AI governance (см. урок 08 про LLM governance).
- Wide ecosystem: совместимость с Apache Hive metastore API, Iceberg REST API.
- Активная разработка, контрибьюторы Databricks + community.
Deployment: Self-hosted (Docker / Kubernetes) или Databricks managed. Resources: Java service, PostgreSQL. Лицензия: Apache 2.0 (OSS), proprietary (Databricks managed).
Сильные стороны:
- Multi-modal: tables + files + ML models + agents.
- Compat с Hive Metastore API.
- Native интеграция с MLflow для AI BOM.
Ограничения:
- OSS-релиз отстаёт от Databricks managed по features.
- Lineage column-level — только в managed.
- ABAC/ReBAC нет — только RBAC.
Когда выбирать: уже на Databricks; нужен AI/ML governance в одном каталоге; миграция с Hive.
Lakekeeper
Происхождение: независимый OSS проект, написан на Rust, Apache 2.0.
Что реализует:
- Iceberg REST Catalog API.
- OpenFGA-based ReBAC (Relationship-Based Access Control) — главное архитектурное отличие.
- Vended credentials: AWS STS, Azure, GCP, on-prem S3.
- Remote signing для S3 (engine не получает credentials, только подписанные URLs).
- Multi-tenant isolation.
ReBAC через OpenFGA: OpenFGA — open-source реализация Google Zanzibar (от того же автора Auth0). Вместо “user X has role Y in namespace Z” задаётся граф отношений: “user X is_member_of team Y, team Y owns table Z, therefore X can read Z”. Это позволяет выражать сложные иерархии (organizational structure, project ownership, dataset sharing) декларативно.
Deployment: Self-hosted (Docker / Kubernetes), Helm chart, Rust binary. Resources: Rust service (низкое RAM ~ 200 MB), PostgreSQL для metadata, OpenFGA для авторизации. Лицензия: Apache 2.0.
Сильные стороны:
- ReBAC (OpenFGA) — самая выразительная авторизационная модель.
- Rust — низкий resource footprint, высокая производительность.
- Vended credentials с remote signing (S3 keys никогда не покидают catalog).
- Multi-cloud (AWS, Azure, GCP, on-prem S3).
Ограничения:
- Молодой проект (2024+), меньше production case studies.
- Нет multi-modal (только tables).
- Lineage минимальный.
Когда выбирать: нужна fine-grained авторизация (cross-team sharing, project-based access), security-first organisation, multi-cloud.
Apache Gravitino
Происхождение: Datastrato → Apache Software Foundation. Top-level в июне 2025, версия 1.1.0 в декабре 2025.
Что реализует:
- Federated metadata lake: НЕ заменяет существующие каталоги, а объединяет их. Connects to: Hive Metastore, Iceberg REST, Kafka Schema Registry, ML Model Registries.
- Multi-modal: tables + filesets + vectors + messaging streams.
- Geo-distributed metadata.
- AI/ML asset management (вступил в Agentic AI Foundation в начале 2026).
Federation модель: вы не мигрируете с Hive Metastore — вы подключаете Hive под Gravitino как один из catalog providers. Engine спрашивает Gravitino, Gravitino форвардит в Hive Metastore. Это migration-friendly path для крупных enterprise со множеством существующих каталогов.
Deployment: Self-hosted (Docker / Kubernetes), JVM-сервис. Resources: Java service, RDBMS для metadata. Лицензия: Apache 2.0.
Сильные стороны:
- Federation: объединяет Hive + Iceberg REST + Kafka SR + ML registries.
- Multi-modal: tables + filesets + vectors + streams.
- Geo-distributed.
- Активная разработка с участием Datastrato, Apple, Intel.
Ограничения:
- Federation-overhead в latency.
- ABAC/ReBAC нет — RBAC.
- Молодой TLP, ecosystem меньше Polaris.
Когда выбирать: enterprise с legacy Hive + новый Iceberg + ML registries, нужна единая точка входа без миграции.
Project Nessie
Происхождение: Dremio, OSS под Apache 2.0.
Что реализует:
- Iceberg REST Catalog API.
- Git-like semantics: branches, tags, merges, multi-table cross-table transactions.
- Time-travel в catalog scope, не только table scope.
Git-like модель: создаёте branch feature/new-pipeline, делаете там изменения схемы и data, тестируете изолированно, merge в main когда готово. Это уникально среди catalog-ов — Polaris/Unity/Lakekeeper не дают branching на уровне catalog state.
Deployment: Self-hosted (Docker / Kubernetes), Java/Quarkus. Resources: Java service, RocksDB / DynamoDB / Mongo / RDBMS для metadata. Лицензия: Apache 2.0.
Сильные стороны:
- Git-like branching catalog state (уникально).
- Multi-table transactions (atomic commits через несколько таблиц).
- Поддержка всех Iceberg engines: Spark structured streaming, Trino, Flink, Hive.
Ограничения:
- RBAC — простой.
- Меньше acceptance в enterprise, чем Polaris.
- Cognitive overhead branching-модели для простых use-cases.
Когда выбирать: experimental data engineering (sandbox branches), ML feature engineering (каждая модель в своей ветке данных), multi-table cross-cutting изменения.
AWS Glue REST Catalog
Контекст: AWS Glue Data Catalog исторически был proprietary AWS API. В 2024 AWS добавил Iceberg REST endpoint поверх Glue, делая его совместимым с любым Iceberg client.
Когда выбирать: AWS-only deployment, уже используется Lake Formation для governance, не хочется содержать отдельный catalog service. Минусы: vendor lock-in, ABAC через Lake Formation tag-based policies, выходит дороже self-hosted.
Comparison matrix
RBAC / ABAC / ReBAC (20%) | Multi-modal (15%) | Credential vending (15%) | Federation (10%) | Multi-engine support (15%) | Maturity (15%) | Resource footprint (10%) | Итого | |
|---|---|---|---|---|---|---|---|---|
| Apache Polaris | 3 | 2 | 5 | 2 | 5 | 4 | 4 | 3.6 |
| Unity Catalog OSS | 3 | 5 | 3 | 3 | 4 | 3 | 3 | 3.5 |
| Lakekeeper | 5 | 1 | 5 | 1 | 4 | 3 | 5 | 3.5 |
| Apache Gravitino | 3 | 4 | 3 | 5 | 4 | 3 | 3 | 3.5 |
| Project Nessie | 2 | 1 | 3 | 1 | 5 | 4 | 4 | 2.9 |
| AWS Glue REST | 4 | 2 | 5 | 1 | 5 | 5 | 5 | 4.0 |
Governance implications: RBAC vs ABAC vs ReBAC
Выбор каталога — это в первую очередь выбор модели авторизации.
RBAC (Role-Based Access Control):
- “User X has role data_engineer, role data_engineer has SELECT on namespace warehouse.”
- Простая, scaleable до сотен ролей.
- Подходит для простых иерархий: dev/staging/prod, по командам, по доменам.
- Реализуют все каталоги: Polaris, Unity, Gravitino, Nessie.
ABAC (Attribute-Based Access Control):
- “User X with department=Marketing can SELECT WHERE column.classification=PUBLIC.”
- Атрибутные правила: на пользователя (department, location), на ресурс (classification, sensitivity), на контекст (time, IP).
- Подходит для compliance: GDPR data residency, PII masking.
- Реализуют: AWS Glue REST + Lake Formation (tag-based), Unity Catalog (managed Databricks fine-grained).
ReBAC (Relationship-Based Access Control):
- “User X is_member_of team Y, team Y is_owner_of project Z, project Z owns table T → X can read T.”
- Граф отношений вместо плоских ролей. Inspired by Google Zanzibar.
- Подходит для cross-team sharing, organisational hierarchies, dataset marketplaces.
- Реализует: Lakekeeper через OpenFGA — единственный из major catalog-ов.
Когда что:
| Сценарий | Выбор |
|---|---|
| Стандартная команда data engineering, ясные домены | RBAC (Polaris / Unity) |
| Compliance: PII masking, data residency, fine-grained на колонки | ABAC (Glue + Lake Formation, Unity managed) |
| Organisational hierarchy: сотни команд, cross-team sharing, federated organisations | ReBAC (Lakekeeper) |
Migration: Hive Metastore → REST Catalog
Многие организации унаследовали Hive Metastore. Миграция на REST Catalog (Polaris / Unity / Lakekeeper) идёт несколькими паттернами:
Pattern 1: Big-bang миграция (small scale). Mock convert Hive metadata в Iceberg metadata, перенаправить engines на новый catalog. Риск: downtime, несовместимость старых jobs.
Pattern 2: Federation через Gravitino. Подключить Hive Metastore как один из providers Gravitino. Engines переходят на Gravitino, Gravitino форвардит legacy запросы в Hive. Постепенно мигрируете таблицы из Hive в Iceberg внутри Gravitino. Низкий риск, длительный.
Pattern 3: Compat layer. Unity Catalog поддерживает Hive Metastore API напрямую: legacy engines (старый Spark) ходят в Unity как в Hive Metastore, новые engines используют REST API. Единый storage, два API.
Pattern 4: Dual-write. Producer пишет в Hive table и в Iceberg table параллельно. Consumers переходят на Iceberg по мере готовности. Выключаете Hive когда все мигрировали. Дорого по storage, безопасно.
В большинстве enterprise — Pattern 2 (Gravitino federation) или Pattern 3 (Unity compat) оптимальны.
Production checklist
Что должно быть настроено в catalog для production:
- Persistence backend: PostgreSQL/RDBMS, не SQLite — нужны параллельные writes.
- Authentication: OIDC через Okta/Azure AD/Google. Не базовая auth.
- Credential vending: scoped STS / SAS, expiry < 1 час.
- Audit log: все commits, schema changes, GRANT/REVOKE экспортируются в SIEM.
- Backup metadata: PostgreSQL и S3 metadata folder — оба бэкапятся.
- Multi-region replication: для critical workloads (Polaris, Gravitino поддерживают).
- Snapshot expiry policy: snapshots старше 30 дней deletes — иначе metadata explosion.
- Compaction job: регулярная compaction (Iceberg
rewrite_data_files), иначе small files. - Schema evolution policy: какой compatibility mode — BACKWARD / FORWARD / FULL.
- Lineage export: в OpenLineage или OpenMetadata для downstream governance.
Связь с другими модулями
- Урок 02 (data catalog platforms): OpenMetadata / DataHub каталогизируют бизнес-метаданные (что есть, кто владеет). Lakehouse-каталоги управляют runtime Iceberg-таблиц. Они дополняют друг друга: OpenMetadata показывает governance metadata о таблице, а Polaris/Unity/Lakekeeper enforce-ят access во время чтения.
- Урок 06 (BI/Analytics governance): lakehouse-каталог хранит certified-flag на уровне таблицы; semantic layer (Cube, dbt) использует это.
- Модуль 08 (AI governance): Unity Catalog OSS как central governance plane для tables + ML models + agents — критично для AI BOM (см. следующий урок).
- Streaming Lakehouse pattern в Kafka course: Iceberg sink connector / Tableflow требуют REST catalog endpoint — Polaris / Lakekeeper / Glue.