Delta Lake UniForm: eine Datenkopie, die Delta und Iceberg bedient
Die Kernaussagen auf einen Blick.
- Delta Lake UniForm (Universal Format) ergänzt Delta-Tabellen um Iceberg-Metadaten, sodass Iceberg-Clients dieselben Daten lesen können.
- Delta und Iceberg greifen dabei auf dieselben Parquet-Dateien zu: Die Daten werden nicht dupliziert; nur die Metadaten werden für beide Formate bereitgestellt.
- Vor der Aktivierung sollten drei Punkte geprüft werden: der Schreibpfad (bleibt Delta), die Metadaten-Verzögerung nach Commits und die Feature-Kompatibilität.
- Bei einer bestehenden Delta-Plattform sollte UniForm zunächst an wenigen Serving-Tabellen getestet werden, bevor eine Format-Migration geplant wird.
Inhaltsverzeichnis
Wenn unterschiedliche Formatvorgaben die Plattformplanung verzögern
Eine Databricks-Plattform mit mehreren hundert Delta-Tabellen läuft seit zwei Jahren produktiv. Dann kommt die Anforderung aus dem Konzern: Das zentrale Reporting arbeitet auf Snowflake und soll die Daten als Apache-Iceberg-Tabellen lesen. Das Team richtet zunächst Exportprozesse ein, die zusätzliche Datenkopien erzeugen und nur in festgelegten Intervallen aktualisiert werden. Gleichzeitig wird diskutiert, ob Delta Lake langfristig das passende Tabellenformat ist.
Diese Situation tritt häufig auf, wenn externe Systeme auf die Daten einer bestehenden Plattform zugreifen sollen. Die Diskussion verlagert sich dabei schnell von konkreten Anforderungen auf eine grundsätzliche Formatentscheidung. Dadurch können geplante Integrationen und weitere Plattformvorhaben verzögert werden.
Ist eine Migration bestehender Delta-Tabellen erforderlich, nur weil ein Konsument Iceberg erwartet? Soll eine zusätzliche Datenkopie aufgebaut werden, obwohl dadurch Speicherbedarf, Verzögerungen und mögliche Inkonsistenzen entstehen? Welche langfristigen Abhängigkeiten entstehen durch das heute gewählte Tabellenformat? Wie offen bleibt die Plattform für künftige Abfrage-Engines und Konsumenten?
Die Bedeutung der Formatentscheidung nimmt ab, wenn unterschiedliche Clients dieselben Daten über eigene Metadaten lesen können. UniForm adressiert genau diesen Anwendungsfall.
Was ist Delta Lake UniForm?
Delta Lake UniForm (Universal Format) erzeugt für eine Delta-Tabelle zusätzliche Metadaten, über die andere Tabellenformate auf dieselben Daten zugreifen können. Die Delta-Dokumentation beschreibt, dass Delta-Tabellen mit Iceberg- und Hudi-Clients gelesen werden können, wenn UniForm aktiviert ist. Eine Engine mit Iceberg-Unterstützung kann die Delta-Tabelle dadurch über eine Iceberg-kompatible Sicht lesen. Die zugrunde liegenden Parquet-Dateien müssen dafür weder kopiert noch konvertiert werden.
Eingeführt wurde die Funktion mit Delta Lake 3.0. Databricks positionierte UniForm im August 2023 als Vereinheitlichung der Tabellenformate ohne zusätzliche Datenkopien. Die Funktion adressiert die zunehmende parallele Nutzung von Delta Lake und Apache Iceberg, die sich als die beiden dominierenden offenen Tabellenformate etabliert haben.
UniForm reduziert die langfristigen Auswirkungen der ursprünglichen Formatentscheidung: Ob eine Tabelle auch für Iceberg-Clients lesbar sein soll, kann dadurch pro Tabelle entschieden werden. Bestehende Delta-Tabellen und Pipelines können weiterhin genutzt werden, während neue Konsumenten mit Iceberg-Anforderung dieselbe Datenbasis lesen. Die Architekturentscheidung kann sich dadurch stärker an Workloads, Governance und Betriebsanforderungen orientieren.
UniForm ersetzt jedoch keine native Iceberg-Plattform. Änderungen an der Tabelle werden weiterhin ausschließlich über Delta geschrieben, Iceberg-Clients greifen ausschließlich lesend zu, und die Iceberg-Metadaten werden erst nach dem Delta-Commit erzeugt und stehen daher leicht verzögert zur Verfügung. Wie Speicher, Tabellenformat und Katalog zusammen eine tragfähige Plattform ergeben, zeigen wir im Überblick zum Lakehouse.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Wie funktioniert Delta Lake UniForm?
UniForm nutzt, dass Delta Lake, Apache Iceberg und Apache Hudi ihre Daten in Parquet-Dateien im Objektspeicher speichern. Die Unterschiede liegen hauptsächlich in den Metadaten, Transaktionsprotokollen und Verwaltungsfunktionen. Eine alternative Sicht auf dieselben Daten kann deshalb über zusätzliche Metadaten bereitgestellt werden. Die bestehenden Parquet-Dateien müssen dabei nicht verändert werden.
Auf dieser Grundlage arbeitet UniForm in drei Schritten:
Tabellenweise Aktivierung
UniForm wird über Tabellen-Eigenschaften der Delta-Tabelle eingeschaltet, wahlweise für Iceberg, Hudi oder beide. Den Hudi-Pfad führt das Delta-Projekt bislang als Vorschau-Funktion. Bestehende Tabellen lassen sich nachträglich umstellen; durch die Aktivierung steigen die Protokollanforderungen der Tabelle, und Column Mapping wird eingeschaltet.
Zeitversetzte Erzeugung der Metadaten
Nach jedem Delta-Commit erzeugt UniForm die Iceberg-Metadaten zeitversetzt über denselben Parquet-Dateien. Da nur Metadaten erzeugt werden, bleibt der zusätzliche Schreibaufwand begrenzt.
Bereitstellung über einen Iceberg-kompatiblen Katalog
Iceberg-Clients lösen die Tabellen über einen Katalog mit Iceberg-REST-Schnittstelle auf. Auf Databricks stellt Unity Catalog diesen Endpunkt bereit.
Die Open-Source-Variante von Unity Catalog dokumentiert den Lesezugriff für Engines mit reinen Iceberg-Konnektoren gesondert.
Alternativ können einzelne Engines, darunter BigQuery, direkt auf die aktuelle Iceberg-Metadatendatei verweisen. Dieser Verweis muss nach Änderungen der Tabelle regelmäßig aktualisiert werden, üblicherweise als zusätzlicher Schritt in der Schreib-Pipeline. Die Anbindung über einen Katalog vermeidet diesen zusätzlichen Pflegeaufwand; für produktive Integrationen ist der Katalogzugriff daher in der Regel geeigneter.
Über den Katalog lassen sich zudem Berechtigungen und Auditierung zentral durchsetzen: Liest ein externes System über den Iceberg-REST-Endpunkt von Unity Catalog, greifen dieselben Berechtigungen und dieselbe Auditierung wie für interne Nutzer. Direkte Speicherzugriffe können dagegen zentrale Berechtigungs- und Auditmechanismen umgehen.
Für die Kapazitätsplanung relevant: Zusätzlicher Speicher wird lediglich für die Iceberg-Metadaten benötigt, die Datendateien werden nicht dupliziert; neue Parquet-Dateien schreiben UniForm-Tabellen mit Zstandard-Kompression. Für Iceberg-Clients entsteht eine leichte Verzögerung: Sie sehen einen neuen Datenstand erst, wenn die Metadaten-Konvertierung abgeschlossen ist. Bei vielen aufeinanderfolgenden Schreibvorgängen kann sich diese Verzögerung erhöhen, weil UniForm mehrere Delta-Commits in einen Iceberg-Commit bündelt und die Metadatenkonvertierung nacheinander verarbeitet wird.
Was UniForm im Betrieb verändert
UniForm kann bestehende Export- und Kopierprozesse für Iceberg-Konsumenten ersetzen. Externe Konsumenten greifen dadurch auf dieselben Parquet-Dateien wie die Delta-Plattform zu. Dadurch können mehrere laufende Aufwände reduziert werden: die Compute-Kosten der Export-Jobs und der Speicher der Duplikate. Zusätzlich sinkt der Aufwand für den Abgleich unterschiedlicher Datenstände.
Über das Iceberg-Ökosystem können verschiedene externe Analyseplattformen angebunden werden. AWS beschreibt UniForm als Weg, Delta-Tabellen für Iceberg-basierte Analytik-Dienste zu öffnen: Snowflake liest Delta-Tabellen als Iceberg, ebenso Trino, BigQuery oder Microsoft Fabric über OneLake. Grundsätzlich können Engines mit geeigneter Iceberg-Unterstützung als lesende Konsumenten der Delta-Plattform angebunden werden.
Im beschriebenen Szenario könnte die Umsetzung folgendermaßen aussehen: Die Serving-Tabellen der Gold-Schicht werden auf UniForm umgestellt, das Snowflake-Reporting bindet sie über den Iceberg-REST-Endpunkt von Unity Catalog an, und die Export-Pipelines werden abgeschaltet. Das externe Reporting liest damit dieselbe Datenbasis wie die internen Anwendungen. Zu berücksichtigen ist lediglich die Verzögerung bei der Aktualisierung der Iceberg-Metadaten. Die Verantwortlichkeiten bleiben dabei eindeutig verteilt: Schreibvorgänge und Tabellenwartung erfolgen weiterhin über Delta, gelesen wird über den Katalog.
Auch organisatorisch vereinfacht UniForm die Entscheidung: Teams entscheiden pro Tabelle, welche Konsumenten bedient werden, und Integrationsvorhaben müssen dadurch nicht mehr auf eine vollständige Formatmigration warten.
Löst UniForm die Wahl zwischen Delta Lake und Iceberg?
Für reine Lesezugriffe löst UniForm viele Interoperabilitätsfragen, für externe Schreibzugriffe jedoch nicht. UniForm eignet sich insbesondere für externe Engines, die bestehende Delta-Tabellen lesend nutzen sollen. Sollen externe Engines dieselben Tabellen verändern oder verlangt ein Konzern-Standard native Iceberg-Tabellen mit Schreibpfad, ist UniForm nicht ausreichend.
Die drei möglichen Ansätze lassen sich anhand weniger Kriterien vergleichen:
| Achse | UniForm aktivieren | Format-Migration nach Iceberg | Daten-Duplikation pro Konsument |
|---|---|---|---|
| Datenkopien | eine | eine (nach Abschluss) | zwei oder mehr |
| Schreibpfad | Delta | Iceberg | Delta plus Export-Jobs |
| Aktualität für Konsumenten | leicht verzögert (Metadaten-Konvertierung) | direkt | abhängig vom Export-Takt |
| Aufwand | Tabellen-Eigenschaft, Katalog-Anbindung | Migrations-Projekt über alle Tabellen und Pipelines | laufende Pipeline-Pflege |
| Betriebsrisiko | vergleichsweise gering, die UniForm-Sicht kann deaktiviert werden | hoch während der Umstellung | Konsistenz- und Kostenrisiko dauerhaft |
| Typischer Auslöser | Lese-Anforderung externer Engines | Schreib-Anforderung oder verbindlicher Iceberg-Standard | häufig als bestehende Übergangslösung vorhanden |
Für einen reinen Iceberg-Lesezugriff ist UniForm in der Regel ausreichend. Für Schreibzugriffe oder die vollständige Nutzung Iceberg-spezifischer Funktionen sollten native Iceberg-Tabellen geprüft werden. Zusätzliche Datenkopien verursachen in der Regel den höchsten dauerhaften Betriebsaufwand und eignen sich höchstens als Übergangslösung.
Vor der Aktivierung sollte geprüft werden, welche Zielsysteme Delta bereits direkt lesen können: Einige Ziel-Engines, darunter Trino und BigQuery, lesen Delta-Tabellen inzwischen direkt über eigene Delta-Konnektoren. Für solche Systeme ist UniForm möglicherweise nicht erforderlich; die Brücke bleibt für Engines relevant, die ausschließlich Iceberg unterstützen.
Die grundlegenden Unterschiede zwischen Delta Lake und Apache Iceberg sollten separat bewertet werden:
- Wie Transaktionsprotokoll, Zeitreisen und Schema-Prüfung in Delta arbeiten, zeigen wir im Überblick zu Delta Lake.
- Wann das herstellerneutrale Tabellenformat als natives Fundament die bessere Wahl ist, klären wir im Überblick zu Apache Iceberg.
- Wie aus Rohdaten über Bronze-, Silber- und Gold-Schichten eine verlässliche Serving-Ebene entsteht, führen wir in der Medaillon-Architektur aus.
Mit Apache XTable existiert außerdem ein eigenständiger Ansatz zur Konvertierung von Metadaten zwischen Tabellenformaten. Das Delta-Projekt ordnet beide Werkzeuge als Wege zu einem formatunabhängigen offenen Lakehouse ein: UniForm ist in Delta Lake eingebaut und erzeugt die Iceberg-Sicht direkt beim Schreiben, XTable konvertiert als eigenständiges Inkubator-Projekt Metadaten zwischen Delta, Iceberg und Hudi in mehrere Richtungen. Für eine bestehende Delta-Plattform ist UniForm meist einfacher zu integrieren; XTable kann relevant sein, wenn mehrere bestehende Tabellenformate miteinander verbunden werden müssen.
Auch die Marktentwicklung bewegt sich in Richtung einer stärkeren Interoperabilität. Mit der Übernahme von Tabular, dem Unternehmen der Iceberg-Gründer, hat Databricks 2024 die Annäherung beider Formate zur erklärten Strategie gemacht, und Unity Catalog verwaltet inzwischen auch native Iceberg-Tabellen. Mit zunehmender Interoperabilität sinkt die Zahl der Anwendungsfälle, die allein wegen des Tabellenformats eine vollständige Migration erfordern.
Grenzen
UniForm ermöglicht lesenden Iceberg-Clients den Zugriff auf bestehende Delta-Daten ohne zusätzliche Datenkopie. Nicht alle Anforderungen an eine native Iceberg-Plattform werden damit abgedeckt, und einige Eigenschaften gehören vor der Aktivierung auf den Prüfstand.
Nur Lesezugriff über Iceberg
Schreiboperationen laufen ausschließlich über den Delta-Pfad. Ein Client, der über die Iceberg- oder Hudi-Sicht schreibt, kann die Tabelle beschädigen. Externe Clients brauchen deshalb einen Katalog mit ausdrücklich vergebenen Leserechten. Sollen externe Engines schreiben, sind native Iceberg-Tabellen mit eigenem Schreibpfad erforderlich.
Metadaten mit Verzögerung
Die Metadaten-Konvertierung läuft asynchron nach dem Delta-Commit. Für Streaming-Konsumenten mit hohen Aktualitätsanforderungen ist der Iceberg-Zugriff über UniForm meist ungeeignet, und Delta- sowie Iceberg-Sicht können unterschiedliche Versionsstände ausweisen.
Eingeschränkte Feature-Kompatibilität
Tabellen mit aktivierten Deletion Vectors unterstützt UniForm nicht; die Umstellung entfernt sie und kann Datendateien neu schreiben. Change Data Feed und Delta Sharing funktionieren nur für Delta-Clients, ohne Gegenstück in der Iceberg-Sicht.
Dauerhaft höhere Protokollanforderungen
Die bei der Aktivierung eingeschaltete Spalten-Zuordnung und die angehobenen Protokoll-Versionen bleiben auch nach einer Deaktivierung bestehen. Schreibzugriffe brauchen anschließend mindestens Delta Lake 3.1.
Governance hängt an der Kataloganbindung
Der Nutzen der Brücke gilt nur, wenn externe Zugriffe über den Iceberg-REST-Endpunkt des zentralen Katalogs laufen. Direktzugriffe auf Speicher-Pfade umgehen Lineage, Berechtigungen und Auditierung.
Tabellen-Pflege bleibt bei Delta
Optimierungen wie Liquid Clustering und der Lebenszyklus folgen weiterhin der Delta-Logik. Iceberg-Clients erhalten nur eine Lesesicht mit begrenztem Funktionsumfang, ohne eigene Verwaltungs-Features.
Diese Einschränkungen begrenzen den Einsatzbereich, sprechen aber nicht grundsätzlich gegen UniForm. Für den lesenden Zugriff externer Engines auf eine bestehende Delta-Plattform ist UniForm meist mit überschaubarem Einführungsaufwand nutzbar.
Bei externen Schreibanforderungen, verbindlichen Iceberg-Vorgaben oder Streaming-Konsumenten muss die Tabellenarchitektur erneut bewertet werden. Dann konkurriert UniForm mit nativem Iceberg auf derselben Plattform; entscheidend sind Schreibanforderungen, Betriebsmodell und benötigte Iceberg-Funktionen.
Fazit
Delta Lake UniForm reduziert die Notwendigkeit, sich für lesende Konsumenten dauerhaft auf nur ein Tabellenformat festzulegen.
Eine Delta-Plattform kann Iceberg-Konsumenten bedienen, ohne Daten zu kopieren oder Tabellen zu migrieren, und die Iceberg-Kompatibilität kann dadurch für einzelne Tabellen konfiguriert werden.
Der Einsatz ist besonders sinnvoll, sobald eine bestehende Delta-Plattform Konsumenten außerhalb des eigenen Ökosystems bedienen soll. Typische Einsatzszenarien sind:
- ein Konzern-Reporting auf Snowflake, Trino oder BigQuery, das Delta-Tabellen lesen soll
- Exportprozesse, die zusätzliche Datenkopien erzeugen und regelmäßig synchronisiert werden müssen
- eine Plattformentscheidung, die durch unterschiedliche Formatvorgaben der Konsumenten verzögert wird
- Bedenken hinsichtlich der langfristigen Interoperabilität von Delta Lake, die einer geplanten Databricks-Einführung im Weg stehen
Wenn dagegen Dritt-Engines schreiben sollen, ein verbindlicher Iceberg-Standard mit Schreibpfad existiert oder die Plattform ohnehin neu aufgebaut wird, ist UniForm möglicherweise nicht die geeignete langfristige Lösung. Dann steht der direkte Vergleich zwischen nativem Iceberg und Delta an, mit UniForm als Ergänzung für Übergangsphasen.
Mein Vorschlag: Die Formatentscheidung sollte sich an den konkreten Anforderungen der konsumierenden Systeme orientieren. Zunächst sollten alle geplanten Konsumenten mit ihren Lese- und Schreibanforderungen erfasst werden. Reicht ein lesender Zugriff aus, sollte UniForm zunächst an wenigen repräsentativen Serving-Tabellen getestet werden. Dabei sollten Aktualisierungsverzögerung, Client-Kompatibilität und die Anbindung an den zentralen Katalog geprüft werden, bevor der Rollout breiter wird.
Die Entscheidung kann dadurch auf konkrete technische Anforderungen gestützt werden; maßgeblich sind die tatsächlichen Lese- und Schreibanforderungen der angebundenen Systeme.
Deckt UniForm eure Format-Anforderungen ab?
- welche eurer Tabellen und Konsumenten echte Kandidaten für UniForm sind
- welche Kompatibilitäts-, Governance- und Latenz-Risiken vor der Aktivierung geprüft werden müssen
- welcher Architekturpfad zwischen UniForm, nativem Iceberg und Migration für eure Situation trägt
FAQ
Delta Lake UniForm (Universal Format) ist eine Funktion von Delta Lake, die zu einer Delta-Tabelle zusätzlich Iceberg- und optional Hudi-Metadaten erzeugt. Iceberg-Clients können die Tabelle dadurch lesen, als wäre sie eine native Iceberg-Tabelle. Die Daten liegen weiterhin nur einmal als Parquet-Dateien im Objektspeicher; lediglich die Metadaten-Schicht wird mehrfach geführt.
