Data Virtualization: Definition, Vertreter, Abgrenzung

Data Virtualization (Datenvirtualisierung) ist ein Integrationsmuster, bei dem eine Abfrage-Schicht Auswertungen zum Zeitpunkt der Anfrage an unterschiedliche Datenquellen weiterreicht und die Teilergebnisse zu einer einheitlichen logischen Sicht zusammenführt, ohne die Daten zu kopieren. Die Rohdaten bleiben in ihren Ursprungs-Systemen (Datenbanken, Data Warehouses, Lakehouses, Cloud-Anwendungen) liegen; der Zugriff läuft über eine gemeinsame Beschreibungs- und Zugriffs-Schicht.

Was ist Data Virtualization?

Data Virtualization ist ein Sammelbegriff für logische Integrations-Plattformen, die verstreute Datenbestände erst bei der Abfrage zusammenführen. Das ist kein Standard, sondern eine Produktkategorie mit einem gemeinsamen Wirk-Prinzip: eine Föderations-Engine (die zentrale Vermittlungs-Software) nimmt eine Abfrage in SQL oder GraphQL (den beiden gängigen Abfrage-Sprachen) entgegen, zerlegt sie in Teil-Abfragen für die jeweiligen Quell-Systeme, schiebt möglichst viel Arbeit (vor allem Filter) an diese Quellen herunter (Predicate Pushdown) und fügt die Teilergebnisse anschließend wieder zusammen. Für die aufrufende Anwendung sieht das aus wie eine ganz normale Datenbank-Abfrage.

Die technischen Bausteine umfassen Konnektoren zu den Quell-Systemen (JDBC, REST, native APIs), ein logisches Datenmodell mit virtualisierten Tabellen und Views, einen kostenbasierten Query-Planer und eine Semantik- und Governance-Schicht, in der Zugriffssteuerung, Row-/Column-Level-Security und Katalog-Metadaten liegen. Ein Result- und Metadaten-Cache dämpft die Latenz bei wiederkehrenden Abfragen; einige Plattformen erlauben zusätzlich das explizite Materialisieren einzelner Views, wenn die Query-Häufigkeit hoch wird.

Historisch wanderte der Begriff durch drei Wellen. Die Enterprise-Data-Virtualization-Anbieter der 2000er (Composite, Denodo, IBM InfoSphere Federation Server) adressierten heterogene Warehouse-Landschaften und Legacy-Datenbanken. Die Trino-basierte Welle (Starburst, Dremio, Ahana) verlagerte den Ansatz auf Data Lakes und offene Formate. Die aktuelle Welle integriert Federation direkt in die Governance-Schicht der Lakehouse- und SAP-Plattformen: Databricks Lakehouse Federation innerhalb von Unity Catalog, SAP HANA Smart Data Access, SAP Datasphere-Föderation, Microsoft Fabric Shortcuts, Google BigQuery Omni. Die Grenze zwischen Data Virtualization und Katalog-Federation verschwimmt dadurch zunehmend.

Der Zweck bleibt konstant: schnellere Time-to-Data, weniger Datenkopien, konsolidierte Sicht in föderierten Organisationen (Data Mesh, Multi-Cloud) und Prototyping vor der Entscheidung, welche Datensätze materialisiert werden. Grenzen zeigen sich bei komplexen Joins über Systemgrenzen (Netzwerk-Latenz und CPU-Kosten summieren sich), bei Abhängigkeit von der Verfügbarkeit der Quell-Systeme und bei fehlender Governance-Tiefe gegenüber physischer Materialisierung. Die typische Architektur kombiniert deshalb beide Muster: Federation für seltene, konsolidierende Zugriffe, Materialisierung für hochfrequente Reporting-Workloads.

Abgrenzung gegen Data Federation, Data Integration, Zero-ETL und Lakehouse Federation

Data Virtualization wird häufig mit einem seiner Nachbar-Begriffe gleichgesetzt. Die folgende Tabelle sortiert sie entlang von Datenbewegung und Verantwortung.

Begriff	Verhältnis zu Data Virtualization	Kernunterschied
Data Federation	historischer Kern	Bezeichnet den reinen Query-Router zwischen heterogenen Quellen. Data Virtualization erweitert das Muster um Semantik-Layer, Katalog, Zugriffssteuerung und Caching. Heute nutzen viele Anbieter beide Begriffe synonym.
Data Integration (physisch)	Gegenmuster	ETL, ELT und CDC kopieren Daten in ein Zielsystem und arbeiten mit Materialisierung, fester Kadenz und Latenz durch Batch- oder Log-Strecken. Data Virtualization rechnet zur Query-Zeit ohne Kopie.
Zero-ETL	Bereitstellungsform	Automatisierte, verborgene Pipeline zwischen zwei getrennten Stores (AWS Aurora → Redshift, Fabric Mirroring). Daten liegen physisch doppelt; Data Virtualization behält eine einzige Kopie in der Quelle.
Lakehouse Federation	konkrete Implementierung	Databricks-Ausprägung von Data Virtualization innerhalb von Unity Catalog: föderierter Zugriff auf externe Systeme (Snowflake, BigQuery, PostgreSQL) unter gemeinsamer Governance.
Data Mesh	Organisationsmodell	Dezentrales Modell für Datenprodukte. Data Virtualization kann als technischer Baustein dienen (Cross-Domain-Föderation ohne Kopien), ist aber weder Voraussetzung noch Ersatz.

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

Beispiel: föderierte Retouren-Sicht über PostgreSQL und Lakehouse

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 Retouren-Panel wird eine föderierte View über Unity Catalog Lakehouse Federation bereitgestellt: die Query greift zur Laufzeit auf die PostgreSQL-Tabellen und die Delta-Tabellen zu, ohne die PostgreSQL-Daten physisch ins Lakehouse zu ziehen. Der Query-Planer schiebt die Filter (Zeitraum, Warengruppe) an PostgreSQL und übernimmt den Join im Lakehouse.

Für ein tägliches operatives Retouren-Reporting mit hunderten gleichzeitigen Nutzern trägt dieser Pfad nicht mehr. Statt jeder Abfrage eine Runde zur PostgreSQL zu erlauben, wird eine materialisierte Delta-Tabelle über einen Lakeflow-Connect-CDC-Pfad gepflegt. Die Trennlinie zwischen Federation und Materialisierung ergibt sich aus Query-Häufigkeit und Latenz-Anforderung. Data Virtualization deckt in der Regel seltene, semantik-konsolidierende Zugriffe ab (Regulatorik-Reports, Cross-System-Analysen, Prototyping), während Materialisierung hochfrequente Reporting- und ML-Workloads trägt.