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).
- Basis: 2864 Befragte.jpg
2864 Anwender hat Crisp Research zum Thema In-Memory befragt: 42 Prozent haben sich mit der Technik bereits beschäftigt. Doch nur für 150 von ihnen steht der Einsatz von SAP HANA fest. - Eingesetzte Datenbank.jpg
Vor allem Microsoft- und Oracle-Systeme sind die bevorzugten Datenbanken in den befragten Anwenderunternehmen. - Pläne für In-Memory-Datenbanken
Gut vier von zehn Befragten haben bereits eine In-Memory-Datenbanktechnik evaluiert. Allerdings sagen auch fast 60 Prozent, dass derzeit eine In-Memory-basierte Datenverarbeitung für sie nicht von Interesse sei. - Entscheidung in Sachen HANA
200 Anwenderunternehmen von den 2864 Befragten beschäftigen sich intensiver mit SAP HANA. Rund ein Drittel setzt das System bereits produktiv ein. Fast die Hälfte prüft noch und knapp jeder Fünfte kann sich noch nicht so recht entscheiden. - Ziel: HANA als Beschleuniger.jpg
Mehr als die Hälfte der HANA-Interessenten erwartet, dass das In-Memory-System die Unternehmensprozesse beschleunigt. Außerdem soll HANA dabei helfen, Systeme zu konsolidieren, um so die Komplexität zu verringern. Immerhin jeder Achte ist unzufrieden mit Oracles Lizenzpolitik und will deshalb den Anbieter wechseln. - Strategische Ziele.jpg
Vor allem im Umfeld von Big Data, dem Customer Relationship Management (CRM) und Industrie 4.0 sowie dem Internet der Dinge solle HANA zum Einsatz kommen. Simulationen neuer Geschäftsmodell spielen bei der strategischen Zielsetzung allerdings noch keine besonders große Rolle. - HANA-Einführung.jpg
Das Gros der HANA-Interessenten will das System für Business Intelligence (BI) und das Reporting einsetzen. Der Einsatz als Betriebsplattform für neue Workloads kommt nicht einmal für ein Viertel der Unternehmen in Frage. Als Innovations-Show-Case spielt HANA derzeit nur eine untergeordnete Rolle. - HANA-Architektur.jpg
Die meisten Anwender sehen HANA derzeit als ergänzendes System und Beschleuniger für ihre bestehenden Architekturen. Nur jeder Fünfte der Befragten will HANA als Primär-System einsetzen und bestehende Systeme abschalten. - Anwendern fehlt HANA-Knowhow.jpg
Vor allem das fehlende Knowhow für HANA im eigenen Haus wie bei potenziellen Partnern bereitet den Verantwortlichen Kopfzerbrechen. Außerdem fehlen den Befragten Migrationskonzepte für Nicht-SAP-Systeme. - Anwender monieren technische Probleme.jpg
Neben den Klassikern wie Zeit- und Budget-Überschreitungen beklagen die HANA-Anwender auch Probleme mit der Systemstabilität sowie nicht erfüllte Erwartungen hinsichtlich der Leistung. - Anwendern ist HANA zu teuer.jpg
Verbesserungspotenzial sehen die Befragten vor allem bei den Kosten. Sie wünschen sich ein attraktiveres Lizenzmodell, mehr Out-of-the-Box-Lösungen sowie günstigere Wartungskosten.
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.