Data Lake-Effizienz: Strukturelle Lösungen

Data Lake Struktur - Lösung

Die Organisation der Daten innerhalb eines Data Lake hat einen entscheidenden Einfluss auf deren nachgelagerte Zugänglichkeit. Während das Ablegen von Daten im Data Lake vergleichsweise einfach ist, liegt die eigentliche Herausforderung im effizienten Abrufen dieser Daten. Diese Effizienz ist besonders wichtig für Aufgaben wie den inkrementellen oder initialen Ladevorgang des Enterprise Data Warehouse (EDW) sowie für Data Science Praktiker, die unabhängige Abfragen durchführen. In der Praxis hängt der einfache Zugriff auf die Daten davon ab, wie gut sie im Data Lake strukturiert sind. Eine gut organisierte Struktur ermöglicht reibungslose Abrufprozesse und unterstützt sowohl EDW-Ladevorgänge als auch die unabhängigen Abfrageanforderungen von Datenwissenschaftlern.

Innerhalb einer hybriden Data-Warehouse-Architektur, wie sie im Data Vault 2.0 Boot-Camp-Trainingvermittelt wird, wird ein Data Lake als Ersatz für eine relationale Staging-Area eingesetzt. Um die Vorteile dieser Architektur voll auszuschöpfen, sollte der Data Lake so organisiert sein, dass ein effizienter Zugriff im Rahmen eines persistenten Staging-Area-Musters möglich ist und eine bessere Datenvirtualisierung unterstützt wird.

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 Lakeinnerhalb der hybriden Architektur als persistente Staging-Area (PSA) eingesetzt.  Dies unterscheidet sich von relationalen Staging-Bereichen, in denen entweder eine persistente oder eine temporäre Staging-Area (TSA) verwendet wird. Eine TSA hat den Vorteil, dass der notwendige Aufwand für das Datenmanagement reduziert wird: Wenn sich beispielsweise die Quellstruktur ändert, muss die relationale Staging-Tabelle angepasst werden. Ist die Staging-Tabelle leer, fällt kein Datenmanagement an. Wird jedoch relationale Technologie zur Erstellung einer PSA verwendet, müssen historische Daten innerhalb der Tabelle angepasst werden, um der neuen Struktur zu entsprechen. Dies unterscheidet sich von einer Staging-Area auf einem Data Lake: Ändern sich die Quelldaten, bleiben die historischen Daten in anderen Dateien unberührt. Somit ist kein Datenmanagement erforderlich. Vor diesem Hintergrund werden PSAs auf einem Data Lake gegenüber TSAs bevorzugt. Eine anschauliche Begründung hierfür wird wie folgt dargestellt:

1. Der Data Lake dient nicht nur dem Data-Warehouse-Team bei deren Ladeprozessen, sondern auch den Data Scientists, die direkt auf den Data Lake zugreifen und dabei das EDW gegebenenfalls umgehen. 
2. Vollständige Ladevorgänge können vom Data-Warehouse-Team genutzt werden, um neue Raw-Data-Vault-Entitäten mit historischen Daten initial zu laden.
3. Dieses Muster kann außerdem dazu verwendet werden, das Data Warehouse auf dem Data Lake zu virtualisieren.

Strukturierung des Data Lake für effizienten Datenzugriff

Je nach Organisation der Daten im Data Lake kann der nachgelagerte Zugriff auf diese Daten einfach oder schwierig sein. Während das Ablegen von Daten im Data Lake grundsätzlich unkompliziert ist, stellt es in der Regel eine Herausforderung dar, die Daten effizient abzurufen – sei es für den inkrementellen oder initialen Ladevorgang des EDW oder für Data Scientists, die unabhängige Abfragen durchführen. Ein effizienter Data Lake ist funktional strukturiert, was im Wesentlichen bedeutet, dass die Metadaten der Quellsysteme die Organisation des Data Lakes bestimmen. Aus unserer Erfahrung hat es sich bewährt, folgende Ordnerstruktur zu verwenden:

1. Quellsystem: Der erste Ordner enthält den Typ des Quellsystems (z. B. Oracle).
2. Verbindung: In einer typischen Unternehmensumgebung gibt es häufig 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 jeder Verbindung ein eindeutiger Identifikator zugewiesen wird. Dies kann durch eine Nummer, einen Code oder eine Abkürzung erfolgen.
3. Schema-Name: Manche Quellsysteme stellen pro Verbindung mehrere Schemata oder Datenbanken bereit. Diese Hierarchie sollte in diesem Bereich abgebildet werden und kann tatsächlich aus mehreren Ordnern bestehen.
4. Entitäts-/Relationsname: Dies ist der Name der Entität oder der REST-Sammlung, die abgefragt werden soll.
5. Ladezeitstempel (LDTS): Der LDTS gibt den Zeitpunkt des Batch-Ladevorgangs an.

Innerhalb des letzten Ordners (Ladezeitstempel) ist es häufig von Vorteil, die Daten in mehreren Dateien zu speichern, anstatt in einer einzigen großen Datei oder sehr kleinen Dateien. Dies verbessert in der Regel die Leistung von Abfragewerkzeugen, insbesondere wenn die Daten in einem verteilten Dateisystem gespeichert werden. Es wird außerdem empfohlen, Avro-Dateien zu verwenden, die üblicherweise mit Snappy komprimiert werden. Wenn die nachgelagerten Werkzeuge dieses Dateiformat jedoch nicht unterstützen, sollte alternativ unkomprimiertes JSON verwendet werden. Die Datei selbst sollte zusätzlich zu den Quellattributen folgende Eigenschaften aufweisen:

1. Ladezeitstempel: Viele Werkzeuge können den Ladezeitstempel nicht direkt aus dem Dateinamen oder -schlüssel ablesen. 
2. Subsequenznummer

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

Fazit

Zusammenfassend ist eine effektive Strukturierung des Data Lakes entscheidend, um die Effizienz beim Abrufen von Daten zu erhöhen – wovon sowohl die Prozesse des Enterprise Data Warehouse (EDW) als auch die unabhängigen Analysen von Data Scientists profitieren. Die Implementierung eines gut organisierten Data Lakes innerhalb einer hybriden Data Vault 2.0 Architektur dient als persistente Staging-Area, erleichtert den nahtlosen Datenzugriff und verbessert die Datenvirtualisierung. Dieser Ansatz stellt sicher, dass die Daten jederzeit verfügbar und optimal strukturiert sind, um den unterschiedlichen analytischen und operativen Anforderungen gerecht zu werden.

- Marc Winkelmann (Scalefree)