Diskussionen um die neuesten Data-Warehouse-(DWH-)Konzepte, -Architekturen und -Vorgehensmodelle zu modernen DWH-Systemen sowie allgegenwärtige Umfragen, welche Methoden und Technologien wie häufig eingesetzt werden, neigen oft dazu, die gewünschte Zukunft als Gegenwart darzustellen. Am Anfang sollte darum ein ganz pragmatischer und durchaus subjektiver Blick auf den Zustand der vielen lebendigen und höchst produktiven Data Warehouses stehen, wie sie heute in Unternehmen und Behörden weit verbreitet sind. Als Berater und DWH-Entwickler lernt man solche DWHs in Projekten oder in Vorträgen und Gesprächen auf Konferenzen kennen und staunt dabei über geradezu geniale Lösungen ebenso wie über weitverbreitete Schwächen.
DWH - mehr als nur eine Sammelstelle für Auswertungen
Daten aus Kundenpflege, Buchhaltung oder Rechnungswesen werden täglich oder wöchentlich aus den operativen Datenbanken entnommen und sauber in einer separaten, auf Abfragegeschwindigkeit optimierten Datenbank zusammengefügt. Dieses Vorgehen entlastet andere Anwendungen von ressourcenintensiven Abfragen und erlaubt schnelle, systemübergreifende Auswertungen neuer und historischer Datenbestände.
Der Aufbau eines klassischen Data Warehouse: In den vergangenen zweieinhalb Jahrzehnten haben sich Strukturen und Prozesse für Data Warehouses etabliert, die sich als effektiv und nachhaltig erwiesen haben. Eine Vorgehensweise ist zum Beispiel die Trennung der Datenstrukturen und Verarbeitungsprozesse über drei bis vier Ebenen, in denen die notwendigen Transformationen und Qualitätssicherungsmaßnahmen nach und nach durchgeführt werden. Damit wird die Komplexität auf viele einfache Schritte reduziert und eine Identifizierung und Behebung möglicher Fehler deutlich erleichtert.
Foto: Trivadis
Datenextraktion und Ladevorgang - Staging Area: Die Extraktion relevanter Daten aus den Quellsystemen realisiert das Quellsystem häufig selbst und stellt sie anschließend dem DWH als Dateien oder über direkte Datenbankverbindungen zur Verfügung. Alternativ werden ausgeklügelte Change-Data-Capture (CDC) Verfahren eingesetzt, die zielgenau die Änderungen des Quellsystems in das DWH replizieren.
Die Daten werden anschließend 1:1 in einer Art Laderampe des DWH, der so genannten Staging-Area abgelegt und wenig später weiterverarbeitet. Ganz wie auf der realen Laderampe eines Ladengeschäftes geht es nicht darum, möglichst alle Probleme mit der Qualität gleich bei der Ankunft zu erkennen, sondern lediglich um die Prüfung der Vollständigkeit und Erkennung besonders offensichtlicher Fehler wie zum Beispiel sehr deutlich sichtbarer Schäden - im Falle der Daten beispielweise falscher Lieferformate. Ein anderes wichtiges Ziel ist dabei die Vorbereitung für eine möglichst effiziente und performante Weiterverarbeitung.
Die Struktur der Laderampe entspricht in etwa der des liefernden Quellsystems. Die Daten der unterschiedlichen Quellen werden auch nicht gleich integriert und auch die Konsistenz zwischen den verschiedenen Daten wird noch nicht gesichert. Oft erfolgt noch nicht einmal eine Prüfung der Datentypen, da zunächst alle Informationen in Textfelder geladen werden.
Die Qualitätssicherung - Cleansing Area: Eine detaillierte Prüfung der Daten, das so genannte Cleansing, wird je nach Komplexität der Prozesse gerne auch gemeinsam mit der nächsten Phase, der Transformation, durchgeführt. Hier werden Datentypen und teilweise auch Inhalte und Zusammenhänge evaluiert. Dabei werden die fehlerhaften Daten herausgefiltert und bei Bedarf mit Standardwerten ergänzt. Beispielsweise können unbekannte - und damit vermutlich fehlerhafte - Rechnungsstati auf "unbekannt" gesetzt werden. Eine weitere wesentliche Eigenheit der Cleansing-Area: Die Daten aus den unterschiedlichen Quellsystemen werden hier in einheitliche Strukturen zusammengeführt, also integriert. Entsprechend ähnelt das Datenmodell der Cleansing-Area stark dem Zielmodell des DWH - und weniger den einzelnen Quellsystemen.
Das Core-DWH: Im "Kern" des Data Warehouses werden die Daten aus den unterschiedlichen Quellsystemen schließlich zentral integriert. Dabei wird nicht selten die gesamte Historie der Daten beibehalten. Nicht nur Rechnungen und Rechnungspositionen sind somit über viele Jahre verfügbar. Auch geänderte Kundenadressen, längst ungültige Produktkategorien oder frühere Regionsverantwortlichkeiten von Vertriebsmitarbeitern sind jederzeit nachvollziehbar und vergleichbar. Das Core-DWH ist der Single-Point-of-Truth (SPOT), gerne auch "Single Point Of Trust" genannt - denn mit der Wahrheit ist das bekanntlich so eine Sache.
Meist einigen sich IT und Fachbereich darauf, dass hier steht, was der Wahrheit am nächsten kommt. Denn oft ist nicht die Zeit, widersprüchliche Daten aus unterschiedlichen Quellsystemen sauber abzugleichen. Daher werden an dieser Stelle häufig pragmatische Annahmen getroffen und Daten gezielt angepasst. Wesentlich ist aber eine vollständige Dokumentation der Nachvollziehbarkeit dieser Änderungen. Schließlich sollte man nachweisen können, warum derselbe Bericht auf dem DWH und auf dem Quellsystem nicht exakt dieselben Ergebnisse liefert.
Dieses Vorgehen ist übrigens keine Ausnahme, sondern die Regel. Denken Sie an einen Bericht zum Umsatz vom vergangenen Jahr aufgeteilt nach dem Wohnort der Kunden. In einem operativen Rechnungssystem ohne vollständige Historie der Kundendaten kann eine fehlerhafte Eingabe der Postleitzahl eine Woche später längst wieder korrigiert sein. Und da es ja eine Fehleingabe war, würde es auch nicht als früherer Wohnort geführt. Der Bericht sähe also vor der Korrektur der Kundendaten anders aus als danach. Im Data Warehouse, das täglich mit Daten beliefert wird und für die Kunden jede Änderung protokolliert, sieht es aber anders aus. Hier ist der Kunde für die Zeit vor der Korrektur immer noch einer anderen Postleitzahl zugeordnet. Damit gibt es Abweichungen in den Teilsummen des Berichts in Abhängigkeit der verwendeten Version der Kundendaten. Zu entscheiden, welche Summe nun richtig und welche falsch ist, kann schwierig sein, wenn das DWH nicht weiss, ob die Änderung der Daten regulär war (Kunde ist umgezogen) oder irregulär (Daten wurden korrigiert).
Foto: Trivadis
Solche Probleme lassen sich zwar durchaus beheben: Es braucht dafür lediglich passgenaue Erkennungsmechanismen und einen Prozess zur Anpassung von Daten und Berichten im DWH. Da es aber meist hunderte oder tausende solcher und ähnliche gelagerter Fälle gibt und der Aufwand für eine hundertprozentige Lösung immens wäre, werden kleinere Abweichungen häufig toleriert. Sofern diese Daten statistisch genutzt werden und die Fehler vernachlässigbar klein sind, ist dies durchaus legitim. Kritisch wird es jedoch, wenn diese DWH-Daten auch auf Detailebene für operative Zwecke eingesetzt werden.
Die Data Marts: Um Berichte und Auswertungen direkt auf den Daten im DWH-Core auszuführen, sind die Datenstrukturen dort zu unübersichtlich und für schnelle Antwortzeiten zu wenig für Auswertungen und zu sehr für schnelles Befüllen optimiert. Darum werden fachlich gegliederte Teilmengen der Daten aus dem DWH Core nochmals so aufbereitet, dass sie für Benutzerabfragen in geeigneter Form zur Verfügung stehen. Um die Komplexität zu verringern und die Performance weiter zu erhöhen, enthalten die aus diesem Prozess resultierenden Data Marts nur die für die jeweilige analytische Anwendung relevanten Daten in passend verdichteter Form. Das erhöht zudem die Akzeptanz bei den Endanwendern.
Die Datenintegration: Man spricht auch von ETL-Prozessen (Extraktion-Transformation-Load), alternativ auch von ELT, wenn die Transformation innerhalb der DWH-Datenbank stattfindet und nicht auf einem externen ETL-Server. Transformation bezeichnet dabei das Umwandeln, Anreichern, Bereinigen und Aggregieren, also das Verdichten von Daten. Diese Prozesse sind für die gesamte Datenbewegung ins und im DWH verantwortlich, also auch für die Befüllung der Data Marts mit leseoptimierten Daten. Es gibt dabei meist keine - oder nur sporadische - direkte Benutzereingriffe. Stattdessen werden die einzelnen Schritte über ein Workflow-Werkzeug gesteuert und überwacht.
Die Metadaten: Oft unterschätzt und dabei unabdingbar. Erst umfangreiche, saubere und immer aktuelle Metadaten ermöglichen den reibungslosen Betrieb und eine effiziente Weiterentwicklung von DWHs. Insbesondere aber sichern diese durch ihren dokumentierenden Charakter die Akzeptanz durch die Anwender. Dabei beschreiben fachliche Metadaten die Bedeutung und Regeln von Kennzahlen und Attributen sowie die Hierarchien und Beziehungen zwischen den verschiedenen Objekten. Technische Metadaten erklären Strukturen und Zusammenhänge der Tabellen sowie Parameter und Transformationsregeln der Bewirtschaftungsprozesse. Operative Metadaten sind schließlich die permanent geloggten Informationen rund um durchgeführte Datenintegrationsprozesse, Abfragen, Änderungen und vieles mehr.
Die BI-Plattform: Über dem Data Warehouse thront die BI-Plattform. Dort stehen diverse Werkzeuge zur Verfügung, welche Fachanwendern, Statistikern, Berichts-Entwicklern oder auch weiterführenden Services den passgenauen und sicheren Zugriff auf die aufbereitenden Daten ermöglichen.