Das Data Lake Konzept: Die Schatzsuche im Datensee geht weiter

Zwei Jahre sind nunmehr seit dem Artikel „Der Schatz im Datensee“ vergangen. Insofern erscheint es an der Zeit, die damals beschriebenen Konzepte und Aussagen im aktuellen Kontext noch einmal zu betrachten und einen Blick auf Trends und neue Entwicklungen zu werfen.

Was sich zumindest aus unserer Erfahrung zunächst bestätigen lässt ist, dass der Data Lake das Data Warehouse nicht verdrängt hat, sondern es in den meisten Fällen eine Koexistenz gibt, da beide Konzepte durchaus unterschiedliche Anwendungsbereiche bedienen. Data Lakes adressieren üblicherweise eher explorative Anwendungsfälle, man kann auch von „Datenforschung“ sprechen. Dabei werden häufig neue Fragestellungen unter Einbeziehung bisher nicht genutzter Daten untersucht, so dass diese von sehr hoher Dynamik geprägt sind.

Der Data Lake Anwender muss kein Programmierprofi mehr sein

Dies führt allerdings zu einigen Herausforderungen. So sind die Anforderungen an den Anwender deutlich höher, oftmals sind sogar Programmier- und Skriptingkenntnisse erforderlich. Um dem zu begegnen ist erfreulicherweise ein Trend zu benutzerfreundlichen Werkzeugen für alle Schritte der Data Lake Wertschöpfungskette vom Laden der Daten bis zum Analysieren erkennbar. Ein Beispiel dafür ist IBM Bluemix Data Connect (siehe Bild 1), ein interaktiver Cloud Service mit dem sich mit Hilfe einer grafischen Oberfläche einfach Daten aus einer Vielzahl von Systemen in Hadoop-Systeme oder Datenbanken laden lassen. Dabei können durchaus auch komplexere Transformationen durchgeführt werden und die Daten so für die Analyse vorbereitet werden, und das ganz ohne Programmierkenntnisse. Grafische Werkzeuge zur Datenaufbereitung gibt es unter dem Namen ETL-Werkzeuge zwar schon lange, diese sind aber meistens eher darauf ausgerichtet, Daten wirklich perfekt aufzubereiten, zu standardisieren und wirklich alle Ausnahmen zu behandeln. Dies erfordert eine Menge Funktionalität, die für die minimale Aufbereitung im Data Lake überflüssig ist und unnötige Komplexität darstellt. Die neuen Werkzeuge stellen eher eine „Lightweight-ETL“ Variante dar, mit einem auf den Anwendungsfall und Benutzer zugeschnittenen Funktionsumfang und ohne nicht notwendigen Ballast.

Bild 1: Data Connect (Bildquelle IBM).

Dynamisch und agil arbeiten und trotzdem den Überblick behalten

Aus dem einfachen Laden ergibt sich allerdings eine andere Herausforderung: Wie behält man eigentlich den Überblick, was sich im Data Lake befindet, und wie findet man die relevanten Daten. Das Stichwort dazu ist damals wie heute Governance. Die eigentliche Herausforderung dabei ist das richtige Maß: ohne irgendeine Art von Governance ist der Data Lake irgendwann eine Sammlung von einzelnen Datenstücken ohne eine Navigation. Legt man hingegen die gleichen Maßstäbe für Governance wie an ein Data Warehouse an, angefangen vom Datenkatalog (idealerweise inklusive Data Stewardship), operativen Metadaten (z.B. wann sind welche Ladeprozesse gelaufen) bis hin zur Verknüpfung von fachlichen und technischen Metadaten, so erscheint die in Data-Lake-Anwendungsfällen gewünschte Dynamik unmöglich erreichbar. Was ist also das richtige Maß an Data Governance?

Nachdem die Beladung im Gegensatz zum Data Warehouse viel fragmentierter ist (es gibt mehr Datenquellen, die teilweise auch nur einmalig geladen werden) und häufig eine Vielzahl verschiedener Werkzeuge eingesetzt werden, ist der Standardisierungsgrad viel niedriger. Dies erfordert in dem meisten Fällen einen unverhältnismäßig hohen Aufwand für eine komplette End-to-End Data Lineage über die komplette Datenwertschöpfungskette vom Laden bis zur Analyse. Daher wird hierauf üblicherweise verzichtet. Was allerdings sehr sinnvoll ist, ist das Anlegen eines Datenkatalogs mit grundsätzlichen Informationen über die Daten wie zum Beispiel deren Herkunft, Ursprungsformat, fachliche Bedeutung etcetera. Dazu gibt es verschiedene Werkzeuge wie Apache Atlas. Eine sehr anschauliche und einfach zu bedienende Lösung für einen Datenkatalog beinhaltet die IBM Data Science Experience, wie in Abbildung 2 dargstellt. Neben den durch den Benutzer erfassten Daten finden dort auch automatische Discovery-Prozesse statt, um zum Beispiel Postleitzahlen, Adressen, Kreditkartennummern etcetera zu erkennen und zu zusätzliche Informationen über die Daten bereitzustellen.

Bild 2: Catalog (Bildquelle IBM).

Noch mehr als nur Hadoop – neue technologische Entwicklungen

Wie schon 2015 dargestellt erstrecken sich Data Lakes durchaus über mehrere Repositories, damals war vor allem von Hadoop und relationalen Technologien die Rede. Die Diversifizierung in diesem Bereich ist in den letzten beiden Jahren eher gestiegen. Beispiele dafür sind Graph-Datenbanken, vor allem aber auch Object Storage und Spark. Gerade letzteres zeigt, dass Hadoop immer mehr Konkurrenz bekommen hat. Die große Idee hinter Hadoop ist, die Daten zu verteilen (HDFS) und die Analysen (via Map Reduce) direkt bei den Daten durchzuführen (also Storage (Speicherung) und Compute (Rechenleistung) zusammenzuführen). Dies ist speziell vorteilhaft, wenn innerhalb einer Analyse sehr große Datenmengen betrachtet werden, da man so das Bewegen eben dieser Daten vermeidet. Allerdings hat die feste Verbindung von Compute und Storage Einschänkungen was flexible Skalierung und Elastizität angeht.

Eine Trennung von Storage und Compute würde zum Beispiel das dynamische Hinzufügen von Rechenkapazität für sehr komplexe Berechnungen ermöglichen. Genau dies adressiert Object Storage. Dieser ist sehr einfach administrierbar und gleichzeitig sehr kostengünstig und skalierbar und ermöglicht das effiziente Speichern auch sehr großer Datenmengen. In Kombination mit Spark (das für die Parallelisierung der Berechnung sorgt) lassen sich damit sehr gut analytische Berechnungen durchführen. Dabei müssen die Daten allerdings in die entsprechenden Spark Compute-Knoten geladen werden und somit bewegt werden, da aber häufig nur kleinere Ausschnitte der Daten betrachtet werden, hat dies oftmals keine negativen Performance-Auswirkungen und wird durch die In-Memory Verarbeitung von Spark überkompensiert. Die Bedeutung dieser Kombination zeigt sich auch daran, dass es mit Stocator ein dediziertes Projekt zur Integration dieser Technologien gibt. Letztendlich hängt es immer vom jeweiligen Anwendungsfall ab, welche Technologie am besten geeignet ist.

Es halt sich also in den letzten beiden Jahren technologisch gesehen einiges getan, mit neuen, interessanten Möglichkeiten. Am Grundkonzept, also einem logischen Data Lake bestehend aus verschiedenen physischen Repositories, die durch entsprechende Governance integriert werden, hat sich nichts verändert. Allerdings hat der Reifegrad der bereitstehenden Werkzeuge die Realisierung und Nutzung des Data Lakes maßgeblich vereinfacht. Abgesehen von der Technologie ist jedoch vor allem interessant, wie und wo Data Lakes in Unternehmen genutzt werden.

Data Lake und Data Labs

Viele der aktuell in Unternehmen bereits umgesetzen oder in der Implementierung befindlichen Big Data- bzw. Data Lake-Projekte nutzten hierfür am Anfang überwiegend strukturierte bzw. relationale Daten aus den jeweiligen operativen Systemen.

Die reine Zusammenführung dieser Daten an zentraler Stelle schafft aber, neben einer ggf. vorhandenen Kostenreduzierung durch günstigere Plattformen wie Hadoop, noch keine Vorteile gegenüber einem klassischen Enterprise Data Warehouse. Der Zugriff auf diese Daten mit den gleichen Methoden und Tools wie im Warehouse ermöglicht nicht tiefere Erkenntnisse über bislang verborgen gebliebene Zusammenhänge zu gewinnen.

Um das im Data Lake schlummernde Potential wirklich zu heben, unterhalten etliche Unternehmen heute sogenannte Data Labs. In diesen Data Labs arbeiten Data Scientists mit profundem Know-how in den Bereichen Mathematik, Statistik, Maschinellem Lernen und im Idealfall tiefem branchen- bzw. unternehmensspezifischem Wissen. Oft bewusst außerhalb etablierter Strukturen angesiedelt, sollen sie mit neuen, explorativen Methoden jenseits traditioneller BI-Ansätze helfen, die Schätze im Datensee zu heben.

Entwicklungen werden hier auf agile Art und Weise ohne jede Denkverbote vorangetrieben. Wenn sich nicht in relativ kurzer Zeit der Mehrwert einer Idee oder eines Analyseansatzes beweisen lässt, wendet man sich dem nächsten Projekt zu.

Moderne Werkzeuge für neue Erkenntnisse

Benötigt werden hierzu Werkzeuge die über klassisches SQL hinausgehen und diesen neuen Ansatz für Analysen optimal unterstützen.

Hier erfreuen sich sogenannte Notebooks einer stetig wachsenden Beliebtheit. Von ersten Anfängen in Paketen wie Mathematica oder Matlab haben sich Notebooks unter anderem über die Python Community im Bereich Data Science etabliert. Beispiele für beliebte Notebooks in diesem Umfeld sind Jupyter (früher iPython) und Zeppelin.

Bild 3: Jupyter Notebook mit Python Code und Visualisierung (Bildquelle IBM).

Diese Notebooks ermöglichen die Programmierung in Python, R, Scala und weiteren Sprachen, die Dokumentation sowie die Visualisierung der Daten und Ergebnisse. Weiterhin ermöglichen sie, die entsprechende Implementierung vorausgesetzt, die Ausführung der Analysen über den Kernel/Backend auf zum Beispiel Spark als Laufzeitumgebung.

Diese Offenheit des Toolings birgt aber auch gewisse Gefahren. Ohne ein stringentes Management von Beginn an führt dieser Ansatz oft zu einer stark fragmentierten Ansammlung von Tools und unterschiedlichsten Versionsständen von Analyse Packages und Libraries innerhalb eines Teams. Dies kann das Zusammenführen von Teilergebnissen einer Analyse sehr stark erschweren.

Tools für ein wirklich professionelles Arbeiten in diesem Bereich erfordern daher einen deutlich umfassenderen Ansatz. Im Idealfall stellt ein Data Science Environment identische, kontrollierte Arbeitsbedingungen für alle Teammitglieder sicher, ohne die kreative Vielfalt einzuschränken. Die Entwicklung läuft innerhalb von Projekten mit klaren Zugriffsrechten und Versionsständen ab. Zusätzlich implementierte oder aktualisierte Packages oder Libraries stehen unmittelbar allen zur Verfügung und ermöglichen so ein gemeinsames Arbeiten am jeweiligen Projekt.

Data Science ist ein Teamsport

Das vielfältige für diese Entwicklungen benötigte Wissen verteilt sich meist auf mehrere Köpfe. Schon allein deshalb ist für Einzelkämpfer im Data Lab kein Platz. Frei nach dem Motto „Das Ganze ist mehr als die Summe seiner Teile“ ist Data Science ein Teamsport bei dem jeder von und an den bereits erzielten Ergebnissen der eigenen Teammitglieder oder auch einer breiteren Community partizipieren können sollte.

Neben dem eigentlichen offenen und erweiterbarem Toolset spielt daher Collaboration (Zusammenarbeit) eine wichtige Rolle. Ergebnisse oder aktuelle Entwicklungsstände müssen, auch in Teilen, einfach innerhalb des Teams, mit dem Fachbereich und ggf. auch ausserhalb (GitHub etc.) geteilt werden können.

Als weitere Herausforderung bei Entwicklungen im Bereich Data Science stellt sich oft die Operationalisierung der fertig entwickelten Analysen dar. Zusätzlich zur Entwicklungsumgebung benötige ich also noch ein Environment wie zum Beispiel einen Spark Cluster auf dem man die Analysen per Scheduler regelmäßig geplant ausführen kann.

Professionelle Umgebungen in diesem Umfeld bringen alle diese Tools und Fähigkeiten zusammen und bieten beste Bedingungen für neue Entwicklungen bei gleichzeitiger Integration mit der bestehenden Systemlandschaft.

Wer sich einen Überblick verschaffen möchte wie eine solche moderne Analyse Umgebung heute aussieht, kann die IBM Data Science Experience in der Cloud für 30 Tage unkompliziert testen. Wenn die Daten das eigene Datacenter nicht verlassen dürfen, gibt es diese Umgebung auch in einer „local“ Variante, welche die Installation on premise ermöglicht.

Matthias Reiss (li.) und Stephan Reimann, IT Specialisten Big Data, IBM