Lakehouse kombiniert Eigenschaften von Data Lakes und Data Warehouses Einblick in Lakehouse und Delta Lake
13. November 2020
Cloud-Objekt-Speicher wie Amazon S3 haben sich zu einigen der größten und kostengünstigsten Speichersysteme der Welt entwickelt, was sie zu einer attraktiven Plattform für die Speicherung von Daten aus Data Warehouses und Data Lakes macht.
Aufgrund ihres Charakters als Key-Value-Speicher ist es jedoch schwierig, darauf ACID-Transaktionen (atomicity, consistency, isolation und durability) zu realisieren. Außerdem wird die Leistung durch teure Metadaten-Operationen und begrenzte Konsistenz-Garantien beeinträchtigt. Ausgehend von den Merkmalen von Objekten haben sich drei Ansätze herauskristallisiert.
Data Lakes
Das erste sind Dateiverzeichnisse (d.h. Data Lakes), in denen die Tabelle als eine Sammlung von Objekten gespeichert wird, typischerweise in spaltenorientierten Dateiformaten wie Apache Parquet. Das ist ein attraktiver Ansatz, weil die Tabelle nur eine Gruppe von Objekten ist, auf die von einer Vielzahl von Werkzeugen aus ohne viele zusätzliche Datenspeicher oder Systeme zugegriffen werden kann.
Allerdings sind sowohl Leistungs- als auch Konsistenzprobleme weit verbreitet. Versteckte Datenkorruption ist aufgrund von Transaktionsfehlern weit verbreitet, eventuelle Inkonsistenzen führen zu inkonsistenten Abfragen, die Latenzzeit ist hoch, und grundlegende Verwaltungsfunktionen wie Tabellen-Versionierung und Audit-Protokolle sind nicht verfügbar.
Benutzerdefinierte Storage-Engines
Der zweite Ansatz sind benutzerdefinierte Speicher-Engines, zum Beispiel proprietäre Systeme, die für die Cloud entwickelt wurden, wie Data Warehouses verschiedener Anbeiter. Diese Systeme können die Konsistenzprobleme von Data Lakes umgehen, indem sie die Metadaten in einem separaten, stark konsistenten Dienst verwalten, der in der Lage ist, eine einzige Quelle der Wahrheit zu liefern. Alle E/A-Operationen müssen jedoch mit diesem Metadatendienst verbunden werden, was die Ressourcenkosten erhöht und die Leistung und Verfügbarkeit verringern kann.
Darüber hinaus erfordert die Implementierung von Konnektoren zu bestehenden Computing-Engines wie Apache Spark, TensorFlow und PyTorch einen hohen technischen Aufwand, was für Data Teams, die für ihre Daten eine Vielzahl von Computing-Engines verwenden, eine Herausforderung darstellen kann.
Die technischen Herausforderungen können durch unstrukturierte Daten noch verschärft werden, da diese Systeme im Allgemeinen für herkömmliche strukturierte Datentypen optimiert sind. Schließlich, und das ist das Schlimmste, bindet der proprietäre Metadatendienst die Kunden an einen bestimmten Dienstanbieter, so dass die Kunden mit gleichbleibend hohen Preisen und teuren, zeitaufwändigen Migrationen zu kämpfen haben, wenn sie sich später für einen neuen Ansatz entscheiden.
Lakehouse als neues Paradigma
Bei Delta Lake handelt es sich um eine Open-Source-basierte ACID-Tabellenspeicherschicht über den Cloud-Objektspeichern. Damit möchte man sozusagen ein Auto anstelle eines schnelleren Pferdes einsetzen, das nicht nur eine bessere Datenspeicherung bietet, sondern auch eine grundlegende Änderung in der Art und Weise darstellt, wie Daten über das Lakehouse gespeichert und verwendet werden.
Ein Lakehouse, der dritte Ansatz, ist ein neues Paradigma, das die besten Eigenschaften von Data Lakes und Data Warehouses kombiniert. Lakehouses werden durch ein neues Systemdesign ermöglicht: die Implementierung ähnlicher Datenstrukturen und Datenverwaltungsfunktionen wie in einem Data Warehouse, direkt auf die Art der kostengünstigen Speicherung, die für Data Lakes verwendet wird. Sie sind das, was man erhalten würde, wenn man die Speichermaschinen in der modernen Welt neu entwerfen müsste, jetzt, da billige und höchst zuverlässige Speicher (in Form von Objektspeichern) verfügbar sind.
Delta Lake verwirklicht ACID-Transaktionen, indem es Informationen darüber pflegt, welche Objekte Teil einer Delta-Tabelle sind, die zu Parquet verdichtet und ebenfalls im Cloud-Objektspeicher gespeichert werden. Dieses Design ermöglicht es den Kunden, mehrere Objekte gleichzeitig zu aktualisieren, eine Teilmenge der Objekte durch eine andere zu ersetzen usw., und zwar in einer serialisierbaren Weise, bei der immer noch eine hohe parallele Lese-/Schreibleistung der Objekte erreicht wird.
Das Protokoll bietet auch wesentlich schnellere Metadatenoperationen für große tabellarische Datensätze. Zusätzlich bietet Delta Lake erweiterte Funktionen wie Zeitreisen (d.h. Abfragen von Point-in-Time-Snapshots oder Rollback fehlerhafter Aktualisierungen), automatische Datenlayout-Optimierung, Upserts, Caching und Audit-Protokolle. Zusammen verbessern diese Funktionen sowohl die Verwaltbarkeit als auch die Leistung bei der Arbeit mit Daten in Cloud-Objektspeichern und öffnen letztlich die Tür zum Lakehouse-Paradigma, das die Hauptmerkmale von Data Warehouses und Data Lakes kombiniert, um eine bessere und einfachere Datenarchitektur zu schaffen.
Heute wird Delta Lake bei Tausenden von Databricks-Kunden, die täglich Exabytes strukturierter und unstrukturierter Daten verarbeiten, sowie bei vielen Unternehmen der Open-Source-Community eingesetzt. Diese Anwendungsfälle umfassen eine Vielzahl von Datenquellen und Anwendungen. Zu den gespeicherten Datentypen gehören Change Data Capture (CDC)-Protokolle aus OLTP-Systemen von Unternehmen, Logdateien aus Anwendungen, Zeitreihendaten, Grafiken, aggregierte Tabellen für das Reporting und Bild- oder Featuredaten für das maschinelle Lernen.
Zu den Anwendungen gehören SQL-Workloads (am häufigsten), Business Intelligence, Streaming, Data Science, maschinelles Lernen und Graphenanalyse. Insgesamt hat sich Delta Lake als gut geeignet für die meisten Data Lake-Anwendungen erwiesen, die strukturierte Speicherformate wie Parquet oder ORC und viele herkömmliche Data Warehousing-Workloads verwendet hätten.
Joel Minnick ist Vice President Marketing bei Databricks.
