MDWH vs DWH: Wir erklären Ihnen den Unterschied

Das DWH ist tot – es lebe das DWH! Experten haben in den vergangenen Jahren immer wieder das Ende der zentralen Unternehmensdatenbank vorhergesagt. Und tatsächlich sind klassische Data-Warehouse-Lösungen z.B. von den stetig wachsenden Datenmengen und technischen Möglichkeiten zunehmend überfordert. Im Gegenzug ist eine konsolidierte und harmonisierte Datensammlung nach wie vor attraktiv. Mitarbeiter können Abfragen schneller und komfortabler durchführen. Informationen werden organisiert verwaltet, sodass sie für Berichte und Datenanalysen leichter zugänglich sind – Vorteile, auf die Unternehmen auch im Zuge von Internet of Things, Künstliche Intelligenz & Co. nicht verzichten wollen. Daher hat das Data Warehouse nunmehr eine Begriffserweiterung erfahren. Neuerdings hört man immer wieder vom sogenannten Modern Data Warehouse, das alte und neue Datenwelten unter einem Dach vereint. Vor allem Microsoft forciert dieses Konzept.

Aber was ist am Modern Data Warehouse so modern? Wo liegen die Unterschiede zum klassischen Ansatz? Und wie gelingt es, die Vielfalt aller Anforderungen miteinander zu verbinden? Werfen wir einen genaueren Blick auf das neue Allheilmittel der unternehmensweiten Datenanalyse. Dabei schauen wir uns diese Aspekte an:

1. Aufbau eines Modern Data Warehouse
2. Struktur des Data Lakes
3. Anwendungsfälle im Modern Data Warehouse
4. Migration einer alten DWH-Lösung
   

1. Aufbau eines Modern Data Warehouse

Ursprünglich betreiben Unternehmen ein DWH auf lokalen Ressourcen im unternehmenseigenen Rechenzentrum – im Fachjargon „On-Premises“. Speicher und Rechenleistung sind somit in ihren Größen festgelegt. Entsprechend unflexibel zeigen sich diese Systeme bei neuen und vor allem schnell wechselnden Anforderungen. Im Unterschied dazu liegt ein Modern Data Warehouse (MDWH) grundsätzlich in der Cloud – d.h., Sie nehmen die erforderliche Ressourcen und Dienste nach aktuellem Bedarf in Anspruch.

Ein weiterer, gravierender Unterschied betrifft die Datenhaltung. Beim DWH legen Sie die Daten prinzipiell tabellarisch in einem relationalen Datenbankmanagementsystem (RDMS) ab. Dieses Vorgehen eignet sich primär für strukturierte Daten, wie Tabellen aus Zahlen und Buchstaben. Demgegenüber basiert das MDWH auf einem Data Lake Konzept mit verteiltem Dateisystem. Dadurch können Sie beliebige Dateiformate speichern und performant bereitstellen, angefangen bei Textdateien bis hin zu Bildern und Filmen.

Gleichzeitig sind Speicher und Berechnungen beim MDWH voneinander getrennt. So lässt sich der im Vergleich zum RDMS sehr günstige Speicher beliebig skalieren, was speziell im Kontext von Big Data von Vorteil ist. Ebenso können Sie den Data Lake – dank der filebasierten Ablage – auch ohne spezielle Rechenressourcen als Datenquelle nutzbar machen, etwa wenn ein Data Scientist auf bestimmte Textdateien zugreifen möchte.

2. Struktur des Data Lakes

Das Data-Lake-Konzept als solches ist selbstverständlich nicht erst mit dem MDWH entstanden. Bereits seit längerem haben Unternehmen erkannt, dass sich in allen prozessrelevanten Daten Werte verbergen können. Und so wurden auch schon auf lokalen Infrastrukturen zunehmend Sammelbecken für Rohdaten aller Art eingerichtet. Allerdings hat sich das Verhältnis der Kosten für Speicher- und Rechenressourcen durch den Einsatz der Cloud vollständig umgekehrt. Während On-Prem vor allem der Speicherplatz schwer skalierbar ist und hohe Kosten verursacht, schlagen in der Cloud insbesondere die Dienste für Berechnungen zu Buche.

Das hat wiederrum Auswirkungen auf die Data-Lake-Architektur im MDWH. Um langwierige bzw. kostenintensive Berechnungen so weit wie möglich zu umgehen, werden – ähnlich einer klassischen DWH-Architektur – mehrere Schichten zugrunde gelegt. Damit können bereits vorhandene Ergebnisse aus vorangegangenen Operationen zur weiteren Verwendung vorgehalten werden, was umfassend Rechenleistung einspart.

Eine beispielhafte Architektur, die sich in diesem Kontext bewährt hat, besteht aus drei Schichten:

1. Replication Layer: Die Schicht dient als Archiv, das die Quellsysteme entlastet. Quelldaten werden in ihrer Rohform angeliefert und gespeichert. Dabei wird auf Formate gesetzt, die für Menschen lesbar sind, wie z.B. CSV-Dateien. Entsprechend handelt es sich auch um einen guten Anlaufpunkt für die explorativen Analysen von Data Scientists. Massendaten lassen sich indes nur in geringer Geschwindigkeit abfragen.
2. Technology Layer: Auf dieser Ebene werden die Daten technisch transformiert, zusammengefasst und gegebenenfalls historisiert. Sie werden in spaltenbasierten, komprimierten Formaten wie Parquet oder Delta abgelegt, die für Menschen nicht mehr lesbar sind. Dafür ermöglichen sie Abfragen über SQL in hoher Geschwindigkeit. Somit fungiert der Technology Layer z.B. auch als Quelle für schnelle Datenextrakte, etwa wenn Echtzeitdatenströme durch aktuelle Stammdaten angereichert werden sollen.
3. Business Layer: Der Business Layer dient schließlich Fachabteilungen und Analysten für Berichte, Ad-hoc-Abfragen und eigene Analysen. Entsprechend sind die Daten dimensional modelliert und mit einer Business-Logik unterlegt.

Die stringente Anwendung dieses Layer-Konzeptes führt nicht nur zu umfassenden Einsparungen bei den Cloud-Services. Ebenso stellt die Struktur sicher, dass der Data Lake nicht zu einem unübersichtlichen Datensumpf verkommt. Vielmehr entsteht ein geordneter Daten-Hub, der von verschiedenen Anwenderkreisen genutzt werden kann.

3. Anwendungsfälle im Modern Data Warehouse

Entsprechend vielfältig sind dann auch die Use Cases, die sich mit einem MDWH verwirklichen lassen. So kann einerseits die klassische Business Intelligence (BI) mit Standard-Reporting sowie einer 360°-Sicht auf den Kunden und das Geschäft bedient werden. Andererseits lassen sich aber auch brandaktuelle Themen aus den Bereichen Echtzeit und Künstliche Intelligenz mit passenden Cloud-Diensten integrieren. Data Scientists erhalten Zugriff auf die Rohdaten, um neue Muster und Zusammenhänge aufzudecken. Gleichzeitig existiert eine breite Datenbasis, um Fachanwendern neben vormodellierten, fachlichen Cubes auch Self-Service-Modelle nach individuellen Anforderungen im Data Lake bereitzustellen. Nicht zuletzt werden alte Daten, die kaum noch in Gebrauch sind, im Data Lake archiviert, um das RDMS zu entlasten.

4. Migration einer alten DWH-Lösung

Die Migration einer On-Prem-Lösung zum Cloud-MDWH kann nunmehr durch verschiedene Gründe motiviert sein. Ein typisches Szenario ist, dass sich mit dem herkömmlichen DWH die hohen Anforderungen aus dem Big-Data-Bereich nicht mehr bewältigen lassen. Dabei kann es sich um schnell eintreffende Streaming-Daten von Maschinen handeln, umfangreiche Mengen an Log- und Sensordaten oder auch variierende Dateiformate aus ganz unterschiedlichen Quellen.

Mitunter existiert auch schon ein Big-Data-Cluster im lokalen Rechenzentrum. Derlei Lösungen, etwa auf Basis von Hadoop, sind jedoch sehr serviceintensiv und teuer. Daher ist ein Umzug in die Cloud im Regelfall lohnenswert. Gleiches gilt, wenn der limitierte Speicher und die Rechenleistung der Big-Data-Hardware an ihre Grenzen stoßen.

Halten wir zusammenfassend fest: Volatile Märkte und schnell wechselnde Kundenanforderungen verlangen von Ihnen auch eine laufende Anpassung Ihrer Datenlösung. Diese Herausforderungen meistern Sie am besten mit einem MDWH, dass sich auf die Flexibilität der Cloud stützt und Speicher sowie Rechenleistung voneinander trennt. Wenn Sie hierzu mehr erfahren möchten, dann informieren Sie sich weiter auf der Seite Big Data Engineering oder besuchen Sie mein Training zum Microsoft Modern Data Warehouse.

Bei der Microsoft Cloud Konferenz habe ich das MDWH-Konzept sowie verschiedene Einsatzszenarien ausführlich erläutert: