Nachdem der letzte Beitrag dieser Serie das grundsätzliche Begriffsverständnis sowie die Motivation für den Aufbau eines Data Lakes thematisierte, betrachtet dieser Artikel nun Fragestellungen hinsichtlich der Architektur und des Aufbaus eines Data Lakes. Entsprechend den unterschiedlichen Beweggründen für die Etablierung eines Data Lakes, gibt es auch verschiedenste Ansätze für die Strukturierung einer entsprechenden Systemlandschaft, welche die folgenden Abschnitte anhand ausgewählter architektonischer Fragestellungen kurz verdeutlichen.
Welche Komponenten gehören zu einem Data Lake?
Für eine systematische Annäherung an diese Frage, steckt Abbildung 1 den technologischen Rahmen eines Data Lakes ab. Hierbei gibt es, wie so oft bei diesem Thema, keine einheitliche Abgrenzung. Meist beinhaltet ein Data Lake insbesondere neuartige Ansätze der Datenhaltung, die im Zuge der Big-Data-Bewegung an Relevanz gewonnen haben (Enges Verständnis). In einem weiten Verständnis bezeichnen viele Organisationen aber auch ihre komplette Analytics-Landschaft, inklusive traditionellen Data-Warehouse-Strukturen und nachgelagerten informationsgenerierenden Systemen, als Data Lake.
Beide Sichtweisen haben aber je nach Gegebenheiten der Umwelt und nach Grad der Integration traditioneller und neuartiger Ansätze ihre Berechtigung und die Wahrheit liegt in der Praxis meist irgendwo dazwischen.
Welche Rolle spielt das Data Warehouse im Data Lake?
Ein zentraler Treiber des Data-Lake-Themas ist die Anforderung der Speicherung von großen Mengen an strukturierten- und unstrukturierten Rohdaten, wie bspw. Sensor-Daten oder Bild- und Video-Dateien. Traditionelle Data-Warehouse-Konzepte stoßen hierbei oft an Grenzen und wurden daher in den letzten Jahren oft durch Massenspeicher-fokussierte Data-Lake-Ansätze erweitert. Technologien wie Hadoop oder cloudbasierte Objektspeicher erlauben hierbei durch eine horizontale Skalierung große Datenmengen kostengünstig zu speichern und effizient zu verarbeiten. Vor diesem Hintergrund hat sich das Verständnis eines Data Lakes als „große Festplatte“ entwickelt, da alles was kein Platz im Data Warehouse (DWH) hat in einem Data Lake abgelegt werden kann.
Umso mehr Daten sich nun aber in einem Data Lake befinden, desto näher liegt der Gedanke, dass dieser die traditionelle Rolle des DWH als führende Datenquelle (Single Point of Truth) übernimmt. Dieser Konflikt macht es daher essentiell sich Gedanken über das Zusammenspiel des DWH und des Data Lake zu machen.
Abbildung 2 skizziert drei mögliche Lösungsansätze zu dieser Problemstellung. Bei einem parallelen Ansatz existieren DWH und Data Lake unabhängig voneinander und die vor- und nachgeschalteten Systeme füttern bzw. konsumieren beide System separat. Dieser Ansatz ist einfach und geradlinig, bringt aber auch zahlreiche Redundanzen und eine Integration wird leicht unübersichtlich.
Da der Data Lake eher für Rohdaten gedacht ist und das DWH üblicherweise mit aufbereiteten und aggregierten Daten arbeitet, bietet sich als Alternative die Möglichkeit den Data Lake als Vorsystem zu einem DWH zu nutzen. Hier werden zuerst alle Daten in den Data Lake persistiert und anschließend ausgewählte Daten per ETL-Prozess transformiert und in einem DWH bereitgestellt. Dieses Konzept ähnelt dem klassischen Operational Data Store (ODS), mit dem Unterschied, dass der Data Lake Einträge langfristig speichert und Daten auch als eigenständige Komponente (bspw. für explorative Analysen) bereitstellt.
Wird dieser Ansatz konsequent zu Ende gedacht, verschwimmen die Grenzen immer stärker und das DWH wird ein Teil des Data Lakes (im weiten Verständnis). Der Data Lake wird hiermit zum führenden System in der Datenschicht mit einem DWH als Teilkomponente für die Bereitstellung strukturierter Daten (bspw. für dispositive Auswertungen im Controlling). Diese führende Rolle der Rohdaten, wird auch stark von Techniken wie der DWH-Automatisierung propagiert, die es ermöglichen nachgelagerte Strukturen zu jeder Zeit auf Basis der zugrundeliegenden Rohdaten neu zu generieren.
Wie gehe ich mit Heterogenität im Data Lake um?
Eine weitere wichtige Säule eines Data Lakes ist die Integration zahlreicher heterogener Systeme und Datenquellen.
Abbildung 3 veranschaulicht drei Stufen der Integration innerhalb eines Data Lakes. In einem wenig integrierten Szenario existieren verschiedene Systeme als losgelöste Daten-Silos. Diese Entwicklung ist oft bei historisch-gewachsenen Systemlandschaften zu beobachten, in denen etwa die traditionelle DWH-Kompetenzen im Finanzwesen aufgehängt sind und sich gleichzeitig zahlreiche operative Analyse-Systeme verteilt über die Fachbereiche finden. Entsprechend gibt es viele Redundanzen und ein Mehrwert durch eine Kombination von Daten ist schwer realisierbar. Eine Integration findet hier, wenn überhaupt, manuell oder mittels komplexer ETL-Strecken statt.
Als Abhilfe gibt es verschiedene partiell integrierte Konzepte. Ein gutes Beispiel hierfür ist die vor einigen Jahren stark diskutierte Lambda-Architektur, die traditionelle (eher auf Stapelverarbeitung ausgelegt) und Echtzeit-orientierte Systeme (Streaming) durch eine voraggregierte Zwischenschicht (Serving-Layer) integriert. Hierdurch ergeben sich Synergie-Effekte und neue Anwendungsfälle. Gleichzeitig ist das eigentliche Problem der Systemredundanz nicht behoben und die Komplexität in der Verwaltung der Systemlandschaft steigt sogar eher.
Eine eher neuartige Art für den Umgang mit komplexen Systemlandschaften sind ereignisgetriebene Architekturen. Motiviert aus den technologischen Fortschritten aus dem Bereich der Stream-Verarbeitung, setzt dieser Ansatz auf eine asynchrone Kommunikation zwischen den Systemen über einen zentralen Vermittler (Event-Hub). Der Vorteil hierbei ist die hohe Flexibilität, da die Systeme schnell und minimalinvasiv, also ohne größere Anpassungen des Systems selbst, integriert werden können. Gerade wenn ein Data Lake nicht nur als simpler Massenspeicher genutzt wird, sondern eine ganze Reihe an verschiedenen Datenhaltungs- und Verarbeitungskomponenten umfasst, bietet sich ein solcher Ansatz an.
Welches architektonische Vorgehen ist das richtige für mich?
Steht man nun vor der konkreten Herausforderung des Aufbaus eines Data Lakes, stellt sich natürlich die Frage, welches Vorgehen das passendste ist. Wie so oft gibt es auf diese Frage keine ultimative Antwort und jede Organisation hat andere Anforderungen und Umweltbedingungen. Abbildung 4 versucht trotzdem verschiedene Vorgehen einzuordnen und eine Unterstützung bei der Architekturplanung eines Data Lakes zu geben.
Ein grundsätzlicher Unterschied ist es, ob eine existierende Systemlandschaft transformiert werden soll (Brownfield) oder ob eine neue Landschaft ohne Vorbelastung aufgebaut werden kann (Greenfield). Gleichzeitig spielt die Komplexität des Szenarios (ausgedrückt durch die Anzahl und die Heterogenität der Systeme, den Umfang der Datensätze, die Anzahl der Abhängigkeiten zwischen den Komponenten etc.) eine entscheidende Rolle.
Bei einer existierenden hoch-komplexen Landschaft ist es ggf. ratsam nicht zu sehr in die bestandenen Strukturen einzugreifen und einen Data Lake eher mit eigenständigen parallel Strukturen aufzuziehen. Ist die Komplexität aber überschaubar, sollte man eine stärkere Integration anstreben und im besten Fall auf eine Ablösung der Altsysteme durch den Data Lake hinarbeiten, so dass der Data Lake keine weitere Insel in einem Flickenteppich von Datensystemen wird.
Anders sieht es aus, wenn man auf einer grünen Wiese startet. Hier hat man weniger Einschränkungen durch Altsysteme und eher die Qual der Wahl. Befindet man sich hier in einer komplexen Umgebung, die perspektivisch noch eher umfangreicher wird, liegt es nahe direkt auf einen flexiblen Ansatz, wie bspw. eine ereignisgetriebene Architektur zu setzen. Ist die Komplexität aber überschaubar, ist es ratsam dem KISS-Prinzip zu folgen und die am operativ passendste Architektur zu wählen und bspw. einfach das Data Warehouse mit einem Massenspeicher zu ergänzen oder eine parallele Streaming-Pipeline aufzubauen.
Zusammenfassung
Dieser Artikel hat nur einige ausgewählte Fragestellungen herausgepickt, die sich bei einem Aufbau eines Data Lakes stellen und viele Details, wie bspw. die Frage nach der Cloud, ausgelassen. Jedem der Punkte könnte man zudem ein eigenes Kapitel in einem Buch widmen und bekäme trotzdem keine Pauschalantworten. Es zeigt sich daher wieder, dass auch bei der Architektur ein Verständnis der grundsätzlichen Anforderungen und der Motivation notwendig ist, um einen zielführenden und zukunftsfähigen Rahmen aufzubauen.
Die Diskussion der Punkte zeigt zudem, dass ein moderner Data Lake, bei einem richtigen Aufbau, weit mehr als nur eine Erweiterung der Analytics-Landschaft um eine große Festplatte sein kann. Als strukturiertes Konglomerat verschiedener Datenhaltungs- und Analyse-Systeme kann er eine zentrale Rolle bei dem Umgang mit zunehmender System- und Datenheterogenität übernehmen und sich damit zum technologischen Herzstück einer zukunftsorientierten Analytics-Landschaft emanzipieren.
Der nächste Teil dieser Serie beschäftigt sich mit prozessualen und organisatorischen Herausforderungen bei der Implementierung eines Data Lakes in der Praxis.
Quellen:
[1] Baar, H. und Kemper, H. G. „Integration von Big-Data-Komponenten in die Business Intelligence“, in Controlling (27, 4-5), S. 222–228, 2015.
Sie wollen mehr erfahren:
[1] TDWI Seminar “Data-Lake-Ansätze und Best Practices”
[2] TDWI E-Book: “Der Data Lake als zentrales Element in Analytics-Architekturen“
[3] Whitepaper „Streaming-Frist Architectures”
https://www.pragmatic-apps.de/de/streaming-first-architekturen/
*Der Beitrag spiegelt die Meinung des Autors wider und ist keine allgemeingültige Meinung des TDWI. Als TDWI bieten wir die Plattform, alle Themen und Sichtweisen zu diskutieren.*
Schreibe einen Kommentar