Data Catalog Federation: Mehrere Catalogs über AWS, Azure und GCP verbinden

Jedes Plattform-Team läuft irgendwann gegen dieselbe Wand: Deine Daten liegen in drei Clouds, zwei On-Prem-Systemen und der API eines SaaS-Anbieters — und niemand findet etwas. Du hast Catalogs, im Plural. Was du nicht hast: einen Catalog.

Data Catalog Federation ist das Architektur-Pattern, das dieses Problem löst, ohne dass du alles migrieren musst. Statt aller Metadaten in ein Tool zu konsolidieren, verbindest du mehrere Catalogs über gemeinsame Protokolle.

TL;DR

• Single-Catalog-Strategien scheitern bei Acquisitions, Multi-Cloud und Domain-Autonomie.
• Drei Federation-Patterns: Hub-and-Spoke (zentral), Protokoll-basiert (Iceberg REST), Metadata Mesh (dezentral).
• Iceberg REST Catalog API ist der Standard, der Cross-Catalog-Interop möglich macht.
• Die Wahl ist organisatorisch, nicht technisch.

Warum Single-Catalog scheitert

• Acquisitions: Über Nacht neue Stacks.
• Multi-Cloud: Jeder Provider hat seinen eigenen Catalog (AWS Glue, Google Dataplex, Azure Purview).
• Domain-Autonomie: Auch ohne Data Mesh wählen Teams unterschiedliche Tools.

Erzwungene Konsolidierung wird ein Metadaten-Migrationsprojekt — genauso schmerzhaft wie eine Datenmigration.

Die drei Federation-Patterns

Pattern 1: Hub-and-Spoke

Ein Catalog ist die Primary-Discovery-Schicht und zieht Metadaten aus Satellite-Catalogs. Nutzer:innen suchen an einer Stelle, Governance läuft zentral.

Beispiele: Databricks Unity Catalog mit Lakehouse Federation, Atlan, Collibra.

Passt für: Organisationen mit dominanter Analytics-Plattform, die zentrale Governance wollen.

Pattern 2: Protokoll-basiert (Iceberg REST API)

Statt Aggregator implementieren Catalogs ein gemeinsames Protokoll — die Iceberg REST Catalog API. Jede Engine, die das Protokoll spricht, kann Tables aus jedem kompatiblen Catalog lesen.

Beispiele: Apache Polaris, Apache Gravitino, Unity Catalog (als Iceberg REST Endpoint), Project Nessie.

Passt für: Organisationen mit Commitment auf offene Tableformate, die Engine-Agnostik wollen.

Pattern 3: Metadata Mesh

Jede Domain besitzt ihren Catalog und veröffentlicht Metadaten-Contracts in einer Shared Registry. Kein zentraler Catalog, nur ein Lightweight-Discovery-Service.

Passt für: Große Enterprises mit starker Domain-Ownership, wo zentrale Governance politisch nicht durchsetzbar ist.

Catalog-Vergleich

Wann welches Pattern?

Hub-and-Spoke wenn:

• Du eine dominante Analytics-Plattform hast (70 %+ der Queries über Databricks oder Snowflake).
• Zentrale Governance Pflicht ist (regulierte Branchen, BaFin, SOX).
• Du Vendor-Coupling am Metadata-Layer akzeptierst.

Protokoll-basiert wenn:

• Open Table Formats (Iceberg, Delta) gesetzt sind.
• Mehrere Compute-Engines (Spark, Flink, Trino, Dremio) dieselben Tables sehen müssen.
• Du Self-Host kannst.

Metadata Mesh wenn:

• 100+ Datendomains, mehrere Geschäftseinheiten.
• Domain-Autonomie nicht verhandelbar ist.
• Reife Data-Engineering-Teams pro Domain vorhanden sind.

Iceberg REST Catalog: Der Standard, der alles verändert hat

Vorher sprach jeder Catalog seine eigene Sprache. Jetzt implementieren immer mehr Catalogs dieselbe HTTP-API.

Apache Polaris — Ursprünglich von Snowflake open-sourced, jetzt Apache-Projekt. Reiner Iceberg-Catalog. Kein Governance-Layer.

Apache Gravitino — Apache TLP seit Mai 2025. Metadaten-Federation-Layer, der Iceberg, Hive und mehrere Formate unterstützt. Meta-Catalog für mehrere Backends.

Databricks Unity Catalog — Managed Option. Exposed Iceberg REST Endpoint, externe Engines (Trino, Flink, Dremio) können UC-Tables via Standard Iceberg REST lesen. Gleichzeitig liest UC via Lakehouse Federation von Glue, HMS, Snowflake Horizon.

Project Nessie — Git-ähnliches Branching und Versioning für Catalog-Operationen.

Was die REST API nicht standardisiert

Access Control, Lineage, Data-Quality-Metriken, Business-Glossary. Protokoll-Federation allein löst Governance nicht — du brauchst eine Policy-Schicht darüber.

Governance in Federated Welt

Im federated Modell reicht ein einzelner Catalog-RBAC nicht. Du brauchst eine Policy-Engine darüber oder Policies, die über Catalogs hinweg repliziert werden — eigenes Wartungsproblem.

Lineage über Catalogs hinweg

• OpenLineage — Der entstehende Standard. Spark, Airflow, dbt, Flink emittieren Events, ein zentraler Collector (Marquez, Atlan, DataHub) baut den Graph.
• Manuelle Registrierung — Skaliert nicht, aber ehrlich.
• Vendor-Lösungen — Atlan, Collibra, Alation. Pricing ab ~60k$/Jahr Enterprise.

Häufige Fallen

1. Federation als Tech-Problem behandeln. Es ist ein organisatorisches Pattern. Ohne Naming-Conventions, Ownership und Metadaten-Standards rettet dich keine Technologie.
2. Zu früh federieren. Eine Cloud, eine Analytics-Plattform → du brauchst einen Catalog, keine Federation.
3. Staleness ignorieren. Federated Metadaten sind eventually consistent. SLA definieren, monitoren.
4. Iceberg REST = Governance. Falsch. Es ist ein Table-Management-Protokoll, kein Governance-Framework.
5. Open-Source ohne Ops-Reife wählen. Polaris und Gravitino sind mächtig, brauchen aber Self-Hosting.

FAQ

Brauchen wir Federation, wenn alles in einer Cloud läuft? Nein. Ein Catalog reicht. Federation lohnt sich, wenn mehrere Catalogs schon nebeneinander existieren.

Reicht Unity Catalog allein für Multi-Cloud? Über Lakehouse Federation liest UC aus Glue und BigQuery, aber dein Governance-Plane sitzt bei Databricks. Wenn das ok ist, ja.

Open Source oder managed? Wenn du Kubernetes-Erfahrung und Kapazität hast: Polaris/Gravitino. Wenn nicht: managed (UC, Glue, Purview).

Wie groß ist die DACH-Relevanz von Iceberg REST? Hoch. Wer DSGVO-getrieben on-prem oder in eu-central-1 Iceberg fährt, profitiert von Engine-Wahl ohne Vendor-Coupling.

Stand: 14. Mai 2026.