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.
Die Data Warehouse Technik
DWHs werden heute fast ausschließlich auf relationalen Datenbanken betrieben und Daten werden mittels SQL gelesen und verarbeitet. Für die Data Marts sind zum Teil auch speziell abfrageoptimierte multidimensionale OLAP-Datenbanken (Online Analytical Processing) im Einsatz. Beide Technologien sind für viele typische Anwendungsfälle eines Data Warehouse bestens geeignet, beispielsweise für betriebswirtschaftliches Berichtswesen oder Controlling. Relationale Datenbanken bieten durch die Möglichkeit, jederzeit Daten miteinander zu verbinden (Join) die nötige Flexibilität für Ad-hoc-Abfragen - selbst bei völlig neuen Anforderungen.
Zudem ist die Abfragesprache SQL leicht zu erlernen und wird von jeder etablierten BI- und Reporting-Software direkt unterstützt. Relationale und Multidimensionale Datenbanken gewährleisten zudem Datenkonsistenz, Hochverfügbarkeit, flexible und wirksame Sicherheitsmechanismen und Verfahren zur Sicherstellung eines wirksamen Datenschutzes sowie eine gute Verarbeitungsgeschwindigkeit auch für größere, strukturierte Datenmengen. Kein Grund also, sich aus der Komfortzone heraus zu wagen? Ganz im Gegenteil!
"Neue" Anforderungen
Verringerte Kosten und damit verbunden der Wunsch nach mehr Effizienz sind immer ein wesentlicher Treiber für Veränderungen, nicht nur im Umfeld von Data Warehouses. Hier haben sich in den vergangenen Jahren zahlreiche Ansätze etabliert. Dazu gehören Softwarelösungen zur Aufnahme fachlicher Anforderungen und deren möglichst einfache Überführung in technische Strukturen. Zudem sind hier Konzepte und Tools zur Modellierung von Datenstrukturen und Prozessen sehr hilfreich, welche dann eine weitreichende Generierung (statt manueller Entwicklung) von ETL Strecken ermöglichen, zumal sie den Aufbau und die Pflege der Dokumentation erleichtern und gleichzeitig die Komplexität der Data-Warehouse-Prozesse reduzieren können.
Im Rahmen neuer fachlicher und technischer Problemstellungen stehen aber vor allem die großen Themen und Trends der vergangenen Jahre im Blickpunkt. Dabei geht es um Tagesaktualität, unflexible Berichte, begrenzte Datenpools, zu große Datenmengen und Datendurchsätze beziehungsweise nicht einheitlich strukturierte Daten. Das sind alles Erfordernisse, die von einem herkömmliche Data Warehouse nicht, oder nur mit erheblichen Mehraufwand zu stemmen sind. Hier ein Überblick gängiger Anforderungen:
DWH operativ einsetzen: Immer mehr Unternehmen sehen das DWH nicht nur als Daten-Endpunkt, sondern als Teil weiterer operativer Prozesse. So kann es das Meldewesen bei Banken unterstützen, online Informationen für Portale bereitstellen oder CRM-Kundendaten analysieren, segmentieren und wieder ins CRM zurückspielen. Letzteres bildet einen sogenannten "Closed-Loop". Solch ein operativer Betrieb erfordert aber einige Zusatzanstrengungen. Zum Beispiel erhöht sich die nötige Systemverfügbarkeit deutlich. War es in der Vergangenheit vielleicht noch akzeptabel, wenn das DWH zwei oder drei Tage abgeschaltet war, ist plötzlich eine 24/7 Verfügbarkeit unabdingbar und stellt die DWH Architektur sowie die damit verbundenen etablierten Bewirtschaftungs- und Administrationsprozesse in Frage: Es gibt keine "keimfreien" Zeitfenster mehr für die ETL-Prozesse und die zulässige Zeit für das Restore eines Backups schrumpft von Tagen auf Stunden.
Wie schon beschrieben, steckt ein weiteres Problem operativer DWHs in der Datenqualität. Wo kleinere Abweichungen früher noch akzeptabel waren, werden plötzlich absolut exakte Zahlen benötigt. Ist eine höhere Verfügbarkeit manchmal noch durch mehr Hardware, teurere Softwarelizenzen und generelle Anpassungen an den Datenintegrationsmechanismen umsetzbar, gibt es bei der Datenqualität häufig nur eine Lösung: Jeden einzelnen Verursacher aufspüren und ganz gezielt praktikable Lösungen zur Korrektur oder Vermeidung der Fehler bauen - ganz wie bei der Programmierung der Quellsysteme selbst.
Self-Service: "Wenn ich das bei der IT in Auftrag gebe, warte ich ein halbes Jahr auf eine Lösung - dabei will ich doch nur ein paar hundert Zeilen aus meinem Excel-Sheet in meinen Bericht einbinden." So ähnlich klingen viele Begründungen für erste "U-Boot Aktivitäten" und den Aufbau diverser "Schatten-Lösungen" rund um das DWH. Fachbereichsanwender exportieren ganze Teile aus dem DWH in eigene, lokale Datenbanken und nutzen gängige Tools - gerne Excel - um die Daten für ihre Analysen zusammenzuführen. Dabei werden massenhaft Mechanismen zur Qualitätssicherung ausgehebelt, die DWH-Entwickler und andere IT-Mitarbeiter über lange Zeit mühevoll aufgebaut haben. Diese sind oftmals auch ein beliebter Grund für gegenseitige Schuldzuweisungen, wenn dabei etwas schiefgeht.
Dabei muss man den Fachanwendern im Grunde Recht geben. Ihre Anforderungen sind die Richtschnur für die Anstrengungen der IT. Hier heißt es Umdenken: Die Anforderungen an das Berichtswesen steigen permanent. Controller, Marketingmitarbeiter oder Vertrieb brauchen mehr Flexibilität bei Ihrer Arbeit. Und mehr Unterstützung durch DWH-affine Kollegen.
Ein organisatorischer Ansatz zur Lösung des Problems ist das BI Competence Center (BICC), in dem nicht nur die Mechanismen für flexiblere Arbeit mit den Daten aus dem Data Warehouse definiert und umgesetzt werden, sondern auch die richtigen Ansprechpartner zwischen Fachbereich und IT angesiedelt sind.
Ein technischer Ansatz heißt "Federation". Hier wird dem Anwender erlaubt, mehrere Quellen in einer Abfrage gemeinsam zu nutzen, also Data Warehouse und Excel-Sheet, ERP, CRM oder was auch immer benötigt wird. Die Einbindung zusätzlicher Datenquellen wird zwar von einigen Business-Intelligence-Frontends gut unterstützt. Zum Teil bildet aber eine zentrale Konfiguration, die nur Administratoren zugänglich ist und keine individuellen Quellen erlaubt, die einzige Möglichkeiten zur Einbindung. An dieser Stelle braucht es deutlich mehr benutzerspezifische Möglichkeiten.
Das größte Problem bei solchen verteilten Daten ist die Performance. Es ist schon schwierig genug, auf einer einzigen, homogenen Datenbank mit abfrageoptimierten Datenstrukturen eine gute Antwortzeit hinzubekommen. Der Zusammenschluss mehrerer unterschiedlicher Datenbanken über ein herkömmliches Netzwerk stellt eine noch wesentlich größere Herausforderung dar, speziell wenn mehrere sehr große Datenbestände über dieses Netzwerk verbunden (gejoined) werden müssen. Darum kann dieser Ansatz keine generelle Lösung sein, sondern sollte nur für besondere Anwendungsfälle eingesetzt werden. Solche Szenarien werden durch spezielle Federation-Software wie zum Beispiel Cisco Composite, Denodo, RedHat JBoss Teiid oder Datavirtuality unterstützt. Hier ist der Zusammenschluss sehr unterschiedlicher Datenquellen auf zentraler Ebene möglich. Diese Werkzeuge bieten zudem Abfrageoptimierung, Datenverteilungsanalysen beziehungsweise Caching-Mechanismen und somit bessere Chancen auf akzeptable Performance. Leider kann der "normale" Anwender auch hier meist nicht einfach "private" Datenquellen nach Bedarf hinzufügen. Immerhin sind aber weitere Datenquellen durch Administratoren in aller Regel innerhalb von Minuten oder Stunden integrierbar.
Ein weiterer Ansatz für Self-Service BI sind die sogenannten "Sandboxes": Lokale, benutzerspezifische Bereiche, oft innerhalb der zentralen Data Warehouse Plattform, auf denen benutzereigene Daten abgelegt werden können. Dieser Ansatz verringert das Risiko schlechter Antwortzeiten für Abfragen, lässt aber die Frage offen, wie individuelle Daten in die Sandbox kommen. Dafür braucht es wiederum spezielle Software für einfache Datenintegration. Open Source Anbieter solcher Tools - wie Pentaho oder Talend - sind in den Community-Editionen zwar kostenfrei und auch relativ einfach zu bedienen. Richtig endbenutzertauglich sind sie darum aber noch lange nicht. Oft kommen daher in der Praxis selbstentwickelte Dienste wie browser-basierte, automatisierte Textdatei-Uploads zum Einsatz.
Große Datenmengen: Bei besonders umfangreichen Datenmengen beispielsweise aus dem Internet-of-Things (IoT), aus Produktionsanlagen oder im Telekommunikationsumfeld denkt man gleich an Big-Data-Technologien wie Hadoop. Dabei sind viele analytische Anforderungen auch bei außerordentlich großen Datenmengen im dreistelligen Terabyte- oder sogar Petabyte-Bereich mit großen relationalen Datenbankclustern von Oracle, Teradata, Microsoft, IBM und anderen einfach und effektiv umsetzbar. Beim Einsatz hunderter CPU-Cores und mehrerer Terabyte RAM lassen sich auch mit herkömmlichen Techniken riesige Datenmengen effektiv bewegen, speichern und auswerten - mit durchaus passabler Performance. Allerdings fallen dabei oft enorme Kosten für Softwarelizenzen und Hardware an.
Besonders der Umgang mit uneinheitlich strukturierten Daten wie Dokumenten, Multimedia-Dateien und Ähnlichen ist zudem nicht gerade die Stärke relationaler oder multidimensionaler Datenbanken. Bei Anforderungen außerhalb relationaler Strukturen - und da genügt es oft schon, jederzeit beliebige neue Attribute zu bestehenden Daten hinzufügen zu können - sind andere Lösungen wie Hadoop oder Wide-Column NoSQL Datenbanken zum Speichern deutlich besser geeignet. Das gilt 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).
Die Hersteller von DWH-Lösungen haben solche Anforderungen in den zurückliegenden Jahren verinnerlicht und bieten mittlerweile Systeme mit RDBMS, Hadoop/NoSQL und entsprechender Software zur Konnektivität zwischen beiden Welten an. Diese Lösungen sind heute allerdings noch recht limitiert und beschränken sich meist auf Werkzeuge für den Datenaustausch und übergreifende SQL-Abfragen. An der nahtlosen, plattformübergreifenden Verwaltung von Metadaten und anforderungsoptimiertem automatischem Komprimieren und Verschieben von Daten zwischen den Technologien (Data Lifecycle Management) wird gegenwärtig intensiv geforscht und entwickelt.
Ein ganz anderer Trend zum Umgang mit großen Datenmengen ist die Modellierung von Core-DWHs nach dem Data-Vault-Model. Dieses erlaubt eine größere Flexibilität bei den Datenstrukturen, eine sehr leicht verallgemeinerbare Vorgehensweise und wesentlich schnellere Befüllung des Cores, hat aber auf der anderen Seite eine beachtliche Inflation an Tabellen zur Folge und macht die Befüllung der Data Marts aus dem DWH-Core nicht unbedingt schneller oder einfacher.
Big Data & DWH
Egal ob es um hohe Kosten, umfangreiche Datenmengen, einen extremen Datendurchsatz oder Echtzeit-Anforderungen geht: Früher oder später kommen Big Data Technologien wie die Hadoop Plattform, Streaming Lösungen beziehungsweise NoSQL-Datenbanken ins Spiel. Und spätestens dann stellt sich die Frage nach zusätzlichem Know-how bei den DWH-Entwicklern. Die Implementierung von MapReduce- oder Spark-Jobs - sei es mittels Java, Scala oder entsprechender Scripting Engines - passt dabei oft nicht zur Expertise langjähriger Datenintegrationsspezialisten.
Unter anderem darum bauen Anbieter von Datenintegrationssoftware wie Informatica oder Oracle immer mehr Big-Data-Funktionalität in ihre Lösungen ein. Solche Werkzeuge können durch grafisch definierte Extraktions-, Lade- und Transformationsprozesse - wenn auch noch mit funktionalen Abstrichen im Hadoop-Bereich - wahlweise SQL-Befehle auf Datenbanktabellen oder Pig- und Spark-Scripts auf HDFS basierten Dateien ausführen und dabei auch NoSQL-Datenquellen und Change-Data-Capture-Prozesse integrieren. Letztere streamen die Änderungen aus ERP und CRM dann direkt beispielsweise ins Hadoop Filesytem HDFS oder Apache Flume. Die Datenintegration kann heute also sowohl auf traditionelle DWHs als auch auf Big-Data-Plattformen verteilt werden. Schon aus Gründen der Kosten und Skalierbarkeit sollten Unternehmen diese Optionen in ihre Überlegungen mit einbeziehen.
Real-time - eine Frage des Budgets
Schon vor 20 Jahren äußerten Fachanwender häufig den Wunsch, Berichte und Analysen auf absolut topaktuellen Daten zu erstellen - zumindest sollten die Daten jedoch nicht älter als ein paar Minuten sein. Solche "Echtzeit" oder "Fast-Echtzeit" Anforderungen relativierten sich allerdings in vielen Fällen nach einer Schätzung des dafür zusätzlich benötigten Budgets. Allein aus diesem Grund sind viele Data Warehouses auch heute bestenfalls tagesaktuell.
Warum die Verkürzung der Latenz einen solch hohen Aufwand mit sich bringt, hat organisatorische wie auch technische Gründe. Zum einen sollen sowohl die Extraktion der Daten aus den Quellsystemen als auch die Integration der Daten ins DWH die Arbeit der Anwender beider Systemtypen möglichst nicht beeinträchtigen. Daten zu schaufeln ist ressourcenintensiv und verlangsamt andere Prozesse. Darum wird für die Datenintegration meist ein Zeitfenster festgelegt, in dem möglichst wenige Anwender aktiv sind. Das vereinfacht auch die Komplexität der gesamten Bewirtschaftung und man kann sich einigermaßen sicher sein, dass die neuesten Kundenstammdaten bereits vorliegen, wenn der erste Rechnungsdatensatz des Tages verarbeitet wird.
Zudem ist Batch- oder Bulk-Processing, also das Verarbeiten von großen Datenmengen - zum Beispiel eine Million Datensätze am Stück - gerade in einem RDBMS oder Datenintegrationsserver wesentlich effizienter als die Behandlung einzelner eintröpfelnder Datensätze. Ein Beispiel: Um bei einem durchschnittlichen Aufkommen von 100 Datensätzen pro Sekunde eine Million Datensätze auf einmal effizient zu verarbeiten, müssen zunächst fast drei Stunden Daten gesammelt werden. Wenn das Verarbeiten dieser Million Datensätze dann 90 Minuten dauert, also etwas über fünf Millisekunden pro Datensatz, sind in Summe viereinhalb Stunden Latenz - also Verzögerung - nicht unterschreitbar. Würde man hingegen jede Minute laden, wäre die Datenmenge pro Ladelauf mit 6000 Datensätzen zwar deutlich kleiner (Microbatching), würde aber aufgrund des Prozess- und RDBMS Overheads auf beispielsweise 15 Millisekunden pro Datensatz steigen. Bei 90 Sekunden Ladezeit aber wäre die Datenmenge in der verfügbaren Zeit mit der eingesetzten Soft- und Hardware überhaupt nicht mehr zu bewältigen. Die Daten kämen schneller an, als sie verarbeitet werden könnten.
Die Alternativen: Mehr Kosten für stärkere Hardware und spezielle RDBMS Optionen beziehungsweise mehr Komplexität in den Bewirtschaftungsprozessen.
Manchmal jedoch müssen aufgrund spezieller Anforderungen eben doch deutlich geringere Latenzen erreicht werden. Zum Beispiel mag die Fähigkeit zur schnellen Fehleranalyse in Produktionsanlagen mit maximal 15 Minuten Latenz einhergehen. Oder die Einbindung von DWH basierten Archivdaten in ein Kundenportal ist erforderlich. Bei solchen operativen Anforderungen an ein sogenanntes "Active DWH" sind besondere Software Patterns wie "Real-Time Partitions" oder verteilte Lösungen auf DWH und OLTP- oder NoSQL-Datenbanken erforderlich. Auch wenn sie den Fokus nicht auf analytische Abfragen legen und daher kein Ersatz für ein DWH sein können, bieten manche NoSQL-Datenbanken wie Cassandra oder HBase durch den Verzicht auf permanente Konsistenz eine sehr hohe Skalierbarkeit gerade bei der Befüllung mit Streaming-Daten. Sie können dann im Zusammenspiel oder als "Vorbrenner" für Data Warehouses eine interessante Option sein. Für alle Detailversessenen sei hier auf das CAP Theorem und den BASE / ACID Vergleich verwiesen.
Auch Architekturen für Mischformen von Batch- und Streaming-Betrieb wie die Lambda-Architektur von Apache Storm Begründer Nathan Marz mit ihren Batch- und Speed-Layern auf jeweils unterschiedlichen Technologien gehören in diese Kategorie.
Nicht immer ist es gleich nötig, Plattform und Architektur zu ändern. Manchmal genügt es auch schon, durch geschicktes Erkennen der geänderten Daten die übertragene Datenmenge zwischen Quelle und DWH zu minimieren, die Prozesslast zu verringern und dadurch auch die mögliche Latenz zu verbessern. Nicht selten werden nämlich weitaus mehr Daten zwischen Quellsystem und DWH übertragen als unbedingt nötig, nur um ja nichts zu vergessen. So sind auch heute noch tägliche Full-Loads, also der Komplettabzug von Quellsystemdaten nicht ungewöhnlich. Eine dafür prinzipiell gute Lösung ist Change-Data-Capture-Software wie zum Beispiel "IBM InfoSphere CDC" oder "Oracle Golden Gate", die ohne besondere Belastung des Quellsystems auf dem operativen System fast in Echtzeit alle neuen, geänderten und gelöschten Daten erkennt und nur diese Informationen ins DWH repliziert. Das immer gleiche Problem dabei: Entsprechende Software verursacht erhebliche Lizenz- und Supportkosten, was in vielen Fällen dazu führt, dass doch wieder auf schlechtere, aber eben kostengünstigere Verfahren ausgewichen wird.
In-Memory Datenbanken
Der Klassiker unter den Trends zur Beschleunigung von (nicht nur) Data Warehouses ist seit nunmehr einigen Jahren die In-Memory-Datenbank. Dabei ist der Begriff ziemlich irreführend, denn seit Anbeginn der Softwareentwicklung ist die optimale Balance zwischen schnellem, flüchtigem Hauptspeicher und langsamem Permanentspeicher eine der großen Herausforderungen für Informatiker. Und folgerichtig nutzen Datenbanken den Hauptspeicher schon lange so intensiv wie möglich und den Permanentspeicher nur dann, wenn es nicht mehr reicht. Der In-Memory Begriff wurde und wird für ganz verschiedene Ansätze miss- und gebraucht. Manchmal suggeriert er höchste Performance und bedeutet doch bloß, dass die so ausgezeichnete Software keine Daten verarbeiten kann, die nicht komplett in den Hauptspeicher passen.
Dabei ist die Idee hinter dem Trend eine ganz andere: In-Memory Datenbanken sollen für die wichtigsten Daten alle Vorteile der schnellen Verarbeitung im Hauptspeicher nutzen, also von besonders viel Hauptspeicher überproportional stark profitieren. Permanentspeicher wie Festplatten oder Flash-Disks werden nur noch für Transaktionssicherung (Logs) sowie für Backup und Recovery benötigt; oder eben für die selten genutzten Daten, die nicht in den Hauptspeicher passen und schlimmstenfalls auf traditionelle Mechanismen wie B*Tree Indexe oder kleine, Block-basierten Caches zurückgreifen müssen. Die RAM-optimierten Daten hingegen werden meist spaltenorientiert, sortiert und komprimiert jeweils im möglichst schnellsten Memory-Baustein (RAM oder CPU Caches) gehalten und sehr effektiv verarbeitet, zum Beispiel mittels intensivem Einsatz von SIMD Operationen (Single Instruction - Multiple Data).
In-Memory Datenbanken gibt es viele. Der Fokus für DWH-Lösungen liegt auf den Lösungen, die für analytische Anforderungen gedacht sind. Inzwischen haben alle großen Datenbankhersteller wie SAP, IBM, Microsoft oder Oracle entsprechende Produkte, Produktoptionen oder Features im Portfolio, die für viele analytische Aufgaben tatsächlich wesentlich bessere Antwortzeiten ermöglichen und sich damit gerade einen festen Platz in vielen DWHs erobern.
Dass Data Warehouses somit komplett überflüssig werden, weil komplexe Analysen nun auch direkt auf den operativen Systemen möglich sind, bleibt aber nach wie vor ein frommer Wunsch.
Denn erstens ist eines der wesentlichen Merkmale der meisten DWHs, dass Daten vieler verschiedener operativer Systeme integriert werden müssen, und nicht nur die Daten eines einzelnen Systems relevant sind.
Zweitens sind DWH-Daten nicht volatil, werden also im Gegensatz zu ERP und CRM meist auch historisch mit allen Änderungen über lange Zeit gespeichert.
Und drittens ist die größte Effektivitätssteigerung bei den meisten Auswertungen (zum Beispiel "Umsatz nach Vertriebsregion, Monat und Produktgruppe") nach wie vor nur durch eine ausgeklügelte und flexible Verdichtungspraxis erzielbar.
Dabei werden Daten für häufig benötigte Analysen schon bei der Bewirtschaftung und nicht erst zum Abfragezeitpunkt gruppiert und aggregiert (also beispielsweise Summen oder Mittelwerte gebildet) und dann als redundanter Datenbestand gespeichert. Auf diese Praxis zu verzichten ist in etwa so effizient, wie ein Buch komplett zu lesen, nur um eine grobe Vorstellung seiner Gliederung zu bekommen und die Menge der pro Tag lesbaren Bücher dadurch zu erhöhen, indem man bessere Methoden zum schnellen Querlesen entwickelt und einübt. Inhaltsverzeichnisse sind da nach wie vor einfach besser geeignet.
DWH-Trends und -Konzepte
Während sich In-Memory Lösungen wie von selbst etablieren, bildet die Integration von DWHs mit Big-Data-Plattformen und (noch) nicht im DWH integrierten Daten (interne und externe) den Dreh- und Angelpunkt einer Modernisierung. 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, stellen das Fundament dieser Aktivitäten dar. 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.
Aus konzeptueller Sicht haben sich all diese Trends schon lange angekündigt. Der "Vater des Data Warehouses", Bill (William H.) Inmon beschrieb schon vor 10 Jahren in seinem Data Warehouse "DW 2.0" Ansatz sowohl das Data Lifecycle Management, die Behandlung nicht relationaler Daten, die Notwendigkeit von Enterprise Metadaten und die Serviceorientierung operativer DWHs.
Das Logical Data Warehouse (LDW) wiederum ist ein Architekturansatz von Mark Beyer (Gartner). 2009 ersonnen existiert es nun schon bald sieben Jahre - und wird doch erst jetzt so langsam bekannt. Das LDW sieht klassische Data Warehouses lediglich als eine von drei (oder wahlweise vier) seiner Säulen. Hier lagern 80 Prozent der allgemein anerkannten Informationen (Anteil der Berichtsanforderungen, nicht der nicht Datenmenge!) des Unternehmens und sollen es auch weiterhin tun.
Die restlichen 20 Prozent verteilen sich einerseits auf die bereits erwähnten Federation Ansätze, welche unter anderem den Self-Service-Ansatz unterstützen als auch Echtzeitaspekte und Pilotprojekte für Berichte und Analysen abdecken. Andererseits werden als dritte Säule richtige "Big Data Projekte" angesiedelt, die ganz gezielt die neuen Technologien nutzen. Sei es, um extrem flexibel zu bleiben, riesige Datenmengen oder Echtzeit-Streams zu bewältigen oder besonders umfangreiche Advanced Analytics (Data-Mining, Natural Language Processing, Machine Learning usw.) durchzuführen.
Das vierte Standbein ist die Spielwiese des Data Scientisten, der aus allen Quellen und Bestandteilen des LDW schöpft und Forschung auf diesen Daten betreibt. Dessen Prototypen bilden später die Basis für neue Projekte in den anderen drei Säulen. Darüber ruht das Dach des gesamten Data Management Systems mit allen Metadaten, SLAs und Lösungen zur Qualitätssicherung, Masterdaten und vieles mehr. Ein Ansatz, den sich inzwischen auch viele Softwareanbieter zu Eigen gemacht haben.
Foto: Trivadis
Fazit
Mit den beschriebenen Mitteln eine funktionierende Gesamtlösung zu konstruieren, ist heute eine zentrale Aufgabe - für die noch kein einheitliches technisches Design, geschweige denn eine fertige Lösung existiert. Es stellt sich daher die Frage, welche dieser neuen Ansätze wie umgesetzt werden sollte. Aus pragmatischer Sicht sind diese Konzepte Leitplanken für die strategische Ausrichtung einer zukünftigen DWH Lösung. Schließt man aus der Tatsache, dass DWHs nach den Konzepten von vor 15 bis 20 Jahren heute gut etabliert sind, auf die Zukunft, sind in fünf bis zehn Jahren DW 2.0 und LDW Patterns als allgemeine Standards zu erwarten. Daher ist jetzt ein guter Zeitpunkt, die Strategie für die nächste geplante Modernisierung eines Data Warehouse neu auszurichten. Es hat sich jedoch in der Praxis als hilfreich erwiesen, dabei "sanft" vorzugehen und die neuen Konzepte in Form einzelner Projekte - also schrittweise - zu evaluieren und auf den individuellen Bedarf zuzuschneiden.