Data Warehouse

Data Warehouse – Definition

Ein Data Warehouse (kurz: DWH) ist eine zentrale Sammlung von Daten in einer zentralen Datenbank. Die Daten werden aus mehreren heterogenen und verteilten Datenquellen, bspw. ERP und FIBU Systemen, zusammengeführt. Im Unterschied zu einem operativen System speichert das Data Warehouse die gesammelten Daten historisch und ist autonom von den Quellsystemen. Ziel ist das ermöglichen von Datenanalysen und betriebswirtschaftlichen Entscheidungshilfen in einem Unternehmen.

Der Erstellung eines DWHs liegen somit zwei Leitgedanken zugrunde:

• Integration von Daten aus verteilten und unterschiedlich strukturierten Datenbestände, mit dem Ziel eine konsistente Sicht auf die Quelldaten und damit Quellsystem übergreifende Auswertungen zu ermöglichen
• Separation der operativ relevanten Geschäftsdaten von solchen Daten, die im DWH für die Zwecke des Berichtswesen, der Entscheidungshilfe, der Geschäftsanalyse und der Unternehmensführung verwendet werden

Data Warehouse – Nutzen

Über den Nutzen bzw. den richtigen Anwendungsfall wird viel diskutiert. Weitgehend Einigkeit besteht darüber, dass die Zusammenfassung, Aggregation und Auswertung von verteilten Unternehmensdaten einen wesentlichen Vorteil eines DWHs beschreibt. In einem Unternehmen entstehen in den verschiedensten Abteilungen Daten, nur der gesamthafte Blick auf diese Informationen ermöglicht eine datengetriebene Entscheidungsunterstützung. Wichtig hierbei ist, dass ein bestehendes Data Warehouse unternehmensweit als Instrument verstanden und genutzt wird.
Wollen Sie in Ihrem Unternehmen Prognosesysteme einsetzen, beispielsweise um zu prognostizieren wie hoch der Abverkauf eines bestimmten Artikels in den nächsten Tagen oder Wochen sein wird, so stellt ein DWH die notwendige historische Datenbasis zur Verfügung.

Data Warehouse – Extrahieren, Transformieren und Laden

Wie kommen jetzt die verteilten Daten aus den Quellsystemen in ein Data Warehouse. Dies geschieht im Rahmen von ETL-Prozessen (Extraktion-Transformation-Laden). Dabei werden die Daten aus dem Quellsystem extrahiert, durch Transformation bereinigt und vereinheitlicht um danach geladen zu werden. Dieser ETL-Prozess läuft üblicherweise in regelmäßigen Zeitabständen ab. Vor einigen Jahren liefen diese Prozesse meist einmal täglich in der Nacht (sogenannte Batch-Läufe). Mittlerweile entwickelt sich der Trend hin zu Echtzeitbeladungen, d.h. sobald neue Daten in einem Quellsystem „entstehen“ lädt der ETL Prozess diese in das DWH.

Der gesamte Prozess wird auch als Data Warehousing bezeichnet, welcher folgende Aspekte enthält:

• Datenbeschaffung, Integration und Weiterverarbeitung im Rahmen eines ETL-Prozesses
• Datenhaltung, das heißt die langfristige Speicherung der Daten im Data Warehouse
• Auswertung und Analyse der gespeicherten Daten
• Versorgung und Aufbereitung der für die Analysen notwendigen Datenbestände (Stichwort Data Marts)

Data Warehouse – Modellierung

Das Data Warehouse speichert die heterogenen Daten der Quellsysteme zentral und harmonisiert ab. Für diese Anforderung gibt es verschiedene Möglichkeiten der Datenmodellierung. Wir wollen hier nicht ins Detail gehen, da es im Internet ausreichende Informationen gibt. Folgende Datenmodelle haben sich in den Jahren als Standard etabliert:
– Dimensional Model nach Kimball (u.a. https://de.wikipedia.org/wiki/Sternschema)
– Dritte Normalform nach Inmon (u.a. https://www.computerweekly.com/tip/Inmon-or-Kimball-Which-approach-is-suitable-for-your-data-warehouse)
– Data Vault (2.0) nach Dan Linstedt (u.a. https://www.derdatenarchitekt.de/blog/2017/08/18/data-vault-eine-einfuehrung/)

Insbesondere die Modellierungen nach Kimball und Inmon haben in der Vergangenheit gezeigt, dass diese relativ hohe Erweiterungs- und Wartungskosten mit sich bringen. Die Anforderungen an ein modernes DWH ändern sich häufig, daher ist eine schnelle und kostengünstige Erweiterung zwingend notwendig. Der Data Vault Ansatz nach Dan Linstedt verspricht diese flexible Anpassung (https://danlinstedt.com/allposts/datavaultcat/a-short-intro-to-datavault-2-0/) zu geringen Kosten. Aus unserer Projekterfahrung heraus können wir das bestätigen, jedoch gilt es für diese Flexibilität Vorbereitungen in der Data Warehouse Architektur zu treffen.

Nachteile klassischer Data Warehouse Entwicklung

Klassische Data Warehouse Lösungen stoßen häufig an ihre Grenzen bezüglich flexibler und zeitkritischer Business-Anforderungen. Die typischen ETL-Entwicklungsschritte in grafischen ETL Tools wie beispielsweise ODI, Talend oder IBM Datastage nehmen viel Zeit in Anspruch und können nur mit erhöhten Aufwand das Datenmodell aktuell halten. Im Laufe der Zeit entstehen für das Data Warehouse viele einzelne ETL Jobs, was unweigerlich einen höheren Wartungsaufwand nach sich zieht. Zusätzlich reichen nicht immer die vorhandenen Komponenten des ETL Tools aus. In solchen Fällen kommen eigen entwickelte Skripte (beispielsweise Bash oder Java) zum Einsatz. Diese Skripte sind über Komponenten in den ETL Jobs eingebunden. Der postulierte Vorteil der grafischen ETL-Tools den Ladeprozess optisch einfach nachvollziehen zu können, geht damit zumindest teilweise verloren.

Data Warehouse Automation

Definition

In der klassischen Entwicklung eines DWH werden viele Werkzeuge eingesetzt: Modellierungs-, ETL-, Deployment-, Workflow-, Datenqualitäts-, Monitoring- sowie Analysewerkzeuge, teilweise sogar mehrere der gleichen Art parallel.
Jedes Werkzeug bringt dabei seine Eigenheit mit. Es fehlt somit an übergreifenden Standards genauso wie an konsolidierter Dokumentation. Der Data Warehouse Automation Ansatz stellt hier eine echte Alternative dar.
Im Zentrum der Data Warehouse Automatisierung (kurz: DWA) steht die Standardisierung über alle Artefakte, die in einem DWH-Projekt relevant sind. Wir kennen diesen Ansatz schon aus der Software-Entwicklung bei den sogenannten „Design Pattern„. Aus der Projekterfahrung heraus ist zu erkennen, dass sich bei der DWH-Entwicklung immer wieder die selben Aufgaben ergeben. Durch die angestrebte Standardisierung muss das Rad nicht immer wieder neu erfunden werden. Dies verkürzt Entwicklungszeit und stellt hohe Qualität und Performance sicher. Außerdem bleibt so mehr Zeit sich auf die individuellen fachlichen Anforderungen in einem Projekt zu konzentrieren.

Herausforderungen

Wo Licht da ist auch Schatten. Neben dem beschriebenen Vorteilen einer DWA gibt es auch gewisse „Nachteile“ oder Herausforderungen. So gibt es derzeit wenig „fertige“ Software auf dem Markt, zu nennen ist Wherescape, biGENiUs und TimeXtender. Für diese Anwendungen fehlt teilweise eine aussagekräftige Projekthistorie und/oder Support bei bestimmten Themen (u.a. Business Vault Generierung für den Data Vault Approach). Weiterhin stellen die Lizenz-, Support- und Beratungskosten insbesondere für KMUs eine große Hürde dar. Immer mehr auch kleine Unternehmen haben Bedarf an flexiblen DWH Lösungen.

Entscheidet man sich für eine Eigenentwicklung sind die initialen Ramp-Up Kosten und Aufwände nicht zu unterschätzen. Es brauch einiges an Erfahrung und Zeit bis die DWA Applikation soweit ist, dass Data Warehouse generisch mit Quelldaten zu beladen.
Allgemein gilt für die Data Warehouse Automation das gleiche wie für viele IT-Projekte: es ist sehr schwer notwendiges Knowhow zu bekommen.

Data Warehouse Automation – Konkrete Projektbeispiele von DER DATEN ARCHITEKT

Neben der grauen Theorie folgt nur ein Auszug aus unserer Projekthistorie zu dem Thema Data Warehouse Automation.

Entwicklung einer DSL und SQL Generatoren

Auf Basis von Xtext wurde eine Domain-specific-language (DSL) entwickelt. Diese ermöglichte dem Datenmodellierer einfach das Datenmodell zu beschreiben. Die Generierung der notwendigen SQL Artefakte (Tabellenstrukturen, Beladeprozeduren etc.) basiert auf diesen Modellen.

Beispielhafter Auszug aus der DSL (Xtext Syntax)
Hub:
"hub" name=ID
documentation=Documentation
"businesskeys" bks+=Attribute ("," bks+=Attribute)*
("hubsatellites" "{" (hubsatellites+=hSatellite)+ "}" )?

Beispielhafter Auszug aus der Modellbeschreibung eines Hubs
hub person_h doc("This is the hub for person related BK")
businesskeys PERSON_ID
hubsatellites { … }

Als Input ist „nur“ die oben skizzierte Modellbeschreibung notwendig. Auf Basis der zur Verfügung gestellten Metainformationen (wie der Name des Hubs), werden die notwendigen Datenbank-Artefakte (Create Table, Insert Into) erstellt. Stellt man also während der Modellierung fest, dass der Business Key (Data Vault Approach) ein anderer ist, muss nur die Modellbeschreibung geändert werden. Die notwendigen Artefakte werden daraufhin automatisch neu generiert und können deployed werden. Die umfangreiche Integration von Xtext in die eclipse Entwicklungsumgebung ermöglicht hier eine sehr gute Unterstützung für den Modellierer. Neben Syntax-Highlighting kann beispielsweise schnell zwischen abhängigen Modellelementen gesprungen werden.
Die Definition der DSL erfolgt in enger Absprache mit den Anwendern (hier: Modellierer). Ziel ist eine möglichst einfache und intuitive Beschreibung des Modells.

Entwicklung eines Data Lake + Core DWH auf Basis Cloudera

In diesen Big Data Projekt entwickelten wir mit Hilfe von Scala und Apache Spark ein ETL Framework, das auf Basis der zugeführten Metainformationen Quelldaten bis in die Auswerteschicht transformiert und lädt. Ziel war die fachliche Trennung der Modellierung von der Beladung(slogik). Im Wesentlichen beschrieb ein Source-To-Target Mapping die Metainformationen. Dieses Mapping wurde aus einem grafischen Modellierungstool heraus generiert und dem ETL Framework per CSV zugeführt. Mit diesen Informationen war das ETL Framework in der Lage die Quelldaten zu laden. Die Beladung erfolgte in den Data Lake (Basis Hadoop/HDFS und Hive) und von dort in den Raw Data Vault (Hive) und Business Data Vault (Hive Views). Um die Daten für Tableau auswertbar zu machen, wurden die notwendigen Informationen nach Exasol in das Zielschema (dimensionales Modell) übertragen. Die komplette Transformationslogik und die eigentliche, technische Datenbeladung erfolgte über das ETL Framework. Die Datenmodellierung konnte sich ausschließlich auf die fachliche Modellierung der Geschäftsobjekte konzentrieren.

Trends im Data Warehouse Umfeld

Zu dem bereits beschriebenen Trend der Data Warehouse Automatisierung gibt es auch immer mehr die Bestrebung das DWH in die Cloud auszulagern. Neben den Bedenken der Datensicherheit kristallisiert sich immer mehr der Wunsch heraus das Data Warehouse flexibel skalieren zu können. Anbieter wie Snowflake gehen dabei vollständig den Weg eines Cloud Data Warehouse. Die Zukunft wird zeigen inwieweit sich der Cloud-Ansatz für Data Warehouse in Deutschland durchsetzt. Gerade für KMUs stellt dies aber eine einfache und flexible Möglichkeit dar ein DWH ohne teure Hardwareanschaffungen aufzubauen.
Data DevOps oder auch DataOps ist ein weiterer, sehr junger Trend im Data Warehouse Umfeld. Insbesondere Big Data Projekte verlangen speziellen Strategien und Werkzeuge im Operations/Betrieb Umfeld. Auch hier wird sich zeigen, ob dieser Trend anhält.

Zusammenfassung

Data Warehouse ist kein neues, hippes Phänomen sondern begleitet uns schon viele Jahre. Die täglich steigenden Datenmengen, der Wettbwerbsdruck und die notwendigen Innovationen erfordern, dass wir im DWH Context mit der Zeit gehen. Neben einer hohen Qualität sind Performance und Time-To-Market wesentliche Faktoren an dem ein DWH gemessen wird. Insbesondere die Data Warehouse Automatisierung eröffnet viele Möglichkeiten sich wieder mehr auf die fachlichen Anforderungen zu fokussieren.