Data Lake-Effizienz: Strukturelle Lösungen

Data Lake Struktur - Lösung

Die Organisation von Daten innerhalb einer Datensee kann die nachgelagerte Zugänglichkeit erheblich beeinträchtigen. 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) Last und für Datenwissenschaftler, die unabhängige Abfragen durchführen.

In der Praxis hängt der einfache Zugang zu den Daten davon ab, wie gut die Daten in der Datenbank organisiert sind. Datensee. Eine gut organisierte Struktur erleichtert reibungslosere Abrufprozesse und unterstützt sowohl EDW-Lasten als auch die unabhängigen Abfrageanforderungen von Datenwissenschaftlern.

Innerhalb einer hybride data warehouse-ArchitekturWie 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, muss die Datensee ist am besten so organisiert, dass ein effizienter Zugriff innerhalb eines persistenten Staging Area-Musters und eine 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

Die Datensee, as shown in Figure 1, is used within the hybrid architecture as a persistent staging area (PSA).  Dies unterscheidet sich von der relationalen Bereitstellung, bei der ein persistenter oder transienter Bereitstellungsbereich (TSA) verwendet wird.

As a TSA has the advantage that the needed effort for data management is reduced: e.g. if the source structure is changing, the relational stage table must be adjusted. Thus, if the stage table is empty, data management doesn’t occur.

However, if relational technology is used to create a PSA, the historical data within the table must be modified to match the new structure.

This is different from a staging area on a data lake as in the instance that the source data changes, the historical data in other files is not affected.

Therefore, no data management is necessary and with that in mind, PSAs on data lake are preferred over TSAs.

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

1. It not only serves the data warehouse team in their loading jobs, but it also serves data scientists who directly access the data lake, potentially ignoring the EDW. 
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 das 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 nachgelagert sein oder nicht. 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-Last und von Data Scientists für unabhängige Abfragen verwendet werden können.

In diesem Sinne ist ein effizienter Data Lake funktional strukturiert, 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: Das typische 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 der Bezeichner 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 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. Unter-Sequenznummer

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.

Um die Erstellung von Visual Data Vault-Zeichnungen in Microsoft Visio zu unterstützen, wurde eine Schablone implementiert, die zum Zeichnen von Data Vault-Modellen verwendet werden kann. Die Schablone ist erhältlich bei www.visualdatavault.com.