Data Lakehouse vs. Data Warehouse in der Cloud: Teil 1 - Unterschiede und Einsatzbereiche
Azure Data Lakehouse vs. DWH-Architektur
Dieser Blog-Beitragsreihe beseht aus 2 Beiträgen und behandelt die Gegenüberstellung einer Data Lakehouse/Data Warehouse-Architektur auf Basis von Apache Spark zu klassischen (analytischen) relationalen Datenbanksystemen. Der Vergleich betrachtet ausschließlich den Einsatz in Cloud-Umgebungen. Hierbei werden sowohl die Unterschiede als auch die Gemeinsamkeiten der beiden Architekturansätze dargestellt. Des Weiteren werden ausschlaggebende Kriterien zur Findung der optimalen Lösung für den eigenen Anwendungsfall aufgezeigt.
Data Lakehouse vs. Data Warehouse – Abgrenzung und Einsatzszenarien
Ein Data Lakehouse definiert die Speicher- und Schichtenarchitektur eines großen Datenbestands (Data Lake). Dieser umfasst unternehmensinterne und -externe Quellen, die in strukturierter, semi-strukturierter und unstrukturierter Form in unterschiedlichen Dateiformaten (Text, Bild- und Video-Dateien) in ihrem Rohformat aufgenommen werden. Die Daten sind vor ihrer Speicherung nicht validiert oder in eine andere Struktur transformiert worden. Zum Zeitpunkt ihrer Speicherung ist noch keine konkrete Verwendung definiert. Erst wenn die Daten für einen konkreten Anwendungsfall benötigt werden, erfolgt eine Aufbereitung der betroffenen Daten. Entgegen relationalen Datenbanksystemen verfügt das Lakehouse über keine festen Strukturen und bietet hierdurch eine größere Flexibilität gegenüber einem Data Warehouse bezüglich Datenspeicherung und verwendeter Analysemethoden.
Ein Data Warehouse-System (DWH) führt ebenfalls Daten aus unterschiedlichen Quellen zusammen. Hierbei werden die Daten sowohl in einheitliche Formate als auch in feste Strukturen (Schemata) überführt, die eine direkte, effiziente Analyse ermöglichen. Die aufgenommenen Daten sind qualitätsgesichert und verfügen i.d.R. über eine Historienbetrachtung. Bei den gespeicherten Daten handelt es sich um Transaktionsdaten und die sie beschreibenden Geschäftsobjekte, auf deren Grundlage Kennzahlen berechnet und Berichte gebildet werden. Binäre Daten wie Bilder oder Audiodaten werden im Data Warehouse aufgrund der Implementierung in relationalen Datenbanken i.d.R. nicht abgelegt, können aber mittels weiterer Techniken referenziert werden.
Beide Architekturen sind in der Lage, große Informationsmengen zu speichern und für Auswertungen bereitzustellen. Date Lakehouses und DWH-Systeme unterscheiden sich somit grundsätzlich in ihren Konzepten, den Anwendungsfällen und der Art der Datenspeicherung. Die grundlegende Architektur beider Ansätze ist nachfolgend dargestellt.
Vergleich der Konzepte Data Lakehouse vs. Data Warehouse
Data Lakehouse vs. Data Warehouse - Datenspeicherung
In den meisten Fällen wird als Data Lakehouse-Architektur die technische Implementierung mittels Apache Spark als Open Source-basierte, parallel arbeitende analytische Anwendung eingesetzt. Alternativangebote (bspw. Presto) existieren ebenfalls.
Apache Spark Clusters werden von allen namhaften Cloud-Anbietern als integrierter Dienst (SaaS) bereitgestellt. Hierbei handelt es sich um eine erprobte Technologie, die ihren Ursprung Anfang dieses Jahrhunderts in dem Aufkommen von Big Data-Anwendungen hat.
Kernbestandteil von Apache Spark ist ein hochverfügbares, verteiltes Dateisystem zur Speicherung von sehr großen Datenmengen. Bis zum Aufkommen der Cloud-Infrastrukturen war hier HDFS (Hadoop Distributed File System) der Standard. In Cloud-Umgebungen wird mittlerweile zunehmend AWS S3 als Dateisystem verwendet. Azure Clouds ermöglichen es, BlobStore- bzw. ADLS-Dateisystemen als intelligente Speichersysteme zu verwenden. Verglichen mit HDFS sind diese oft kosteneffizienter und einfacher zu betreiben.
Hierbei werden die Daten auf mehreren Rechnern innerhalb des Clusters gespeichert. Die Speicherung der Daten erfolgt in offenen Dateiformaten wie Avro, Parquet u.a.
Nachteilig ist, dass die Auswahl des Dateiformats von den Daten und ihrer Verwendung abhängt. Weiterhin ist das Löschen, Ändern von Daten unflexibel – Änderungen an gespeicherten Daten wurden anfangs durch neu zu schreibende Dateien realisiert. Inzwischen wurden neue Dateiformate wie Delta Lake, Iceberg u.a. entwickelt, die ähnlich Datenbanktabellen neben Datentypisierung auch selektive Abfragen ermöglichen.
Das direkte Ändern von Daten ist auch durch die neuen Dateiformate nicht möglich. Nach wie vor muss eine Datei gelesen, Änderungen an den Daten vorgenommen werden und diese als neue Datei wieder geschrieben werden.
Dank der neuen Formate können Spark-basierte Anwendungssysteme zu den RDBM-Systemen aufschließen. Es werden Funktionalitäten bereitgestellt, wie sie in traditionellen DHW-Systemen vorhanden sind:
ACID-Transaktionen: Delta Lake unterstützt atomare, konsistente, isolierte und dauerhafte Transaktionen.
Zeitreisen: Anwender können auf frühere Versionen Ihrer Daten zugreifen und diese wiederherstellen.
Versionierung: Änderungen an Daten werden nachverfolgt, sodass sie den Verlauf verfolgen können.
Die Strukturierung des Dateisystems zur Speicherung der Data Lake-Dateien erfolgt in beiden Dateisystemen (HDFS und ADLS) hierarchisch und orientiert sich dabei an der am häufigsten ausgeführten Abfrage. Die Dateisystemstruktur ist somit auf die performante Ausführung einer Art von Abfragen optimiert. Ergänzend ermöglichen Zeitangaben im Dateipfad die Verwendung von zeitbezogenen Filtern, um die Menge der zu lesenden Daten einzuschränken.
Das folgende Beispiel soll diesen Ansatz verdeutlichen. Alle, zu einer Geschäftssicht/Kontext gehörenden Daten (in diesem Fall Kunden mit den zugehörigen Transaktionsdaten), befinden sich im gleichen Pfad des Dateibaums. Die Transaktionsdaten sind nach Kundennummern und Zeitbezug gruppiert bzw. partitioniert, d.h. anhand der Datei-Metadaten können einzelnen Dateien bei Abfragen nach Kunden ein- oder ausgeschlossen werden. Der Zeitbezug ergibt sich aus dem Dateipfad.
/Customer/Parquet/2024/05/07/sales_transaction_2024_05_07.parquet
Abfragen nach anderen Geschäftskontexten wie bspw. den verkauften Artikeln, werden entsprechend suboptimal ausgeführt, da sich Artikeldaten in alle Dateien befinden und somit sich einzelne Dateien von der Selektion nicht ausschließen lassen. Hier zeigt sich eine strukturelle Inflexibilität von Spark, in der eine Ordnerstruktur jeweils für einen Anwendungsfall ausgelegt ist. Im Allgemeinen wird das Data Lakehouse bzgl. der Datenhaltung in Quellsystem-bezogenen Strukturen aufgebaut. Eine direkte Unterstützung von unterschiedlichen Endbenutzer-Abfragen ist nicht vorgesehen. Zur Unterstützung komplexerer Abfragen ist es ratsam, die Daten in denormalisierter Form zu speichern, damit weniger Anforderungen an das Zusammenführen der Daten bestehen. JOINs sind die langsamsten Operationen im Data Lakehouse Dateisystem. Es empfiehlt sich zwecks JOIN-Vermeidung, die Daten zu denormalisieren, sind häufige Aggregationen erforderlich, sollten die Daten vorberechnet werden.
Analog hierzu haben Hersteller von traditionellen relationalen Datenbank Management Systemen als auch Cloud-Anbieter neue analytische Datenbanksysteme entwickelt, die sich aufgrund ihrer Architektur und Leistungsfähigkeit neben klassischen DWH-Systemen auch für Data Lakehouse-Systeme eigenen, sieht man hier von der Analyse von Binärstrukturen, wie Bilder, Audio, etc. einmal ab.
Auch bei Abfragen in Datenbanksystemen gilt: am schnellsten werden Abfragen ausgeführt, wenn irrelevante Daten erst gar nicht gelesen werden. Hierzu lassen sich im DBMS beim Anlegen eines Tabellenobjekts Datenverteilungsparameter mitgeben. Bei MPP-basierten Datenbanksystemen sind dies:
PARTITION BY - vertikale Verteilung der Sätze innerhalb eines Rechenknotens
DISTRIBUTION BY - horizontale Verteilung der Sätze innerhalb des DB-Clusters auf unterschiedliche Rechnerknoten
Bei beiden Architekturen ist auf eine Gleichverteilung der Daten zu achten, um eine gleichmäßige Ressourcennutzung zu ermöglichen. Die Partitionierungs- und Distributionsschlüssel sind so zu wählen, dass nicht zu viele Datenpartitionen bzw. Dateien erzeugt werden bzw. die Knoten zu ungleiche Datenvolumina zugeordnet ist.
Abschließend sei in diesem Abschnitt noch das Datenaustauschformat JSON erwähnt. Apache Spark auf ADLS oder HDFS als Dateisystem speichert JSON-Dateien wie gewöhnliche Textdateien. In Datenbank Management Systemen gibt es hier zwei unterschiedliche Ansätze zur Verarbeitung. Im ersten Fall können die JSON-Daten mittels der eigenen SQL-Spracherweiterung gelesen und in ihre relationalen Strukturen überführt werden und sind dann somit mit dem Kern-SQL-Sprachumfang abfragbar. Im zweiten Fall werden die JSON-Daten satzweise in einem Character-Attribut gespeichert und erst bei Bedarf durch SQL-JSON-Pfadabfragen in ihre relationalen Strukturen überführt. Kriterien für die erste oder zweite Variante sind der eigene Anwendungsfall und die Empfehlung des DMBS-Herstellers bzgl. der Effizienz.
Data Lakehouse vs. Data Warehouse - Transaktionssicherheit (ACID)
Der Begriff ACID (Atomicity, Consistency, Isolation, Durability) beschreibt Regeln und Eigenschaften zur Durchführung von Transaktionen. Hält die Transaktion das ACID-Prinzip ein, gelten die Informationen in den Datenstrukturen als verlässlich und konsistent.
Apache Spark wurde für das parallele Lessen von Massendaten konzipiert und konnte anfänglich für seine administrierten Data Lakes keine Transaktionssicherheit bei Schreiboperationen garantieren
Inzwischen ist dies dank neuer Dateiformate wie Iceberg und Delta Lake überholt. Die klassischen relationale Datenbanken als technische Data Lake-Basis verfügen seit jeher über ACID-Fähigkeiten.