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) load and for Data Science practitioners conducting independent queries. In practice, the ease of accessing data downstream depends on how well the data is organized within the data lake. A well-organized structure facilitates smoother retrieval processes, empowering both EDW loads and the independent querying needs of data scientists.

Innerhalb einer hybriden Data Warehouse-Architektur, as promoted in the Data Vault 2.0 Boot Camp training, a data lake is used as a replacement for a relational staging area. Thus, to take full advantage of this architecture, the data lake is best organized in a way that allows efficient access within a persistent staging area pattern and better data virtualization.

Der Data Lake in einer hybriden Data Vault-Architektur

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

Die 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. In our experience, it is always a better practice to have the following folder structure:

1. Source system: The first folder is the type of source system (e.g. 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. It is also recommended to utilize Avro files, usually compressed using Snappy, though if downstream tools don’t support this file format, use unzipped JSON instead. Die Datei selbst sollte zusätzlich zu den Quellattributen die folgenden Attribute aufweisen:

1. Load Date Timestamp: many tools cannot retrieve the load date time stamp from the file’s key 
2. Untersequenznummer

This structure can be used with multiple query engines (e.g. Apache Drill, Impala, Bienenstock, etc.) and have proven to work in these scenarios well.

Schlussfolgerung

In summary, structuring a data lake effectively is crucial for enhancing data retrieval efficiency, which benefits both Enterprise Data Warehouse (EDW) processes and data scientists’ independent analyses. Implementing a well-organized data lake within a hybrid Data Vault 2.0 architecture serves as a persistent staging area, facilitating seamless data access and improved virtualization. This approach ensures that data is readily available and optimally structured to meet diverse analytical and operational needs.

- Marc Winkelmann (Scalefree)