Was ist Delta Lake?

Delta Lake – erstmals entwickelt im Jahr 2016 von Databricks – ist ein offenes Tabellenformat: ein Open-Source-Framework für tabellarische Daten, das eine Metadatenschicht auf bestehenden Dateiformaten aufbaut. Delta Lake verwendet explizit Parquet-Tabellen für die Datenspeicherung. Weitere offene Tabellenformate sind Apache Iceberg und Apache Hudi.

Die Metadatenschicht ermöglicht es Delta Lake und anderen offenen Tabellen, Suchabfragen zu optimieren und erweiterte Datenoperationen zu unterstützen, was viele Standard-Tabellenformate nicht können. Unternehmen nutzen Delta Lake häufig, um ihre Data Lakes zuverlässiger und intuitiver zu machen.

Die Entwicklung von Delta Lake war ein kritischer Schritt in der Entwicklung der Data-Lakehouse-Architektur, welche den Speicher eines Data Lake mit der Leistung eines Data Warehouse kombiniert.

Delta Lake und Data Lakes werden oft in Gesprächen zusammen behandelt, aber es ist wichtig zu wissen, dass sich diese Technologien voneinander unterscheiden.

Ein Data Lake ist eine kostengünstige Datenspeicherumgebung, die für die Verarbeitung großer Datensätze aller Arten und Formate von Daten konzipiert ist. Die meisten Data Lakes verwenden Cloud-Objektspeicherplattformen wie Amazon Simple Storage Service (S3), Microsoft Azure Blob Storage oder IBM® Cloud Object Storage.

Delta Lake ist ein tabellarisches Datenspeicherformat, das ein Unternehmen in einem Data Lake oder einem anderen Datenspeicher verwenden kann.

Delta Lake ist weder eine Art Data Lake noch eine Alternative zu einem Data Lake. Vielmehr kann man sich einen Data Lake als das „Wo“ und Delta Lake als das „Wie“ vorstellen:

• Wo werden die Daten gespeichert? In einem Data Lake.
• Wie wird die Daten gespeichert? Als Delta Lake-Tabelle.

Das Delta Lake-Format kann dazu beitragen, Data Lakes einfacher zu verwalten und effizienter zu machen.

Data Lakes haben viele Vorteile, aber in der Regel fehlen ihnen integrierte Datenqualitätskontrollen, und es kann schwierig sein, Data Lakes direkt abzufragen. Unternehmen müssen oft Daten aus einem Data Lake herausnehmen, diese bereinigen und in separate Data Warehouses und Data Marts laden, bevor sie genutzt werden können.

Durch die Einführung einer Metadatenebene bietet Delta Lake Unternehmen die Möglichkeit, Schemas durchzusetzen, Änderungen zu verfolgen und rückgängig zu machen und ACID-Transaktionen zu unterstützen.

Benutzer können SQL Queries, Analyse-Workloads und andere Aktivitäten direkt in einem Data Lake ausführen, wodurch Business Intelligence (BI), Data Intelligence (DI), künstliche Intelligenz (KI) und maschinelles Lernen (ML) optimiert werden.

Delta Lake hat zwei Kernkomponenten: die Datendateien, die Daten enthalten, und das Transaktionsprotokoll, das Metadaten zu diesen Datendateien enthält.

• Datendateien in Delta Lake werden als „Delta Lake-Tabellen“ oder „Delta-Tabellen“ bezeichnet und verwenden das spaltenbasierte Dateiformat Parquet.
  
  
• Das Transaktionsprotokoll speichert die letzten Aktivitäten in JSON-Protokolldateien und archiviert ältere Metadaten in Parquet-Dateien. Das Protokoll wird zusammen mit den Datendateien im Data Lake gespeichert.

Das Transaktionsprotokoll zeichnet Informationen zu den Datendateien (z. B. Spaltennamen sowie Minimal- und Maximalwerte) sowie an den Dateien vorgenommene Änderungen (was wurde geändert, wann, wie und von wem) auf.

Das Protokoll ist es, was Delta Lake von einer Standard-Parquet-Datei unterscheidet. Das Transaktionsprotokoll fungiert im Wesentlichen als Verwaltungsebene und als Satz von Anweisungen für alle Aktivitäten im Data Lake und ermöglicht Funktionen wie ACID-Transaktionen, „Zeitreisen“ und Schemaentwicklung.

Gewöhnliche Parquet-Dateien sind unveränderlich, d. h. sie können nach ihrer Erstellung nicht mehr geändert werden – sie können nur umgeschrieben werden. Das Transaktionsprotokoll von Delta Lake macht Parquet-Dateien funktional, wenn nicht sogar buchstäblich, veränderlich, indem es physische Aktionen (Aktionen, die direkt mit den Daten ausgeführt werden) von logischen Aktionen (Aktionen, die mit den Metadaten ausgeführt werden) trennt.

Beispielsweise kann ein Benutzer nicht eine einzelne Spalte aus einer Parquet-Tabelle entfernen, ohne die gesamte Datei neu zu schreiben. In Delta Lake kann der Benutzer diese Spalte effektiv entfernen, indem er die Metadaten der Tabelle so ändert, dass diese Spalte als gelöscht markiert wird. Die Spalte verbleibt in der Datei, aber alle nachfolgenden Abfragen, Aktualisierungen und Schreibvorgänge sehen die Metadaten und behandeln die Spalte als nicht vorhanden.  

„ACID“ steht für „Atomicity, Consistency, Isolation and Durability“ (Atomarität, Konsistenz, Isolation und Dauerhaftigkeit) – Schlüsseleigenschaften einer zuverlässigen Datentransaktion.

• Atomarität bedeutet, dass alle Datenänderungen so ausgeführt werden, als wären sie ein einziger Vorgang.
  
  
• Konsistenz bedeutet, dass sich Daten zu Beginn und am Ende einer Transaktion in einem konsistenten, also einheitlichen, Zustand befinden.
  
  
• Isolation bedeutet, dass der Zwischenzustand einer Transaktion für andere Transaktionen unsichtbar ist.
  
  
• Dauerhaftigkeit bedeutet, dass Änderungen an Daten bestehen bleiben und nicht rückgängig gemacht werden.

Gewöhnliche Data Lakes unterstützen keine ACID-Transaktionen. Ohne ACID-Garantien sind Data Lakes anfällig für fehlgeschlagene Transaktionen, unvollständige Schreibvorgänge und andere Probleme, die Daten beschädigen können. 

Das Transaktionsprotokoll von Delta Lake kann Transaktionsinformationen in Übereinstimmung mit den ACID-Prinzipien aufzeichnen, wodurch Data Lakes für Streaming Data Pipelines, Business Intelligence, Analysen und andere Anwendungsfälle zuverlässiger werden. 

Administratoren können Schemaanforderungen im Transaktionsprotokoll festlegen, die für alle Daten gelten, die aufgenommen werden. Daten, die nicht den Schemaanforderungen entsprechen, werden abgelehnt.

Administratoren können das Transaktionsprotokoll zudem verwenden, um das Schema einer bestehenden Datei zu ändern, z. B. neue Spalten hinzuzufügen oder Spaltentypen zu ändern. Dieser Prozess wird „Schemaentwicklung“ genannt.

Das Transaktionsprotokoll ist zwar kein herkömmlicher Index, kann aber bei Abfragen helfen, Daten schneller und effizienter abzurufen.

Nehmen wir zum Beispiel an, dass ein Benutzer nach einem bestimmten Wert in einer Spalte sucht: Anhand von Metadaten im Transaktionsprotokoll kann die Abfrage des Benutzers alle Dateien überspringen, in denen der Zielwert möglicherweise nicht vorhanden ist. Wenn der Minimalwert höher oder der Maximalwert niedriger als der Zielwert ist, kann die Abfrage die Datei überspringen.

Das Transaktionsprotokoll speichert ebenfalls Dateipfade. Anstatt den gesamten Data Lake zu durchsuchen, können Abfragen diese Dateipfade verwenden, um direkt zu den relevanten Dateien zu gelangen.

Delta Lake kann Methoden wie Z-Ordering verwenden, um ähnliche Daten näher beieinander auf der Festplatte zu speichern, was es einfacher macht, irrelevante Dateien zu überspringen und relevante zu finden. 

Gewöhnliche Parquet-Dateien sind unveränderlich, aber Delta-Tabellen können vom Benutzer über die Metadatenschicht bearbeitet werden. Delta Lake unterstützt alle Arten von Datenoperationen, einschließlich dem Hinzufügen oder Löschen von Spalten, dem Aktualisieren von Einträgen und dem Zusammenführen von Dateien.

Da das Transaktionsprotokoll alles aufzeichnet, was in den Delta-Tabellen geschieht, verwaltet es effektiv Versionsverläufe für jede Tabelle. Benutzer können vergangene Versionen und „in der Zeit reisen“, d. h. Änderungen rückgängig machen, um frühere Tabellenversionen wiederherzustellen.

Delta Lake verfügt über ein robustes Ökosystem von Konnektoren. Das Format kann mit verschiedenen Rechenmaschinen wie Apache Spark, Apache Hive, Apache Flink oder Trino verwendet werden. Delta Lake verfügt außerdem über Anwendungsprogrammierschnittstellen (APIs) für Python, Java, Scala und andere Sprachen, sodass Entwickler Delta-Tabellen programmgesteuert verwalten und abfragen können.

Delta Lake erzwingt zwar keine nativen Sicherheitskontrollen, kann aber mit Tools für Datensicherheit und Data Governance integriert werden. Diese Tools können dann Metadaten aus dem Transaktionsprotokoll verwenden, um Aktivitäten zu überprüfen, Änderungen zu verfolgen und rollenbasierte Zugriffskontrollrichtlinien (RBAC) durchzusetzen.

Delta Lake kann sowohl Streaming- als auch Batchdaten akzeptieren, und Daten können von Delta-Tabellen als Stream oder in Batches an verbundene Dienste gesendet werden.

Delta Lake 4.0 – die nächste geplante Release für Delta Lake – soll über weitere Funktionen verfügen, wie zum Beispiel:

• Koordinierte Commits, um den Prozess des Schreibens in mehrere Tabellen und von mehreren Engines auf einmal zu rationalisieren.
  
  
• Ein neuer „Variant“-Datentyp zum Speichern halbstrukturierter Daten, die traditionell schwierig im Tabellenformat zu speichern sind.
  
  
• Typerweiterung, mit der Benutzer den Datentyp einer Spalte ändern können. 

Apache Iceberg ist ein hochleistungsfähiges Open-Source-Format für umfangreiche Analysetabellen. Wie Delta Lake baut Iceberg eine Metadatenschicht auf vorhandenen Tabellenformaten auf, um ACID-Transaktionen und andere Vorgänge in einem Data Lake zu unterstützen.

Iceberg kann Daten in Parquet-, ORC- oder Avro-Dateien speichern, während Delta Lake ausschließlich Parquet verwendet. Iceberg verwendet außerdem eine dreistufige Metadatenschicht anstelle eines einzelnen Transaktionsprotokolls wie Delta Lake.

Iceberg lässt sich nativ in viele verschiedene Abfrage-Engines integrieren und ist eine gängige Wahl für SQL-basierte Analysen in einem Data Lake. 

Wie Delta Lake und Iceberg verwaltet auch Hudi eine Metadatenschicht über einer Datenschicht. Hudi unterstützt die Dateiformate Parquet, HFile und ORC, und die Metadatenschicht hat die Form einer „Zeitleiste“, die alles aufzeichnet, was in der Datenschicht passiert.

Hudi ist für die inkrementelle Datenverarbeitung konzipiert, bei der häufig kleine Datenmengen verarbeitet werden. Dieser Fokus auf inkrementelle Verarbeitung macht Hudi zu einer gängigen Wahl für Echtzeitanalysen und Change Data Capture (CDC). 

Die Entwicklung des Delta Lake-Formats ebnete den Weg für die Entwicklung von Data Lakehouses.

Lange Zeit verwalteten Unternehmen ihre Daten hauptsächlich in Data Warehouses. Warehouses sind zwar für Analysen und BI nützlich, erfordern jedoch strenge Schemata: Sie funktionieren nicht gut mit unstrukturierten oder halbstrukturierten Daten, die in einer Zeit, in der Unternehmen zunehmend in KI und ML investieren, immer häufiger vorkommen und an Bedeutung gewinnen.

Das Aufkommen von Data Lakes in den frühen 2010er Jahren gab Unternehmen die Möglichkeit, alle Arten von Daten aus allen möglichen Datenquellen an einem Ort zusammenzufassen.

Data Lake haben jedoch ihre eigenen Probleme. Es fehlt ihnen oft an Qualitätskontrollen. Sie unterstützen keine ACID-Transaktionen und es ist nicht einfach, sie direkt abzufragen.

Um Daten nutzbar zu machen, mussten Unternehmen oft separate ETL-Pipelines (Extrahieren, Transformieren und Laden) von Daten aufbauen, um Daten aus einem Lake in ein Warehouse zu verschieben.  

Delta Lake kam 2016 auf den Markt und erweiterte Data Lakes um ACID-Transaktionen, Schemadurchssetzung und „Zeitreisen“, was ihre Zuverlässigkeit für direkte Abfragen und Analysen erhöhte.

Delta Lake wurde 2019 als Open-Source-Lösung zur Verfügung gestellt und spielte eine Schlüsselrolle bei der Gestaltung der Data-Lakehouse-Architektur, welche die Flexibilität von Data Lakes mit der Leistung von Data Warehouses kombiniert.

Viele Unternehmen erstellen Data Lakehouses, indem sie eine Delta Lake-Speicherebene auf einem bestehenden Data Lake aufbauen und diesen mit einer Datenverarbeitungsengine wie Spark oder Hive integrieren.

Data Lakehouses tragen zur Unterstützung der Datenintegration bei und optimieren die Datenarchitektur, indem sie die Notwendigkeit beseitigen, separate Data Lakes und Warehouses zu unterhalten, was zu Datensilos führen kann.

Diese gestrafften Architekturen wiederum tragen dazu bei, dass Data Scientists, Data Engineers und andere Benutzer auf die benötigten Daten zugreifen können, wenn sie sie benötigen. KI- und ML-Workloads sind häufige Anwendungsfall für Delta Lake-gestützte Data Lakehouses.

Data Lakes sind für diese Workloads an sich bereits nützlich, da sie große Mengen strukturierter, unstrukturierter und halbstrukturierter Daten speichern können.

Durch die Hinzufügung von Funktionen wie ACID-Transaktionen und Schemadurchsetzung trägt Delta Lake dazu bei, die Datenqualität und Zuverlässigkeit von Trainingsdaten auf eine Weise zu gewährleisten, wie es bei gewöhnlichen Data Lakes nicht möglich ist.