Dieser Beitrag ist als Titelthema zunächst in dem Magazin BI-Spektrum ( Ausgabe 4 / 2021) unter der Überschrift „Data Lakes der zweiten Generation” erschienen.

Als zentrales Element einer datengetriebenen Organisation setzen viele Unternehmen auf den Aufbau einer Datenplattform auf Basis der Data Lake Konzeption. Häufig wird die hohe Erwartungshaltung an derartige Data Lakes jedoch kurzfristig nicht erfüllt. Statt über die Umsetzung von datengetriebenen Use Cases zu diskutieren, entbrennt vielmehr ein Streit um unterschiedliche Architekturen und infrage kommende Technologien zur Architekturumsetzung des Data Lake. Die Marktdynamik hat zudem dazu geführt, dass die On-Premise Data Lakes der ersten Generation häufig schon nach kurzer Zeit durch Architekturen und Technologien der zweiten Generation ergänzt bzw. ersetzt wurden. Als Best Practices werden in diesem Beitrag anhand einer Referenzarchitektur gängige Gestaltungsprinzipien sowie die relevanten Cloud-Technologien für Data Lakes der zweiten Generation vorgestellt.

Data Lake als weiteres Element innerhalb eines analytischen Ecosystems    

In den 90er Jahren setzte sich mit dem Data Warehouse Konzept die Idee einer separaten Datenplattform für dispositive Reporting- & Analysezwecke in der Praxis durch, die redundant Datenbestände aus den operativen Systemen integriert und konsolidiert speichert [Gluchowski et al. 2008]. Im Fokus des Data Warehouse Konzeptes stand die Vorstellung, die in der Regel strukturierten Daten der Quellsysteme in ein vorab definiertes und abgestimmtes Datenmodell zu integrieren. Der hohe Anspruch an korrekte und unternehmensweit harmonisierte Daten führte in der Regel bei Data Warehouse Vorhaben dazu, dass es recht lange dauerte, bis Daten aus einer neuen Datenquelle in dieser konsolidierten Sicht integriert wurden, da im Vorfeld viel Konzeptions- und Abstimmungsaufwand nötig war. 

Nach der Jahrtausendwende entstand im Rahmen der Diskussion um Big Data mit dem Fokus auf der schnellen und unmittelbaren Verarbeitung von strukturierten als auch unstrukturierten Massendaten mit dem Data Lake Konzept eine neue Idee für eine integrierende dispositive Datenplattform. Die Grundidee wird gemeinhin James Dixon zugeschrieben, der in einem Blogpost von 2010 erstmalig das Bild eines Data Lakes prägte [Dixon 2010]. Der Data Lake stellt alle Quelldaten – interne und externe, strukturierte und unstrukturierte – auch in ihrer nicht aufbereiteten Form als Rohdaten zur Verfügung. Die Daten sollen möglichst unmittelbar nach der Datenerzeugung schnell und unverfälscht im Data Lake zur Verfügung stehen, um aktuelle, aber auch zukünftige analytische Fragestellungen bedienen zu können. 

Zweifelsfrei haben sich in der Praxis unterschiedliche Ausprägungen von Data Lakes entwickelt. Entlang des im Date Lake verfügbaren Anteils von Daten aus dem gesamten Datenhaushalt und der Anzahl und organisatorischen Herkunft der Nutzer kann man z.B. zwischen Data Puddles, Data Ponds, Data Lake im engeren Sinne oder einem Data Ocean unterscheiden [Gorelik 2019]. 

Ein Data Puddle als erste Adaptionsform des Data Lake Konzeptes ist gekennzeichnet durch seinen eingeschränkten, nur den aktuellen Nutzungsfall abdeckenden Datenhaushalt und eine lokale Nutzung durch (IT) Experten, was einen hohen Grad an manuellen Tätigkeiten zur Nutzung bedingt. Als Data Pond Konstrukt wird eine Vielzahl von nebeneinander, isoliert stehenden Data Puddles bezeichnet.  

Ein Data Lake im engeren Sinne unterscheidet sich von einem Data Pond in zwei wesentlichen Faktoren: Erstens wird eine Self-Service Nutzung durch Anwender ohne Beteiligung der IT ermöglicht. Zweitens enthält ein Data Lake im engeren Sinne Daten, die aktuell zwar nicht genutzt werden, aber perspektivisch interessant werden können. Der Data Ocean gilt als ultimative Antwort auf datengetriebene Entscheidungen, basierend auf allen (fachlichen) Daten eines Unternehmens und mit einem einfachen, verständlichen Zugang für alle Mitarbeiter. Die resultierende Wertschöpfung kann jedoch gegenüber einem gut positionierten Data Lake im engeren Sinne nur noch marginal erhöht werden.  

Eine Sonderform stellt der berüchtigte Data Swamp dar. Er ist eine Ansammlung von verschiedenen Daten, die jedoch überhaupt nicht oder wenig organisiert und aufbereitet sind. Weiterhin fehlen Metadaten, die eine Nutzung durch eine breitere Anwenderbasis verhindern.  

Gestaltungsprinzipien eines Date Lakes  

Bei der Gestaltung von Data Lakes bilden sich gerade erst Best Practices heraus. Anhand von Gestaltungsprinzipien lassen sich wesentliche Eigenschaften eines Data Lakes übergreifend von einzelnen Ausprägungen festlegen. Diese Gestaltungsprinzipien können innerhalb des Datenverarbeitungsprozesses in die 3 Schritte Anbindung von Datenquellen, Datenhaltung und Zugriff auf die Daten unterteilt werden. Daneben existieren Gestaltungsprinzipien, die die charakteristischen Eigenschaften der zugrundeliegenden Data Lake Plattform beschreiben.  

Die folgende Abbildung liefert einen Überblick über die Gestaltungsprinzipien eines Data Lakes, die natürlich in unterschiedlichen Projektkontexten unterschiedlich stark ausgeprägt sind. 

Die Anbindung von Datenquellen an den Data Lake soll derart erfolgen, dass die schnelle (und agile) Verprobung und die darauffolgende produktive Umsetzung aktueller und potenziell neuer Use Cases ermöglicht wird. Quelldaten sollen dazu möglichst breit entlang von den Primärquellen mit der feinsten verfügbaren Datengranularität angebunden werden.  

Im Bereich der Datenhaltung ist das Vorhalten des originären Rohdatenformats ein entscheidender Faktor, um jegliche Neuinterpretation der Daten zu ermöglichen. Die Nutzung eines Zonenkonzeptes hat sich als sinnvolle Ordnungseinheit innerhalb einer Data Lake Architektur etabliert. Insbesondere nach der Novellierung der Datenschutzbestimmungen ist es in vielen Data Lakes üblich geworden, die Nutzung personenbezogener Daten durch eine vollständige Anonymisierung zu vermeiden. Im Gegensatz zum Data Warehouse stellt die Umsetzung eines ausgewogenen anstatt eines vereinheitlichten Datenmodells eine prägende Eigenschaft eines Data Lakes dar. Im Data Lake sind durch unterschiedliche Use Cases begründbare abweichende Definitionen erlaubt, so dass ein aufwendiger und langwieriger Abstimmungsprozess zur Harmonisierung der Daten nicht benötigt wird. 

Ein liberaler Zugriff auf einen Data Lake ermöglicht idealtypisch vielen Nutzer den Zugriff auf die Daten. Nur in begründeten Ausnahmefällen ist der Zugriff feingranular zu steuern. Beispiele sind personenbezogene, vertrauliche oder Buchungskreis-bezogene Daten. Auch technisch soll ein Zugriff möglichst ohne Einschränkung ermöglicht werden. 

Die Data Lake Plattform selbst soll stabil, skalierbar und kosteneffizient sein. Geeignete Mittel hierfür sind die Implementierung als ´Infrastrukture as a Code´ sowie die Nutzung offengelegter Standards. Entgegen dem originären Grundsatz der Apache Hadoop Architektur ist eine Trennung von Storage und Compute Ressourcen anzustreben. Data Lakes sollen alle Ingest- und Datenmanagementfähigkeiten besitzen, die für eine Datenintegration und -verarbeitung notwendig sind. Letztere sollen zudem über zentrale Scheduling- und Monitoring-Prozesse nutzbar sein. Um einen Data Swamp zu vermeiden, ist es elementar wichtig, fachliche und operative Metadaten mit einem geeigneten Tool möglichst automatisiert zu erfassen und für alle Anwender nutzbar zu machen. Im Rahmen der Verwendung in einem (Groß-)Unternehmen ist es zudem wichtig, die Integration in die allgemeine IT durchzuführen. Hierzu zählen u.a. die Einbindung in das zentrale Identity Management System, Abrechnungsmöglichkeiten der Nutzung, Auditierbarkeit der Nutzung (entsprechend den jeweils geltenden Auflagen) und die Bereitstellung eines Continious Integration/ Continious Deployment (kurz CI/CD) Prozesses. 

Zonenorientierte Referenzarchitektur eines Data Lakes  

Die Datenarchitektur des Data Lakes orientiert sich in der Regel an sog. Zonen, häufig spricht man daher auch von einem zonenbasierten Data Lake [Madsen 2015]. Eine Zone bestimmt dabei den Verarbeitungsgrad der Daten, die in der Zone enthalten sind. Ein typischer Zonenaufbau differenziert vier Zonen, wie in der folgenden Abbildung dargestellt wird. 

Regelmäßig enthält die erste Zone als Rohdatenzone (Raw Zone) die eingehenden Daten in ihrer rohen, unverarbeiteten Form. Die Daten in der Raw Zone bleiben auch nach ihrer Weiterverarbeitung erhalten und werden grundsätzlich nicht gelöscht.

In der darauffolgenden annotierten Zone (Annotated Zone) werden die Daten der Quellen so aufbereitet, dass Nutzerzugriffe möglich sind. Hierzu werden technische Format-Transformationen durchgeführt, die einen einfacheren Zugriff ermöglichen, und technische Datenqualitätsinformationen hinzugefügt. Weiterhin werden Informationen zur einheitlichen Datenzugriffsberechtigungssteuerung über den Bezug auf einheitlich definierte Access Control Dimensions (ACDs) eingefügt. Spätestens hier werden personenbeziehbare Daten für die Nutzung anonymisiert.

In der darauffolgenden Prozessierungszone (Processing Zone) erfolgt die Aufbereitung der Daten für die einfache Nutzung durch Anwender. Hierzu werden fachliche Transformationen durchgeführt, um Daten unterschiedlicher Quellen miteinander zu kombinieren, Anreicherungen und Berechnungen durchzuführen sowie fachliche Datenqualitätsinformationen hinzuzufügen.

Die Serving Zone schließlich ist logisch keine eigene Zone, sondern dient ausschließlich der technischen Optimierung der Datenzugriffe auf Daten, die in den darunter angeordneten Zonen bereits vorhanden sind. In dieser Zone werden unterschiedliche Speicherorganisationsformen wie z.B. Row vs. Column based eingesetzt, um bekannte Zugriffsarten schnellstmöglich zu unterstützen.

Generationen von Data Lakes  

Die großen Data Lakes der ersten Generation wurden primär im eigenen Rechenzentrum mit groß dimensionierten Knoten aufgebaut. Ziel war es für viele Unternehmen, eine Datenplattform für alle Nutzungszwecke zu bauen. Dieser Ansatz brachte zahlreiche Herausforderungen mit sich, da sich Anforderungen wie z.B. „tief analytische Abfragen auf sehr große Datenmengen“ und „API für Kunden-facing Website mit erwartetem Antwortzeitverhalten im Sekundenbereich“ zum Teil in ihren Architekturpattern widersprechen.

Weiterhin wurde das originäre Grundparadigma des Apache Hadoop Stacks in Form der dedizierten Kopplung von Storage und Compute in den Knoten eines Clusters umgesetzt. Data Lakes der ersten Generation basieren zumeist auf kommerziellen Distributionen des Apache Hadoop Stacks. Man versprach sich damit, dass das notwendige Know-How für die produktive Nutzung gesenkt wurde. In der Rückbetrachtung muss man aber feststellen, dass trotz der Verwendung von kommerziellen Distributionen im Vergleich zu anderen gängigen kommerziellen Applikationen ein höheres Know How zur produktiven Betreuung notwendig war. Hinzu kommt, dass sich der Markt der Anbieter von kommerziellen Distributionen in den letzten Jahren konsolidiert hat. Dies hatte zur Folge, dass sich für Nutzer allgemein die kommerziellen Konditionen verschlechtert haben.

Getrieben durch die veränderte Marktsituation der kommerziellen Distributionsanbieter und durch die allgemeine Strategie der verstärkten Cloud-Nutzung verlagert sich die Basis der Data Lakes der zweiten Generation: Die Trennung von Storage und Compute wird beim Cloud Computing sinnvoll und möglich, (preiswerte) Object Stores lösen somit das Hadoop Distributed File System (HDFS) weitestgehend ab. Bei dieser zweiten Generation wird eine Mischung aus Cloud nativen Services und Apache Hadoop Stack Komponenten eingesetzt. Somit wird der monolithische Ansatz verworfen und multiple, dedizierte Cluster für einzelne Aufgaben werden verwendet. Auch kommerzielle Anbieter von Distributionen verlagern ihr Angebot weg von on-premise installierbarer Software, hin zu Service Angeboten auf der Infrastruktur der großen Cloud Anbieter.

Technologieklassen zum Aufbau eines Data Lakes 

Die Data Lakes der zweiten Generation lassen sich in zwei Klassen mit typischen Bebauungsmustern einteilen, gegliedert an den Zonen, die in Abbildung 2 dargestellt sind.

Der erste Typ ist eine Migration des Hadoop Stack Ansatzes in die Cloud. Hier wird die RAW Zone nicht mehr in HDFS, sondern zumeist als Object Storage des verwendeten Cloud Anbieters abgebildet, also ADLSv2 bei MS Azure bzw. S3 bei AWS. Auch das Storage der weiteren Zonen wird als Object Storage abgebildet, aber häufig ergänzt um Performance-optimierte Speicherorganisationen in der Serving Zone, z.B. Apache Impala im Cloudera CDP Angebot. Das Datenmanagement wird ebenfalls aus dem klassischen Data Lake Stack übernommen und erfolgt insbesondere mit Apache Spark. Typische Vertreter dieser Gattung sind AWS EMR, MS Azure HDInsights, Cloudera CDP oder Databricks ECS.

Der zweite Typ teilt die Abbildung der RAW Zone in Cloud Object Storage, folgt in der Abbildung der weiteren Zonen aber einem anderen Ansatz: Die Daten werden möglichst frühzeitig in eine Cloud basierte relationale Datenbank in der Ausprägung MPP (Massive-Parallel-Processing) geladen und dann innerhalb dieser parallel verarbeitet. Hier wird das ELT (Extract-Load-Tranform) Pattern angewendet, das die parallele Verarbeitung von Aufgaben auf die zur Verfügung stehenden Knoten verteilt. Typische Vertreter sind z.B. AWS Redshift, Snowflake und Teradata Vantage.

Beide Typen nutzen zumeist zum Ingest Cloud-native Services, wie z.B. MS Azure Data Factory oder AWS Glue, wenn die Daten erreichbar für diese sind, oder aber das verbreitete Apache NiFi, welches auch die Integration unterschiedlichster on-premise Datenquellen ermöglicht.

Auf der Nutzungsseite wird in zwei Arten unterschieden: klassisches Dashboarding und Reporting auf der einen Seite und Advanced Analytics Umgebungen auf der anderen Seite. Für das Dashboarding und Reporting wird im Wesentlichen per klassischem JDBC (Java Database Connectivity) Zugriff auf Daten in relationaler Repräsentation (entweder via z.B. Apache HIVE, Apache Impala im Typ eins oder auf die relationale MPP Datenbank im Typ zwei) zugegriffen. Typische Vertreter sind AWS Quick Sight, MS PowerBI, Tableau, Qlik. Daneben bieten Advanced Analytics Umgebungen die Grundlage für die Arbeit via Code (z.B. Python, Apache Spark, R). Die Nutzungsoberflächen sind sogenannte Notebooks, die mit zugeordneten Compute-Ressourcen ausgestattet sind und auf die Daten zugreifen können. Beispiele sind das Open Source Projekt Jupyter und die kommerziellen Cloud-Angebote Amazon Sage Maker, MS Azure ML, Cloudera ML und Databricks ECS.

Weiterhin gibt es große Fortschritte bei den einfach zu nutzenden integrierten Services. Diese beinhalten das gesamte notwendige Spektrum für den Aufbau und die Nutzung einer Data Lake Plattform. Aktuelle Beispiele sind AWS Lake Formation, Azure Synapse, Databricks ECS. Daneben gibt es zahlreiche Nischen-Anbieter, die diesen Ansatz versuchen umzusetzen.

Fazit 

Data Lakes haben sich als zentrales Instrument der Digitalisierung in den letzten Jahren durchgesetzt. Die Prinzipien zum Aufbau haben sich weiterentwickelt: Wesentliche Grundsätze wie „möglichst eine Quelle mit ihrem Datenbestand sofort komplett anbinden, auch wenn für den aktuell umzusetzenden Use Case nur ein Subset benötigt wird“ haben weiterhin Bestand. Andere haben eine Evolution durchlaufen: So ist heute vorwiegend nicht mehr Apache Hadoop HDFS der Standard für die Speicherung von Rohdaten, es gibt eine strikte Trennung von Storage und Compute – und es gibt somit keine großen neuen Monolithen mehr. Nur für sehr große Datenmengen und Anfragevolumen ist eine Lösung im eigenen Rechenzentrum auf Basis des klassischen Hadoop Stacks wirtschaftlicher. 

Durch die Diversifizierung des Lösungsangebotes sind bisherige Hemmnisse wie die extreme Komplexität und der Mangel an notwendigen Skills zum Aufbau eines Data Lakes im Unternehmen signifikant gesunken.