Data-Lake-Struktur – Lösung
Die Organisation von Daten innerhalb eines Data Lakes beeinflusst deren nachgelagerte Verfügbarkeit maßgeblich. Während das Auslagern (Offloading) von Daten in den Data Lake meist unkompliziert ist, liegt die eigentliche Herausforderung in der effizienten Abfrage dieser Daten. Eine hohe Effizienz beim Datenabruf ist entscheidend für Aufgaben wie das inkrementelle oder initiale Laden des Enterprise Data Warehouse (EDW) sowie für Data Scientists, die eigenständige Analysen durchführen. In der Praxis steht und fällt der einfache Zugriff auf nachgelagerte Daten mit ihrer Strukturierung im Data Lake. Eine durchdachte Organisation sorgt für reibungslose Abrufprozesse und unterstützt sowohl EDW-Ladevorgänge als auch die Abfrageanforderungen der Data Scientists optimal.
In einer hybriden Data-Warehouse-Architektur, wie sie in der Data-Vault-2.0-Bootcamp-Schulung vermittelt wird, dient ein Data Lake als Ersatz für eine relationale Staging Area. Um das Potenzial dieser Architektur voll auszuschöpfen, sollte der Data Lake so strukturiert sein, dass er einen effizienten Zugriff im Rahmen eines Persistent-Staging-Area-Musters sowie eine verbesserte Datenvirtualisierung ermöglicht.
Der Data Lake in einer hybriden Data-Vault-Architektur
Abbildung 1: Der Data Lake in einer hybriden Data-Vault-Architektur
Wie in Abbildung 1 dargestellt, wird der Data Lake innerhalb der hybriden Architektur als Persistent Staging Area (PSA) genutzt. Dies unterscheidet sich vom relationalen Staging, bei dem eine Persistent oder Transient Staging Area (TSA) zum Einsatz kommt. Eine TSA bietet den Vorteil, dass der Aufwand für das Datenmanagement reduziert wird: Ändert sich beispielsweise die Quellstruktur, muss lediglich die relationale Stage-Tabelle angepasst werden. Ist diese Tabelle leer, fällt kein weiterer Pflegeaufwand an. Wird jedoch relationale Technologie zur Umsetzung einer PSA genutzt, müssen auch die historischen Daten in der Tabelle an die neue Struktur angepasst werden. Bei einer Staging Area im Data Lake verhält sich dies anders: Ändern sich die Quelldaten, bleiben historische Daten in anderen Dateien davon unberührt. Es ist somit kein nachträgliches Datenmanagement erforderlich, weshalb PSAs auf einem Data Lake gegenüber TSAs bevorzugt werden. Die wesentlichen Gründe hierfür sind:
- Er unterstützt nicht nur das Data-Warehouse-Team bei seinen Ladejobs, sondern ermöglicht auch Data Scientists den direkten Zugriff auf den Data Lake unter potenzieller Umgehung des EDW.
- Full Loads können vom Data-Warehouse-Team genutzt werden, um neue Raw-Data-Vault-Entitäten initial mit historischen Daten zu befüllen.
- Dieses Muster kann verwendet werden, um das Data Warehouse direkt über dem Data Lake zu virtualisieren.
Strukturierung des Data Lakes für effizienten Datenzugriff
Ob Daten nachgelagert leicht zugänglich sind, hängt maßgeblich von ihrer Organisation im Data Lake ab. Während das reine Auslagern von Daten unkompliziert verläuft, besteht die Herausforderung darin, die Daten so effizient bereitzustellen, dass sie sowohl für das initiale und inkrementelle EDW-Laden als auch für unabhängige Abfragen von Data Scientists genutzt werden können. Ein effizienter Data Lake ist zu diesem Zweck funktional strukturiert. Das bedeutet: Die Metadaten der Quellsysteme steuern die Organisation des Data Lakes. Aus unserer Praxis empfehlen wir stets folgende Ordnerstruktur:
- Source system: Der erste Ordner entspricht dem Typ des Quellsystems (z. B. Oracle).
- Connection: Da in typischen Unternehmen oft mehrere Verbindungen desselben Quellsystemtyps existieren (z. B. mehrere Oracle-Datenbanken), werden diese getrennt geladen. Achten Sie jedoch darauf, dass der Identifier für jede Verbindung eindeutig ist (z. B. über eine Nummer, einen Code oder ein Kürzel).
- Schema name: Bieten Quellsysteme mehrere Schemata oder Datenbanken pro Verbindung, sollte sich diese Hierarchie an dieser Stelle widerspiegeln, gegebenenfalls aufgeteilt auf mehrere Unterordner.
- Collection/Relation name: Name der abzufragenden Entität oder REST-Collection.
- Load date timestamp: Der LDTS gibt den Load Date Timestamp des jeweiligen Batches an.
Innerhalb des letzten Ordners (Load Date Timestamp) ist es ratsam, die Daten auf mehrere Buckets aufzuteilen, anstatt eine einzelne Riesendatei oder extrem viele Kleinstdateien abzulegen. Dies steigert die Performance der Query Engines erheblich insbesondere bei der Nutzung verteilter Dateisysteme. Zudem empfiehlt sich die Verwendung von Avro-Dateien, die in der Regel mit Snappy komprimiert sind.Sollten nachgelagerte Tools dieses Format nicht unterstützen, sollte stattdessen unkomprimiertes JSON verwendet werden. Die Datei selbst sollte neben den Quellattributen folgende Attribute aufweisen:
- Load Date Timestamp: Viele Tools können den Load Date Timestamp nicht direkt aus dem Dateipfad bzw. -schlüssel (Key) auslesen.
- Sub sequence number: Die Untersequenznummer zur eindeutigen Sortierung.
Diese Struktur lässt sich flexibel mit verschiedenen Query Engines (z. B. Apache Drill, Impala, Hive) einsetzen und hat sich in diesen Szenarien bestens bewährt.
Fazit
Eine durchdachte Strukturierung des Data Lakes ist entscheidend, um die Effizienz der Datenabfrage nachhaltig zu steigern. Davon profitieren sowohl die Ladeprozesse des Enterprise Data Warehouse (EDW) als auch die unabhängigen Analysen der Data Scientists. Die Implementierung eines gut organisierten Data Lakes als Persistent Staging Area innerhalb einer hybriden Data-Vault-2.0-Architektur ermöglicht einen nahtlosen Datenzugriff und eine leistungsfähige Virtualisierung. Dieser Ansatz stellt sicher, dass Daten jederzeit problemlos verfügbar und optimal strukturiert sind, um vielfältigen analytischen und operativen Anforderungen gerecht zu werden.
