OneLake-Interoperabilität: Microsoft Fabric virtualisiert Apache Iceberg und Delta Lake
OneLake-Interoperabilität: Microsoft Fabric virtualisiert Apache Iceberg und Delta Lake
Zusammenfassung
Microsoft Fabric hat native Virtualisierungsfunktionen für OneLake angekündigt. Diese ermöglichen den transparenten, kopierfreien Zugriff auf Delta-Lake-Tabellen als Apache-Iceberg-Tabellen und umgekehrt via Metadaten-Virtualisierung. Zudem wird die Spiegelung von Dremio-verwalteten Iceberg-REST-Katalogen unterstützt, wodurch verteilte Lakehouse-Daten ohne physische Duplizierung direkt in Fabric nutzbar sind. Dies entschärft den Formatstreit zwischen führenden Lakehouse-Technologien erheblich.
Was ist passiert?
- Native Virtualisierung: Microsoft OneLake virtualisiert ab sofort automatisch Metadaten zwischen Delta Lake und Apache Iceberg.
- Delta Lake als Iceberg: Delta-Lake-Tabellen erhalten virtuelle Iceberg-Metadaten (z. B.
*.metadata.jsonimmetadata/-Ordner) und können von externen Iceberg-Engines wie Snowflake gelesen werden. - Iceberg als Delta Lake: Externe Apache Iceberg (V2) Tabellen können als Verknüpfungen (Shortcuts) in Fabric eingebunden werden. OneLake generiert automatisch virtuelle Delta-Logs (
_delta_log/), um sie für alle Fabric-Engines nutzbar zu machen. - Dremio REST Catalog Mirroring: Metadaten von Dremio-verwalteten Iceberg-Tabellen können gespiegelt werden. Fabric vended automatisch temporäre Zugriffsschlüssel (Credential Vending), um kopierfreie Abfragen über T-SQL, Spark oder Power BI Direct Lake zu ermöglichen.
- Snowflake-Partnerschaft: Die nahtlose Integration mit Snowflake (General Availability seit Februar 2026) ermöglicht das Schreiben und Lesen von Iceberg-Tabellen direkt in OneLake über externe Volumes.
Warum es wichtig ist
Der Wettstreit um offene Tabellenformate (Delta Lake vs. Apache Iceberg vs. Apache Hudi) zwang Unternehmen bisher zu aufwendigen ETL-Pipelines, Datenkopien und doppelten Speicherkosten. Die metadatenbasierte Virtualisierung von Microsoft Fabric löst dieses Dilemma auf Architekturebene. Daten müssen nicht mehr konvertiert werden. Dies senkt Speicher- und Compute-Kosten drastisch und beschleunigt die Bereitstellung von Analysen über verschiedene Plattformen hinweg.
Beweise
- Microsoft Learn Dokumentation: Offizielle Ankündigungen und technische Anleitungen zur Metadaten-Virtualisierung.
- Dremio-Blog: Details zur Spiegelung des Dremio Iceberg REST Catalogs und der automatischen Token-Verteilung (Credential Vending).
- Snowflake-Blog: GA-Ankündigung der OneLake-Interoperabilität und der catalog-linked Databases.
Analyse
Die Virtualisierung findet rein auf Metadaten-Ebene statt, da beide Formate auf Parquet-Dateien basieren. OneLake übersetzt die Log-Strukturen (Delta Log JSONs in Iceberg Avro/JSON-Metadaten) on-the-fly mit einer Latenz von 5 Sekunden bis 2 Minuten. Die größte Einschränkung bleibt vorerst die Beschränkung auf Apache Iceberg V2; Iceberg V3 befindet sich noch in der Entwicklung. Dennoch zeigt sich hier ein klarer Trend: Cloud-Data-Plattformen positionieren sich nicht mehr als geschlossene Silos, sondern als interoperable Ökosysteme, die auf offenen Datenstandards aufbauen.
Praktische Erkenntnisse
- Keine ETL-Pipelines für Konvertierungen: Entwickler sollten bestehende Pipelines zur Formatkonvertierung abschalten und stattdessen die OneLake-Virtualisierung nutzen.
- Einrichtung von Shortcuts: Externe Iceberg-Tabellen müssen direkt im Ordner
Tableseines nicht-schemaaktivierten Lakehouse abgelegt werden, um die Delta-Virtualisierung zu triggern. - Prüfung der Update-Frequenz: Da die Konvertierungslatenz bis zu 2 Minuten betragen kann, eignet sich diese Methode primär für Batch-Updates oder moderate Schreibfrequenzen.
- Snowflake-Integration: Nutzen Sie externe Volumes in Snowflake, um Iceberg-Tabellen direkt in OneLake zu verwalten.
Offene Fragen
- Wie gut skaliert die Metadaten-Virtualisierung bei extrem großen Tabellen mit Millionen von Parquet-Dateien und hoher Partitionierungstiefe?
- Wann wird die Unterstützung für Apache Iceberg V3 und fortgeschrittene Partitionstransformationen wie
bucket[N]odertruncate[W]nachgeliefert? - Wie verhält sich die Performance bei komplexen Leseoperationen im Vergleich zu nativ geschriebenen Formaten?