Federation: Definition und Abgrenzung im Datenkontext

Federation ist ein Muster, um mehrere getrennte Datenbanken oder Systeme so anzusprechen, als wären sie eine einzige. Eine Vermittler-Schicht nimmt die Anfrage entgegen, holt die Teil-Ergebnisse aus den jeweiligen Quell-Systemen zum Zeitpunkt der Anfrage und setzt sie zusammen. Die Daten bleiben in ihren Ursprungs-Systemen und werden nicht kopiert. Im Datenkontext ist damit meist Query-Federation (auf Deutsch: Abfrage-Föderation über verteilte Datenquellen) gemeint, teils auch Data Federation oder Datenföderation genannt.

Was ist Federation?

Federation ist im Datenmanagement ein Integrationsmuster ohne Datenkopie. Eine zentrale Abfrage-Engine (englisch Query-Engine) nimmt eine SQL-Anfrage (Structured Query Language, die Standardsprache für Datenbank-Abfragen) entgegen, zerlegt sie in Teil-Abfragen für die einzelnen Quell-Systeme, schickt jede Teil-Abfrage zur Ausführung an das jeweilige Quell-System (englisch Query Pushdown, wörtlich: Anfrage nach unten reichen) und fügt die Teil-Ergebnisse zu einer Antwort zusammen. Aus Sicht der Anwendung sieht der Zugriff aus wie eine gewöhnliche Datenbank-Abfrage. Die Quell-Systeme bleiben führend, die Daten werden nicht dupliziert.

Der Begriff hat zwei etablierte Bedeutungsstränge im IT-Sprachgebrauch: erstens die hier beschriebene Query-Federation im Datenmanagement, zweitens Identity Federation im Access-Management (Vertrauensketten zwischen Identity-Providern und Service-Providern über SAML, OIDC oder SCIM). Der Datenmanagement-Strang ist im Kontext von Data- und Analytics-Plattformen der übliche, die Identity-Bedeutung wird am Ende dieses Eintrags nur zur Abgrenzung genannt.

Zu den technischen Bausteinen einer Federation-Schicht zählen Konnektoren zu den Quell-Systemen (JDBC, REST, native APIs), ein logisches Datenmodell mit virtualisierten Tabellen und Views, ein kostenbasierter Query-Planer sowie ein Governance-Layer für Zugriffssteuerung und Metadaten. Ein Result- und Metadaten-Cache dämpft die Latenz bei wiederkehrenden Abfragen. Wikipedia führt den Begriff „föderiertes Informationssystem" auf dieselbe Idee zurück: Zugriff auf mehrere autonome Informationsquellen, ohne die Daten wie in einem Data-Warehouse zu kopieren.

Aktuelle Ausprägungen tragen den Namen in den Anbieter-Plattformen: Databricks Lakehouse Federation innerhalb von Unity Catalog (Foreign Catalogs, Connections, Query Pushdown zu PostgreSQL, MySQL, Snowflake, BigQuery, Redshift, SQL Server), SAP HANA Smart Data Access, SAP Datasphere-Föderation, Microsoft Fabric Shortcuts und OneLake Federation, Google BigQuery Omni. Als offene Query-Federation-Engine dient Trino (mit den Distributionen Starburst und Dremio), als Enterprise-Referenz für Data Virtualization mit Federation-Kern gilt Denodo.

Grenzen zeigen sich in drei Dimensionen. Netzwerk-Latenz und CPU-Kosten summieren sich bei komplexen Joins über Systemgrenzen. Die Verfügbarkeit der föderierten Sicht hängt an der Verfügbarkeit jeder einzelnen Quell-Datenbank. Und die Governance-Tiefe bleibt hinter physischer Materialisierung zurück: kein einheitliches Lineage bis in die Quell-Systeme, kein einheitliches Backup, keine plattformweite Optimierung. Die typische Architektur kombiniert Federation für seltene, konsolidierende Zugriffe (Regulatorik-Reports, Cross-System-Analysen, Prototyping) mit Materialisierung für hochfrequente Reporting-Workloads.

Abgrenzung: Federation, Data Virtualization, Data Integration und Zero-ETL

Federation, Data Virtualization, Data Integration und Zero-ETL adressieren dieselbe Grundfrage (wie kommen Daten aus mehreren Systemen in eine gemeinsame Sicht) mit unterschiedlichen Mitteln. Die folgende Tabelle sortiert sie entlang von Datenbewegung und Verantwortung.

Begriff	Verhältnis zu Federation	Kernunterschied
Data Virtualization	breitere Klammer	Federation ist der Query-Router; Data Virtualization ergänzt Semantik-Layer, Katalog, Zugriffssteuerung und Caching. Anbieter nutzen beide Begriffe heute weitgehend synonym.
Data Integration (physisch)	Gegenmuster	ETL, ELT und CDC kopieren Daten in ein Zielsystem; Materialisierung, feste Kadenz, Latenz durch Batch- oder Log-Strecken. Federation rechnet zur Query-Zeit ohne Kopie.
Zero-ETL	Bereitstellungsform	Automatisierte, verborgene Pipeline zwischen zwei getrennten Stores (AWS Aurora nach Redshift, Fabric Mirroring). Daten liegen physisch doppelt. Federation behält eine einzige Kopie in der Quelle.
Lakehouse Federation	konkrete Implementierung	Databricks-Ausprägung von Query-Federation innerhalb von Unity Catalog: Foreign Catalogs, Connections, gemeinsamer Governance-Layer.
Identity Federation	anderer Wortstamm	Vertrauensketten zwischen IdPs und Service-Providern über SAML oder OIDC. Weder Query- noch Datenmuster; hier nur als Randabgrenzung genannt, um die Wortverwechslung aufzulösen.

Zwei Trennlinien sind für Architektur-Entscheidungen zentral. Erstens die Trennung zwischen logischer und physischer Integration: Federation liest zur Query-Zeit, klassische Integration kopiert im Voraus. Sobald die Auswertungslast steigt, wird Materialisierung wirtschaftlicher als Federation. Zweitens die Trennung zwischen Federation und Data Virtualization: Federation ist die technische Wurzel (Query-Router), Data Virtualization ergänzt Semantik- und Governance-Bausteine. In der Anbieter-Kommunikation verschwimmen beide Begriffe.

Beispiel: föderierter Zugriff über Unity Catalog Foreign Catalog

Ein Handelsunternehmen betreibt Bestandsdaten in SAP S/4HANA, Kundendaten in einem Databricks Lakehouse und Retouren-Daten in einer operativen PostgreSQL-Datenbank. Für ein wöchentliches Regulatorik-Panel wird ein Foreign Catalog über Unity Catalog Lakehouse Federation angelegt: die Query greift zur Laufzeit auf die PostgreSQL-Tabellen zu, die Filter (Zeitraum, Warengruppe) werden per Query Pushdown an PostgreSQL delegiert, der Join mit den Delta-Tabellen läuft im Lakehouse. Eine Kopie entsteht nicht.

Für ein tägliches operatives Retouren-Reporting mit hunderten gleichzeitigen Nutzern trägt der Federation-Pfad nicht mehr, weil jede Abfrage eine Runde zur PostgreSQL kostet und die Quell-Datenbank zum Engpass wird. Statt Federation läuft dort ein Lakeflow-Connect-CDC-Pfad in eine materialisierte Delta-Tabelle. Die Trennlinie ergibt sich aus Query-Häufigkeit und Latenz-Anforderung, nicht aus Vorliebe für eines der beiden Muster.