Über unsMediaKontaktImpressum
Peter Welker 16. Mai 2017

Data Warehouse im Wandel

Der zentrale Lieferant von Informationen zur strategischen Steuerung von Unternehmen war das Data Warehouse (DWH) schon Ende des letzten Jahrtausends und ist damit längst zum unverzichtbaren Bestandteil von Organisationen geworden. Heute stellen emanzipierte und gut ausgebildete Nutzer neue Ansprüche an Menge, Aktualität und Reichhaltigkeit, aber auch an die Flexibilität im Umgang mit neuen Daten, Szenarien und Analysemöglichkeiten.

So ein Data Warehouse ist doch eigentlich ziemlich kompliziert und kostet viel Geld. Warum lassen wir unsere Daten also nicht einfach da, wo sie sind und werten Sie dort aus, sondern holen sie lieber mit viel Mühe und Zeit aus den Quellsystemen heraus, nur um sie anschließend sofort an anderer Stelle wieder redundant abzulegen?

Analysen direkt im OLTP-System

Das ist zugegebenermaßen eine ziemlich gute Frage. Vor 10 Jahren war die naheliegendste Antwort noch relativ einfach: Es geht um Performance! Es gab in den Quellsystemen weder die nötigen technischen Ressourcen, noch war – die üblichen Datenmengen vorausgesetzt – die passende Aufbereitung der Daten für akzeptable Laufzeiten von Berichten und Analysen möglich. Zudem wollte man die OLTP-Systeme von den ausgesprochen rechenintensiven Analysen entlasten. Heute haben wir mit Datenbankclustern, In-Memory-Lösungen wie SAP HANA, der Oracle In-Memory-Option oder DB2 Blu und der dem allgemeinen IT-Fortschritt (Mooresches Gesetz [1]) geschuldeten, um Faktoren höheren Gesamtsystemleistung durchaus die Möglichkeit, auch auf operativen Systemen dispositive Abfragen mit akzeptabler Antwortzeit zu fahren.

Data Federation

Aber leider sind oft nicht nur Daten eines einzelnen ERPs, CRMs oder MES interessant. Vielmehr sind es Informationen aus den integrierten Daten vieler Quellsysteme im Zusammenspiel, welche man gewinnen möchte. Nehmen wir das Beispiel eines Vertriebscontrollers, der Bestelldaten gemeinsam mit Kundenkontakten analysieren will. Dazu muss er im einfachsten Fall Daten aus dem CRM und dem Billing-System verbinden. Stehen diese Daten nicht zufällig in der gleichen Datenbank zur Verfügung, müssen sie über Systemgrenzen hinweg gejoined werden. Dieser Join kann durch eine Kopie der Daten auf ein gemeinsames System erfolgen – dann wären wir im Grunde wieder beim Data Warehouse angekommen – oder durch übergreifende Abfragen auf mehrere Quellsysteme.

Letzteres beschreibt den Ansatz sogenannter "Data-Federation"-Lösungen. Diese ermöglichen (meist in SQL geschriebene) Abfragen, die zum Ausführungszeitpunkt als "Distributed Query" simultan Daten aus unterschiedlichen Quellen wie RDBMS, NoSQL-Datenbanken, Rest-APIs oder sogar Excel-Sheets ermitteln und zusammenführen. Übergreifende Abfragen sind auch mit den meisten BI-Auswertewerkzeugen möglich, scheitern dann aber nicht selten wieder am erstgenannten Problem: der Performance. Was innerhalb einer Datenbank, eines Query Optimizers und eines Rechners oder gut abgestimmten Rechnerverbundes (Cluster) in Sekunden erledigt ist, kann im Zusammenspiel mehrerer unterschiedlicher Systeme über ein reguläres Firmennetzwerk leicht Minuten oder Stunden dauern. Mit optimierten Federation Servern wie Denodo, Cisco Composite oder der Open Source-Lösung JBoss Teiid [2] sind heute zwar auch sehr effiziente Lösungen auf dem Markt, die mit Caches und ausgefeilten Query-Optimizern das Bestmögliche aus den verteilten Daten machen. Mit den grundsätzlichen Performancenachteilen verteilter Systeme haben aber auch diese Werkzeuge zu kämpfen.

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.

Das folgende Beispiel (s.Abb.3) verdeutlicht recht gut, warum es ausgesprochen schwierig sein kann, hundertprozentige Datenqualität sicherzustellen. Nehmen wir einen Bericht, der Umsätze des Vorjahres nach Postleitzahlenbereichen der Kunden summiert. In einem OLTP-System ohne Historie der Kundendaten wird die PLZ des Kunden zunächst falsch eingegeben. Eine Woche später wird sie korrigiert. Da es eine Fehleingabe war, wird sie nicht als Wohnungswechsel oder separate Rechnungsadresse definiert, sondern einfach nur geändert. Eine Auswertung, die auf der falschen PLZ beruht, sieht 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, gelten aber andere Regeln. Schließlich will man dort eine vollständige Historie der Daten vorhalten. Hier ist der Kunde für die Zeit vor der Korrektur demnach noch immer einer anderen Postleitzahl zugeordnet. Somit liefert der Bericht andere Werte. Solange das Data Warehouse nicht "weiß", ob die Änderung der Daten eine Korrektur war, ist dort nicht entscheidbar, welche Betrachtungsweise nun die korrekte ist.

Auch wenn solche Probleme prinzipiell behebbar sind (passgenaue Erkennungs- und Korrekturmechanismen), gibt es eine Unmenge solcher Ausnahmen und Sonderfälle. Der Aufwand zur vollständigen Korrektur ist immens. Darum 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, wenn diese Data Warehouse-Daten auch auf Detailebene für operative Zwecke eingesetzt werden. Das kann beispielsweise im Meldewesen einer Bank oder bei der Kalkulation von Mitarbeiterboni der Fall sein.

Schritt 4: Informationen abfrageoptimiert aufbereiten

Im Data Warehouse Core werden Datenstrukturen häufig so definiert, dass sie effizient zu befüllen sind. Redundanzen werden also weitgehend vermieden, die Indexierung ist eher spärlich und Updates werden auf ein Minimum reduziert oder sogar gänzlich vermieden. So entstehen meist normalisierte, in zunehmenden Maße auch am "Data Vault"-Ansatz orientierte Modelle.

Darum werden Teilmengen der Daten anschließend nochmals mit fachlichem Fokus aufbereitet und antwortzeitoptimiert in sogenannten Data Marts bereitgestellt. Dabei werden nur die für den jeweiligen Anwendungszweck relevanten Attribute beibehalten und die Daten so verdichtet (bspw. summiert), dass sie so effizient wie möglich in den fachlichen Analysen zum Einsatz kommen. Sehr häufig werden die Daten in den Data Marts dimensional modelliert, d. h., die beschreibenden Attribute werden in Dimensionstabellen gruppiert (z. B. Regionen, Produkte, Kunden) und die Kennzahlen in Faktentabellen (Umsatz, Anzahl usw.) abgelegt. Dimensionen können wiederum normalisiert sein (Kategorie und Produkt in unterschiedlichen Tabellen) oder Redundanzen in Kauf nehmen (Kategorie und Produkt in einer Tabelle). Die normalisierte Variante heißt auch "Snowflake schema", weil sich die Dimensionstabellen wie die Arme einer Schneeflocke um die Faktentabellen herum verzweigen. Die redundante Variante nennt sich "Star schema", weil die Dimensionstabellen keine weiteren Verzweigungen aufweisen [4]

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. 

Literatur
  • Data Warehousing mit Oracle: Jordan et al. Hanser. 2010
  • Data Warehouse Blueprints: Jordan et al. Hanser. 2015
  • The Data Warehouse Toolkit: Kimball et al. Wiley. 3. Edition. 2013
  • Modeling the Agile Data Warehouse with Data Vault. Hultgren. Brighton Hamilton. 2012
  • Information Management: DW 2.0 – Architecture for the Next Generation of Data Warehousing. B. (W. H.) Inmon. DM Review. April 2006

Autor

Peter Welker

Peter Welker verfügt über 25 Jahre IT-Projekterfahrung als Entwickler und Lösungsarchitekt. Als Autor verschiedener Fachbücher, regelmäßiger Referent und Keynote Speaker auf Data Warehouse- und Datenbankkonferenzen ist er mit…
>> Weiterlesen
Das könnte Sie auch interessieren
Kommentare (0)

Neuen Kommentar schreiben