Data Warehouse im Wandel

Historische Daten

Zudem benötigen viele Analysen historische Daten, die in den Quellsystemen oft nicht verfügbar sind. Ändert sich beispielsweise die Zuordnung eines Produktes zu einer Produktkategorie, genügt in einem OLTP-System ein einfaches Update. Möchte man nun die Umsätze zu einer Produktkategorie im Vorjahresvergleich betrachten, stimmt die Zuordnung des Produktes für das vergangene Jahr nicht mehr. Im Data Warehouse, wo dieser Wechsel der Produktkategorie mit Zeitstempel vermerkt ist – eine gängige Methode dafür sind die "Slowly Changing Dimension" vom Typ II – und für das Vorjahr noch die damalige Kategorie korrekt mit dem Produkt verbunden ist, sind die damaligen Zahlen hingegen abrufbar. Es ist dann sogar möglich, alte Verkaufsdaten aus heutiger Sicht und damaliger Sicht zu vergleichen. Das ist nur mit dem expliziten Vorhalten historischer Daten machbar.

Mehr als nur eine Sammelstelle für Auswertungen

Das Data Warehouse ist also auch in Zeiten von In-Memory-Datenbanken und datenbankübergreifenden Abfragen noch längst nicht obsolet. Werfen wir darum zunächst einen Blick auf die Architektur eines traditionellen Data Warehouses, wie es sich in den vergangenen zweieinhalb Jahrzehnten so oder ähnlich als effektiv und nachhaltig erwiesen hat.

Für die Verarbeitung der Daten werden ETL-Prozesse (Extraktion-Transformation-Load) genutzt. Alternativ spricht man auch von ELT, wenn die Transformation innerhalb der – fast immer relationalen – DWH-Datenbank stattfindet und nicht auf einem separaten ETL Server. Transformieren bedeutet Umwandeln, Anreichern, Bereinigen und Aggregieren von Daten. ETL beinhaltet die vollständige Datenbewegung ins und im Data Warehouse. Interaktion ist dabei auf den Fehlerfall beschränkt. Im Normalfall ist alles vollautomatisiert und wird über ein entsprechendes Workflow-Tool gesteuert.

Besonders wichtig für Akzeptanz und Betrieb eines Data Warehouses sind möglichst aussagekräftige und aktuelle Metadaten: Fachliche Metadaten für Kennzahlen und Attribute sowie Hierarchien und Beziehungen zwischen den verschiedenen Objekten; technische Metadaten für Strukturen und Zusammenhänge der Tabellen und Parameter und Transformationsregeln für Bewirtschaftungsprozesse. Operative Metadaten sind Informationen rund um Datenintegrationsprozesse, Abfragen, Änderungen und vieles mehr. Die Bedeutung dieser Daten ist kaum zu überschätzen. Sie sind Dokumentation, Inhaltsverzeichnis, Abhängigkeitsregister und technische Historie des Data Warehouses mit all seinen Strukturen und Prozessen.

Über allem sitzt die BI-Plattform. Sie ermöglicht Fachanwendern, aber auch technischen Schnittstellen, den geordneten Zugriff auf die Data Warehouse-Daten. Die Datenstrukturen und Verarbeitungsprozesse werden meist über drei bis vier Ebenen aufgetrennt, in denen dann alle erforderlichen Transformationen nach und nach durchgeführt werden. Das reduziert Komplexität durch eine schrittweise Anwendung passender und gut dokumentierter Prozess- und Datenstrukturpatterns. Diese Patterns sind laufzeitoptimiert und erlauben das verhältnismäßig einfache, teils vollautomatisierte Identifizieren und Behandeln von Fehlern.

Schritt 1: Daten extrahieren und laden

Ganz gleich, ob die Quellsysteme selbst für die Bereitstellung ihrer Daten in Form von CSV-Dateien sorgen, die Daten von einem ETL-Werkzeug abgesaugt oder mit ausgefuchsten Change Data Capture-Lösungen wie Golden Gate ins Data Warehouse repliziert werden: Der Extraktions- und Ladeprozess ist der bei weitem generischste Teil der Verarbeitung, da hier weitgehend 1:1-Abbilder der operativen Daten erstellt werden. Die individuelle und fachliche Behandlung der Daten erfolgt erst später.

Diese "Laderampe" des DWHs nennt man "Staging-Area". Und wie bei echten Laderampen geht es noch nicht darum, alle denkbaren Qualitätsprobleme unmittelbar zu erkennen, sondern Vollständigkeit und korrekte Datenstruktur zu gewährleisten. Oft werden nicht einmal die Datentypen geprüft, sondern alle Daten möglichst vollständig in VARCHAR-Felder geladen.

Schritt 2: Qualität sichern

Beim "Cleansing"-Prozess werden Datentypen und zum Teil auch Inhalte und Zusammenhänge evaluiert. Fehlerhafte Daten werden erkannt und – sofern möglich – korrigiert oder als fehlerhaft kategorisiert. Trifft beispielsweise ein Rechnungsdatensatz für einen unbekannten Kunden ein, kann dieser je nach gewünschtem Verhalten einem "Standardkunden" zugeordnet (Orphan/Singleton-Pattern) oder ein zusätzlicher passender Kundendatensatz automatisch erzeugt werden (Embryo-/Dummy-Pattern). Letzterer wird gegebenenfalls später mit echten Kundendaten aktualisiert.

Beim Cleansing erfolgt auch eine andere wichtige Transformation der Daten: Sie werden in einheitliche Zielstrukturen überführt, die dem Zielmodell des Data Warehouses entsprechen und nicht mehr den Strukturen der Quellsysteme. Oft erfolgt der "Cleansing"-Schritt auch kombiniert mit dem folgenden Prozess.

Schritt 3: Transformation in das Zielmodell

Beim anschließenden Transfer der Daten ins Core Data Warehouse erfolgt die endgültige Integration und sofern nötig auch deren Historisierung. Nicht nur Bewegungsdaten wie Rechnungen und Transaktionen sind somit über viele Jahre verfügbar. Auch geänderte Kundenadressen oder die bereits erwähnten, ungültigen Produktkategorien sind von nun an vollständig nachvollziehbar. Das Ergebnis ist der SPOT des Data Warehouses, der Single Point of Truth, oftmals auch als "Single Point Of Trust" verspottet [3], denn einer wie auch immer gearteten "Wahrheit" kommt man mit einem Data Warehouse erfahrungsgemäß bestenfalls nahe. In der Regel einigen sich IT und Fachbereich also in einem Kompromiss darauf, dass hier steht, was der Wahrheit am nächsten kommt.

Für diesen Anwendungsfall verlassen die Daten auch gerne das RDBMS und werden in speziell abfrageoptimierte multidimensionale OLAP-Datenbanken (Online Analytical Processing) überführt. Dort können Werte für alle Verdichtungsstufen vorberechnet werden, was den Endanwendern bei Antwortzeiten von deutlich unter einer Sekunde eine interaktive Arbeit auch mit größeren Datenmengen ermöglicht.

Das genügt nicht

Wenn die Data Warehouse-Welt inzwischen so etabliert und stabil ist, woher kommt dann der Wunsch nach anderen Lösungen? Welche Nachteile und Einschränkungen bringt die herkömmliche Vorgehensweise mit sich?

Neben dem Dauerbrenner "Kosten" und dem damit verbundenen Ruf nach mehr Effizienz – dem mit weiterer Automatisierung wiederkehrender Arbeiten mittels Generatoren gut beizukommen ist – stehen unter anderem im Zuge des sich permanent entwickelnden Internets und dem Internet of Things (IoT) weitere Anforderungen auf der Liste der Data Warehouse-Nutzer.

Operativer Einsatz

Im Data Warehouse sind mehr Informationen zusammengefasst und aufbereitet als in allen anderen IT-Systemen des Unternehmens. Warum also diese Daten nicht auch operativ nutzen und nicht nur für Reporting und Analysen?

Ob Meldewesen, Kundeninformationen für Online-Portale oder Kampagnensupport. Die Liste denkbarer operativer Szenarien ist lang, die Anforderungen hoch und ebenso die Auswirkungen auf das Data Warehouse: Durfte das Data Warehouse bisher bis zu drei Tagen ausfallen, steigen bei der Einbindung in den operativen Betrieb die Verfügbarkeiten – und damit die Kosten – spürbar an. Kommen wir gar in den 24/7-Betrieb, kollidieren wir möglicherweise mit den Nächten, in denen normalerweise die ETL-Prozesse laufen. Hoffen wir, dass es da keine nennenswerten Inkonsistenzen gibt!

Ein weiteres Problem kann die schon erwähnte Datenqualität sein. Sobald absolut exakte Zahlen unerlässlich sind, ist ebenso mit höheren Kosten zu rechnen.

Self-Service Business Intelligence?

"Vergessen Sie das Data Warehouse – wenn wir das dort anfragen, bekommen wir erst in sechs Monaten eine Lösung". So beginnen Geschichten, die man unter dem Begriff "Schatten-IT" zusammenfassen kann.

Aber die Fachanwender haben (meistens) recht. Die IT muss sich, wo immer möglich, nach ihren Anforderungen richten. Mehr Unterstützung und Flexibilität insbesondere für IT-affine Nutzer muss möglich sein. Eine gute Maßnahme kann ein Center of Excellence (CoE) oder Competence Center (BI-CC) sein. Diese Schnittstelle zwischen Fach und IT bietet Ansprechpartner, die beide Seiten verstehen und helfen, Lösungen zu finden.

Auch technische Lösungen gibt es: Neben Kollaborationsfunktionen in BI-Suiten helfen sogenannte "Sandboxes". Technisch erfahrene Endanwender erhalten im DWH ein eigenes Schema, in dem sie frei agieren können. Leider ist damit eine wichtige Anforderung noch nicht erfüllt: Die Einbindung anderer, auch individueller Datenquellen. Da kommen die eingangs erwähnten Data Federation-Werkzeuge ins Spiel. Damit bauen Benutzer mit SQL-Kenntnissen nicht nur eigene Schemata und Sichten auf Data Warehouse-Daten, sondern können auch selbst weitere Datenquellen einfach hinzufügen. Sie können sogar Excel-Sheets und Access-Datenbanken einbinden, Daten selbst transformieren und eigene Werkzeuge zur Auswertung darauf aufsetzen, ohne den regulären Data Warehouse-Betrieb damit zu behindern.

Big Data?

Sobald richtig viele Daten anfallen, zum Beispiel bei der Verarbeitung von Sensordaten in Produktionsanlagen oder dem IoT, aber auch in Logs und Traces von Applikationen oder Steuerungssystemen, denkt man an Big Data-Plattformen. Das ist nicht pauschal richtig. Relationale Clusterlösungen beispielsweise von Oracle, Teradata, Microsoft, IBM oder anderen können durchaus auch Daten bis in den Petabyte-Bereich hinein noch effizient verarbeiten. Allerdings zu entsprechenden Kosten, insbesondere für Softwarelizenzen und Support.

Fallen aber viele Terabytes pro Tag an oder wird eine Lösung für nicht-tabellarische Daten benötigt, also zum Beispiel für Bilder, Audio, Video oder Dokumente, aber auch für spezielle technische Anforderungen bei strukturierten Daten wie Zeitreihen, gibt es dafür besonders geeignete, meist extrem skalierbare DBMS, die NoSQL-Datenbanken. Dabei ist allerdings – wie bei den meisten der neuen Big Data-Tools – ein Best fit-Ansatz angesagt: Nicht eine DB für alle Anwendungsfälle, sondern je Anwendungsfall die passende DB. Verteilte Dateisysteme mit Verarbeitungwerkzeugen wie Hadoop aber auch reine Transformations- und Analyselösungen wie Apache Spark erlauben darüber hinaus die vollständig datenbankunabhängige Speicherung und Verarbeitung von extrem großen Datenmengen. Das hilft insbesondere bei Anforderungen, bei denen die Strukturen jederzeit flexibel sind und erst bei der Analyse klar definiert werden müssen (Schema-On-Read) und nicht schon zur Zeit der Modellierung feststehen (Schema-On-Write).

Auch die DWH-DB-Vendoren stellen sich der neuen Heterogenität und bieten inzwischen Lösungen mit RDBMS, Hadoop/NoSQL und entsprechender Software zur Konnektivität zwischen beiden Welten an. Gerade die Tools für die plattformübergreifende Arbeit mit Daten – die auch Information Lifecycle Management (ILM) und andere Aspekte beinhaltet – sind heute allerdings noch recht limitiert und beschränken sich auf Werkzeuge für den Datenaustausch und übergreifende SQL-Abfragen. Die genauso wichtige Pflege von übergreifenden Metadaten befindet sich gegenwärtig aber noch im Entwicklungsstadium. Bleibt zu hoffen, dass die Hersteller und Communities hier bald eine Lösung bieten, die sich nicht nur auf die eigene Produktpalette beschränkt.

Sobald die neuen Technologien ins Spiel kommen, wird neues Know-how benötigt. Die Entwicklung entsprechender Transformationsjobs in Java, Python oder Scala passt in den seltensten Fällen zum Sprachenfundus von Datenintegrationsspezialisten. Viele ETL-Werkzeuganbieter wie Talend, Oracle oder Informatica unterstützen darum die Generierung von Code rund um die gängigsten Big Data-Technologien wie Hive, Spark und MapReduce. Umgekehrt unterstützen auch immer mehr Big Data-Tools und NoSQL-Datenbanken Abfragesprachen, die sich stark an SQL orientieren. Ein Trend der anhalten und damit weiter zur Integration beider Welten beitragen dürfte.

Topaktuell

Auf den aktuellen Daten zu arbeiten hat etwas für sich. Während im Data Warehouse fast immer nur der Zustand von gestern abgebildet wird, ist es gerade für eine operative Anbindung des Data Warehouse – bspw. an Online-Portale für Kunden oder der Analyse aktueller Vorkommnisse in der Produktion oder der Kundenbetreuung – hilfreich, auch auf aktuelle Daten zugreifen zu können. Das Argument, man möge sich beim Data Warehouse doch bitte auf reine Analytik mit alten Daten beschränken, ist nachvollziehbar, aber heute zunehmend durch neue Ideen gefährdet.

"Echtzeit"-Anforderungen sind allerdings im Data Warehouse schnell mit hohem zusätzlichen Aufwand verbunden. Die gängigen ETL-Prozesse setzen ein nächtliches Zeitfenster und große Datenmengen für eine effiziente Batchverarbeitung voraus, in dem auch die zusätzliche Systembelastung der Quellen stattfinden soll. Zudem sollen sich ETL-Prozesse und Analysen möglichst nicht in die Quere kommen, sonst sind Ressourcenengpässe oder Konsistenzprobleme nicht ausgeschlossen.

Bei operativen Anforderungen an ein sogenanntes "Active DWH" sind Software-Patterns wie "Microbatching", "Real-Time Partitions" oder verteilte Lösungen auf DWH und OLTP- oder NoSQL-Datenbanken erforderlich. Auch wenn letztere nicht unbedingt auf komplexe Analytik optimiert sind, bieten manche NoSQL-Datenbanken wie Cassandra oder HBase durch den Verzicht auf 100 Prozent verfügbare Konsistenz eine sehr hohe Skalierbarkeit gerade bei der Befüllung mit Streaming-Daten. Sie können dann als "Vorbrenner" oder Ergänzung eine interessante Möglichkeit für die Optimierung eines DWHs darstellen.

DWH-Trends und -Konzepte

Auch Lösungen, die sowohl Batch als auch Streaming unterstützen (Lambda-Architektur, Kappa-Architektur) gehören in diese Kategorie. Sie setzen zudem Stream-Processing-Werkzeuge wie Spark-Streaming oder Oracle Stream Analytics (ehem. "Complex Event Processing") voraus. Streaming ermöglicht die permanente Reaktion auf einfließende Daten bis hinunter auf Reaktionszeiten in Millisekunden. Dabei stehen alle Daten, die in einem bestimmten Zeitfenster eintreffen für Analysen zur Verfügung. Das ist für Szenarien wie schnelle Betrugserkennung oder Geofencing äußerst hilfreich. Die Integration solcher Ansätze mit dem DWH ist eine der aktuell spannendsten Herausforderungen für die Entwicklung und den Betrieb.

Die meist SQL-basierten Konnektoren zu und von Hadoop und NoSQL-DBs, Federation Software und Datenintegrationswerkzeuge, die neben RDBMS auch mit Hadoop, NoSQL und Web-basierten Quellen gut zusammenarbeiten, bilden das Fundament dieser Aktivitäten. Was noch weitgehend fehlt, sind wirklich zuverlässige Entscheidungskriterien für oder gegen den Einsatz der jeweiligen Technologie in einem bestimmten Anwendungsfall, auch wenn es hier von diversen Anbietern schon grobe Handlungsempfehlungen gibt.

Dabei ist das alles eigentlich nichts Neues. Schon vor über zehn Jahren beschrieb Bill Inmon, der "Vater des Data Warehouses" in seinem "DW 2.0"-Papier sowohl das Data Lifecycle-Management, die Behandlung nicht relationaler Daten, den die Notwendigkeit von Enterprise Metadaten und die Serviceorientierung operativer DWHs [5].

Ein anderer und doch ähnlicher Ansatz ist das "Logical Data Warehouse" (LDW). Dieses Konzept des Gartner-Analysten Mark Beyer hat ebenfalls schon acht Jahre auf dem Buckel. Das LDW betrachtet das Data Warehouse lediglich als eines seiner Grundkonzepte. Für Beyer behält das DWH seine Existenzberechtigung fast unvermindert bei und wird durch neue Ansätze unterstützt und entlastet.

Diese Ansätze sind einerseits das erläuterte Data Federation-Konzept, welches sich neben der Self-Service-Komponente insbesondere auch für Prototyping eignet. Dazu kommen die "richtigen" Big Data-Projekte, die ganz gezielt die neuen Technologien einsetzen, wo die traditionellen nicht mehr verfangen. In "Data Labs" werden schließlich explorative Verfahren für die Identifikation wichtiger Informationen in den intern und extern verfügbaren Daten eingesetzt. Dort etablierte Lösungen können anschließend "operationalisiert" und in eines der drei Grundkonzepte überführt werden.

Fazit

Es wird zunehmend schwieriger, neue Anforderungen mit den gängigen Data Warehouse-Lösungen zu implementieren, sei es aus organisatorischer oder technischer Sicht. Schnelle und "schmutzige" Ansätze wie das "Data Lab" können die sorgfältige und erprobte Lösungsarchitektur eines Data Warehouses aber aus Qualitätssichtpunkten nicht ersetzen, sondern nur um den agilen und forschenden Charakter ergänzen. Die Kunst wird es sein, die nach wie vor wichtigen Anforderungen an ein Data Warehouse um neue Erfordernisse (große Datenmengen, kurze Latenzen, komplizierte Datenstrukturen) zu ergänzen und in diesem Zusammenhang die neuen Technologien zu berücksichtigen. Wir nähern uns einer brauchbaren Lösung demnach von beiden Seiten: Das Data Warehouse öffnet sich neuen Bedürfnissen und Technologien und die Big Data-Welt adaptiert im Gegenzug erprobte Patterns und Methoden der geordneten Domäne des Data Warehousing. Die probaten Mittel dafür heißen Abstraktion (mehr SQL, mehr Generieren), Agilität (mehr Self-Service, schnellere Entwicklungszyklen) und Performance (In-Memory, bessere Skalierbarkeit, kürzere Latenzen). Die nächsten fünf Jahre werden interessante Zeiten für das Data Warehouse.