Die stürmischen Gewässer des Data Lakes

In einem anderen Beitrag haben wir bereits geschrieben, dass der Begriff „Data Warehouse“ oft missverstanden wird. Dasselbe gilt für „Data Lake“ – eine neuere Bezeichnung für die Datenspeicherung. Die beiden Begriffe werden häufig verwechselt. Ein weiterer weit verbreiteter Irrtum ist, ein Data Lake als Ersatz oder moderne Version eines Data Warehouse zu betrachten. Um die Verwirrung zu verstärken, tauchte kürzlich das „Data Lakehouse“ auf – aktiv beworben als eine Mischung aus Data Warehouse und Data Lake, die angeblich das Beste aus beiden Welten vereint.

Wenn wir über Data Lakes sprechen, sollten wir zunächst klären, warum dieses Konzept überhaupt entstanden ist. Zurück geht es in die frühen 2000er Jahre.

Es beginnt an der Quelle

Auf der anderen Seite tauchte das Konzept des „Big Data“ auf. „Big Data“ war ein weiteres schlecht definiertes Konzept, das verwendet wurde, um alles zu beschreiben, was nicht in die damals verfügbaren RDBMS passte. Es könnte an der schieren Menge der Daten gelegen haben oder an der Schwierigkeit, diese in das relationale Modell einer Datenbank zu pressen. Unter diesen Umständen wurde Hadoop erschaffen. Es kam mit dem Hadoop Distributed File System (HDFS) als Speicher und Map-Reduce als Programmiermodell. Die Daten wurden als flache Dateien gespeichert, sodass man nicht an Schlüssel, Attribute, Spalten und Relationen denken musste. Hadoop wurde schnell populär für die Verarbeitung von Daten im großen Maßstab, ohne in teure High-End-Hardware und ebenso teure Datenbanklizenzen investieren zu müssen.

Dies war eindeutig eine alternative Möglichkeit, Daten zu sammeln und sie für Abfragen und Analysen zu verarbeiten. Wenige Jahre später wurde in der Hadoop-Community ein neues Konzept geschaffen, das als „Data Lake“ bezeichnet wurde. Ähnlich wie „Big Data“ hatte es keine (und hat immer noch keine) präzise Definition. Die klassische Beschreibung stammt aus einem Blogartikel von James Dixon, der 2010 veröffentlicht wurde, und ist eher bildhaft als konkret:

Wenn du dir ein Data Mart als Lager von abgefülltem Wasser vorstellst – gereinigt und verpackt und strukturiert für einfachen Konsum – dann ist der Data Lake ein großer Wasserkörper in einem natürlicheren Zustand. Der Inhalt des Data Lakes strömt von einer Quelle in den See, und verschiedene Nutzer des Sees können kommen, um zu untersuchen, hineinzutauchen oder Proben zu entnehmen.

James Dixon

Der Vergleich zwischen einem kleinen Volumen einer Wasserflasche und der riesigen Kapazität eines Sees, mit den scheinbar endlosen Möglichkeiten, ihn zu nutzen, erweckt leicht den Eindruck der Überlegenheit des Data Lakes. Wenn du diesen Eindruck bekommen hast, empfehlen wir dir dringend, den ursprünglichen Artikel zu lesen (er ist kurz und prägnant). Ein wichtiger Punkt ist, dass Dixon auf die Daten verweist, die aus einem einzigen System stammen – daher verwendet er den Begriff „Data Mart“ und nicht „Data Warehouse“.

Tauche in einen See, trinke aus einer Flasche

Ursprünglich war ein Data Lake nicht als einfacher Ersatz für ein Data Warehouse gedacht, das typischerweise Daten aus vielen Quellen integriert. Die Verarbeitung unstrukturierter Daten war ebenfalls nicht der Hauptantrieb – fast alle in der Praxis behandelten Daten waren strukturiert oder semi-strukturiert. Es wurde entwickelt, um Daten zu verarbeiten, die in der damaligen Zeit (noch) nicht in ein RDBMS passten. Wichtiger noch, es wurde entwickelt, um Fragen zu beantworten, die zum Zeitpunkt der Systemgestaltung noch nicht bekannt waren.

Das Ziel, unbekannte Fragen zu beantworten, hat weitreichende Konsequenzen. Man kann nicht einfach eine Auswahl treffen: Diese Daten sind von entscheidender geschäftlicher Bedeutung, jene haben keinen Wert über kurzfristige operative Zwecke hinaus. Diese bewahren wir, die anderen werfen wir weg. Wenn wir die Frage nicht kennen, können wir nicht wissen, welche Daten hilfreich wären, um sie zu beantworten. Also speichern wir alles, nur für den Fall. Auch wenn einige Daten heute nutzlos erscheinen, können sie später jemandem helfen, eine Frage zu beantworten, die morgen auftaucht. Offensichtlich wäre in dieser Situation jeder Versuch der Datenmodellierung zu diesem Zeitpunkt vergeblich. Das Einzige, was man jetzt praktisch tun kann, ist, die Daten so zu speichern, wie sie sind, ohne Vorverarbeitung, Transformation oder Modellierung. Es wird die Verantwortung von jemandem sein, der die Daten irgendwann in der Zukunft für einen bestimmten Zweck nutzt.

Es ist der zweite wesentliche Unterschied zwischen dem Data Warehouse und dem Data Lake. Das Data Warehouse soll (meistens) vordefinierte Fragen zu bekannten Geschäftsprozessen beantworten. Der Hauptzweck eines Data Warehouse ist deskriptive Analyse, die auf einem bekannten Bereich basiert. Dementsprechend werden die Daten modelliert, um die bekannten Geschäftsprozesse zu beschreiben, die sie darstellen. Die Daten sind integriert. Sowohl Integration als auch Modellierung erfordern Vorverarbeitung und Datenumwandlung. Tatsächlich könnte es einem abgefüllten Wasser ähneln – aus der Quelle entnommen, gereinigt und fertig verpackt geliefert. Der Data Lake besitzt keine dieser Merkmale. Er wurde entwickelt, um explorative Analysen zu ermöglichen, die nur durch Fantasie und Verfügbarkeit der Daten begrenzt sind. Er speichert rohe, unverarbeitete Daten. Jede (Vor-)Verarbeitung findet nur als Teil des Analyseprozesses statt.

Eutrophierung des Sees

Das Konzept des Data Lakes fand schnell eine große Popularität. Leider wurde die ursprüngliche Idee kurz nach ihrem Erscheinen verzerrt. Viele Menschen, die enttäuscht von großen, teuren und oft erfolglosen Data-Warehouse-Projekten waren, betrachteten den Data Lake als Ersatz oder Alternative zum Data Warehouse. „Big Data“ war angesagt, „Hadoop“ war angesagt, also war auch der „Data Lake“ angesagt. Das altmodische Data Warehouse war passé, es gab ein neues, schickes Data Warehouse 2.0, genannt „Data Lake“. Das Konzept des Data Lakes wurde schnell vereinfacht und es entstanden Aussagen wie: „Hadoop ersetzt die Rolle von OLAP (Online Analytical Processing) bei der Vorbereitung von Daten, um spezifische Fragen zu beantworten“^[1]. Es wurde zu einer Strategie: „Lass uns alle unsere Daten in Hadoop werfen, es Data Lake nennen und wir werden glücklich bis ans Ende unserer Tage leben“. Nun, nicht ganz…

Mit all dem Hype auf der einen Seite und den häufigen Missverständnissen des gesamten Konzepts auf der anderen Seite ist es kein Wunder, dass Enttäuschungen und Kritik auftauchten. Ein großer Teil der Kritik basierte in der Tat auf falschen Annahmen oder einem Missverständnis der Idee. Der ursprüngliche Autor versuchte, dieser Kritik zu begegnen, insbesondere den Missverständnissen in seinem Beitrag „Data Lakes Revisited“, der bereits 2014 erschien. Er schrieb (wir empfehlen, den gesamten Beitrag zu lesen):

„Ein einzelner Data Lake beherbergt Daten aus einer Quelle. Man kann mehrere Seen haben, aber das ist nicht dasselbe wie ein Data Mart oder ein Data Warehouse.

Ein Data Lake ist kein Data Warehouse, das in Hadoop untergebracht ist. Wenn du Daten aus vielen Systemen speicherst und diese miteinander verbindest, hast du einen Wasser-Garten, keinen Data Lake.“

James Dixon

Aber seine Stimme wurde entweder nicht gehört in dem ganzen Aufruhr um Big Data oder es war bereits zu spät. Die Bedeutung des Begriffs „Data Lake“ hatte sich bereits vom ursprünglichen Konzept entfernt und es gab keinen einfachen Weg zurück. Die Missverständnisse über das Konzept blieben bestehen, ebenso wie die darauf basierende Kritik.

Was einige Leute vom Konzept falsch verstanden, war, dass alle Daten auf Hadoop gespeichert werden sollten und dass dies schon einen Data Lake ausmachte. Der Data Lake wurde als Ersatz für ein Data Warehouse behandelt, obwohl er nie als solcher gedacht war. Es wurden Datenspeicher auf Hadoop gebaut, die mit Hive oder Impala als Datenzugriffs-Schnittstelle als „Data Lake“ bezeichnet wurden. Sie wurden hauptsächlich verwendet, um dieselben vordefinierten Geschäftsfragen zu beantworten, wie es normalerweise ein Data Warehouse tun würde. Das passende Datenmodell fehlte oft ebenso wie die Daten-Governance. Einige müssen angenommen haben, dass wenn die Daten keine vordefinierte Struktur benötigen, auch keine Daten-Governance erforderlich sei. Die Daten wurden „roh“ gespeichert, wie sie aus der Quelle kamen, ohne Vorverarbeitung oder richtige Integration. Offensichtlich lieferten die Systeme, die auf diesen Missverständnissen basierten, meist nicht die erwarteten Ergebnisse. Diese sogenannten „Data Lakes“ verwandelten sich in das, was Kritiker als Data Swamps bezeichneten.

Wo ist jetzt das Wasser?

Heute gibt es immer noch keine einheitliche Definition dessen, was ein Data Lake ist. Und wenn wir uns ansehen, was die populären Definitionen oder Beschreibungen sagen, können wir sehen, wie sehr sich der Data Lake mittlerweile vom ursprünglichen Konzept entfernt hat:

„Ein Data Lake ist ein zentralisiertes Repository, das es Ihnen ermöglicht, alle Ihre strukturierten und unstrukturierten Daten in beliebigem Maßstab zu speichern. Sie können Ihre Daten so speichern, wie sie sind, ohne sie zuerst zu strukturieren, und verschiedene Arten von Analysen durchführen (…).“

Amazon

„Ein Data Lake (wörtlich übersetzt „Datensee“) ist in der Wirtschaftsinformatik ein System oder ein Repository von Daten, die im Rohdatenformat gespeichert sind (…). Ein Data Lake ist in der Regel ein einziger Speicher für alle Unternehmensdaten, einschließlich Rohkopien von Quellsystemdaten und transformierten Daten, die für Aufgaben wie Berichterstellung, Visualisierung, erweiterte Analysen und maschinelles Lernen verwendet werden. Ein Data Lake kann strukturierte Daten (…), oder unstrukturierte Daten (…), und binäre Daten (…) enthalten.“

Wikipedia

„Ein Data Lake ist ein Konzept, das eine Sammlung von Speicherinstanzen verschiedener Datenbestände umfasst. Diese Bestände werden in einer nahezu exakten oder sogar exakt gleichen Kopie des Quellformats gespeichert und ergänzen die ursprünglichen Datenspeicher.“

Gartner

Diese Beschreibungen konzentrieren sich auf mehrere Quellen, viele Zwecke oder Anwendungen, das rohe Format der gespeicherten Daten und die Möglichkeit, semi-strukturierte oder unstrukturierte Daten zu speichern. Wie wir bereits wissen, war die Idee, Daten aus vielen Quellen zu speichern, ursprünglich nicht vorgesehen, und die Möglichkeit, unstrukturierte Daten zu speichern, war auch nicht das Hauptanliegen. Was vom ursprünglichen Konzept geblieben ist, ist, dass die Daten im rohen Format gespeichert werden, wie sie aus ihrer Quelle kommen, ohne Vorverarbeitung oder Aggregationen. Es gibt keine vordefinierte Struktur oder Schema. Die Daten sollen für verschiedene Aufgaben dienen, offenbar auch für (einfache) Analysen und Reporting. Dies stellt eine Veränderung des ursprünglichen Ziels dar, unbeantwortete Fragen zu beantworten, hin zu der Beantwortung aller Fragen, einschließlich der vordefinierten.

Das Rohdaten-Speicherformat, das Fehlen eines vordefinierten Schemas und folglich das Fehlen einer Datenvorverarbeitung sind die wichtigsten Unterschiede zwischen dem Data Lake und dem Data Warehouse.

Und was, wenn wir all diese Vorverarbeitungs-, Datenbereinigungs- und Integrationsschritte nur einmal durchführen? Und dann die sauberen, konformen, strukturierten und vielleicht aggregierten Daten an einem einzigen Ort speichern, die für vertrauenswürdige Analysen und Reporting sofort verfügbar sind? Eine ausgezeichnete Idee! Genau so wird ein Data Warehouse aufgebaut…