Delta Lake: Wie ein Transaktionslog den Data Lake verlässlich macht
Die Kernaussagen auf einen Blick.
- Delta Lake ist ein offenes Tabellenformat, das Parquet-Dateien im Objektspeicher um ein Transaktionslog ergänzt und sie damit zu verlässlichen Tabellen mit ACID-Garantien macht.
- Die Wahl des Tabellenformats beeinflusst zugleich, wie Korrekturen, Löschungen und die laufende Performance-Optimierung umgesetzt werden.
- Vor der Einführung sollten drei Punkte festgelegt werden: die Interoperabilität gegenüber Apache Iceberg, die Aufbewahrungsfristen für alte Versionen und die Verantwortung für die Tabellen-Wartung.
- Empfehlung: Das Format zusammen mit einem Wartungsplan einführen und die mögliche Interoperabilität mit Apache Iceberg über UniForm von Anfang an berücksichtigen.
Inhaltsverzeichnis
Was passiert, wenn ein Ladeprozess nicht vollständig durchläuft?
In der Nacht bricht ein Ladeprozess für Bewegungsdaten nach etwa zwei Dritteln ab. Ein Teil der Parquet-Dateien wurde bereits geschrieben, während andere Dateien fehlen. Am nächsten Morgen basiert das Vertriebsdashboard auf einem unvollständigen Datenbestand. Das Team muss die unvollständigen Dateien identifizieren, manuell entfernen und den Prozess erneut starten. Bis zur Korrektur stehen keine verlässlichen Zahlen für das Reporting zur Verfügung.
Solche Probleme treten häufig auf, wenn ein Data Lake ausschließlich auf einzelnen Dateien ohne Transaktionsschicht basiert. Solange eine Tabelle lediglich aus einem Verzeichnis mit Parquet-Dateien besteht, fehlt ein Mechanismus, der unvollständige Schreibvorgänge vor Abfragen verbirgt, eine Schema-Änderung stoppt oder eine Löschung über Millionen Dateien hinweg nachvollziehbar macht.
Warum sehen Berichte Daten, die nie vollständig geschrieben wurden? Wie löschen wir personenbezogene Daten aus Jahren von Dateien, ohne Wochen zu verlieren? Wie werden unbemerkte Schemaänderungen in einem Quellsystem erkannt? Und warum verschlechtert sich die Abfrageleistung mit wachsendem Datenbestand?
Ein Data Lake wird nicht allein durch sorgfältigere Ladeprozesse transaktionssicher, sondern durch eine Schicht, die unfertige Schreibvorgänge gar nicht erst sichtbar macht. Delta Lake stellt eine solche Transaktionsschicht bereit.
Was ist Delta Lake?
Delta Lake ist ein offenes Tabellenformat für Daten auf Objektspeichern: Es speichert Daten als Parquet-Dateien im Objektspeicher (Amazon S3, Azure Data Lake Storage, Google Cloud Storage); zusätzlich zu den Parquet-Dateien führt Delta Lake ein Transaktionslog, in dem Änderungen versioniert dokumentiert werden. Dadurch können die Dateien als konsistente, versionierte Tabelle mit ACID-Transaktionen und Schema-Regeln verwaltet werden. Entwickelt wurde das Format bei Databricks, seit 2019 ist es ein Open-Source-Projekt unter dem Dach der Linux Foundation.
Die Transaktionsschicht erweitert die Einsatzmöglichkeiten des Data Lake. Ein Schreibvorgang wird erst sichtbar, wenn der zugehörige Eintrag im Transaktionslog vollständig abgeschlossen ist; Abfragen greifen dadurch nur auf vollständige Tabellenstände zu. Löschungen und Korrekturen laufen als belegbare Tabellen-Operationen; Löschanforderungen aus der DSGVO lassen sich damit reproduzierbar umsetzen. Die Versionshistorie erleichtert es, Fehler und Änderungen auf einen bestimmten Tabellenstand zurückzuführen.
Fachliche Datenqualität, Modellierung und Zugriffsrechte werden durch das Tabellenformat jedoch nicht automatisch geregelt; diese Aufgaben bleiben eigene Architektur-Entscheidungen. Wie Data Warehouse, Data Lake und Tabellenformat in einem gemeinsamen Zielbild zusammenpassen, zeigen wir im Überblick zur Lakehouse-Architektur.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Wie funktioniert das Transaktionslog von Delta Lake?
Neben den Datendateien jeder Delta-Tabelle liegt ein Unterverzeichnis namens _delta_log. Es dokumentiert sämtliche Änderungen an der Tabelle als nummerierte Einträge; eine Änderung wird erst wirksam, wenn sie vollständig im Transaktionslog verzeichnet ist. Jeder Eintrag ist eine JSON-Datei, die beschreibt, welche Dateien hinzukommen, welche entfallen und wie das Schema aussieht. Damit auch umfangreiche Versionshistorien effizient verarbeitet werden können, erstellt Delta Lake regelmäßig Checkpoints, die den aktuellen Tabellenstand zusammenfassen.
Für den abgebrochenen Ladeprozess aus dem Einstieg bedeutet dieser Aufbau: Die bereits geschriebenen Dateien können physisch im Speicher vorhanden sein, ihr abschließender Log-Eintrag fehlt jedoch. Sie werden dadurch nicht Teil des sichtbaren Tabellenstands, jede Abfrage liest weiter die letzte vollständige Version, und der Ladeprozess kann anschließend kontrolliert wiederholt oder bereinigt werden. Damit wird das Prinzip atomarer Transaktionen auch auf einem Objektspeicher umgesetzt: Eine Änderung wird ganz oder gar nicht sichtbar.
Das Transaktionslog ermöglicht darüber hinaus drei wichtige Funktionen für den Betrieb. Erstens prüft Delta Lake jedes Schreiben gegen das hinterlegte Schema (Schema Enforcement) und weist abweichende Daten zurück; geplante Schemaänderungen, beispielsweise zusätzliche Spalten, können als Schema Evolution kontrolliert freigegeben werden. Zweitens funktionieren UPDATE, DELETE und MERGE als Tabellen-Befehle, sodass Korrekturen und das Zusammenführen von Quelldaten möglich sind, ohne dass Dateien manuell identifiziert und neu geschrieben werden müssen. Drittens koordiniert eine optimistische Nebenläufigkeitskontrolle parallele Jobs: Jeder Prozess erstellt zunächst seine Änderungen auf Grundlage des gelesenen Tabellenstands, und vor dem Commit wird geprüft, ob zwischenzeitlich konkurrierende Änderungen erfolgt sind. Bei einem Konflikt wird einer der Schreibvorgänge kontrolliert abgebrochen, die Tabelle bleibt konsistent.
Das Transaktionslog unterstützt außerdem eine gemeinsame Verarbeitung von Batch- und Streaming-Daten. Eine Delta-Tabelle lässt sich gleichzeitig per Batch-Job befüllen, als Streaming-Quelle abonnieren und als Schreib-Ziel für Datenströme nutzen; das Log stellt dabei sicher, dass Wiederholungen nach Fehlern keine doppelten Daten erzeugen. Separate Datenbestände und Verarbeitungsstrecken für Batch und Streaming können dadurch in vielen Fällen vermieden werden.
Das Transaktionslog verbessert zudem den Zugriff auf sehr große Tabellen. Das Auflisten von Dateien im Objektspeicher ist langsam und für große Tabellen ein eigener Engpass. Die Delta-Entwickler zeigen im VLDB-Paper von 2020, dass eine Tabelle mit einer Million Partitionen über klassisches Datei-Listing mehr als eine Stunde zum Öffnen brauchte, über das gecachte Log dagegen 17 Sekunden. Zusätzlich speichert das Log Statistiken je Datei, sodass Abfragen nicht relevante Dateien überspringen, noch bevor die eigentlichen Datendateien gelesen werden.
Was unterscheidet Delta Lake von einem Data Lake?
Der wesentliche Unterschied liegt in der zusätzlichen Tabellen- und Transaktionsschicht: Ein Data Lake stellt den zugrunde liegenden Objektspeicher für Dateien aller Art bereit, Delta Lake verwaltet die darauf abgelegten Dateien als konsistente, versionierte Tabellen. Der bestehende Data Lake bleibt dabei als Speicherschicht erhalten.
Apache SparkPhotonTrino · StarRocks
Apache Flink
dbt
MLflow| Situation | Parquet-Dateien ohne Transaktionsschicht | Delta-Tabelle |
|---|---|---|
| Job bricht beim Schreiben ab | Unvollständige Datenstände können für Abfragen sichtbar werden | Letzte vollständige Version bleibt gültig |
| Quellsystem ändert das Schema | Die Schemaänderung wird möglicherweise erst bei der späteren Verarbeitung erkannt | Schreiben wird geprüft, Änderung läuft kontrolliert |
| Personenbezogene Daten löschen | Betroffene Dateien suchen und neu schreiben | Löschung über eine nachvollziehbare Tabellenoperation |
| Stand von letzter Woche ansehen | Nur über separate Kopien möglich | Versionshistorie ist abfragbar |
| Wartung | Reaktiv und ohne festgelegten Wartungsprozess | Geplante Kompaktierung und Aufräum-Läufe |
Die zusätzlichen Funktionen erfordern jedoch einen geregelten Betrieb: Delta-Tabellen benötigen regelmäßige Wartung und definierte Aufbewahrungsregeln. Warum der rohe Lake als alleinige Plattform an Transaktionen und Governance scheitert, klären wir im Überblick zum Data Lake.
Die Komponenten im Überblick: sechs zentrale Funktionen von Delta Lake
Neben dem Transaktionslog bietet Delta Lake mehrere Funktionen für Betrieb und Performance, die jeweils eine bestimmte technische Anforderung adressieren. Dieser Überblick ordnet ein; die Entscheidungstiefe je Komponente liegt in den verlinkten Artikeln.
| Komponente | Löst welches Problem | Wann sie relevant wird |
|---|---|---|
| Change Data Feed | Liefert zeilengenaue Änderungen zwischen Versionen | Wenn nachgelagerte Prozesse ausschließlich neue oder geänderte Datensätze verarbeiten sollen, nicht jedes Mal den Vollbestand |
| Time Travel | Macht frühere Tabellenstände abfragbar und wiederherstellbar | Fehleranalyse, Audit-Anfragen, reproduzierbare ML-Trainingsstände |
| Liquid Clustering | Ordnet Daten flexibel ohne feste Partitionsgrenzen | Neue Tabellen, wechselnde Abfragemuster, Schlüssel mit vielen Ausprägungen |
| Z-Ordering | Sortiert Daten über mehrere Spalten für schnelles Überspringen | Bestehende Tabellen mit stabilen, bekannten Abfragemustern |
| Deletion Vectors | Löscht und ändert Zeilen ohne sofortiges Neuschreiben ganzer Dateien | Häufige kleine Änderungen, Löschpflichten auf großen Tabellen |
| Optimize & Vacuum | Verdichtet kleine Dateien und räumt alte Versionen auf | Produktive Tabellen mit regelmäßigen Schreibvorgängen |
Zwei Zusammenhänge sollten bereits vor der Einführung berücksichtigt werden.
Der erste betrifft das Daten-Layout: Liquid Clustering und Z-Ordering verfolgen unterschiedliche Ansätze zur Optimierung des Datenlayouts. Z-Ordering ist der klassische Weg und erfordert regelmäßige Optimierungsläufe auf zuvor festgelegten Spalten. Liquid Clustering arbeitet schrittweise, erlaubt das spätere Ändern der Schlüssel und ist laut den Release-Notes des Delta-Projekts seit Version 3.2.0 vom Mai 2024 allgemein verfügbar. Für neue Tabellen ist Liquid Clustering damit häufig die flexiblere Option; bestehende Z-geordnete Tabellen laufen weiter und wechseln nach Aufwand und Nutzen.
Der zweite Zusammenhang betrifft das Zusammenspiel von Deletion Vectors, Optimize und Vacuum. Deletion Vectors markieren gelöschte Zeilen zunächst nur in einer komprimierten Lösch-Markierung; die betroffenen Datensätze bleiben zunächst physisch in den Datendateien erhalten. Erst nach einer entsprechenden Wartung über Optimize und Vacuum können die zugrunde liegenden Dateien endgültig entfernt werden. Dieselbe Aufbewahrungsfrist entscheidet darüber, wie weit Time Travel zurückreicht. Aufbewahrungsfristen, Löschanforderungen und Time-Travel-Bedarf müssen deshalb gemeinsam abgestimmt werden.
Delta Lake oder Apache Iceberg: Wie lässt sich das passende Tabellenformat auswählen?
Apache Iceberg ist neben Delta Lake eines der verbreitetsten offenen Tabellenformate und löst dieselbe Grundaufgabe: Metadaten und Transaktionsgarantien über Parquet-Dateien. Die Entscheidung zwischen beiden hängt daher nicht ausschließlich vom Funktionsumfang ab. Wesentlich sind die eingesetzten Abfrage-Engines, die zentrale Plattform für die Workloads und die Frage, wie offen die Tabellen für unterschiedliche Plattformen und Engines zugänglich sein müssen.
Die mögliche Anbieterabhängigkeit sollte anhand von Datenformat, Protokoll und Engine-Unterstützung bewertet werden. Die Daten liegen als Parquet im eigenen Objektspeicher, das Delta-Protokoll ist als offene Spezifikation dokumentiert, und das Projekt gehört der Linux Foundation. Engines außerhalb von Spark lesen Delta-Tabellen über eigene Anbindungen auf Basis von Delta Kernel, darunter Apache Flink, Trino und Presto; Microsoft Fabric nutzt Delta als natives Tabellenformat, und auch Snowflake und Google BigQuery können Delta-Tabellen einbinden. Delta Lake kann grundsätzlich auch außerhalb von Databricks genutzt werden; auf Databricks selbst ist Delta Lake das standardmäßig verwendete Tabellenformat, neue Tabellen werden dort als Delta-Tabellen angelegt. Manche Funktionen erscheinen allerdings zuerst in der Databricks-Plattform und später oder eingeschränkt in der Open-Source-Variante. Diese Unterschiede sollten bei der Planung des Funktionsumfangs berücksichtigt werden.
Für Plattformen, die Delta- und Iceberg-Clients unterstützen müssen, bietet UniForm eine Interoperabilitätsschicht: Das Delta-Projekt dokumentiert, dass UniForm nach jedem Schreibvorgang zusätzlich Iceberg-Metadaten erzeugt, sodass Iceberg-Clients dieselbe Tabelle lesen können. Die Grenzen sind klar benannt: Externe Clients lesen nur, und einzelne Funktionen wie Deletion Vectors stehen über die Iceberg-Sicht nicht zur Verfügung. Welche Stärken Apache Iceberg als eigenständiges Format mitbringt, ordnen wir im Überblick zu Apache Iceberg ein; wie UniForm im Detail eingesetzt werden kann, zeigen wir unter UniForm.
Auch die Weiterentwicklung des Tabellenprotokolls muss bei der Entscheidung berücksichtigt werden: Aktiviert ein Team neue Funktionen wie Deletion Vectors, hebt das die Protokoll-Version der Tabelle dauerhaft an. Ältere Engines, die diese Version nicht beherrschen, verlieren den Zugriff. Die Aktivierung neuer Tabellenfunktionen betrifft damit alle Systeme, die auf diese Tabellen zugreifen, und sollte abgestimmt werden, bevor neue Protokollfunktionen aktiviert werden.
Betrieb gehört zum Format: Wartung, Fristen, Kosten
Ohne regelmäßige Wartung können sich Performance und Speicherkosten einer Delta-Tabelle verschlechtern. Häufige kleine Schreibvorgänge, etwa aus Streaming-Quellen, erzeugen mit der Zeit eine große Anzahl kleiner Dateien, und Abfragen müssen dadurch deutlich mehr Dateien und Metadaten verarbeiten: Die Abfrageleistung verschlechtert sich schrittweise, ohne dass zwingend ein klar erkennbarer Fehler auftritt. Gleichzeitig sammeln sich alte Versionen und gelöschte Daten im Speicher; die Speicherkosten können steigen, obwohl sich der fachlich relevante Datenbestand kaum verändert.
Für diese Aufgaben stehen insbesondere Optimize und Vacuum zur Verfügung. Optimize fasst kleine Dateien zu größeren Dateien zusammen und hält Abfragen schnell. Vacuum entfernt ältere Dateien, die nach Ablauf der Aufbewahrungsfrist von keiner benötigten Tabellenversion mehr verwendet werden; das Delta-Projekt dokumentiert dafür eine Standard-Aufbewahrungsfrist von sieben Tagen. Die Aufbewahrungsfrist ist eine zentrale betriebliche und fachliche Entscheidung: Eine kürzere Frist spart Speicher, verkürzt jedoch den Zeitraum, in dem frühere Tabellenstände verfügbar sind. Zu kurze Fristen oder unkoordinierte Vacuum-Läufe können laufende Prozesse beeinträchtigen und Wiederherstellungsmöglichkeiten einschränken.
Für jede Tabellenklasse sollten drei Betriebsparameter definiert werden: ein Wartungs-Rhythmus, der zur Schreibfrequenz passt, eine Aufbewahrungsfrist, die Lösch-Zusagen und Anforderungen an historische Versionen ausbalanciert, und eine klar zugewiesene Verantwortung für Ausführung und Monitoring. Wie ein solcher Wartungsplan aussieht und welche Fristen sich für welche Tabellen-Klassen eignen, führen wir unter Optimize & Vacuum aus.
Grenzen
Delta Lake ergänzt einen Data Lake um Transaktionssicherheit, Versionierung und verbindliche Tabellenstrukturen und legt damit das Fundament für BI, Machine Learning und Streaming auf einem gemeinsamen Datenbestand. Für eine vollständige Datenplattform werden darüber hinaus Modellierung, Datenqualität, Governance und Betrieb benötigt.
Datenqualität bleibt eine eigene Aufgabe
Das Transaktionslog verhindert unvollständige Commits und kann nicht freigegebene Schemaabweichungen ablehnen. Ob Werte fachlich korrekt und vollständig sind, prüft das Format dagegen nicht; diese fachlichen Prüfungen müssen weiterhin in den Datenpipelines umgesetzt werden.
Modellierung liefert das Format nicht mit
Delta Lake kann auch technisch gültige, aber fachlich ungeeignete Tabellenstrukturen speichern. Wie Roh-, Aufbereitungs- und Serving-Schichten aufeinander aufbauen, zeigt die Medaillon-Architektur.
Zugriffsrechte und Auffindbarkeit liegen außerhalb
Welche Nutzer eine Tabelle lesen dürfen, welche Daten als sensibel gelten und wo Verantwortliche stehen, regelt eine Governance-Schicht wie Unity Catalog. Zugriffsrechte, Rollen und Datenklassifikationen werden außerhalb des Tabellenformats verwaltet.
Ein geregelter Tabellenbetrieb bleibt erforderlich
Verwaltete Plattformen automatisieren Teile der Wartung, die Entscheidungen über Fristen, Kosten und Verantwortung bleiben. Ohne Wartung können auch Delta-Tabellen langfristig an Performance verlieren und unnötige Kosten verursachen.
Neue Protokollfunktionen erfordern Abstimmung
Das Format entwickelt sich schnell, und jede aktivierte Funktion kann ältere Engines aussperren. Plattform-Teams brauchen einen Prozess, der Protokoll-Anhebungen mit allen lesenden Systemen abgleicht.
Diese Einschränkungen zeigen, welche Aufgaben Delta Lake übernimmt und welche außerhalb des Formats bleiben: Delta Lake bildet eine technische Grundlage innerhalb einer Lakehouse-Architektur, auf der Qualitätsregeln, Modellierung und Governance aufsetzen. Mit dem Tabellenformat ist eine zentrale technische Basis geschaffen; die nächsten Entscheidungen folgen darauf.
Sobald produktive Berichte, Lösch-Zusagen oder ML-Workloads auf den Tabellen laufen, sollte deshalb neben dem Format auch das Betriebsmodell stehen: Wartungsplan, Fristen und Zuständigkeiten, bevor produktive und geschäftskritische Pipelines in Betrieb genommen werden.
Fazit
Delta Lake lohnt sich, sobald ein Data Lake neben der Rohdatenablage auch produktive analytische Workloads mit verbindlichen Berichten und belegbaren Löschungen tragen soll.
Delta Lake ist sinnvoll, sobald ein Data Lake neben der Rohdatenablage auch produktive analytische Workloads unterstützen soll: verbindliche Berichte, belegbare Löschungen, parallele Lese- und Schreib-Jobs oder reproduzierbare Datenstände für Machine Learning. Besonders geeignet ist das Format für Unternehmen, die bereits einen Lake auf S3, ADLS oder GCS betreiben und ihn zur gemeinsamen Datenbasis für BI und ML ausbauen wollen, ohne dafür einen zusätzlichen geschlossenen Datenspeicher aufzubauen.
Typische Ausgangssituationen sind:
- Berichte, deren Datenstände nach fehlgeschlagenen Ladevorgängen nicht zuverlässig nachvollzogen werden können
- DSGVO-Löschanfragen, die umfangreiche manuelle Dateioperationen erfordern
- eine zusätzliche Datenplattform, weil der Data Lake nicht als verlässliche Reporting-Basis genutzt wird
- ML-Teams, die Trainingsdaten kopieren, weil sich alte Stände nicht reproduzieren lassen
Wer dagegen ausschließlich strukturiertes Reporting auf einem stabilen Data Warehouse fährt und weder Datenvielfalt noch ML-Ambitionen hat, braucht das Tabellenformat nicht als nächstes Projekt. In diesem Fall besteht möglicherweise kein unmittelbarer Bedarf für die Einführung eines offenen Tabellenformats, bis sich der Workload-Mix ändert.
Mein Vorschlag: Delta Lake zunächst an einer klar abgegrenzten und geschäftlich relevanten Datenpipeline erproben und von Anfang an drei Dinge mitentscheiden: den Wartungsplan mit Optimize und Vacuum, die Aufbewahrungsfristen entlang der Lösch- und Audit-Anforderungen und die Anforderungen an die Interoperabilität mit Apache Iceberg über UniForm. An diesem Pilot lässt sich prüfen, ob Tabellenformat, Wartungsprozesse und Verantwortlichkeiten im Betrieb funktionieren.
Die Wahl des Tabellenformats ist im Vergleich zu sichtbaren Plattformkomponenten oft weniger präsent. Sie hat jedoch langfristige Auswirkungen auf Interoperabilität, Betrieb und Datenzugriff und beeinflusst, wie zuverlässig, nachvollziehbar und offen die Daten genutzt werden können.
Erprobt Delta Lake zunächst an einer klar abgegrenzten Pipeline und entscheidet von Anfang an Wartungsplan, Aufbewahrungsfristen und die Interoperabilität mit Apache Iceberg über UniForm mit.
Macht Delta Lake aus eurem Data Lake eine tragfähige Datenbasis?
Ob Delta Lake aus eurem Data Lake eine tragfähige Datenbasis macht oder zunächst andere Architektur-Fragen anstehen, lässt sich in einem ersten Gespräch zum Aufbau eurer Databricks-Plattform gut einordnen.
- welche eurer Lade-Strecken und Workloads echte Kandidaten für Delta-Tabellen sind
- welche Compliance-, Interoperabilitäts- und Betriebsrisiken vor dem Rollout geprüft werden müssen
- welcher Einführungspfad mit Wartungsplan und klaren Zuständigkeiten für eure Situation trägt
FAQ
Delta Lake ist ein offenes Tabellenformat für Daten im Objektspeicher. Es kombiniert Parquet-Datendateien mit einem Transaktionslog, das jede Änderung als Version festhält. Dadurch erhalten Daten im Data Lake Eigenschaften, die sonst Datenbanken vorbehalten sind: ACID-Transaktionen, Schema-Prüfung und eine abfragbare Historie. Das Projekt wurde bei Databricks entwickelt und ist seit 2019 Open Source unter der Linux Foundation.
