Lakehouse Federation in Unity Catalog: Wann Foreign Catalogs reichen und wann Pipelines besser sind
Lakehouse Federation bindet externe Datenquellen als Objekte in Unity Catalog ein, ohne die Daten vorher zu kopieren, zum Beispiel operative Datenbanken oder andere Data Warehouses.
Die Kernaussagen auf einen Blick.
- Lakehouse Federation bindet externe Quellen wie Snowflake, BigQuery, PostgreSQL, SQL Server, Hive Metastore oder AWS Glue als Foreign Catalogs in Unity Catalog ein.
- Der Vorteil: Daten werden schnell auffindbar, Berechtigungen laufen über Unity Catalog, Lineage wird sichtbar und einzelne Abfragen über mehrere Quellen sind möglich, ohne die Daten sofort ins Lakehouse zu kopieren.
- Federation ersetzt keine Ingestion-Strategie. Bei hoher BI-Last, großen Datenmengen, schreibenden Workloads, harten SLAs oder teurer Quelle ist eine Pipeline über Lakeflow Connect, CDC oder Fivetran meist die sauberere Lösung.
- Mein Vorschlag: Federation zuerst für Inventur, Self-Service, Migrationsvorbereitung und einzelne Abfragen über mehrere Quellen nutzen. Pro Tabelle sollte vorher klar sein, ab welcher Nutzung sie ins Lakehouse übernommen wird.
Inhaltsverzeichnis
Federation ersetzt kein ETL
Im Architekturtermin kommt schnell die Frage, ob BI jetzt direkt auf Snowflake, Postgres und den alten Hive Metastore zugreifen kann. Die kurze Antwort: ja. Die Folgen sieht man oft erst ein paar Wochen später. Dann stellt sich die Frage, warum ein Report über mehrere Quellen plötzlich mehrere Stunden läuft und warum die Quellplattform plötzlich deutlich mehr kostet.
Das passiert oft, wenn Federation als Ersatz für Datenpipelines verstanden wird. Federation ermöglicht einen schnellen Zugriff auf externe Quellen. Die Abfragen laufen aber weiterhin ganz oder teilweise auf der Quelle, deren Lizenz weiter bezahlt wird und die plötzlich BI-Spitzen abfangen muss. Ohne klare Regeln entsteht eine schwer steuerbare Abhängigkeit von Performance, Verfügbarkeit und Kosten der Quelle.
Aus Sicht eines Plattform-Verantwortlichen oder einer Daten-Governance-Rolle stehen jedes Mal dieselben Fragen im Raum:
Welche Abfragen dürfen direkt auf der Quelle laufen, und welche Daten gehören ins Lakehouse? Wie verändern sich Lizenz- und Rechenkosten, wenn mehrere BI-Bereiche gleichzeitig auf die Quelle zugreifen? Welche Nutzerinformationen stehen im Quell-Audit zur Verfügung, wenn alle Abfragen über dieselbe technische Identität laufen? Für welche Abfragen reichen Zuverlässigkeit, Antwortzeit und Kostenprofil der Federation aus? Ab wann ist eine Replikation in das Lakehouse die geeignetere Lösung?
Federation kann ein guter direkter Zugriffsweg sein oder nur eine sinnvolle Zwischenlösung, je nach Anwendungsfall. Richtig eingeordnet verkürzt Federation den Zugang zu Daten und erleichtert schrittweise Migrationen. Wird Federation dagegen als genereller Pipeline-Ersatz genutzt, landen Last, Kosten und Betriebsrisiken wieder bei den Quellsystemen.
Was ist Lakehouse Federation in Unity Catalog?
Lakehouse Federation bindet externe Datenquellen als Objekte in Unity Catalog ein, ohne die Daten vorher zu kopieren, zum Beispiel operative Datenbanken oder andere Data Warehouses.
Für die Einordnung ist vor allem entscheidend: Federation bringt externe Quellen in Governance und Discovery, verschiebt Datenhaltung und Last aber nicht aus der Quelle heraus. Die Daten bleiben im Quellsystem, die Quell-Engine verarbeitet weiterhin Abfragen, die Quell-Lizenz wird weiterhin genutzt. Unity Catalog ergänzt die externe Quelle um zentrale Berechtigungs-, Lineage- und Auditfunktionen. Ein relevanter Teil der Abfrage bleibt damit von Performance, Kosten und Verfügbarkeit der Quelle abhängig.
Wie Connection, Foreign Catalog und Pushdown in der breiteren UC-Architektur mit Catalogs, Permissions und Lineage zusammenspielen, zeigen wir im Überblick zu Unity Catalog auf Databricks.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Zwei unterschiedliche Arten von Federation
Databricks unterscheidet zwei grundlegende Federation-Varianten, und die Wahl beeinflusst vor allem Performance, Kosten und Ausführungspfad. Query Federation leitet Abfragen über einen Connector an die externe Datenbank oder das externe Data Warehouse weiter. Die Quelle führt unterstützte Teile der Abfrage aus und trägt die Last. Das ist der Pfad für Snowflake, PostgreSQL, MySQL, SQL Server, Redshift, BigQuery, Azure Synapse und Salesforce Data 360. Catalog Federation funktioniert anders. Unity Catalog übernimmt die Metadaten des externen Katalogs, die Daten bleiben im Objektspeicher, und Databricks liest die Daten direkt aus dem Speicher und führt die Abfrage mit eigener Rechenleistung aus. Das ist der Pfad für externe und legacy Hive Metastores, AWS Glue und Salesforce Data 360 File Sharing. Catalog Federation kann wirtschaftlicher und performanter sein, da keine separate Quell-Engine pro Abfrage benötigt wird, laut Microsoft Learn.
Query Federation passt, wenn
- die Quelle eine relationale Datenbank oder ein Data Warehouse ist (Snowflake, PostgreSQL, MySQL, SQL Server, Redshift, BigQuery, Azure Synapse, Salesforce Data 360)
- die Quell-Engine die Abfrage selbst ausführen und die Last tragen soll
- ein Connector die Abfrage in den SQL-Dialekt der Quelle übersetzen kann
Catalog Federation passt, wenn
- die Quelle ein externer oder legacy Hive Metastore oder ein AWS Glue Catalog ist
- die Daten bereits im Objektspeicher liegen und Databricks direkt darauf lesen kann
- keine separate Quell-Engine pro Abfrage vorgehalten werden soll
Foreign Catalogs, Connections und Query Pushdown einfach erklärt
Das Modell besteht aus drei Bausteinen. Erstens die Connection: ein Unity-Catalog-Objekt auf Account-Ebene, das Quelltyp, Endpunkt und technische Zugangsdaten enthält. Der Zugriff auf die Quelle läuft meist über eine technische Identität. Der einzelne Databricks-Nutzer ist im Audit der Quelle deshalb oft nicht direkt sichtbar. Zweitens der Foreign Catalog: ein Unity-Catalog-Objekt, das die Struktur der externen Quelle als Catalog, Schema und Tabellen abbildet. Für Nutzer sieht eine externe Tabelle dadurch fast wie ein normales Unity-Catalog-Objekt aus. Drittens der Query-Pushdown: Databricks schiebt unterstützte Filter, Spaltenauswahlen, Aggregate und Joins zur Quelle. Nicht unterstützte Operationen werden ganz oder teilweise in Databricks verarbeitet. Dadurch können mehr Daten übertragen werden, Abfragen länger laufen und zusätzliche Kosten entstehen.
Connection
Unity-Catalog-Objekt auf Account-Ebene mit Quelltyp, Endpunkt und technischen Zugangsdaten. Der Zugriff läuft meist über eine technische Identität. Der einzelne Nutzer ist im Quell-Audit oft nicht direkt sichtbar.
Foreign Catalog
Bildet die Struktur der externen Quelle als Catalog, Schema und Tabellen ab. Eine externe Tabelle sieht für Nutzer fast wie ein normales Unity-Catalog-Objekt aus.
Query-Pushdown
Schiebt unterstützte Filter, Spaltenauswahlen, Aggregate und Joins zur Quelle. Nicht unterstützte Operationen verarbeitet Databricks selbst.
Welche Quellen unterstützt Lakehouse Federation?
Die unterstützten Quellen und Funktionen werden regelmäßig erweitert. Für die Architektur ist eine Einteilung nach Quelltypen sinnvoller als eine feste Produktliste. Databricks dokumentiert die aktuelle Connector-Matrix für catalog federation und führt den Stand pro Quell-Typ.
Gut etablierte Quellen sind unter anderem klassische relationale Datenbanken und analytische Plattformen wie PostgreSQL, MySQL und SQL Server, die DWHs Snowflake, BigQuery, Redshift und Azure Synapse, sowie Salesforce Data Cloud und Sonderfälle wie der Hive Metastore und der AWS Glue Catalog. Databricks beschreibt die Lakehouse-Federation-Fähigkeiten in Unity Catalog mit MySQL, PostgreSQL, Amazon Redshift, Snowflake, Microsoft SQL Server, Azure Synapse, Google BigQuery und weiteren als unterstützten Quell-Plattformen.
Dass ein Connector verfügbar ist, beantwortet aber drei wichtige Fragen noch nicht: ob nur Lesen oder auch Schreiben unterstützt wird, welche Operationen wirklich an die Quelle geschoben werden und wie sich der Connector unter echter Last und paralleler Nutzung verhält. Diese drei Fragen entscheiden später über Last und Kosten. Vor dem produktiven Einsatz sollte der aktuelle Funktionsumfang für jede relevante Quelle geprüft werden. Zusätzlich sollte mit realistischen Abfragen auf der echten Quelle getestet werden.
Wovon der Query Pushdown abhängt
Wie viel Pushdown möglich ist, entscheidet stark über Laufzeit, Datenbewegung und Kosten. Databricks übersetzt SQL so weit wie möglich in den Dialekt der Quelle und schickt sie an die Quelle. Im besten Fall liefert die Quelle nur das bereits gefilterte oder aggregierte Ergebnis zurück. Was nicht übersetzt werden kann, verarbeitet Databricks selbst. Dann müssen unter Umständen große Datenmengen aus der Quelle übertragen werden.
Die Faustregel sieht in der Regel so aus, lässt sich pro Quell-Engine aber nur belastbar mit Stand-Bezug formulieren:
| Operation | Typisches Pushdown-Verhalten | Konsequenz |
|---|---|---|
| Filter / Prädikate | fast immer Pushdown | Die Quelle filtert, Databricks bekommt nur die relevanten Zeilen. |
| Projektion / Spalten-Auswahl | fast immer Pushdown | Nur ausgewählte Spalten verlassen die Quelle. |
| einfache Aggregate (count, sum, avg) | häufig Pushdown | Quelle aggregiert, Ergebnis ist klein. |
| Joins innerhalb derselben Quelle | häufig Pushdown | Quelle joint, Databricks bekommt das Join-Ergebnis. |
| Cross-Source-Joins | kein Pushdown möglich | Databricks zieht beide Seiten und joint selbst. |
| Window-Funktionen, komplexe Analyse-SQL | quellabhängig | oft in Databricks, mit deutlich mehr Datenbewegung. |
| Schreibzugriff | konnektor-spezifisch | kein Default, pro Quelle prüfen. |
Daraus folgt: Federation funktioniert besonders gut, wenn ein großer Teil der Abfrage direkt in der Quelle ausgeführt werden kann. Cross-Source-Joins und komplexe Analysen erhöhen dagegen häufig Datenbewegung und Compute-Verbrauch. An diesem Punkt geht es nicht mehr nur um Geschwindigkeit, sondern auch um Kosten. Wenn die Quellplattform stärker belastet wird oder viele Rohdaten übertragen werden, kann der Betrieb dort spürbar teurer werden.
Berechtigungen, Lineage und Audit für Foreign Catalogs
Für den Betrieb sind drei Dinge wichtig: Jede Connection braucht eine klar verantwortete technische Identität mit geregelter Rotation und Lebenszyklus. Die Quellplattform sollte durch Limits und Priorisierung geschützt werden, damit Federation-Abfragen keine operativen Systeme ausbremsen. Und Foreign Catalogs müssen von Anfang an ins Berechtigungsmodell aufgenommen werden, damit Zuständigkeiten zwischen Quelle und Unity Catalog nicht auseinanderlaufen.
Unity Catalog aktualisiert Metadaten aus einem Foreign Catalog je nach Quelle und Zugriffspfad automatisch. Wenn sich ein Schema in der Quelle ändert, kann Databricks diese Änderung bei einer späteren Abfrage erkennen. Für viele Workloads reicht das aus.
Für den Betrieb sind trotzdem zwei Punkte wichtig.
Erstens sollte der Metadaten-Refresh geplant werden, wenn Änderungen nicht erst bei der nächsten produktiven Abfrage auffallen sollen. Dafür können REFRESH FOREIGN CATALOG, REFRESH FOREIGN SCHEMA oder REFRESH FOREIGN TABLE regelmäßig über einen Job laufen.
Zweitens brauchen externe Hive Metastores eine zusätzliche Absicherung über authorized paths. Damit wird festgelegt, auf welche Speicherpfade Tabellen aus dem föderierten Hive Metastore überhaupt zeigen dürfen. Das verhindert, dass über den Foreign Catalog Daten erreichbar werden, die in Unity Catalog eigentlich nicht freigegeben sind.
Gerade in regulierten Umgebungen sollte deshalb klar sein: Welche Foreign Catalogs werden regelmäßig aktualisiert, und welche Speicherpfade sind ausdrücklich erlaubt?
Discovery, Self-Service, Cross-Source-Abfragen und Migration
Lakehouse Federation ist besonders sinnvoll, wenn Daten schnell sichtbar werden sollen, ohne direkt eine dauerhafte Pipeline zu bauen. Vier Anwendungsfälle kommen häufig vor.
Discovery
Eine externe Quelle soll schnell in Inventur, Suche und Governance sichtbar werden, für ein Datenkatalog-Projekt, ein Reifegrad-Assessment oder die Vorbereitung einer Migration. Wichtig ist der schnelle Überblick, nicht die beste Abfragegeschwindigkeit.
Cross-Source-Abfragen
Daten für eine Analyse liegen in mehreren Systemen: Vertrieb in Snowflake, operative Aufträge in Postgres, historische Daten im Hive Metastore. Bei seltenem Bedarf ist Federation schneller als mehrere Pipelines aufzubauen.
Self-Service
Fachbereiche greifen über Unity Catalog lesend auf externe Quellen zu, ohne dass sofort eine vollständige CDC- oder Replikationsstrecke steht. Berechtigungen, Lineage und Audit laufen über UC.
Migrationsvorbereitung
Federation dient als Übergang, wenn ein Quellsystem später ins Lakehouse migriert werden soll. Nutzer arbeiten schon mit den Daten, während die Migration vorbereitet wird.
Die Faustregel: Federation ist ein schneller Einstieg. Für häufig genutzte, performancekritische oder geschäftskritische Workloads sollte später eine stabile Ingestion- oder Replikationsstrecke übernehmen.
Lakehouse Federation vs Replikation
Die zentrale Frage lautet pro Tabelle: Reicht direkter Zugriff über Federation, oder sollte die Quelle repliziert werden? Entscheidend sind Nutzung, Datenvolumen, Latenz und Belastung der Quellplattform.
| Frage | Federation passt eher | Replikation passt eher |
|---|---|---|
| Wie oft wird abgefragt? | selten, einmalig oder mit wenigen Nutzern | täglich, regelmäßig oder mit vielen parallelen Nutzern |
| Wie groß sind die Abfragen? | kleine Ausschnitte, Filter oder Aggregate | große Scans, breite Tabellen oder lange Zeiträume |
| Wie schnell müssen Antworten sein? | Sekunden bis Minuten sind akzeptabel | Dashboards oder Anwendungen brauchen kurze Antwortzeiten |
| Wird nur gelesen? | ja | nein, es gibt schreibende oder zustandsbehaftete Prozesse |
| Wie stark darf die Quelle belastet werden? | die Quelle hat genug Kapazität | die Quelle ist teuer, kritisch oder operativ sensibel |
Als Faustregel: Federation eignet sich gut für Discovery, einmalige Analysen und seltene Cross-Source-Abfragen. Ein häufig genutztes BI-Modell, regelmäßige ML-Trainings oder große Reports sollten dagegen meist ins Lakehouse übernommen und dort optimiert werden.
Für die Replikation kommen in Databricks vor allem Lakeflow Connect mit verwalteten Ingestion-Konnektoren oder CDC-Strecken infrage. Auch Tools wie Fivetran können diese Rolle übernehmen. Der Vorteil: Die Daten liegen lakehouse-nativ vor, können optimiert werden und belasten die Quellplattform nicht bei jeder Abfrage neu.
Ein pragmatischer Weg ist deshalb: zunächst Federation für Sichtbarkeit, Inventur und erste Analysen nutzen. Danach pro Tabelle klare Schwellen definieren, zum Beispiel Anzahl der Abfragen, Scan-Volumen oder Belastung der Quelle. Sobald diese Schwellen überschritten werden, sollte die Tabelle in eine Lakeflow-Connect- oder CDC-Pipeline überführt werden. Federation ist damit der schnelle Einstieg, Replikation der stabilere Weg für dauerhafte Nutzung.
Lakehouse Federation vs Delta Sharing
Lakehouse Federation und Delta Sharing lösen unterschiedliche Aufgaben.
Federation wird genutzt, wenn Databricks auf Daten zugreifen soll, die weiterhin in einem externen System liegen, zum Beispiel in Snowflake, Postgres oder einem Hive Metastore. Die Daten bleiben dort, Databricks liest sie über eine Connection.
Delta Sharing wird genutzt, wenn eigene Daten kontrolliert an andere Empfänger bereitgestellt werden sollen. Dabei geht es nicht um Zugriff auf eine fremde Engine, sondern um die Verteilung ausgewählter Daten an interne oder externe Konsumenten.
Die einfache Abgrenzung: Federation holt externe Daten für die Nutzung in Databricks sichtbar. Delta Sharing gibt eigene Daten kontrolliert an andere weiter.
Lakehouse Federation vs. External Locations
External Locations und Lakehouse Federation werden oft verwechselt, weil beide den Zugriff auf externe Daten ermöglichen. Sie lösen aber unterschiedliche Aufgaben.
External Locations werden genutzt, wenn Daten als Dateien im Cloud-Speicher liegen, zum Beispiel in S3, ADLS oder GCS. Databricks liest diese Dateien direkt aus dem Object Store, etwa als Delta, Parquet, CSV oder JSON. Unity Catalog regelt dabei, wer auf welchen Speicherpfad zugreifen darf. Wie das funktioniert, erklären wir im Überblick zu External Locations in Unity Catalog.
Lakehouse Federation wird genutzt, wenn Daten weiterhin in einem externen System verwaltet werden, zum Beispiel in Snowflake, Postgres oder BigQuery. Databricks greift dann nicht direkt auf einen Speicherpfad zu, sondern fragt die externe Datenbank über deren SQL-Schnittstelle ab. Speicherung, Rechenleistung und ein Teil der Kosten bleiben beim Quellsystem.
Praktisch heißt das: External Locations passen für Daten, die bereits als Dateien im Cloud-Speicher liegen. Lakehouse Federation passt für Daten, die weiterhin von einer externen Datenbank oder Plattform verwaltet werden. Eine Snowflake-Tabelle ist daher kein Fall für External Locations. Ein ADLS-Pfad ist kein Foreign Catalog.
Grenzen von Lakehouse Federation
Die Quelle wird weiter belastet
Jede föderierte Abfrage läuft gegen das Quellsystem: Compute, Lizenzen, Connection-Pools und Kosten. Wenn viele BI-Nutzer regelmäßig über Federation auf Snowflake, Postgres oder BigQuery zugreifen, kann die Quelle schnell stärker belastet werden als geplant.
Nicht jede Abfrage bleibt in der Quelle
Einfache Filter und Aggregationen lassen sich oft gut an die Quelle weitergeben. Komplexe Analysen, Cross-Source-Joins oder Window-Funktionen laufen aber nicht immer vollständig dort. Dann wandern mehr Daten nach Databricks, Laufzeit und Kosten steigen.
Das Quellsystem sieht oft nur die technische Connection
Databricks greift meist über eine technische Identität auf die Quelle zu. Das Quellsystem sieht damit nicht automatisch, welcher Endnutzer die fachliche Abfrage gestellt hat. Diese Zuordnung muss über Unity Catalog oder zusätzliche Audit-Logik nachvollziehbar sein.
Federation ist keine Ausfallabsicherung
Wenn die Quelle nicht verfügbar ist, sind auch die föderierten Daten nicht verfügbar. Für kritische Reports mit festen SLA- oder RTO-Anforderungen ist eine replizierte Datenstrecke meist belastbarer.
Federation spart nicht automatisch Quellkosten
Eine Snowflake- oder BigQuery-Quelle verursacht weiterhin Kosten, wenn sie über Federation abgefragt wird. Federation ersetzt keine Kostenprüfung, es verlagert nur den Zugriff in Unity Catalog.
Federation baut kein fachliches Datenmodell
Foreign Catalogs zeigen Daten so, wie sie in der Quelle liegen. Einheitliche Kennzahlen, bereinigte Strukturen und kuratierte Datenmodelle müssen weiterhin im Lakehouse aufgebaut werden.
Fazit
Lakehouse Federation bindet externe Quellen in Unity Catalog ein, ohne sofort eine Pipeline aufzubauen, ersetzt aber keine Ingestion-Strategie für dauerhaft kritische Workloads.
Tabellen aus Snowflake, Postgres, BigQuery oder anderen Quellen können über Unity Catalog gesucht, berechtigt, auditiert und in Lineage-Zusammenhänge eingebunden werden. Die Daten bleiben aber in der Quelle, und jede Abfrage belastet weiterhin das Quellsystem.
Federation passt besonders gut für Discovery, Migrationsvorbereitung, seltene Cross-Source-Abfragen und erste Self-Service-Zugriffe auf operative Daten. In diesen Fällen verkürzt ein Foreign Catalog den Weg zur Nutzung, ohne direkt eine vollständige Ingestion-Strecke aufzubauen.
Für dauerhaft hohe BI-Last, regelmäßige ML-Workloads, schreibende Prozesse oder harte Verfügbarkeitsanforderungen ist Federation meist nicht der richtige Dauerbetrieb. Dann sollte eine replizierte Datenstrecke übernehmen, zum Beispiel über Lakeflow Connect, CDC oder eine eigene Pipeline. So werden Quelle, Kosten und Performance besser entkoppelt.
So sind Federation und Replikation keine Gegensätze. Federation ist der schnelle Einstieg, Replikation der stabile Weg für dauerhafte Nutzung.
Federation zunächst für Inventur, erste Analysen und kontrollierten Zugriff auf externe Quellen nutzen, danach pro Tabelle klare Schwellen festlegen, ab wann sie ins Lakehouse übernommen wird.
FAQ
Lakehouse Federation ist der Unity-Catalog-Mechanismus, mit dem externe Datenquellen wie Snowflake, BigQuery, Postgres, MySQL, SQL Server, Hive Metastore oder AWS Glue als Foreign Catalogs in Unity Catalog eingebunden werden. Eine Connection enthält Quelltyp, Endpoint und technische Zugangsdaten. Der Foreign Catalog macht die Schemas der Quelle in Unity Catalog sichtbar. Pushdown schiebt SQL-Operationen so weit wie möglich zur Quelle, der Rest wird in Databricks gerechnet.
