Data-Warehouse-Modernisierung

Mit dem Data Lake zu neuen Erkenntnissen

| Autor / Redakteur: Alexander Thume und Jörg Stephan* / Nico Litzel

Exemplarischer Aufbau für das Zusammenwirken von Data Warehouse und Data Lake
Exemplarischer Aufbau für das Zusammenwirken von Data Warehouse und Data Lake (Bild: Oraylis)

Die Modernisierung vorhandener Data-Warehouse-Lösungen (DWH) bietet diverse Ansatzpunkte, angefangen bei der Architektur über die verwendeten Technologien bis hin zu den zugrundeliegenden 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?

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.

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.

Der Data Lake ist kein DWH-Ersatz

Bei Data Lake und DWH handelt es sich also um zwei Komponenten einer unternehmensweiten Analyse-Plattform, die jeweils unterschiedliche Nutzerbedürfnisse adressieren (siehe Grafik). 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.

Indes 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 unterschiedlich 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.

Integration eines Data Lakes

Wie aber ist ein Data Lake sinnvollerweise aufzubauen? Und wie lässt er sich homogen in das bestehende Analyseumfeld integrieren? Herzstück des Data Lakes 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 der bekannten DWH-Konzepte 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 oder unauffindbarer Daten endet.

Zudem benötigt ein Data Lake eine dezidierte Zone, in der Daten vorstrukturiert abgelegt und somit 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 der Abbildung 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 DWHs definiert ist. Auf diese Weise können die Daten auch größeren Anwender-Gruppen, 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 der Abbildung 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 letztlich 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 Lakes entspricht also im Wesentlichen dem Konzept eines DWHs. 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 auch beansprucht hat, was vor allem beim Einsatz von großen Hadoop-Clustern zu erheblichen Kosteneinsparungen führt.

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 sowie einem Treuhandmodell, bei dem ein Tochterunternehmen der Telekom den Zugriff auf die Daten kontrolliert. 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 nutzungsorientierten Kosten zugunsten einer abgeschirmten und isolierte Umgebungen 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 Lakes 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, um aus Massendaten überhaupt neue Erkenntnisse ziehen zu können. Um Matching-Problemen vorzubeugen, kommen die qualitätsgesicherten und konformen Dimensionen des DWHs 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 mithilfe entsprechender Dienste zu definierten Anwendungsfällen abgefragt. Daraus resultieren unmittelbare Aktionen, wie zum Beispiel Warnmeldungen, automatisierte Prozesse oder eine Darstellung in Echtzeitdashboards. Mitunter sollen auch nur bestimmte Events herausgefiltert werden, da eine voll umfängliche Speicherung nicht lohnenswert erscheint. Das brauchbare Datenmaterial wird indes nach der Echtzeitanalyse konsolidiert und im Data Lake bzw. DWH abgelegt. Als qualitätsgesicherte Stammdaten stehen sie dann wiederrum 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. Mithilfe 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.

* Alexander Thume und Jörg Stephan sind Principal Consultants bei Oraylis

Kommentare werden geladen....

Kommentar zu diesem Artikel abgeben

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44936613 / Infrastruktur)