Mit dem Data Lake zu neuen Erkenntnissen
Aspekte der DWH-Modernisierung
von Alexander Thume und Jörg Stephan
Die Modernisierung vorhandener Data-Warehouse-(DWH-)Lösungen bietet diverse Ansatzpunkte, angefangen bei der Architektur über die verwendeten Technologien bis hin zu den zugrunde liegenden Prozessen. Eine Kernkomponente bildet dabei der unternehmensweite Data Lake. Er ermöglicht es, die ganz unterschiedlich strukturierten Big Data nutzbar zu machen und kombiniert auszuwerten. Wie aber lässt sich ein Data Lake homogen in das bestehende Umfeld integrieren? Und welche Rolle nimmt er gegenüber dem etablierten DWH ein? In diesem Artikel werden die Einsatzmöglichkeiten von Data-Lake-Konzepten ebenso beleuchtet wie die Implementierung der entsprechenden Technologien. Darüber hinaus wird auf die Verwendung von Sandbox-Modellen als Testumgebung für Big-Data-Szenarien sowie den Umgang mit Echtzeitdaten eingegangen.
Die IT-Abteilungen stehen vor einem Dilemma: Aufgrund mangelnder Flexibilität und Agilität entwickeln Fachbereiche zunehmend eigene Analyselösungen vorbei am etablierten DWH. Dabei kommen oftmals neue Technologien zum Einsatz, wie etwa Self-Service-Werkzeuge oder Hadoop. In der Folge geht dem Unternehmen nicht nur der sogenannte Single Point of Truth verloren. Vielfältige Potenziale der bereichsübergreifenden Vernetzung bleiben ungenutzt. Und was ganz entscheidend ist: Irgendwann sind die Fachabteilungen mit dem Management ihrer Lösung überfordert. Die IT kann an diesem Punkt kaum mehr unterstützen, da die genutzten Technologien nicht in die vorhandene DWH-Umgebung passen [GaL17].
Daher ist ein entscheidender Aspekt bei der DWH-Modernisierung die „Zentralisierung“ – sprich: Bestehende Insellösungen aus den einzelnen Fachbereichen werden auf einer Analyseplattform zusammengeführt. Ein Kernelement bildet dabei der unternehmensweite Data Lake. Er fungiert einerseits als Sammelbecken für unterschiedlichste Rohdaten, andererseits bildet er den Ausgangspunkt für explorative Analysen. Somit erweitert der Data Lake die bestehende Umgebung um jene Fähigkeiten, derer es beim Umgang mit Big Data bedarf, wie etwa die drei „Vs“ – Volume, Variety und Velocity. Daher ist er auch nicht als DWH in neuem Gewand zu betrachten, sondern vielmehr als wichtige Ergänzung.
Data Lake ist kein DWH-Ersatz
Bei Data Lake und DWH handelt es sich also um zwei Komponenten einer unternehmensweiten Analyseplattform, die jeweils unterschiedliche Nutzerbedürfnisse adressieren (Abbildung 1). Das traditionelle DWH legt den Fokus auf eine hohe Prozesseffizienz im Kontext interaktiver Self-Service-Analysen und Berichte, wobei die Informationen relativ passgenau für die Anwender aufbereitet werden. Entsprechend gehen hier strukturierte Daten, beispielsweise aus ERP und CRM, in eine bewährte Schichtenarchitektur aus Replication Layer, Technical Layer und Business Layer ein.
Allerdings lässt sich die Heterogenität von Big Data über diese Prozesse und Methoden nur schwerlich abbilden. Zwar handelt es sich im Regelfall nicht um gänzlich neue Formate. Schließlich speichern und verarbeiten wir bereits seit Jahren Daten aus E-Mails, Web-Anwendungen, PDFs, Social Media oder Sensoren über das Internet of Things (IoT). Jedoch lassen sich diese Quellen nicht ohne Weiteres mit traditionellen Daten mischen und gemeinsam auswerten.
Dies ist insbesondere auf den hohen Aufwand bei der Datenintegration zurückzuführen, die einer kurzfristigen und agilen Umsetzung neuer Anforderungen entgegensteht. Zudem lassen sich manche der Daten nur schwer in die klassischen, relationalen Strukturen überführen.
Hier greift das Data-Lake-Konzept: Daten aus ganz unterschiedlichen Quellen werden unmittelbar in ihrer Ursprungsform abgelegt. Im Weiteren lassen sich strukturierte wie unstrukturierte Daten schnell und einfach für die Analyse nutzbar machen sowie beliebig verknüpfen. Folglich können Data Scientists und Fachanwender kreativ mit den Daten arbeiten und neue Zusammenhänge jenseits des standardisierten Reportings erschließen. Dieses explorative Vorgehen kommt vor allem dann zum Einsatz, wenn sich der Wert von Datenbeständen im Vorhinein nicht genau einschätzen lässt [OBr15].
Integration eines Data Lake
Wie aber ist ein Data Lake sinnvollerweise aufzubauen? Und wie lässt er sich homogen in das bestehende Analyseumfeld integrieren? Herzstück des Data Lake ist üblicherweise Hadoop. Das Open Source Framework kann beliebige Datenarten in großen Mengen verarbeiten, wobei die Berechnungen auf verschiedene Knoten eines Rechnerverbundes verteilt werden. Infolgedessen können Rohdaten sehr effektiv in ihrer Ursprungsform gespeichert und analysiert werden.
Auf dieser technologischen Basis gilt es zunächst einen Bereich einzurichten, in dem die unstrukturierten Daten lediglich gespeichert werden. In diesem Kontext verschafft eine Metadatenschicht den erforderlichen Überblick und hilft bei der Suche nach den gewünschten Quellen. Sie umfasst technische und operative wie auch geschäftsrelevante Information. Im besten Fall werden die Metadaten bereits bei der Beladung automatisch generiert.
Entsprechend den bekannten DWH-Konzepten werden die Daten in identifizierbaren „Eigentümer“-Gruppen oder logischen Zonen organisiert, wie zum Beispiel einer „Raw Data Area“ oder „Staging Area“. Auf diese Weise wird auch eine Data Governance aufgebaut, die verhindert, dass der Data Lake als gigantische Ansammlung unbrauchbarer bzw. unauffindbarer Daten endet.
Zudem benötigt ein Data Lake eine dezidierte Zone, in der Daten vorstrukturiert abgelegt werden, damit sie für spätere Auswertungen verwendet werden können. Beispielsweise greift auch der Data Scientist immer wieder auf Stammdaten und konforme Dimensionen zurück, um diese in seine freien Analysen einzubeziehen und etwaigen Erkenntnissen die notwendige Aussagekraft zu verleihen. In Abbildung 1 ist der vorstrukturierte Teil durch die Überlappung zwischen Data Lake und DWH dargestellt.
Beim Einrichten bieten sich verschiedene Vorgehensweisen an: Zum einen können Stammdaten generell im DWH gespeichert werden. So hat der Data Scientist etwa bei der Analyse von IoT-Sensordaten die Möglichkeit, konkrete Aussagen zu Standorten oder Bezeichnungen der jeweiligen Geräte zu treffen. Zum anderen lassen sich die Stammdaten im Data Lake ablegen, wobei dieser Bereich als Bestandteil des DWH definiert ist. Auf diese Weise können die Daten auch für größere Anwendergruppen, zum Beispiel im Rahmen des Standard-Reportings, bereitgestellt werden.
Innovativ ist an diesem Lösungsansatz, dass ein direkter Zugriff aus dem DWH in den Data Lake – oder umgekehrt – ermöglicht wird. Somit sind die in Abbildung 1 gezeigten Grenzen nur konzeptionell zu verstehen. Und: Ob die gewonnenen Erkenntnisse über zusätzliche Hive-Modelle oder andere Technologien bereitgestellt werden, ist letztendlich unerheblich.
Welches Vorgehen jeweils zum Einsatz kommt, hängt von unterschiedlichen Faktoren ab. Hierzu zählen unter anderem Fragen der Data Governance: Wer ist Eigentümer der Daten? Welche Engineer-Prozesse liefern die Daten? Wie oft werden die Daten in welchen Auswertungen verwendet? Ebenso spielen aber auch die vorhandenen Technologien eine Rolle. Ein DWH im Data Lake ist per se ausgeschlossen, wenn keine Abfrage-Schnittstelle vorhanden ist, die einen direkten Zugriff ermöglicht. Gleiches gilt, wenn der Entwickler nicht über das erforderliche Big-Data- bzw. Technologie-Know-how verfügt.
Einsatz von Cloud-Technologien
Der aufbereitete Teil des Data Lake entspricht also im Wesentlichen dem Konzept eines DWH. Jedoch besteht dadurch die Gefahr, dass die gewonnene Flexibilität und Agilität gleich wieder verloren geht. „On Premise“-Lösungen lassen sich im Big-Data-Kontext kaum noch effizient realisieren. Die stetig wachsenden Anforderungen führen meist dazu, dass die Systeme immer komplexer und kostenintensiver werden. Ein stabiler Betrieb ist nur durch einen hohen administrativen Aufwand zu gewährleisten.
Um dem entgegenzuwirken, bieten sich Cloud- Technologien für die Umsetzung an. Die erforderlichen Ressourcen stehen innerhalb weniger Minuten zur Verfügung. Speicher- und Rechenkapazitäten – bzw. „Storage“ und „Compute“ – können unabhängig voneinander skaliert werden. Nach der Verwendung spezifischer Dienste werden diese einfach wieder abgeschaltet. Der Nutzer bezahlt nur das, was er tatsächlich beansprucht hat – was vor allem beim Einsatz großer Hadoop-Cluster zu erheblichen Kosteneinsparungen führt [She15].
Allerdings sollte der Einsatz von Cloud-Ressourcen einer klar definierten Strategie folgen. Dabei geht es nicht nur darum, Vorgehensweisen und Einsatzgebiete festzulegen. Ebenso ist die Auswahl des Anbieters von Relevanz, um für vertrauliche Unternehmensdaten entsprechend hohe Sicherheitsstandards gewährleisten zu können. Ein etablierter Cloud-Provider wie beispielsweise Microsoft begegnet der Sicherheitsdiskussion mit deutschen Rechenzentren und Treuhandmodellen.
Einige Anbieter stellen entsprechende Architekturen auch als „Private Cloud“ zur Verfügung. Infolgedessen können sich Unternehmen eine Cloud im eigenen Rechenzentrum aufbauen. Jedoch gehen die Vorteile hinsichtlich der Skalierung und der nutzungsorientierten Kosten zugunsten einer abgeschirmten und isolierten Umgebung verloren.
Experimente in der Sandbox
Ein wichtiges Einsatzgebiet der Cloud-Dienste bildet das sogenannte Sandboxing. Prinzipiell handelt es sich um eine Methode, mit der Software in einer separaten Umgebung getestet werden kann, ohne laufende Prozesse zu behindern. Im Kontext des Data Lake bedeutet das: Der Data Scientist erhält für seine Analysetätigkeiten ein autarkes Experimentierfeld. Nach Bedarf kann er ganze Hadoop-Cluster mit beliebig vielen Servern in Anspruch nehmen. Andere Anwender, Programme oder Systeme bleiben von seinen Aktivitäten unberührt. Zudem entsteht der IT keinerlei Aufwand für die Installation, Konfiguration und Wartung der Infrastruktur. Entsprechend ist das Kostenrisiko verhältnismäßig gering, falls aus den explorativen Analysen kein konkreter Nutzen resultieren sollte.
Währenddessen gehen gewinnbringende Erkenntnisse in die DWH-Umgebung ein – sprich: Sie werden operationalisiert und in das Standard- Reporting überführt. Hier wird erneut deutlich, dass das Data-Lake-Umfeld durch sauber aufbereitete Stammdaten anzureichern ist, damit aus Massendaten überhaupt neue Erkenntnisse gezogen werden können. Um Matching-Problemen vorzubeugen, kommen die qualitätsgesicherten und konformen Dimensionen des DWH zum Einsatz.
Umgang mit Echtzeitdaten
Im Zuge des Internet of Things zählt auch die Nutzung von Echtzeitdaten zunehmend zu den typischen Anforderungen an eine unternehmensweite Analyseplattform. Dabei werden die eingehenden Datenströme bereits vor der Speicherung mit Hilfe entsprechender Dienste zu definierten Anwendungsfällen abgefragt. Daraus resultieren unmittelbare Aktionen, wie zum Beispiel Warnmeldungen, automatisierte Prozesse oder eine Darstellung in Echtzeit-Dashboards.
Mitunter sollen auch nur bestimmte Events herausgefiltert werden, da eine voll umfängliche Speicherung nicht lohnenswert erscheint. Das brauchbare Datenmaterial wird dabei nach der Echtzeitanalyse konsolidiert und im Data Lake bzw. DWH abgelegt. Als qualitätsgesicherte Stammdaten steht es dann wiederum für die Anreicherung von Echtzeit- oder explorativen Analysen wie auch das Standard-Reporting zur Verfügung.
Fazit
Der Data Lake ist eine entscheidende Komponente im Rahmen der DWH-Modernisierung. Er fungiert nicht nur als kostengünstiges Speichermedium für Big Data. Vielmehr eröffnet er die Möglichkeit, strukturierte wie unstrukturierte Daten schnell und einfach für kombinierte Analysen nutzbar zu machen. Insofern kann der Data Lake das etablierte DWH durch viele neue Erkenntnisse bereichern.
Allerdings ist er kein adäquater Ersatz. Denn: Ohne konsolidierte Stammdaten stoßen freie Analysen auf Rohdaten schnell an ihre Grenzen. Mit Hilfe von Cloud-Technologien lässt sich ein Data Lake in kürzester Zeit in das vorhandene DWH-Umfeld integrieren. Ebenso können auf diesem Weg flexibel und preiswert Testumgebungen bzw. Sandboxes für die explorativen Analysen der Data Scientists eingerichtet werden. Letztlich hat aber auch beim Data Lake Bestand, was für Maßnahmen der DWH-Modernisierung im Allgemeinen gilt: Die Projekte scheitern in den seltensten Fällen an der Technologie. Ausschlaggebend ist vor allem der Faktor Mensch. Seine Akzeptanz und Aktivität erwecken eine neue Lösung erst zum Leben.
Infolgedessen erfordert die Implementierung neuer DWH-Komponenten eine enge Abstimmung mit den Nutzern – und das frühestmöglich im Rahmen der Planung und Entwicklung. Auf diese Weise wird sichergestellt, dass die Technologien den Anwendern tatsächlich den gewünschten Mehrwert bringen. Gleichzeitig sollten diese Vorgehensweisen lediglich Bestandteil eines umfassenden Kulturwandels hin zur datengetriebenen Organisation sein. Dabei sind insbesondere die höheren Managementebenen gefordert, für entsprechende Strukturen, Prozesse und Ressourcen zu sorgen.
Literatur
GaL17] Gadatsch, A. / Landrock H.: Big Data für Entscheider – Entwicklung und Umsetzung datengetriebener Geschäftsmodelle. Springer-Vieweg 2017
[OBr15] O’Brien, J.: The Definitive Guide to the Data Lake. 2015
[She15] Sheldon, R.: Azure Data Lakes. 2015, www.simple-talk.com/cloud/cloud-data/azure-data-lakes, abgerufen am 10.7.2017
Alexander Thume
