Einsatz von In-Memory zur Virtualisierung im Data Warehouse

Virtualisierung im Data Warehouse mit In-Memory
1
Einsatz von In-Memory zur Virtualisierung im Data Warehouse
.
Es gibt mittlerweile eine Reihe von In-Memory-Techniken für Datenbank-Systeme im Data Warehouse – Umfeld.
Hat man bislang bzgl. „Data Warehouse“ auch irgendwie immer an Performance gedacht, so wird In-Memory auch
gleich als ultimativer Performance-Kick für das Data Warehouse wahrgenommen, als wäre dies die einzige
Herausforderung.
Ein Data Warehouse ist mehr als nur (platt verstanden) eine performante Datenbank oder ein „Daten1
Durchlauferhitzer“ für Business Intelligence-Tools . Viele aktuelle Probleme haben ihre Ursache oft in genau dieser
verkürzten Betrachtung:






Nicht die richtigen Informationen für die Benutzer.
Fehlende Kombinationsmöglichkeiten zwischen den Daten.
Fehlende Stimmigkeit in den Auswertungen.
Unflexibilität gegenüber neuen Anwenderanforderungen (zu lange Lieferzeiten für neue Berichte und
Daten).
Zu viel Technik – Einsatz bei zu wenig Erfolg und of als zu teuer empfunden.
Zu komplexe Systeme, die nur mit viel Personal und Experten zu beherrschen sind.
In-Memory lindert auch solche Probleme, wenn man mithilfe dieser Technik Architekturen modifiziert. Kurz gesagt:
wenn man Architekturen verschlankt, Wege kürzer gestaltet und indirekt Aufwand senkt. So sind z. B. Aggregate
und ganze Data Marts (Star Schemen) verzichtbar und automatisch alle technischen Objekte und Funktionen, zur
Verwaltung dieser Objekte, wie Teile des ETL, Indexe etc. Man spart erheblich Plattenplatz. Man wird schneller
neue Informationen bereitstellen, Komplexität senken und man schafft korrektere Kennzahlen.
Aber wie?
Zugegeben, bei den meisten Warehouse-Systemen wird In-Memory zwar etwas Luft gegenüber PerformanceQualen verschaffen, aber nachhaltige Veränderungen bleiben aus: Strohfeuer-Effekt.
2
Starten wir mit dem klassischen 3-Schichtenmodell , also
1.
2.
3.
einer Stage-Schicht zum harmonisieren und integrieren von Unternehmensdaten,
einer Sachgebiets-neutralen Kern-Warehouse-Schicht mit granularen Stamm-, Bewegungs- und
Referenzdaten,
und den nachgelagerten Sachgebiets-bezogenen Data Marts, mit synchronisierten und für Anwender
mundgerecht aufbereitetet Informationen aus der zentralen Warehouse-Schicht.
Landläufig modellieren wir die 3. Schicht (Data Marts) genau nach dem Geschmack der Anwender. Hier passen
multidimensionale Modelle ( z. B. Star Schemen), mit Dimensionen (Geschäftsobjekte aus den realen Prozessen
der Anwender) und die Fakten (die zu analysierenden Kennzahlen).
1
Die strategische Rolle der Systeme für ein Unternehmen wird gerne unterschätz, weil Data Warehouse im
Gegensatz zu manch anderen Hype-Themen heute eher im Hintergrund wirkt.
2
Die meisten größeren und unternehmensweit angelegten Data Warehouse-Systeme nutzen heute diese von
Inmon Mitte der 90er Jahren besprochene Architektur.
Virtualisierung im Data Warehouse mit In-Memory
2
Oft eingesetzte 3-Schichten-Architektur für unternehmensweite Warehouses
Vielen Unternehmen handhaben diese Architektur jedoch zu statisch. Die 1. und 2. Schicht ist Domaine der ITAbteilung, die sie oft nur technisch administrieren. Mangels Einsicht in echte Endanwenderbedarfe pumpt man die
zentrale Schicht voll mit allem, was die Vorsysteme hergeben „Was man hat, das hat man“. Viele zentrale
Warehouse-Schichten sind überfüllt mit nicht benötigten Daten.
Dagegen erfahren die Data Marts gerne ein Eigenleben in Richtung Fachabteilung. Technischen Unzulänglichkeiten,
Redundanzen, doppelte Modellierungstätigkeiten, unabgestimmten Begriffen und Kennzahlendefinitionen sind die
Folgen. Wenn jemand jetzt diese chaotischen Data Marts noch In-Memory packt, oder in ein In-Memory-basiertes
BI-Tool lädt, wird er dieses Chaos einfach nur beschleunigen, anstatt den oben genannten Herausforderungen zu
begegnen.
Sinnvolle Umsetzung der 3-Schichten-Architektur mit In-Memory sinnvoll
Zunächst sollten wir den Begriff „Schicht“ etwas lockerer betrachten. Die Kern-Warehouse- und Data Mart-Schicht
sollte man nur aufgrund ihrer funktionalen Verwendung unterscheiden. Data Marts sind benutzerbezogen
modelliert, oft multidimensional und die Kern Warehouse – Schicht ist granular entworfen (z. T. normalisiert). Die
Kern Warehouse – Schicht verfügt zu einem früheren Zeitpunkt konsistente Informationen. Das ist aber auch schon
alles. Keinesfalls sind Schichten eine Blaupause für Abteilungs- oder Verantwortlichkeitsgrenzen. Die
zusammenhängende Betrachtung schafft eine Reihe von Vorteilen:
Aufbereitende, berechnende Funktionen, aber auch sachgebietsübergreifende Daten und standardisierte
Kennzahlen lassen sich früher im Informationsbeschaffungsprozess positionieren, also auch schon in der KernWarehouse-Schicht: Je früher eine Information fixiert ist, um so mehr wächst die Chance der Wiederverwendung in
nachgelagerten Schritten und umso geringer ist die Gefahr von Fehlern bei redundantem Tun.
Referenzdaten müssen nicht in die Data Marts kopiert werden. Das Gleiche gilt für große transaktionale
Bewegungsdatentabellen, deren Strukturen und Inhalte sich nicht von Faktentabellen der Data Mart-Star Schemen
unterscheiden. Insgesamt weniger ETL und es spart Datenbankobjekte.
In-Memory liefert das nächste Argument: Eine enge Kopplung zwischen Kern-Warehouse und Data Marts
ermöglicht die Virtualisierung der Data Marts. Multidimensionale Modelle wie Star Schemen aber auch fixe
Kennzahlen lassen sich In-Memory für Analysen vorhalten, ohne die nötigen Datenbanktabellen durch aufwendige
ETL-Läufe in den Data Marts zu persistieren. Anwender verfügen weiter über Data Marts, mit ihren aufbereiteten,
multidimensionalen Sichten bzw. Kennzahlenlisten. Technisch und administrativ sind dies jedoch keine Tabellen
mehr, sondern Views, auf einzelne, granularen und mit In-Memory-Technik vorgehaltene Tabellen.
Virtualisierung im Data Warehouse mit In-Memory
3
Damit die Virtualisierung von Data Marts durch In-Memory gelingt, muss die Struktur-Information dazu muss
bereits in der Warehouse-Schicht erkennbar sein. Viele Warehouse-Umgebungen sehen dies nicht vor, sondern
sind dominiert von den Strukturen der Vorsysteme, anstatt auf Anwendernutzen ausgerichtete Modelle hin zu
orientieren.
Ist die Virtualisierung performant machbar?
Ja. In-Memory-Technik macht Abfragen auf Hunderte Gigabyte große Tabellen im Millisekunden-Bereich möglich.
Der Grund ist nicht nur alleine das Vorhalten der Daten im Hauptspeicher, sondern Techniken wie Columnbezogene Speicherung, höhere Kompressionsraten, neue Arten der In-Memory-Indizierung, höhere
Parallelisierung, In-Memory-Aggregation, Bloom-Filtering, SIMD-Techniken u. a. m. .
Was ist mit Views und denormalisierenden Joins? Umfangreiche Tests haben gezeigt, dass Abfragen auf Views mit
dahinter liegenden Joins auf In-Memory-Tabellen der Warehouse-Schicht, fast genauso kurze Antwortzeiten
benötigen, wie eine Abfrage auf die denormalisierte Dimensionstabelle die ebenfalls in einem In-Memory-Store
liegt. Die Unterschiede liegen im Zentel-Sekundenbereich. Betrachtet man die typische Struktur einer Dimension in
einem Star Schema, dann wird die Erklärung für diesen Effekt augenfällig. Die Anzahl Sätze eines Joins auf eine
normalisierte zusammenhängende Gruppe von Tabellen ist genauso groß, wie die daraus abgeleitete
denormalisierte Dimensionstabelle eines Star Schemas. Und die Anzahl Sätze nimmt entlang der Aggregationslinie
hin zu dem Top-Aggregat-Level sehr schnell ab. An den äußeren Rändern finden sich oft Tabellen mit wenigen 100
Sätzen. Für heutige Datenbanksysteme sind solche nach außen ausgedünnten Joins in kaum messbarer Zeit
auflösbar.
Dimensions-Joins auf normalisierte In-Memory-Tabellen sind nicht teuer. Grund ist die Ausdünnung der Satzmengen
entlang der Hierarchie-Stufen.
Entwicklungsschritte bei der Umsetzung des Konzeptes
Wie in jeder klassischen Vorgehensweise erfassen wir zunächst Anwenderanforderungen und dokumentieren über
einfache Analysemodelle die Abhängigkeit zwischen Geschäftsobjekten und Geschäftstransaktionen der operativen
Prozesse. Das ergibt eine lockere Sammlung relevanter aber noch nicht untereinander organisierter
Geschäftsobjekte. Durch Generalisierung bzw. Spezialisierung modelliert man hierarchische Beziehungen zwischen
Virtualisierung im Data Warehouse mit In-Memory
4
den gefundenen Geschäftsobjekten: Ziel ist das sog. Objektmodell. Die über Hierarchiebeziehungen verbundenen
Objekte ergeben schließlich in dem darauf aufbauenden konzeptionellen Modell (z. B. M E/R – Multidimensional
Entity Relationship) die Dimensionen einer multidimensionalen Sicht. Zum Schluss verbindet man die untersten
Hierarchielevel der Dimensionen durch Kennzahlenobjekte (Transaktionen der operativen Prozesse).
Zwei Etappenziele sind erreicht:
1.
2.
Es sind genau die Informationen strukturiert, die der Anwender wirklich benötigt.
Die Strukturierung von potenziellen Auswertemodellen mit Drillpfaden und Aggregatleveln für die
Anwender.
Jetzt folgt nur noch mechanische Umsetzung. Das konzeptionelle Modell zur Beschreibung von Strukturen und
Inhalten liegt ja vor. Mit Blick auf die Virtualisierung der Data Marts nutzen wir diese Information an zwei Stellen
der Schichten-Architektur: Erstens ganz klassisch für den Entwurf der Star Schemen der Data Marts. Auch wenn wir
später Star Schemen virtuell in Form von Views auf die zentrale Warehouse-Schicht abbilden, so brauchen wir
doch ein Zugriffsmodell, für die der Anwender bzw. BI-Tool-Zugriffe. Wir brauchen eine multidimensionale Sicht.
Zum anderen ist das konzeptionelle Modell auch Input für die Modellierung der Kern-Warehouse-Schicht. Das mag
den ein oder anderen überraschen, der es gewohnt ist, die zentrale Schicht als reines Tabellenwerk aus den
Vorsystemen abzuleiten. Bei der hier vorgestellten Vorgehensweise sind primär die Levelobjekte des
konzeptionellen Modells die Grundlage für die Tabellen der zentralen Schicht. Damit lassen sich die Tabellen der
zentralen Schicht zur Abfragezeit sehr leicht über die bereits erwähnten Views (virtuelles Star Schema) zu
Dimensions-Hierarchie-Leveln „zusammen-joinen“. Die potenziellen Strukturen einer multidimensionalen
3
Benutzersicht sind damit bereits in der zentralen Schicht vorbereitet .
3
Nebeneffekt ist automatisch eine Einschränkung der Tabellen- und Tabellenspaltenanzahl. In viele WarehouseSystemen verfügen die Tabellen über die gleichen Spalten, wie die Vorsysteme, d. h., es ist eine hohe Anzahl nich
genutzter Spalten.
Virtualisierung im Data Warehouse mit In-Memory
5
Herleitungsweg von Modellen im Data Warehouse
Die Vorteile des Konzeptes?
Größter Pluspunkt ist die gewonnene Flexibilität: In der zentralen Warehouse-Schicht ist die maximale
Informationsmenge auf granularstem Level übersichtlich sortiert abgelegt. Jede aus dieser Informationsmenge
ableitbare Anwendersicht ist bei Bedarf und ohne großen Aufwand über View-Definitionen ableitbar. Die
„Anleitung zu dieser Ableitung“ liefert das beschriebene konzeptionelle Modell. Das Definieren der Views ist weit
weniger aufwendig und zeitraubend als z. B. ETL-Projekte.
Das inhaltliche Auseinanderdriften der Data Marts wird verhindert, denn die Ausgangsbasis aller abgeleiteten Data
Marts ist in jedem Fall die gleiche.
Plattenplatz wird geschont: Durch das Virtualisieren der Data Marts entfallen viele Tabellen von den berühmten
10% die oft 90% und mehr Plattenplatz benötigen. Es sind die nicht persistierten Faktentabellen. Sie sind in diesem
Konzept In-Memory-Tabellen (Partitionen oder Spalten-Extrakte) der zentralen Warehouse-Schicht. Hinzu kommt
der Wegfall von Indexen in den Data Marts. Man schätzt eine Speicherplatzreduzierung von 20–50%. Man bedenke
auch den sekundären Plattenplatzbedarf durch Sicherungen, temporäre Daten, Kapazitätspuffer usw.. 20 Terabyte
Nutzdaten lassen sich damit rechnerisch auf 10 TB reduzieren.
Voraussetzungen der Virtualisierung von Data Marts
Die Virtualisierung von Data Marts erfordert einige Randbedingungen. Die Idee des Wegwerf-Data Mart stellt
hierfür eine gute Messlatte dar: Man löscht einen Data Mart, um ihn dann wieder (hoffentlich „ohne Verluste“)
Virtualisierung im Data Warehouse mit In-Memory
6
über die zentrale Warehouse-Schicht neu aufzubauen. Bei bestandenem Test funktionieren die Abfragen auf den
Data Mart weiter. (Vorschlag nur theoretisch durchführen, um Unfälle zu vermeiden).
Als nötige Randbedingungen sollten in der zentralen Warehouse-Schicht bereits existieren:

Historisierung und Versionierungen (im Sinne von Slowly Changing Dimensions)

Künstlichen Warehouse-Schlüssel.

Schlüssel-Referenzen zwischen Stamm-/Referenz und den transaktionalen Bewegungsdaten (die späteren
Fakten).

Das Orphan-Management zwischen Bewegungs- und Stammdaten.

Referenzdaten

Leserecht der Benutzer

Besondere Kennzahlenberechnungen als Vorschrift, z. B. als Views oder als Metadatenobjekte.

Level-Objekte zur Orientierung bei dem Aufbau von Dimensionshierarchien (i. d. R. als einfache
relationale Tabellen).
Zusammengefasst: In-Memory schafft nicht nur Performance?
In vielen Data Warehouse-Installationen ist die Art, wie man das 3-Schichten-Modell praktiziert eine der
Hauptursachen für unnötigen Aufwand und unkontrollierte Zustände. Führt man die In-Memory-Technik ohne
Änderung der Architektur ein, wird sich an diesem Zustand nichts ändern. In-Memory bietet Chancen für
geänderte Architekturen. Man sollte sie nutzen.
Das Ergebnis: eine um die Data Mart-Distanz verkürzte Architektur
Alfred Schlaucher, Oracle, Mai 2015

Download Report