Delta Lake von delta-io: Lakehouse-Storage mit Transaktionsprotokoll und ACID
Projektüberblick: Ein Open-Source-Speicherframework, das den Aufbau einer Lakehouse-Architektur mit Rechen-Engines wie Spark, PrestoDB, Flink, Trino und Hive sowie APIs ermöglicht.
Auf einen Blick
- Was ist das?
- delta-io/delta ist das Scala-Repository des Delta-Lake-Storage-Frameworks, das Lakehouse-Architekturen mit Spark, Flink, Trino, PrestoDB und Hive sowie APIs für fünf Sprachen ermöglicht, unter Apache-2.0-Lizenz.
- Für wen ist es gedacht?
- Delta Lake richtet sich an Datenteams, die Tabellen auf Objektspeichern mit Transaktionsgarantien führen und dabei mehrere Engines wie Spark und Trino mischen wollen; ungeeignet ist es, wenn das zugrunde liegende Speichersystem die drei im README geforderten Eigenschaften atomare Sichtbarkeit, gegenseitiger Ausschluss und konsistente Auflistung nicht liefert.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Scala, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Lakehouse-Grundlage: Storage-Framework zwischen Objektspeicher und Engines
Delta Lake ist ein quelloffenes Storage-Framework, das den Aufbau einer Lakehouse-Architektur ermöglicht. Das README nennt die unterstützten Rechen-Engines: Apache Spark, PrestoDB, Flink, Trino und Hive, dazu APIs für Scala, Java, Rust, Ruby und Python. Das Framework sitzt damit zwischen dem Rohspeicher und den Analysesystemen und verleiht Datendateien eine transaktionale Tabellenschicht.
Das Repository delta-io/delta ist in Scala geschrieben und Teil einer Familie: In der delta-io-Organisation liegen neben delta auch delta-rs, delta-sharing, kafka-delta-ingest und das Website-Repository. Die Metadaten weisen rund 9.000 Sterne, über 2.100 Forks und 938 offene Issues aus, der Standardbranch heißt master. Die Definition der Lakehouse-Architektur übernimmt das README nicht selbst, sondern verweist auf ein CIDR-Paper von 2021 und auf die Dokumentation unter docs.delta.io.
Connector-Landschaft: Spark, Flink-Preview, Trino und die Rust-API
Die Integrationsliste des README unterscheidet nach Lese- und Schreibrichtung. Der Spark-Connector liest und schreibt, der Flink-Connector steht als Vorschau und schreibt, PrestoDB liest, Trino liest und schreibt, Apache Hive liest. Delta Standalone ist eine Bibliothek für Scala- und Java-Projekte, die auch Flink, Hive, Beam und PrestoDB den Lese- und Schreibzugriff erlaubt.
Für nicht JVM-Umgebungen gibt es die Delta Rust API mit Python- und Ruby-Bindungen, die tiefen Zugriff auf Delta-Tabellen bietet und für Datenverarbeitungsframeworks wie datafusion, ballista, rust-dataframe und vega gedacht ist. Die vollständige Integrationsliste liegt unter delta.io/integrations. Das README gibt zu keinem Connector Versionsnummern oder Reifegrade an; die Release-Tabelle des Repositorys zeigt derweil v4.4.0 vom 20.08.2026, v3.3.3 vom 12.08.2026 und v4.3.1 vom 08.07.2026, also parallel gepflegte Linien.
API-Stabilität: direkte Java-, Scala- und Python-Schnittstellen versus Spark-Optionen
Das README zieht eine klare Stabilitätsgrenze. Die Klassen und Methoden der API-Dokumentation gelten als stabile öffentliche APIs; alles, was darüber hinaus im Code erreichbar ist, ist intern und kann sich zwischen Releases ändern. Für Scala, Java und Python gibt es eigene API-Dokumentationsseiten unter docs.delta.io.
Der Spark-Weg läuft über die Standard-Eingänge DataFrameReader und DataFrameWriter, also spark.read, df.write, spark.readStream und df.writeStream. Für die Optionen dieser APIs garantiert das Projekt Stabilität innerhalb einer Hauptversion, etwa 1.x.x. Welche Delta-Version mit welcher Spark-Version gepaart werden darf, klärt die Releases-Seite der Online-Dokumentation; das README überlässt diese Matrix bewusst der verlinkten Dokumentation.
Tabellenkompatibilität: Rückwärts garantie und gebrochene Vorwärtskompatibilität
Bei den Tabellendaten gilt eine asymmetrische Regel. Neuere Versionen von Delta Lake können immer Tabellen lesen, die ältere Versionen geschrieben haben; die Rückwärtskompatibilität ist garantiert. In die andere Richtung behält sich das Projekt Brüche vor: Eine ältere Version kann eine Tabelle, die eine neuere Version erzeugt hat, möglicherweise nicht lesen, wenn das Protokoll neue Features eingeführt hat.
Markiert werden solche Protokollbrüche über die Mindestversionen für Leser und Schreiber in der Protocol-Aktion, auf die das README mit einer Testdatei im Repository verweist. Wer Mischbetrieb plant, etwa ein Upgrade der Spark-Cluster vor dem Rest der Pipeline, sollte diese Reader- und Writer-Versionen prüfen, bevor Tabellen in neuem Protokollstand entstehen. Die Spezifikation des Transaktionsprotokolls selbst liegt als PROTOCOL.md im Repository-Root.
Speichervoraussetzungen: atomare Sichtbarkeit, Ausschluss, konsistente Auflistungen
Die ACID-Garantien von Delta Lake sind an Bedingungen geknüpft, die das README in drei Punkten festmacht. Erstens atomare Sichtbarkeit: Eine Datei muss entweder vollständig sichtbar oder gar nicht sichtbar sein. Zweitens gegenseitiger Ausschluss: Nur ein Schreiber darf eine Datei am endgültigen Ziel erstellen oder umbenennen. Drittens konsistente Auflistung: Sobald eine Datei in einem Verzeichnis liegt, müssen alle künftigen Auflistungen dieses Verzeichnisses sie zurückgeben.
Für den Nebenläufigkeitsfall verspricht das README Serialisierbarkeit gleichzeitiger Lese- und Schreibvorgänge und verweist auf die eigene Dokumentationsseite zur Concurrency Control; Mechanismus und Konfliktbehandlung werden im README nicht ausgebreitet. Die konkrete Speicherkonfiguration für S3-artige Systeme ist unter docs.delta.io/latest/delta-storage.html dokumentiert. Diese drei Anforderungen sind der Punkt, an dem Umgebungsentscheidungen scheitern oder gelingen, denn ohne sie entfällt die Basis der Transaktionsgarantien.
Bau mit SBT, Community-Kanäle und der Apache-2.0-Rahmen
Für Beiträge verweist das README auf CONTRIBUTING.md und den Delta-Lake-Verhaltenskodex. Fehlermeldungen laufen über GitHub Issues; Community-Anlaufstellen sind eine Slack-Registrierung, eine LinkedIn-Seite, ein YouTube-Kanal und eine öffentliche Mailingliste. Die Lizenz ist Apache License 2.0 mit verlinkter LICENSE.txt, was kommerzielle Nutzung, Modifikation und Weiterverteilung unter Namensnennung erlaubt.
Das README endet mit einem Roadmap-Abschnitt, der auf eine Milestones-Seite im Repository und eine eigene Roadmap-Seite unter delta.io verweist. Für den praktischen Einstieg gibt es einen Quick-Start-Guide für Scala, Java und Python unter docs.delta.io/latest/quick-start.html. Insgesamt positioniert sich das Repository als Referenzimplementierung einer Offenheit, die gerade daraus entsteht, dass Protokoll, Connectors und Sprach-APIs getrennt dokumentiert sind und Engines wie Spark oder Trino nur über definierte Schnittstellen andocken.
Redaktionelles Fazit
Delta Lake richtet sich an Datenteams, die Tabellen auf Objektspeichern mit Transaktionsgarantien führen und dabei mehrere Engines wie Spark und Trino mischen wollen; ungeeignet ist es, wenn das zugrunde liegende Speichersystem die drei im README geforderten Eigenschaften atomare Sichtbarkeit, gegenseitiger Ausschluss und konsistente Auflistung nicht liefert. Vor dem Produktivbetrieb sollte man PROTOCOL.md gegen die eigene Speicherkonfiguration lesen und die Versionsmatrix unter docs.delta.io/latest/releases.html prüfen, weil ältere Versionen Tabellen neuerer Versionen möglicherweise nicht lesen können.
Community-Notizen