Data Lake-Effizienz: Strukturelle Lösungen

Data Lake Struktur - Lösung

Die Organisation von Daten innerhalb eines Data Lake kann die nachgelagerte Zugänglichkeit erheblich beeinflussen. Während das Auslagern von Daten in den Data Lake ein unkomplizierter Prozess ist, besteht die eigentliche Herausforderung darin, diese Daten effizient abzurufen. Die Effizienz des Datenabrufs ist entscheidend für Aufgaben wie die inkrementelle oder erste Enterprise Data Warehouse (EDW) Beladung und für Data Scientists, die davon unabhängige Abfragen durchführen.

In der Praxis hängt der einfache Zugang zu den Daten davon ab, wie gut die Daten innerhalb des Data Lake organisiert sind. Eine gut organisierte Struktur erleichtert reibungslosere Abrufprozesse und unterstützt sowohl EDW-Beladung als auch die unabhängigen Abfrageanforderungen von Data Scientists.

Innerhalb einer hybriden Data Warehouse-Architektur, wie in der Data Vault 2.0-Bootcamp-Schulung beschrieben, wird ein Data Lake als Ersatz für einen relationalen Staging-Bereich verwendet. Um die Vorteile dieser Architektur voll auszuschöpfen, sollte der Data Lake am besten so organisiert sein, dass ein effizienter Zugriff mithilfe eines persistenten Staging Area-Musters und bessere Datenvirtualisierung möglich ist.

Der Data Lake in einer hybriden Data Vault-Architektur

Abbildung 1: Der Data Lake in einer hybriden Data Vault-Architektur

Der Data Lake, wie in Abbildung 1 dargestellt, wird innerhalb der hybriden Architektur als persistente Staging Area (PSA) verwendet.  Dies unterscheidet sich vom relationalen Staging, bei der ein persistenter oder transienter Bereitstellungsbereich (TSA) verwendet wird.

Eine TSA hat den Vorteil, dass der Aufwand für die Datenverwaltung reduziert wird: Ändert sich z.B. die Quellstruktur, muss die relationale Staging-Tabelle angepasst werden. Ist die Staging-Tabelle also leer, entfällt diese Anpassung.

Wird jedoch relationale Technologie zur Erstellung einer PSA verwendet, müssen die historischen Daten in der Tabelle an die neue Struktur angepasst werden.

Dies unterscheidet sich von einem Staging-Bereich in einem Data Lake, da im Falle einer Änderung der Quelldaten die historischen Daten in anderen Dateien nicht betroffen sind.

Daher ist kein Datenmanagement erforderlich, und in diesem Sinne sind PSAs auf Data Lake den TSAs vorzuziehen.

Eine klare Begründung für diese Aussage wird wie folgt dargestellt:

1. Es dient nicht nur dem Data Warehouse-Team bei seinen Ladevorgängen, sondern auch den Data Scientists, die direkt auf den Data Lake zugreifen und dabei möglicherweise das EDW ignorieren. 
2. Full Loads können vom Data Warehouse-Team verwendet werden, um neue Raw Data Vault-Entitäten mit historischen Daten zu initialisieren.
3. Dieses Muster könnte verwendet werden, um ein Data Warehouse auf dem Data Lake zu virtualisieren.

Strukturierung des Data Lake für effizienten Datenzugriff

Je nachdem, wie die Daten im Data Lake organisiert sind, kann der Zugriff auf die Daten in Downstream-Prozessen einfach oder schwierig sein. Während es immer einfach ist, Daten in den Data Lake zu verlagern, ist es in der Regel eine Herausforderung, die Daten effizient abzurufen, damit sie von der inkrementellen oder anfänglichen EDW-Beladung und von Data Scientists für unabhängige Abfragen verwendet werden können.

Um dies zu bewirken, sollte ein effizienter Data Lake funktional strukturiert sein, was im Wesentlichen bedeutet, dass die Metadaten der Quellsysteme die Organisation des Data Lake bestimmen.

Unserer Erfahrung nach ist es immer besser, die folgende Ordnerstruktur in einem Data Lake zu haben:

1. Quellsystem: Der erste Ordner in einem Data Lake ist der Typ des Quellsystems (z. B. Oracle).
2. Verbindung: Ein typisches Unternehmen hat mehrere Verbindungen desselben Quellsystems, z. B. mehrere Oracle-Datenbanken, die in den Data Lake geladen werden müssen. Es ist jedoch darauf zu achten, dass die Bezeichnung für jede Verbindung eindeutig ist. Dies kann durch eine Nummer, einen Code oder eine Abkürzung geschehen.
3. Schemaname: Einige Quellsysteme bieten mehrere Schemata oder Datenbanken pro Verbindung. Diese Hierarchie sollte sich in diesem Bereich widerspiegeln und kann tatsächlich aus mehreren Ordnern bestehen.
4. Name der Sammlung/Beziehung: Dies ist der Name der Entität oder der REST-Sammlung, die abgefragt werden soll.
5. Zeitstempel des Ladedatums: Der LDTS gibt den Zeitstempel des Ladedatums (load date timestamp) der Charge an.

Innerhalb des letzten Ordners (Zeitstempel des Ladedatums) ist es oft von Vorteil, die Daten in mehreren Buckets zu speichern (anstelle einer großen Datei oder sehr kleiner Dateien). Dies verbessert im Allgemeinen die Leistung von Abfragetools, insbesondere wenn die Daten in einem verteilten Dateisystem gespeichert sind. Es wird auch empfohlen, Avro-Dateien zu verwenden, die in der Regel mit Snappy komprimiert werden. Wenn Downstream-Tools dieses Dateiformat nicht unterstützen, kann stattdessen gunzipped JSON verwendet werden.

Die Datei selbst sollte zusätzlich zu den Quellattributen die folgenden Attribute aufweisen:

1. Zeitstempel des Ladedatums: Viele Tools können den Zeitstempel des Ladedatums nicht aus dem Schlüssel der Datei im Data Lake abrufen.
2. Untersequenznummer

Diese Struktur kann mit mehreren Abfrage-Engines (z. B. Apache Drill, Impala, Hive usw.) verwendet werden und hat sich in diesen Szenarien bewährt.

- Marc Winkelmann (Scalefree)

Updates und Support erhalten

Bitte senden Sie Anfragen und Funktionswünsche an [email protected]. 

Für Anfragen zu Data Vault-Schulungen und Schulungen vor Ort wenden Sie sich bitte an [email protected] oder registrieren Sie sich unter www.scalefree.com.

Zur Unterstützung bei der Erstellung von Visual Data Vault-Zeichnungen in Microsoft Visio wurde eine Schablone entwickelt, mit der Data Vault-Modelle gezeichnet werden können. Die Schablone ist erhältlich bei www.visualdatavault.com.