Real-Time Data Warehousing - Friedrich-Schiller

Real-Time Data Warehousing - Friedrich-Schiller

Real-Time Data Warehousing
Möglichkeiten und Grenzen echtzeitnaher Analysesysteme
von Lisa Wenige
Betreuerin: Dipl-Math. Katharina Büchse
Seminar „Data Warehousing und Analytische Datenbanken“
Friedrich-Schiller-Universität Jena
27.02.2012
Inhaltsverzeichnis
1
2
3
4
5
6
Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Real-time Data Warehouses: eine Begriffsbestimmung . . . . . . . . . . . . . . .
Klassifikation der Latenzzeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1 Organisatorische Latenz I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Infrastrukturlatenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Organisatorische Latenz II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Beschleunigungspotentiale: Möglichkeiten und Grenzen . . . . . . . . . . . . .
4.1 Beschleunigungspotentiale im ETL-Bereich . . . . . . . . . . . . . . . . . . .
4.1.1 Near-Realtime-Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.2 Direct-Data- oder Trickle-Feed-Ansatz . . . . . . . . . . . . . . . . . .
4.1.3 Partitionsbasierter Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.4 Cachebasierter Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.5 Enterprise Application Integration . . . . . . . . . . . . . . . . . . . . .
4.2 Beschleunigungpotentiale im Analysebereich . . . . . . . . . . . . . . . . . .
4.2.1 Materialisierte Sichten und Präaggregation . . . . . . . . . . . . . .
4.2.2 Rechtebeschränkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.3 Priorisiertes Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.4 Just-in-Time-Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Die Integration von OLTP und OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
4
5
5
6
6
6
7
7
8
8
9
9
10
10
12
12
12
14
15
1
Einführung
Üblicherweise sind Transaktions- und Analysedatenbanken aufgrund ihrer unterschiedlichen Zielstellungen und Einsatzgebiete voneinander getrennt. In klassischen Systemen des Online Transactional Processing (OLTP) werden flüchtige,
sich schnell verändernde Daten ständig neu eingepflegt, angepasst und gelöscht.
Die anfallenden Geschäftsprozessinformationen sollen dabei immer schreibbar
sein und den aktuellen Systemzustand widerspiegeln. Währenddessen arbeiten
Datenbanken, die auf die Prinzipien des Online Analytical Processing (OLAP)
ausgerichtet sind, mit historisierten Informationen. Bei ihnen geht es v. a.
darum, die Transaktionsdaten so zu analysieren, dass adäquate Managemententscheidungen getroffen werden können.
Klassische Data-Warehouse-Systeme weisen daher eine eher statische Struktur
auf. Diese eignet sich zwar gut für lesende Zugriffe, sieht aber keine kontinuierliche Datenintegration vor. Aktualisierungen werden in diesem Zusammenhang
nur periodisch vorgenommen [SaBe08, S. 49].
Allerdings ist mit der sich immer schneller vollziehenden Informationsvermehrung und den kürzeren Produktlebens- und Innovationszyklen der Wirtschaftswelt die Datenaktualität zu einem wettbewerbskritischen Faktor geworden. Unternehmen aus dem Bereich E-Commerce, der Luftfahrt- oder der Finanzindustrie müssen mit einer gestiegenen Umweltdynamik umgehen, schnell Trends
erkennen und auf kurzfristige Ereignisse unmittelbar und adäquat reagieren
[BaGü09, S. 101]. In diesem Zusammenhang können sich nur solche Firmen gegen
die Konkurrenz behaupten, die ihre Entscheidungen mit Hilfe einer Datenbasis
treffen, die sich auf dem neuesten Stand befindet. Dabei wird davon ausgegangen, dass Maßnahmen umso wirkungsvoller sind, je schneller sie ergriffen werden
[Shel06, S. 426].
Aus diesem Grund entwickelt man seit einiger Zeit Strategien und Technologien,
die die Zeitverzögerungen in den einzelnen Data-Warehousing-Phasen reduzieren
sollen. Solche Lösungen werden im Umfeld der Analytischen Datenbanken auch
als Real-time Data Warehouses bezeichnet.
In der vorliegenden Arbeit soll es darum gehen, die Konzepte von EchtzeitOLAP-Systemen vorzustellen und kritisch zu betrachten. Dafür wird in Abschnitt 2 zunächst eine genaue Begriffsbestimmung vorgenommen. Abschnitt 3
wird sich anschließend damit auseinandersetzen, welche Latenzzeiten und Beschleunigungspotentiale es bei der Aktualisierung von OLAP-Datenbanken gibt.
Im Anschluss daran sollen mögliche Maßnahmen und Echtzeit-Architekturen
genauer vorgestellt werden (Abschnitt 4). In Abschnitt 5 erfolgt dann die Vorstellung eines Ansatzes, bei dem OLTP- und OLAP-Datenbanken in einem integrierten System zusammengeführt werden. Die Arbeit endet mit einem Fazit,
welches die in den einzelnen Abschnitten gewonnenen Erkenntnisse zusammenfasst und abschließend bewertet.
3
2
Real-time Data Warehouses: eine Begriffsbestimmung
Um die Echtzeitdimension im Umfeld der Analytischen Datenbanken genauer
zu charakterisieren, existieren zahlreiche Definitionen. So schreiben z. B. Lehner
und Thiele:
„The real-time aspect in the context of data warehouses describes a
new processing model where every change is automatically captured and
pushed into the data warehouse.“ [LeTh09, S. 1]
Diese Begriffsbestimmung verdeutlicht, dass das primäre Ziel eines EchtzeitData-Warehouses die Datenaktualität ist. Jede Änderung, die sich in den Transaktionssystemen vollzieht, soll ohne Verzögerung an die analytischen Komponenten weitergeleitet werden. Allerdings befindet sich in der obenstehenden Definition bereits ein Vorgriff auf die mögliche Implementierung eines solchen EchtzeitData-Warehouses. Wenn Lehner und Thiele schreiben, dass neue Transaktionsinformationen automatisch an die Zielsysteme im „Push-Modus“ propagiert werden, dann wird der Bezugsrahmen der Definition bereits sehr eingeschränkt. Tatsächlich gibt es verschiedene Implementierungsmöglichkeiten und Architekturen,
mit denen ein Echzeit-Data-Warehouse realisiert werden kann (s. Abschnitt 4).
Aus diesen Gründen ist die folgende von Thiele gewählte Definition geeigneter:
„Der Begriff Echtzeit charakterisiert die Fähigkeit eines Data Warehouses [...] Änderungen in der Realwelt bzw. der Diskurswelt zeitnah im
Data Warehouse abzubilden.“ [Thie10, S. 50]
Diese Erklärung beschreibt ein Data Warehouse zum einen unabhängig von der
jeweiligen Realisierung und relativiert zum anderen den Echtzeitbegriff. Tatsächlich wird es bei der Trennung von OLTP- und OLAP-Datenbanken kaum
möglich sein, die analytischen Systeme mit den Transaktionsdaten ohne jegliche Zeitverzögerung zu versorgen. Die Bezeichnung „zeitnah“ verdeutlicht dabei,
dass Änderungen so schnell wie möglich propagiert werden sollten. Nicht ohne
Grund gibt es daher im Englischen auch den Begriff des „Near Real-time“ Data
Warehouse [JöDe10]. Daneben existieren Bezeichnungen, wie „Right-time“ oder
„On-time“ , die zeigen, dass die Forderung nach Datenaktualität nicht Selbstzweck sein sollte [ThPL08] [Baer04]. Vielmehr ist es wichtig, dass die Bereitstellung hochaktueller Daten bedarfsorientiert erfolgt. Es muss demnach eine
auf die entsprechenden Anwenderbedürfnisse gerichtete Datenauswahl getroffen
werden. Für diese Informationen erfolgt dann die Bereitstellung mit möglichst
geringen Verzögerungsraten [BaGü09, S. 101] [ThPL08, S. 456]. Der Begriff der
Datenaktualität wird in diesem Zusammenhang dabei häufig synonym mit dem
englischen Ausdruck „Data Freshness“ verwendet [LeTh09].
In Abgrenzung zu den bereits vorgestellten Konzepten gibt es außerdem das Konzept des „Active Data Warehouse“ [MNSV09]. In einer solchen Datenbank werden
auf Grundlage hochaktueller Daten automatisch Entscheidungen getroffen und
im Falle der Über- oder Unterschreitung bestimmter Grenzwerte Maßnahmen
ausgelöst. So ist es z. B. vorstellbar, dass in einem Multimedia-Online-Shop bei
4
Nichterreichen einer vorgegebenen Verkaufszahl in einem bestimmten Zeitintervall automatisiert eine Preisreduktion erfolgt. Eine aktuelle Datenbasis, die mit
Real-time-Technologien geschaffen wurde, ist für dieses Vorgehen eine unmittelbare Voraussetzung.
In dieser Arbeit soll es allerdings vorrangig um die Betrachtung von Methoden
zur Realisierung eines Echtzeit-Data-Warehouses gehen.
3
Klassifikation der Latenzzeiten
Im Zuge der Phasen des Data Warehousing-Prozesses können zahlreiche Verzögerungen auftreten. Im Folgenden werden unter Zuhilfenahme der von Shelp
beschriebenen und in Abb. 1 dargestellten Einteilung die verschiedenen Latenzzeiten vorgestellt.
Abbildung 1. Verzögerungspotentiale (in Anlehnung an [Shel06, S. 426])
3.1
Organisatorische Latenz I
Diese Art der Zeitverschiebung setzt sich aus der Wahrnehmungslatenz und der
Verzögerung bei der Informationserfassung zusammen. Die Wahrnehmungslatenz beschreibt die Zeitdifferenz vom Auftreten eines Ereignisses in der Realwelt
bis zu dem Zeitpunkt, an dem ein Verantwortlicher realisiert, dass eine Veränderung eingetreten ist. In einem Reisebüro, in dem der zuständige Mitarbeiter per
E-Mail eine Aufforderung zur Buchung einer Reise erhält, ist diese Verzögerung
5
relativ groß. In einem Multimediahandel, in dem ein Kunde selbst die Bestellung tätigt, ist sie hingegen geringer. Auch bei der Erfassung der Veränderungen
im jeweiligen Transaktionsverwaltungssystem können Latenzzeiten auftreten. So
dauert es z. B. eine Weile, bis alle zu einer Reisebuchung gehörenden Informationen in das Datenbankmanagementsystem übertragen wurden.
3.2
Infrastrukturlatenz
Die Infrastrukturlatenz setzt sich aus der Ladelatenz und der Analyselatenz zusammen. Sie charakterisiert die Zeitverschiebungen, die bei der Übertragung und
Analyse der Daten im eigentlichen Data Warehouse auftreten. Diese Formen der
Verzögerung müssen daher, im Gegensatz zur Organisatorischen Latenz I, v. a.
auf der technischen Ebene gelöst werden. Im Fall der Ladelatenz geht es dabei darum, die Daten im Zuge des „Extract, Transfer, Load“ -Prozesses (ETL)
schneller bereitstellen zu können. Ein Multimediaversandhandel muss in dieser
Phase z. B. die Informationen aus den Transaktionssystemen seiner verteilten
Onlineshops und aus den Datenbankmanagementsystemen seiner Einzelhandelszweigstellen zusammenführen. Während der Datenbereinigung und -integration
können in diesem Zusammenhang erhebliche Zeitverzögerungen auftreten, da die
heterogenen Daten an ein einheitliches Schema angepasst und in die bestehenden
Datenstrukturen eingefügt werden müssen.
Im Gegensatz dazu, geht es bei der Analyselatenz um die Zeit, die ab der Bereitstellung im Data Warehouse verstreicht, bis ein Auswertungsergebnis verfügbar
ist. Fragen der Datenhaltung und der Anfrageoptimierung spielen in diesem Bereich eine entscheidende Rolle.
Mechanismen und Architekturlösungen zur Vemeidung von Infrastrukturlatenzen werden in Abschnitt 4 genauer behandelt.
3.3
Organisatorische Latenz II
In diesem Komplex werden alle Latenzzeiten zusammengefasst, die von der Bereitstellung eines Analyseergebnisses vergehen, bis eine konkrete Maßnahme getroffen wird. Wenn sich z. B. in einem Data-Warehouse-Bericht abzeichnet, dass
ein Produkt von einer bestimmten Kundengruppe verhältnismäßig wenig nachgefragt wird, müssten sich die Verantwortlichen für eine adäquate Reaktion entscheiden und diese manuell veranlassen. Die Verzögerungen, die in diesem Zusammenhang auftreten, können erheblich sein. Das bereits geschilderte Konzept
des „Active Data Warehouse“ verspricht für diese Art der Latenz zumindest partiell Abhilfe zu schaffen.
4
Beschleunigungspotentiale: Möglichkeiten und Grenzen
Klassische Data-Warehouse-Systeme bringen ihre Daten oftmals nur täglich auf
den neuesten Stand [BaGü09, S. 102]. Es finden sich sogar Analytische Datenbanken, die lediglich eine Aktualität auf Wochen- oder Monatsbasis besitzen
6
[Thie10]. Während eines Updatevorgangs werden in einem sog. „batch“ oder
„bulk load“ alle seit dem letzten Ladeprozess getätigten Änderungen in das Data
Warehouse übernommen [Shel06, S. 426]. Während des ETL-Prozesses können
die Benutzer und Applikationen des OLAP-Systems in der Regel nicht auf die
Analysedaten zugreifen [SaBe08, S. 49].
Nachfolgend werden Konzepte vorgestellt, die helfen sollen, Transaktionsdaten
schneller im Data Warehouse bereitzustellen.
4.1
Beschleunigungspotentiale im ETL-Bereich
Eine Beschleunigung der Datenintegration ist häufig durch die Optimierung
der in diesem Zusammenhang stattfindenden Prozessoperationen möglich. Dabei muss allerdings berücksichtigt werden, dass eine höhere Aktualität in diesem
Bereich zu Lasten der Datenstabilität geht. Da die Informationen teilweise kontinuierlich in das Data Warehouse eingespeist werden und keine festen Publikationszeitpunkte bestehen, kann es zu Inkonsistenzen und Schemaverletzungen
kommen [Thie10, S. 57]. Zudem haben die gesteigerten Ladegfrequenzen eine
Erhöhung der Analyselatenz zur Folge. Die ständigen Aktualisierungen führen
dazu, dass entweder das OLAP-System vorübergehend nicht verfügbar ist oder
sich die Antwortzeiten aufgrund des gestiegenen Workloads erhöhen [Thie10, S.
56].
4.1.1 Near-Realtime-Ansatz Es wird Transaktionsdaten geben, die zwar
aktuell sein müssen, deren Verfügbarkeit aber nicht unmittelbar erfolgskritisch
ist. So können z. B. die Verkaufszahlen des Multimediahandels auf einem Stand
gehalten werden, der mehrmals am Tag, ggf. auch stündlich, erneuert wird. Zu
diesem Zweck müssen lediglich die Ladefrequenzen der Batchoperationen erhöht
werden.[Lang04]
Um festzustellen, welche Daten sich seit dem letzten Update verändert haben,
wird eine Monitoring-Komponente eingesetzt, die die Datenmanipulationen der
OLTP-Systeme überwacht. Im Zuge des Monitoring werden in den Transaktionssystemen veränderte Datensätze entsprechend markiert. Für diese Vorgehensweise existieren verschiedene Verfahren. Im Near-Realtime-Warehousing sind dabei
v. a. die Ansätze des timestampbasierten, des logbasierten und des snapshotbasierten Monitoring relevant [BaGü09, S. 50].
• timestampbasiert: Jedem Datensatz werden in der Quelldatenbank Zeitstempel zugeordnet. Im Fall einer Änderung erhält ein Tupel eine neue Zeitmarke.
Beim nächsten Batch-Load werden dann die Transaktionsdaten in das Data
Warehouse integriert, deren Timestamps jünger sind als der Zeitpunkt des
letzten Ladeprozesses.
• logbasiert: Im Zuge dieses Verfahrens arbeitet man mit den Logdateien der
Transaktionsdatenbank, um die zu ladenden Tupel zu identifizieren.
7
• snapshotbasiert: Beim Snapshot-Verfahren wird der aktuelle Zustand der
Quelldaten in periodischen Abständen in eine Datei (Snapshot) geschrieben. Um schließlich die für das Batching relevanten Datensätze zu ermitteln,
erfolgt eine Deltaberechnung der Nettoänderungen zwischen den einzelnen
Snapshots.
4.1.2 Direct-Data- oder Trickle-Feed-Ansatz In diesem push-basierten
Verfahren erfolgt eine synchrone Aktualisierung. Die Nettoänderungen werden,
sobald sie in den Transaktionssystemen auftauchen, direkt in die OLAP-Datenbank übertragen [Lehn03, S. 181 f.]. Zu diesem Zweck muss das Datenbankmanagementsystem aktive Mechanismen wie Trigger unterstützen. Sobald eine Manipulation erfolgt, werden die entsprechenden Tupel in die Faktentabellen des Data
Warehouses eingefügt [BaGü09]. Bei diesem Ansatz liegen die Daten minutenoder sogar sekundenaktuell vor, da sie kontinuierlich in die Analysedatenbank
geschrieben werden. Zudem sind die in das OLAP-System zu übertragenden
Datenvolumen nicht sehr umfangreich. Aus diesem Grund kann das Data Warehouse auch während der inkrementellen Aktualisierung genutzt werden.[FaSa10]
Allerdings skaliert das Verfahren nicht gut. Komplexe OLAP-Anfragen können
schnell mit kontinuierlichen INSERT-Operationen in Konflikt geraten. Dies führt
zu einer Verschlechterung der Anfrageperformanz [Lang04].
4.1.3 Partitionsbasierter Ansatz Auch bei diesem Ansatz wird die Aktualisierung inkrementell vorgenommen. Sobald eine Änderung bei den Transaktionsdaten erfolgt ist, wird sie unmittelbar an das OLAP-System propagiert.
Allerdings werden die Informationen in einer Übergangstabelle im Data Warehouse zwischengespeichert, bevor sie in die historisierten Faktentabellen geladen
werden [Lang04].
Santos und Bernardino beschreiben eine Vorgehensweise, die diesen Ansatz weiter spezifiziert [SaBe08, S. 49ff.]. Sie schlagen vor, für jedes Tupel, für das in
der Datenquelle ein COMMIT erfolgt ist, einen Trigger auszulösen, der eine Datentransformation initialisiert. Die auf diese Weise erzeugten Datensätze werden
vorübergehend in die Real-time-Tabellen des Data Warehouses geschrieben. Eine
solche Tabelle besitzt im Unterschied zu den eigentlichen Faktentabellen keine
Indizes, Primärschlüssel oder sonstige Integritätsbedingungen. Auf diese Weise
ist es möglich, eine bessere Schreib- und Leseperformance zu erzielen. Zusätzlich
wird für jede Änderung, die bei ein und derselben Zelle in der temporären Tabelle
erfolgt, ein Zähler inkrementiert. So müssen die Daten nicht erst überschrieben
werden. Stattdessen wird lediglich derjenige Datensatz mit dem höchsten Zähler
in das Data Warehouse übernommen. Für die Abfrage werden dann ggf. historisierte und temporäre Daten gejoint (s. Abschnitt 4.2.4). Vorteilhaft ist zudem,
dass für einen Anfrage-Befehl, welcher nur aktuelle Daten benötigt, ausschließlich die Replikatabellen abgefragt werden müssen.
Eine Übertragung der Daten aus der Partition in das eigentliche Data Warehouse sollte immer dann erfolgen, wenn ein erhöhtes Aufkommen an Echtzeitdaten
zu einer verminderten Anfrageperformance führt. Dies geschieht, da der Auf8
wand der Zusammenführung von Datenmengen aus den dauerhaften und den
temporären Tabellen mit der Zunahme der Informationen ansteigt. In diesem
Zusammenhang ließe sich für die Antwortzeiten z. B. ein Schwellwert festlegen,
den es nicht zu unterschreiten gilt. Es ist auch möglich, im Zuge des DataWarehouse-Designs andere Ladebedingungen zu spezifizieren. So wäre es z. B.
denkbar, die Temporärdaten immer dann in die Faktentabellen zu übertragen,
wenn eine bestimmte Tupel-Anzahl erreicht oder eine gewisse Zeitspanne überschritten ist. Die Einfügeoperationen gehen einher mit dem Wiederaufbau aller
Indizes und der Aktualisierung von Aggregationen und materialisierten Sichten.
4.1.4 Cachebasierter Ansatz Eine weitere Möglichkeit ist es, die neu hinzukommenden Transaktionsdaten vorübergehend in einem Real-time Data Cache
(RTDC) außerhalb des eigentlichen Data Warehouses zu speichern. Dieser Cache ist ein eigener Datenbankserver, in dem die Relationen den Faktentabellen
des historisierten OLAP-Systems gleichen. Allerdings werden nur solche Tabellen vorgehalten, die für die Real-time-Daten benötigt werden [SSPK09].
Diese Architektur eignet sich für alle Arten von Applikationen, die entweder mit
einem großen Aufkommen von Echtzeitdaten umgehen müssen oder eine gesteigerte Anfrageperformanz benötigen. Sollten Analyseprozesse sowohl auf historische als auch auf aktuelle Daten angewiesen sein, können die Daten mit Hilfe
einer Just-In-Time-Integration (s. Abschnitt 4.2.4) zusammengeführt werden.
Wie im Fall des partitionsbasierten Ansatzes müssen die Echtzeitdaten periodisch in das eigentliche Data Warehouse übertragen werden. Bei beiden Verfahren ist im Zuge des Ladeprozesses mit erhöhtem Workload und einer Beeinträchtigung der Antwortzeiten zu rechnen. Während bei der partitionsbasierten Herangehensweise, aufgrund der fehlenden Restriktionen in den Temporärtabellen,
zusätzliche Transformationen nötig sind, treten beim Laden der RTDC-Daten
v. a. Verzögerungen auf, weil die Tupel aus einem separaten System übertragen
werden [Lang04].
4.1.5 Enterprise Application Integration Die Ladeprozesse des Data
Warehouses können auch mit Hilfe bereits integrierter Transaktionsdaten beschleunigt werden. Das kann über die Umsetzung einer Enterprise-ApplicationIntegration-Architektur (EAI) erfolgen. Diese Form der Prozessintegration verknüpft die operativen Prozesse der Transaktionssysteme redundanzfrei miteinander. Im Beispiel des Multimediahandels würden Bestell-, Liefer- und Rechnungsinformationen nicht in separaten Softwaresystemen und Datenbanken gehalten,
sondern ganzheitlich in einem gemeinsamen System erfasst und bearbeitet werden. Die integrierten Daten ließen sich dann von der EAI-Schicht in das Data
Warehouse übertragen. In diesem Stadium wäre bereits ein Großteil der Bereinigungsoperationen, wie z. B. Formatänderungen, schon getätigt [Shel06, S.
432].
9
4.2
Beschleunigungpotentiale im Analysebereich
Klassische OLAP-Systene arbeiten üblicherweise auf statischen, nicht veränderlichen Daten. In einem Echtzeit-Data-Warehouse besteht das Problem, dass
gleichzeitig lesende und schreibende Zugriffe verarbeitet werden müssen. Dies
führt dazu, dass die Daten Inkonsistenzen aufweisen und damit instabil sein
können. Darüber hinaus ist es möglich, dass die kontinuierlichen Ladeprozesse Anfragen blockieren oder Antwortzeiten verlängern. Auf diese Weise führt
die gesteigerte „Data Freshness“ im ETL-Bereich des Data Warehouse zu einer
Belastung der Anfrage-Performance. Gleichzeitig greifen Mechanismen, die der
Anfrageoptimierung dienen, auf historisierte Daten zurück. So könnten z. B.
aggregrierte Daten nicht mit den bereits geladenen Echtzeitinformationen übereinstimmen. [Lang04].
Die richtige Strategie im Spannungsverhältnis zwischen Datenaktualität und verringerter Anfragelatenz muss von Fall zu Fall abgewogen werden. In diesem Zusammenhang sollten Systembenutzer in den Designprozess einbezogen werden,
um Anforderungen an die “Data Freshness“ und gewünschte durchschnittliche
Antwortzeiten zu spezifizieren [Thie10, S. 56].
Im Folgenden werden daher sowohl Ansätze vorgestellt, die die Anfragelatenzen
verringern, als auch solche, die darauf ausgerichtet sind, aktuelle Daten adäquat
abzufragen.
4.2.1 Materialisierte Sichten und Präaggregation Anfragen in OLAPSystemen sind weitaus komplexer, als in OLTP-Datenbanken. Wenn die Daten
eines Data Warehouses in relationen Strukturen abgelegt sind (Relational OLAP
- ROLAP), dann müssen sie anhand mehrerer Dimensionen zusammengefügt
und über viele Hierarchieebenen hinweg aggregiert werden [PaKYJ02, S. 379].
Dies wird auch als „Snowflake-Schema“ bezeichnet. Antwortzeiten von Abfragen
können dabei im Minutenbereich liegen und daher nicht den Echtzeitzustand der
Daten widerspiegeln [Lang04].
Eine verbreitete Strategie, um diesem Problem zu begegnen, ist die Speicherung
häufig abegfragter Ergebnisse in bereits gejointen Relationen. Diese Tabellen
werden auch materialisierte Sichten (materialized views) genannt und dienen der
Zugriffsbeschleunigung. Abb. 2 zeigt das Star-Schema eines potentiellen Data
Warehouses. Dieses Schema könnte die Datengrundlage im OLAP-System des
bereits erwähnten Multimediahandels sein.
Geht man z. B. davon aus, dass die Vertriebsmanager Angaben bzgl. der täglichen Umsatzzahlen aller Einzelhandelszweigstellen in verschiedenen Städten seit
Beginn des Jahres benötigen, dann könnte eine materialisierte Sicht folgendermaßen aussehen (das Beispiel ist angelehnt an [PaKYJ02, S. 381]).
10
Abbildung 2. Star-Schema eines potentiellen Data Warehouse [PaKYJ02, S.
380]
CREATE VIEW Daily_Sales_2012 AS
SELECT Store.city, Time.day, sum(Sales.sales_dollar)
FROM Store, Time, Sales
WHERE Sales.store_id=Store.store_id AND Sales.time_id=Time.time_id
AND Time.year >= 2012
GROUP BY Store.city, Time.day
Auf diese Weise sind die aggegregierten Ergebnisse der zusammengefügten Tabellen bei zukünftig anfallenden Anfragen schon gespeichert und können schnell
abgerufen werden. Allerdings steht dieser Ansatz der Anfragebeschleunigung in
Konflikt mit der kontinuierlichen Aktualisierung. Es müsste sichergestellt werden, dass eine Erneuerung der materialisierten Sichten immer dann erfolgt, sobald zusätzliche Echtzeitdaten in das Data Warehouse eingefügt werden. Ein
solches Vorgehen ist sehr aufwändig und kann dazu führen, dass die Beschleunigung der Antwortperformance durch die häufigen Neuberechnungen der Sichten
wieder verloren geht.
Die provisorische Speicherung aller denkbaren Kombinationen von Aggregationen (Multidimensional OLAP - MOLAP) nimmt darüber hinaus viel Speicherplatz in Anspruch. Aus diesem Grund wird häufig von dem Konzept der anwenderorientierten Voraggregation Gebrauch gemacht, bei dem nur die wichtigsten
Berechnungen im Vorfeld stattfinden. Diese gemischte Vorgehensweise wird auch
als Hybrides OLAP (HOLAP) bezeichnet [PeJe01, S. 43 f.] Allerdings ist darauf
hinzuweisen, dass in den nächsten Jahren durch die zusätzlichen Möglichkeiten
der Hardwarebeschleunigung mit einer Verschiebung zugunsten des ROLAP zu
11
rechen ist, da sich Aggregrationen zunehmend schneller im Hauptspeicher berechnen lassen (s. Abschnitt 5).
4.2.2 Rechtebeschränkungen Eine weitere Möglichkeit, um die Anfragegeschwindigkeiten des OLAP-Systems zu verbessern, ist eine Rechteverwaltung,
die es einigen Nutzern verbietet, Anfragen auf bestimmten Daten durchzuführen
oder komplexe Analysen zu starten. So müsste z. B. das obere Management des
Multimediahandels nicht unbedingt Zugriff auf hochaktuelle Daten haben. Denn
die langfristige, strategische Planung lässt sich ggf. ohne die Absatzzahlen der
letzten Tage oder Stunden durchführen. Für die Marketingabteilung, die auch
auf kurzfristige Trends reagieren muss, ist der Zugriff auf die Echtzeitdaten hingegen relevant. Rollenbasierte Zugriffsbeschränkungen ermöglichen demnach die
Verringerung des Workloads und die Verbesserung der Antwortzeiten [Lang04].
4.2.3 Priorisiertes Scheduling Das prioritätsgesteuerte Laden bietet eine
Möglichkeit, um den Workload im Data Warehouse auf einem niedrigen Level zu
halten und trotz allem die Abfrage hochaktueller Daten zu gewährleisten. Lehner und Thiele stellen ein Verfahren vor, bei dem nur Echtzeitaktualisierungen
vorgenommen werden, die Relevanz für die aktuellen OLAP-Anfragen besitzen
[LeTh09].
Dazu wird angenommen, dass die kontinuierlich anfallenden Echzeitdaten vorübergehend in einer „Update-Queue“ und die an das System gestellten Anfragen in einer „Query-Queue“ zwischengespeichert werden. Unter Berücksichtigung
der von den Systemnutzern vorgegebenen Spezifikationen wird jeder Anfrage
der „Query-Queue“ eine Priorität zugewiesen. Für die Abfrage mit der höchsten Priorität wird ermittelt, welche der sich in der „Update-Queue“ befindenden
Transaktionsdaten zunächst in das Data Warehouse geladen werden müssen. Auf
diese Weise können dann die hochaktuellen Daten aus dem OLTP-System „right
on time“ bereitgestellt werden. Allerdings ist an dieser Stelle darauf hinzuweisen,
dass das geschilderte Vorgehen bei Anfragen, die viele Aktualisierungen benötigen, zu erheblichen Verzögerungen führt. Daher lässt sich das Konzept nur bei
einem geringen Aufkommen an Echtzeitdaten sinnvoll einsetzen.
4.2.4 Just-in-Time-Integration Im Gegensatz zu den in den vorherigen
Abschnitten vorgestellten Konzepten behandelt der kommende Abschnitt kein
Verfahren, das direkt darauf abzielt, die Antwortzeiten des OLAP-Systems zu
verbessern oder den Workload zu senken. Im Folgenden wird vielmehr die Frage zu beantworten sein, inwieweit die Real-Time-Daten durch entsprechende
Anfrage-Tools zeitnah genutzt werden können.
Ein Ansatz, um dies zu erreichen, ist die Just-in-Time-Integration. Bei diesem
Verfahren werden die Daten erst zum Zeitpunkt der Anfrage zusammengeführt.
Im Unterschied zum Ladeprozess beim priorisierten Scheduling werden die während der Anfrage in das Data Warehouse überführten Daten allerdings nicht
persistent gespeichert.
12
Das Verfahren der Just-in-Time-Integration bietet den Vorteil, dass RealtimeInformationen in jeder Phase des ETL-Prozesses (und somit auch noch nicht
integrierte Daten) abgerufen werden können. Abb. 3 zeigt das Schema einer solchen idealtypischen Architektur.
Abbildung 3. Referenzarchitektur eines Echtzeit-Data-Warehouses[Thie10, S.
52]
Nach dieser Vorstellung werden die Anfragen aus dem OLAP-System über die
Vermittlungsschicht auf die einzelnen Prozessstufen umgeleitet. So ist es möglich, die schon extrahierten aber noch unbereinigten Daten aus dem Arbeitsbereich abzufragen. In weiter fortgeschrittenen Phasen des Extraxt-TransferLoad-Prozesses, in denen z. B. bereits Formatanpassungen und Duplettenentfernungen erfolgt sind, kann ein Abruf aus der konsolidierten Basisdatenbank
stattfinden. Zudem steuert die Vermittlungsschicht die Ausgabe von Daten aus
dem Data Warehouse, den Data Marts und dem Reporting-Layer. Die vorgestellte Architektur stellt besonders hohe Anforderungen an den Query-Manager.
Er hat zum einen die Aufgabe, festzustellen, welche Real-Time-Komponenten
die Anfrage enthält. Zum anderen muss er den Anfragebefehl so modifizieren,
dass die Echtzeitdaten auch tatsächlich ermittelt werden können. Dafür ist es erforderlich, dass der Query-Manager die Schemata der Real-Time-Informationen
an den verschiedenen Stationen des ETL-Prozesses kennt [Lang04]. Werden z.
B. Daten abgefragt, die sich noch im Transformationsprozess befinden, müssten
die Anfragen, entsprechend den Schemaanforderungen der einzelnen Prozessstufen, umgeschrieben werden (engl. query-rewrite) [Thie10, S. 52]. Auf diese Weise
könnten OLAP-Anfragen, die beispielsweise in Form einer “Multidimensional
Expression“ (MDX)[Nola99] gestellt sind, in SQL-konforme Teilanfragen zerlegt
und zu den Schichten geschickt werden, die in einer eindimensionalen relationalen Struktur vorliegen.
13
5
Die Integration von OLTP und OLAP
Klassischerweise sind OLAP und OLTP in zwei getrennten Systemen organisiert. Die bisher geschilderten Ansätze haben Wege aufgezeigt, um die Prozesse
im Rahmen dieser Architektur zu beschleunigen. Im Folgenden wird hingegen
ein Verfahren vorgestellt, das das Ziel verfolgt, transaktions- und analyseorientierte Operationen in einem System zu integrieren. Hierzu stellt Plattner ein
Datenbankmanagementsystem vor, welches im Wesentlichen auf einer spaltenorientierten In-Memory-Datenhaltung basiert [Plat09].
Traditionellerweise werden die Informationen einer transaktionsverwaltenden Datenbank tupelweise (d. h. in Form der einzelnen Tabellenzeilen) gespeichert. So
können Datensätze effizienter aktualisiert und eingefügt werden. Demgegenüber
erfolgt die Speicherung der OLAP-Daten weitestgehend spaltenorientiert. Auf
diese Weise lassen sich reine Lesezugriffe und Aggregationen schneller durchführen [Thie10].
Plattner geht nun davon aus, dass die spaltenorientierte Speicherstrategie ebenso
für ein integriertes System anwendbar sein könnte. Seine Argumentation ist, dass
sich die höheren Prozessorgeschwindigkeiten moderner Rechner und die Möglichkeit einer In-Memory-Datenhaltung ausnutzen lassen, um sowohl Lesezugriffe
als auch update-intensive Prozesse in einem gemeinsamen Datenbankmanagementsystem zu organisieren. Zudem ermöglicht die Vorhaltung der Tabellen im
Hauptspeicher eine schnellere Verarbeitung von Join-Operationen und Aggregationen. Dabei werden die Berechnungen nicht mehr im Voraus getätigt, sondern
zur Laufzeit generiert.
Zudem stellt Plattner für seinen Systementwurf einen „insert-only-Ansatz“ vor.
Bei dieser Vorgehensweise finden keine Löschoperationen statt. Stattdessen erhalten neue Zellenwerte einen aktuellen Zeitstempel. So können Einfüge- und
Veränderungsoperationen schneller getätigt werden. Für die Abfrage und Analyse der Daten werden dann nur solche Werte berücksichtigt, deren Zeitstempel
zum Beginn der Anfrage kleiner, als der aktuelle Timestamp sind. Außerdem können mit einem solchen Vorgehen aufwändige Sperrverfahren vermieden werden.
Stattdessen bestimmen Zeitstempel über die Abarbeitungsreihenfolge nebenläufiger Operationen. Dieses Verfahren wird auch als „pessimistisches Sperren“ bezeichnet. Für den Fall, dass auf einem Tupel Datenmanipulationen ausgeführt
werden, wird der Zeitstempel einer neuen Anfrage automatisch dekrementiert.
Auf diese Weise wird der gerade bearbeitete Datensatz aus der Analyse ausgeschlossen. Um die Datenvolumen im Hauptspeicher auf einem möglichst niedrigen Niveau zu halten, erfolgt die Sicherung historischer Daten auf einem separaten persistenten Speichermedium.
In dem von Plattner vorgestellten System entfällt die ETL-Schicht einer klassischen Data-Warehouse-Architektur. Veränderungen werden in der gemeinsamen
Datenbank gespeichert und können unmittelbar in analytische Berechnungen
einbezogen werden. Auf diese Weise ist die Verringerung von Latenzzeiten im
Lade- und Analysebereich möglich. Zudem wird durch die Zusammenführung
des OLTP- und des OLAP-Systems die Redundanz der Datenhaltung beseitigt.
Aufwendungen, die zuvor zweimal für die Speicherung und Verarbeitung der
14
Informationen getätigt wurden, müssen nun nur noch einmal vorgenommen werden.
Das von Plattner beschriebene integrierte System ist bislang allerdings nur für
eine Datenbank mit ca. 35 Millionen Tupeln getestet worden. Es bleibt abzuwarten, wie gut diese Lösung für Tabellengrößen mit über 100 Millionen Tupeln
skaliert. Außerdem ist nach wie vor ungeklärt, inwieweit ein adäquates Sperrund Workloadmanagement bewerkstelligt werden kann. Da in Plattners Systementwurf Abfrageoperationen mit Einfügeprozessen in Konflikt stehen können, ist
das Finden effizienter Lösungen in diesen Bereichen besonders erfolgskritisch.
Gleichwohl ist die Frage zu beantworten, ob die Zusammenführung von OLTPund OLAP-Systemen tatsächlich zielführend ist. So geht z. B. Conn darauf ein,
dass die Transaktiondatenbanken und das Data Warehouse unterschiedlichen
Zwecken dienen und daher getrennt sein sollten. Auf diese Weise könnten Datenschemata und Speicherstrukturen am besten auf die jeweiligen Systemanforderungen ausgerichtet werden. Zudem werden nicht alle Transaktionsinformationen für die Erstellung von Analyseberichten benötigt [Conn05, S. 516].
Zusätzlich vernachlässigt der Ansatz von Plattner, dass in einem OLAP-System
nicht nur Daten aus relationalen Systemen vorzufinden sind, denen ein einheitliches Schema zugrunde liegt. Vielmehr können die integrierten Informationen
sehr heterogenen, mitunter sogar semistrukturierten Quellen (z. B. XML-Daten)
entspringen. Auch Inmon sieht den Verzicht auf die Transformations- und Integrationsprozesse kritisch:
“There is no point in bringing data [...] into the data warehouse environment without integrating it. If the data arrives at the data warehouse
in an unintegrated state, it cannot be used to support a corporate view
of data.“ [Inmo06]
Aus diesem Grund wird ein ganzheitliches Transaktions- und Analysesystem nur
für bestimmte Anwendungsfälle praktikabel sein.
6
Fazit
In der vorliegenden Arbeit wurde darauf eingegangen, dass die Daten klassischer
Data Warehouses mehreren Zeitverzögerungen unterliegen. Die Ausführungen
haben gezeigt, dass bereits zahlreiche Möglichkeiten bestehen, Transaktionsdaten in einem Data Warehouse zeitnah zur Verfügung zu stellen. So gibt es sowohl in den einzelnen Phasen des ETL-Prozesses als auch bei der Erstellung
von Berichten und Analysen Beschleunigungspotentiale. In diesem Zusammenhang sollte nicht vergessen werden, dass Zeiteinsparungen in einem Bereich zu
Verzögerungen in dem jeweils anderen Bereich führen können. Die Entscheidung zwischen einer höheren Datenaktualität und verringerten Anfragelatenzen
muss dabei für jeden Fall neu getroffen werden. Überdies ist zu berücksichtigen,
dass eventuelle Zeiteinsparungen auch immer vor dem Hintergrund der jeweiligen Anwenderbedürfnisse gesehen werden sollten. So müssten z. B. im Fall des
Multimediaversandhandels nicht unbedingt die Daten der Personalverwaltung
15
unmittelbar für die Analyse bereitstehen. Vielmehr ist es wichtig, dass die richtigen Informationen, wie beispielsweise die neuesten Verkaufszahlen, zur richtigen
Zeit verfügbar sind.
Darüber hinaus können mithilfe der Integration von OLTP- und OLAP-Systemen
zusätzliche Zeiteinsparungen erzielt werden. Aber auch hier ist, aufgrund der vereinfachten Systemarchitektur und eines gemeinsamen Schemas für alle Daten,
mit Einbußen bei der Funktionalität zu rechnen. Die höhere Datenaktualität
geht in diesem Fall zu Lasten einer integrierten Sicht auf heterogene Datenbestände. Zudem sind effiziente Sperrmechanismen nötig, um den gleichzeitigen
und konsistenten Zugriff von Schreib- und Leseoperationen zu ermöglichen.
Zusammenfassend kann festgehalten werden, dass die Anforderung der Datenaktualität in einem Data Warehouse vor dem Hintergrund dynamischer Umweltverhältnisse ein wichtiges und wünschenswertes Ziel ist. Gleichwohl sollte bedacht
werden, zu welchem Preis potentielle Zeiteinsparungen erreicht werden können.
Eine Reduktion der Latenzzeit wird mit diesem Wissen nur dann vorgenommen,
wenn sie für den gegebenen Zweck auch tatsächlich sinnvoll erscheint.
Literatur
Baer04.
Hermann Baer. On-Time Data Warehousing with Oracle Database10g Information at the Speed of your Business, March 2004.
BaGü09. Andreas Bauer und Holger Günzel (Hrsg.). Data-Warehouse-Systeme: Architektur, Entwicklung, Anwendung, Band 3. Aufl. dpunkt-Verl., Heidelberg. 2009.
Conn05. Samuel Conn. OLTP and OLAP data integration : a review of feasible implementation methods and architectures for real time data analysis. SoutheastCon, 2005. Proceedings. IEEE, 2005, S. 515–520.
FaSa10.
Farrah Farooq und Syed Mansoor Sarwar. Real-time data warehousing for
business intelligence. Proceedings of the 8th International Conference on
Frontiers of Information Technology, 2010.
Inmo06.
W. H. Inmon. Building the data warehouse, Band 4. eds. John Wiley Sons,
New York. 2006.
JöDe10.
Thomas Jörg und Stefan Dessloch. Near Real-Time Data Warehousing
Using State-of-the-Art ETL Tools. Work, Band 41, 2010, S. 100–117.
Lang04.
Justin Langseth. Real-time Data Warehousing: Challenges and Solutions,
August 2004.
Lehn03.
Wolfgang Lehner. Datenbanktechnologie für Data-Warehouse-Systeme:
Konzepte und Methoden. dpunkt-Verl., Heidelberg. 2003.
LeTh09. Wolfgang Lehner und Maik Thiele. Evaluation of Load Scheduling Strategies for Real-Time Data Warehouse Environments. Proceedings of the 3rd
International Workshop on Business Intelligence for the Real-Time Enterprise, 2009, S. 1–14.
MNSV09. Mukesh K. Mohania, Ullas Nambiar, Michael Schrefl und Millist W. Vincent. Active and Real-Time Data Warehousing. In Encyclopedia of Database
Systems, S. 21–26. 2009.
Nola99.
Carl Nolan. Manipulate and Query OLAP Data Using ADOMD and Multidimensional Expressions, August 1999.
16
PaKYJ02. Chang-Sup Park, Myoung Ho Kim und Lee Yoon-Joon. Finding an efficient
rewriting of OLAP queries using materialized views in data warehouses.
Decision Support Systems, 32(4), 2002, S. 379–399.
PeJe01.
Torben Pedersen und Christian Jensen. Multidimensional database technology. Computer, 34(12), dec 2001, S. 40–46.
Plat09.
Hasso Plattner. A common database approach for OLTP and OLAP using
an in-memory column database. In Proceedings of the 35th SIGMOD international conference on Management of data, 2009, S. 1–2.
SaBe08.
Ricardo Santos und Jorge Bernardino. Real-time data warehouse loading
methodology. Proceedings of the 2008 international symposium on Database
engineering applications, 2008, S. 49–58.
Shel06.
Joachim Shelp. Real-Time Warehousing und EAI. In Analytische Informationssysteme: Business Intelligence-Technologien und –Anwendungen. Springer, 2006.
SSPK09. Michael Soffner, Norbert Siegmund, Mario Pukall und Veit Köppen. Towards Real-Time Data Integration and Analysis for Embedded Devices. In
Grundlagen von Datenbanken, S. 51–55. Universität Rostock, 2009.
Thie10.
Maik Thiele. Qualitätsgetriebene Datenproduktionssteuerung in EchtzeitData-Warehouse-Systemen. Dissertation, Technische Universität Dresden,
2010.
ThPL08. Christian Thomsen, Torben Bach Pedersen und Wolfgang Lehner. RiTE:
Providing On-Demand Data for Right-Time Data Warehousing. In Proceedings of the 2008 IEEE 24th International Conference on Data Engineering.
IEEE Computer Society, 2008, S. 456–465.
17