Was ist Delta Lake?

Delta Lake ist eine quelloffene Speicherschicht, die ACID-Transaktionen, die Durchsetzung des Schemas, Time Travel und effiziente Aktualisierungen in Data Lakes bringt. 2019 von Databricks veröffentlicht und 2020 an die Linux Foundation übergeben, ist Delta Lake zu einem der drei großen offenen Tabellenformate geworden, neben Apache Iceberg und Apache Hudi, die moderne Lakehouse-Architekturen erst möglich machen.

Dieser Leitfaden behandelt, was Delta Lake ist, wie sein Transaktionslog arbeitet, wie es sich zu Iceberg und Hudi verhält und wo es 2026 in Unternehmensarchitekturen sitzt, darunter Microsoft Fabric, Databricks und Snowflake.

Was ist Delta Lake?

Eine Tabelle in Delta Lake ist ein Verzeichnis aus Dateien in Apache Parquet, dazu ein Verzeichnis mit dem Transaktionslog in JSON namens _delta_log/. Begrifflich ist das „Parquet mit einem Transaktionslog“. Diese kleine Ergänzung ist es, die jede höhere Fähigkeit ermöglicht, und der Grund, warum „nimm doch einfach Parquet“ für produktive Data Lakes nicht mehr genügt.

Delta Lake wird unterstützt von:

• Apache Spark - die ursprüngliche und vollständigste Integration. Lesen, Schreiben und alle DML-Operationen (MERGE, UPDATE, DELETE) arbeiten nativ.
• Databricks Runtime - Delta ist das voreingestellte Speicherformat; die Photon-Engine der Plattform optimiert Abfragen auf Delta.
• Microsoft Fabric - OneLake legt Daten standardmäßig im Delta-Format ab. Direct Lake liest Delta unmittelbar in die VertiPaq-Engine von Power BI.
• Trino, Presto und Apache Flink - seit 2023 zunehmend erstklassige Unterstützung für Delta.
• Delta Rust / delta-rs - ein Client in Rust, den Polars, DuckDB und Python ohne Spark nutzen.
• Snowflake - Delta-Tabellen lassen sich über externe Tabellen abfragen (in vielen Fällen über die Kompatibilitätsschicht zu Iceberg).

Warum Delta Lake entstand

Vor den offenen Tabellenformaten bedeutete „Data Lake“ ein Verzeichnis aus Dateien in S3, HDFS oder ADLS, meist Parquet, manchmal ORC oder Avro. Dieser rohe Ansatz funktionierte für rein lesende analytische Lasten, litt aber an einer bekannten Reihe von Problemen:

• Keine Atomarität. Ein Schreibvorgang über mehrere Dateien, der auf halbem Weg abstürzte, hinterließ den Lake in einem widersprüchlichen Zustand. Lesende konnten halb geschriebene Daten sehen.
• Keine Isolation. Gleichzeitig Schreibende und Lesende konnten kollidieren. Wettlaufsituationen beschädigten Partitionen.
• Teure Aktualisierungen. Eine einzelne Zeile zu aktualisieren, hieß eine ganze Parquet-Datei neu zu schreiben. Ein effizientes MERGE gab es nicht.
• Schema-Drift. Dateien, die von verschiedenen Jobs geschrieben wurden, konnten verschiedene Schemata haben. Lesende stürzten ab, wenn Spalten verschwanden oder Typen sich änderten.
• Keine Historie. War eine Datei einmal überschrieben, war die vorige Version fort. Eine Abfrage zu einem Zeitpunkt gab es nicht.
• Kleine Dateien. Streaming-Pipelines erzeugten Millionen winziger Dateien, die die Abfrageleistung zerstörten.

Delta Lake löst all das, indem es ein Transaktionslog einführt, das jede Änderung als unveränderliche, geordnete Liste von Operationen auf den Metadaten festhält.

Kernfunktionen

ACID-Transaktionen

Jeder Schreibvorgang auf eine Delta-Tabelle ist atomar. Entweder werden alle Dateien übernommen oder keine. Eine optimistische Nebenläufigkeitskontrolle behandelt gleichzeitig Schreibende: Kollidieren zwei, scheitert einer und versucht es erneut. Lesende sehen stets einen in sich stimmigen Schnappschuss.

Time Travel

Jeder Commit erzeugt eine neue Version. Frühere Versionen bleiben abfragbar, bis sie per VACUUM entfernt werden:

-- Query the table as it looked at version 12
SELECT * FROM sales VERSION AS OF 12;

-- Query the table as it looked at a specific time
SELECT * FROM sales TIMESTAMP AS OF '2026-04-15 09:00:00';

Time Travel ist unverzichtbar für die Fehlersuche, für reproduzierbares Training im maschinellen Lernen, für regulatorische Audits und für das Zurückrollen nach fehlerhaften Schreibvorgängen.

Durchsetzung und Evolution des Schemas

Delta Lake weist Schreibvorgänge zurück, die gegen das Schema der Tabelle verstoßen. Eine optionale Schemaevolution erlaubt es, neue Spalten ohne Migration von Hand aufzunehmen. Die strengere Durchsetzung ist die Voreinstellung; die Evolution schaltet man über WITH SCHEMA EVOLUTION oder über Eigenschaften der Tabelle frei.

MERGE / UPDATE / DELETE

Operationen der SQL-DML, die rohes Parquet nicht effizient leisten kann:

MERGE INTO customers AS target
USING staging AS source
ON target.id = source.id
WHEN MATCHED THEN UPDATE SET email = source.email
WHEN NOT MATCHED THEN INSERT *;

Delta schreibt nur die betroffenen Dateien neu (die Datendateien mit den getroffenen oder geänderten Zeilen), nicht ganze Partitionen. Ein DELETE für das Recht auf Löschung nach DSGVO ist eine einzige SQL-Anweisung.

OPTIMIZE und Z-Order

Streaming-Pipelines erzeugen viele kleine Dateien. OPTIMIZE verdichtet sie zu größeren. ZORDER BY legt Zeilen nach den angegebenen Spalten beieinander ab und ermöglicht so das Aussortieren von Dateien anhand dieser Spalten:

OPTIMIZE sales ZORDER BY (customer_id, region);

In Microsoft Fabric ist das Gegenstück V-Order, eine von Microsoft abgestimmte Variante von OPTIMIZE, die auf Direct Lake hin optimiert ist.

Historie

DESCRIBE HISTORY tablename liefert jeden Commit zurück, der je auf der Tabelle gemacht wurde, also wer, wann, welche Operation und welche Cluster-ID. Verbunden mit der Protokollierung für Audits in Unity Catalog oder einem anderen Katalog ergibt das eine forensisch belastbare Nachverfolgung von Änderungen.

Wie Delta Lake funktioniert

Das Transaktionslog liegt in einem Verzeichnis _delta_log/ neben den Datendateien. Jeder Commit erzeugt eine neue JSON-Datei:

my_table/
  _delta_log/
    00000000000000000000.json   ← commit 0 (initial CREATE)
    00000000000000000001.json   ← commit 1 (first INSERT)
    00000000000000000002.json   ← commit 2 (UPDATE)
    ...
    00000000000000000010.checkpoint.parquet
  part-00000-...snappy.parquet
  part-00001-...snappy.parquet
  ...

Jede JSON-Datei enthält die Aktionen dieses Commits: welche Parquet-Dateien hinzugefügt wurden (add), welche entfernt wurden (remove), Änderungen am Schema (metaData) und Aktualisierungen des Protokolls. Um die Tabelle in Version N zu lesen, spielt ein Client die JSON-Dateien von 0 bis N nach oder liest, effizienter, den jüngsten Checkpoint (einen Schnappschuss des gesamten Logzustands in Parquet) und nur die JSON-Dateien seitdem.

Dieser Entwurf bedeutet, dass die maßgebliche Quelle für den Zustand der Tabelle das Log ist und nicht das Dateiverzeichnis. Dateien außerhalb des Logs sind für Delta unsichtbar. Dateien, auf die das Log verweist und die noch nicht per VACUUM entfernt wurden, lassen sich über Time Travel weiterhin wiederherstellen.

Delta Lake und Apache Iceberg

Apache Iceberg, entstanden bei Netflix und 2018 an Apache übergeben, ist das wichtigste alternative offene Tabellenformat. Die beiden Formate lösen überlappende Probleme mit verschiedenen Entwurfsentscheidungen.

Wo Delta gewinnt:

• Reife auf Databricks und in Microsoft Fabric, dort überall erstklassig unterstützt.
• Ein etwas einfacheres Betriebsmodell (ein Transaktionslog je Tabelle).
• Mehrdimensionales Clustern per Z-Order.

Wo Iceberg gewinnt:

• Ein breiteres Ökosystem unabhängiger Engines (Snowflake, AWS Athena, Trino, BigQuery, Dremio und ClickHouse lesen Iceberg alle nativ).
• Verborgene Partitionierung, denn Partitionsspalten dürfen Transformationen von Datenspalten sein und sich über die Zeit entwickeln, ohne die Tabelle neu zu schreiben.
• Eine reifere Spezifikation für die Evolution von Partitionen und Schemata im großen Maßstab.
• Von Haus aus katalogunabhängig (REST-Katalogspezifikation, AWS Glue, Hive Metastore, Polaris).

Die beiden Gemeinschaften haben sich von 2024 bis 2026 angenähert: Iceberg hat Konzepte übernommen, die von Delta angeregt waren, Delta hat über UniForm die Interoperabilität zu Iceberg ergänzt. Für die meisten Organisationen hängt die Wahl inzwischen mehr vom eingesetzten Ökosystem an Engines ab als von Unterschieden auf der Ebene des Formats.

Delta Lake und Apache Hudi

Apache Hudi (entstanden 2017 bei Uber) ist das dritte große Format. Hudi ist auf Streaming und auf Anwendungsfälle rund um CDC hin optimiert und kennt zwei Arten von Tabellen:

• Copy-on-Write (CoW) - ähnlich wie Delta. Aktualisierungen schreiben die betroffenen Dateien neu.
• Merge-on-Read (MoR) - Aktualisierungen schreiben Deltas in zeilenbasierte Logdateien, die beim Lesen zusammengeführt werden. Schnelleres Schreiben, langsameres Lesen.

Das MoR-Modell von Hudi ist bei hochfrequenten Aktualisierungen aus dem Streaming tatsächlich schneller als Delta oder Iceberg, doch das Lesen zahlt den Preis dafür. 2026 ist Hudi weiterhin dort am stärksten, wo viel gestreamt wird, also bei Anwendern von AWS Kinesis und Apache Flink, während Delta und Iceberg die analytischen Anwendungsfälle im Lakehouse beherrschen.

Umsetzung mit Spark

Der häufigste Weg, Delta Lake zu nutzen, führt über Apache Spark. Die grundlegenden Operationen:

# Create or write
df.write.format("delta").save("/lakehouse/sales")
df.write.format("delta").saveAsTable("sales")

# Read
spark.read.format("delta").load("/lakehouse/sales")
spark.table("sales")

# Time travel
spark.read.format("delta").option("versionAsOf", 12).load("/lakehouse/sales")
spark.read.format("delta").option("timestampAsOf", "2026-04-15").load("/lakehouse/sales")

Die Operationen in SQL arbeiten genauso wie auf einer verwalteten Tabelle:

CREATE TABLE sales (id BIGINT, amount DECIMAL(18,2), order_date DATE) USING DELTA;
INSERT INTO sales VALUES (1, 99.99, '2026-05-01');
UPDATE sales SET amount = 109.99 WHERE id = 1;
DELETE FROM sales WHERE order_date < '2024-01-01';
OPTIMIZE sales ZORDER BY (order_date);
VACUUM sales RETAIN 168 HOURS;

Delta UniForm und Iceberg-Kompatibilität

Das 2024 veröffentlichte Delta UniForm (Universal Format) erlaubt es, eine einzelne Delta-Tabelle ohne Migration von Iceberg-fähigen Engines lesen zu lassen. UniForm schreibt das Metadatenformat von Iceberg neben dem Delta-Log mit, sodass Engines wie Snowflake oder AWS Athena die Tabelle lesen, als wäre sie Iceberg, während Spark und Databricks sie als Delta lesen.

UniForm ist die praktische Antwort auf die Formatkriege. Eine Delta-Tabelle, die aus Databricks geschrieben wurde, lässt sich aus Snowflake abfragen; eine Iceberg-Tabelle, die aus Snowflake geschrieben wurde, lässt sich (über den Lesepfad für Iceberg in der Databricks Runtime) in Databricks lesen. Die Wahl des Formats bindet die Nutzenden nicht mehr.

Anwendungsfälle

• Architektur des Lakehouse - Delta ist das Fundament der Medallion-Architektur auf Databricks und Fabric. Die Schichten Bronze, Silber und Gold sind allesamt Delta-Tabellen.
• Streaming und Batch vereint - dieselbe Delta-Tabelle lässt sich gleichzeitig von Structured Streaming und von Batch-Jobs lesen.
• Löschungen nach DSGVO und für die Compliance - effizientes DELETE auf Zeilenebene samt Historie für Audits.
• Langsam veränderliche Dimensionen - MERGE beherrscht die Muster SCD Typ 1 und Typ 2 nativ.
• Reproduzierbares Training im maschinellen Lernen - Time Travel heftet die Trainingsdaten an eine bestimmte Version.
• Erfassung per CDC - Delta mit Debezium, Kafka oder den CDC-Strömen von Snowflake verbinden, um Änderungen inkrementell zu landen.
• Power BI auf dem Lakehouse - der Modus Direct Lake in Microsoft Fabric liest Delta-Tabellen unmittelbar in VertiPaq.

Der Erfolg von Delta Lake ist der Erfolg des Musters Lakehouse. Indem es transaktionale Zusicherungen in den Speicher des Lake gebracht hat, hat es den historischen Grund beseitigt, aus dem Organisationen Daten in proprietäre Warehouses dupliziert haben. Verbunden mit starker Governance, über Unity Catalog, Microsoft Purview oder Dawiso, liefert Delta das Speichersubstrat für ein einziges Lakehouse, das getrennte Warehouses, Lakes und operative Speicher ersetzen kann. Das Format selbst ist klein; was es ermöglicht, ist groß.