Über unsMediaKontaktImpressum
Alfred Schlaucher 11. August 2015

Einsatz von In-Memory-Datenbanken zur Virtualisierung im Data Warehouse

Es gibt mittlerweile eine Reihe von In-Memory-Techniken für Datenbank-Systeme im Data Warehouse-Umfeld. Benötigte man bislang spezialisierte In-Memory-Datenbanken, um In-Memory-Effekte zu nutzen, so steht die In-Memory-Fähigkeit seit geraumer Zeit auch in klassischen Datenbanken wie Oracle zur Verfügung. Zusätzliche In-Memory-Datenbanken sind damit nicht mehr nötig. Seit Jahren bewährte integrierte Architekturen kann man weiterbetreiben und sie sogar noch mit In-Memory-Techniken optimieren.

Viele In-Memory-Diskussionen rund um Warehouse-Systeme beschäftigen sich allerdings nur punktuell mit Abfrage/Performance-Aspekten. In-Memory sollte man jedoch auch als Hilfsmittel für das Architekturdesign nutzen, um Architekturen zu verschlanken, Wege zu kürzen und indirekt Aufwand zu senken. So sind z. B. Aggregate und ganze Data Marts (Star Schemen) verzichtbar und damit automatisch alle technischen Objekte und Funktionen, zu deren Verwaltung, wie Teile des ETL, Indexe etc. Als Folge wird man auch erheblich Plattenplatz sparen und den damit zusammenhängenden Ballast abwerfen. Schlankere Architekturen beschleunigen schließlich das Bereitstellen neuer Informationen für Anwender und schaffen nebenbei auch mehr Stimmigkeit in den Kennzahlen und bei fachübergreifenden Analysen.

Aber wie?

Starten wir mit der Betrachtung bei dem in größeren Warehouse-Umgebungen am häufigsten eingesetzten 3-Schichten-Architekturschema (nach Inmon [1]) und der Art, wie dieses Modell heute oft in den Unternehmen "gelebt" wird, also:

  1. einer Stage-Schicht zum Harmonisieren und Integrieren operativer Unternehmensdaten,
  2. einer sachgebietsneutralen Kern-Warehouse-Schicht mit granularen Stamm-, Bewegungs- und Referenzdaten und
  3. den nachgelagerten sachgebietsbezogenen Data Marts, in denen die synchronisierten Informationen der zentralen Warehouse-Schicht für Anwender anforderungsgerecht aufbereitet sind.

Für die Data Marts passen in der Regel multidimensionale Modelle (z. B. Star Schemen), bei denen die Dimensionen den Geschäftsobjekten aus den realen Prozessen der Anwender entsprechen und die Fakten zu den operativen Transaktionen. Sie stellen die zu analysierenden Kennzahlen dar.

In vielen Unternehmen wird diese Architektur jedoch zu statisch gehandhabt [2]. Die 1. und 2. Schicht liegt (vornehmlich in größeren Unternehmen mit größeren Systemen) in der Hoheit der IT-Abteilung, die sie oft nur technisch administrieren. Oft zu beobachten ist ein starres Kopieren von Vorsystemdaten in die zentrale Warehouse-Schicht: Lediglich technisch geprüft, kaum angereichert mit Zusatzinformationen und wenig verzahnt mit anderen Daten mithilfe eines echten integrierten und harmonischen Datenmodells. Das Ergebnis sind zu viele nicht benötigte und zugleich isolierte Daten [3].

Dagegen erfahren die Data Marts gerne ein Eigenleben in Richtung Fachabteilung mit all den technischen Unzulänglichkeiten einer zusätzlichen dezentralen Fachabteilungs-IT. In Data Marts findet man unkontrollierte Redundanzen, Mehrfachmodellierung, unabgestimmte Begriffe und Kennzahlendefinitionen. In-Memory, ob als Technik einer analytischen Datenbank oder in Verbindung mit einem Auswertewerkzeug (BI-Tool), hilft bei diesen Problemen nicht. Das Chaos beschleunigt sich nur.

An welchen Stellen der 3-Schichten-Architektur hilft In-Memory?

Zunächst sollten wir den Begriff "Schicht" etwas lockerer betrachten. Die Kern-Warehouse- und Data Mart-Schicht sollte man nur aufgrund ihrer funktionalen Verwendung bzw. Datenmodellform (z. B. 3NF vs. multidimensional) unterscheiden. Die wichtigsten Unterschiede sind:

  • Die Data Marts sind entsprechend potenzieller Benutzerabfragen Geschäftsobjektbezogen modelliert, oft multidimensional. Die Kern-Warehouse-Schicht ist als Sammlung stark granularisierter Informationsbausteine entworfen (z. T. normalisiert) und dadurch für Fachanwender aufgrund der künstlichen Granularisierung von Einzeldaten und Separieren von Objektmerkmalen oft nicht verständlich.
  • Die Kern-Warehouse-Schicht verfügt zu einem sehr frühen Zeitpunkt über konsistente Informationen. Sachgebietsbezogene Daten sind übergreifend über ein zusammenhängendes Datenmodell verbunden.

Betrachtet man beide Schichten zusammenhängend, schafft das eine Reihe von Vorteilen:

  • Aufbereitende und berechnende Funktionen, aber auch Sachgebietsübergreifende Daten und standardisierte Kennzahlen, lassen sich in beiden Schichten wahlfrei positionieren und damit auch schon zu einem frühen Zeitpunkt in der Kern-Warehouse-Schicht: Je früher eine Information fixiert ist, um so mehr wächst die Chance der Wiederverwendung in nachgelagerten Schritten.
  • Referenzdaten [4] müssen nicht in die Data Marts kopiert werden. Benutzer können sie zentral in der Warehouse-Schicht abgreifen.
  • Das Gleiche gilt für große transaktionale Bewegungsdatentabellen, deren Strukturen und Inhalte sich nicht von Faktentabellen der Data Mart-Star-Schemen unterscheiden.

Letztendlich verschwimmen die Grenzen zwischen der zentralen Warehouse-Schicht und den Data Marts. Entscheidend ist die Art der Verwendung. Angenehmer Nebeneffekt: weniger ETL und weniger zu pflegende Datenbankobjekte. Aber das hat alles noch nichts mit In-Memory zu tun. Die In-Memory-Technik liefert jedoch das nächste Argument für eine gemeinsame Betrachtung der beiden Schichten: Eine enge Kopplung zwischen Kern-Warehouse und Data Marts bzw. sogar eine komplette Auflösung der Trennung ist eine Voraussetzung zur Virtualisierung der Data Marts durch In-Memory. Multidimensionale Modelle wie Star Schemen aber auch fixe Kennzahlen lassen sich In-Memory für Analysen vorhalten, ohne die nötigen Datenbanktabellen durch aufwändige ETL-Läufe in den Data Marts zu persistieren. Für den Anwender bestehen die multidimensionalen Sichten der Data Marts unverändert weiter. Aber aus technischer, administrativer Sicht sind dies keine Tabellen mehr, sondern Views, die sich im Hintergrund die nötigen Daten aus einzelnen granularen und mit In-Memory-Technik im Hauptspeicher vorgehaltenen Tabellen während der Abfrage des Anwenders abgreifen. Das ist ein konsequenter weiterer Schritt zum Verschlanken des Data Warehouse. Fixe Kennzahlen lassen sich weiter aus den jetzt virtuellen (multidimensionalen View-) Sichten vorberechnen oder man bezieht die Daten für vorberechnete Kennzahlen gleich aus den In-Memory-Tabellen der zentralen Warehouse-Schicht.

Ist die Virtualisierung überhaupt performant machbar?

Ja. In-Memory-Technik macht Abfragen auf Hunderte Gigabyte große Tabellen im Millisekunden-Bereich möglich. Der Grund für diese extreme Performance ist nicht nur alleine das Vorhalten der Daten im Hauptspeicher, sondern Techniken wie:

  • Column-bezogene Speicherung im Gegensatz zur satzweisen Speicherung,
  • höhere Kompressionsraten (Kompressionsfaktoren von 6 bis 20 u. m.),
  • neue Arten der In-Memory-Indizierung (Sortierung und Max/Min-Gruppierung von Spaltenwerten),
  • höhere Parallelisierung (durch die höheren Datendurchsatzraten der In-Memory-Speicherung können die CPUs besser ausgelastet werden. D. h. mehr CPUs arbeiten unter Volllast. Bei der klassischen satzorientierten Speicherung wurde eine höhere Parallelisierung oft durch das IO-Limit der Festplatten ausgebremst),
  • In-Memory-Aggregation (On-the-fly-Vorberechnen von Aggregatwerten),
  • Bloom-Filtering zur schnelleren Join-Auflösung vor allem zwischen großen und kleineren Tabellen,
  • SIMD-Techniken ("Single Instruction Multiple Data" zur direkten Versorgung der CPU-Caches),
  • selektives In-Memory-Laden (nur diejenigen Spalten und Partitionen großer Tabellen lädt das System in den Hauptspeicher, die auch durch Abfragen benötigt werden. Das mindert den Hauptspeicherbedarf besonders für sehr große historisierte transaktionale Tabellen, bzw. Faktentabellen),
  • und a. m. [5].

Praxistests auf mehrere Terabyte große Datenmengen haben gezeigt, dass Abfragen auf Views mit dahinter liegenden Joins auf In-Memory-Tabellen der Warehouse-Schicht fast genauso kurze Antwortzeiten benötigen, wie Abfragen auf In-Memory-Star Schemen. Die Unterschiede liegen im Zehntel-Sekundenbereich. Betrachtet man die typische Struktur einer Dimension in einem Star Schema, dann wird die Erklärung für diesen Effekt deutlich: Die über einen Join zu lesende Datenmenge aus normalisierten Tabellen ist ähnlich groß wie die Datenmenge in einer dazu passenden denormalisierten Dimensionstabelle eines Star Schemas. Und die Anzahl Sätze nimmt entlang der Aggregationslinie hin zu dem Top-Aggregat-Level sehr schnell ab.

Join-Abfragen gehören zudem zu den Hauptgewinnern der In-Memory-Technologie: Join-Attribute liegen durch die Column-orientierte Speicherung der Tabellendaten schon vorsortiert im Hauptspeicher. Zusätzlicher temporärer Sortierspeicher ist nicht mehr nötig. Die zu erbringende Rechenleistung für Joins ist nicht besonders hoch.

Wie sehen die Entwicklungsschritte bei der Umsetzung eines solchen Konzeptes aus?

Damit die Virtualisierung von Data Marts durch In-Memory gelingt, müssen potenzielle multidimensionale Sichten (z. B. Star Schema) bereits in der Kern-Warehouse-Schicht vorgedacht (modelliert) sein. Multidimensionale Sichten bestehen aus Dimensionstabellen mit drillfähigen Hierarchie-Leveln und Join-Beziehungen zu den Fakten-Tabellen (Kennzahlen), die sie beschreiben. Ersetzt man die Dimensionen durch Views auf Kern-Warehouse-Tabellen, wie oben vorgeschlagen, dann sollten die Hierarchie-Level der Dimensionen über das Datenmodell der Kern-Warehouse-Schicht leicht ableitbar sein. Die Kern-Warehouse-Schicht muss also nicht nur die Anforderung der Granularisierung (z. B. 3 NF) erfüllen, sondern es müssen auch augenfällig leicht kombinierbare (Join-fähige) Tabellen mit allen nötigen Informationen für die potenziellen Dimensionen in der zentralen Schicht vorhanden sein.

Technisch gesehen müssen folgende Aspekte bereits in der zentralen Warehouse-Schicht und nicht erst in den Data Marts realisiert sein:

  • Historisierung und Stammdatenversionierungen (im Sinne von Slowly Changing Dimensions).
  • Alle künstlichen Warehouse-Schlüssel müssen gebildet sein (also auch diejenigen Schlüssel, die später für Joins zwischen Dimensions- und Faktentabellen genutzt werden, welche i. d. R. den künstlichen Schlüsseln entsprechen).
  • Das Orphan-Management zwischen Bewegungs- und genutzten Stammdaten sollte etabliert sein.
  • Referenzdaten (externe, nicht aus den Vorsystemen stammende Daten) liegen nur in der Warehouse-Schicht und nicht in den Data Marts.
  • Endbenutzer haben Leserechte auf Daten der zentralen Warehouse-Schicht und nicht nur auf die Data Marts (gerade in großen Unternehmen mit zentraler Warehouse-Administration stellt das eine Herausforderung dar).
  • Besondere Kennzahlenberechnungen sollten/können als Vorschrift bereits in der Warehouse-Schicht vorhanden sein, z. B. als Views oder einfach nur als Metadatenobjekte, aus denen heraus man Abfragen generieren kann.
  • Level-Objekte (wie oben beschrieben) müssen z. B. als Tabellen in der zentralen Warehouse-Schicht erkennbar sein, um Drillpfade in Dimensionen aufbauen zu können.

Die Modellierung der Tabellen der zentralen Warehouse-Schicht erfolgt jetzt nicht nur nach den Grundsätzen der Normalisierung von Vorsystemtabellen (wie bislang oft in den Warehouse-Projekten praktiziert), sondern orientiert sich vor allem auch an der notwendigen "Kombinierbarkeit" der Tabellen zu Dimensionen. Drillpfade müssen leicht herstellbar sein. Wie in jeder klassischen Vorgehensweise erfassen wir zunächst Anwenderanforderungen und dokumentieren mithilfe einfacher Analysemodelle die Abhängigkeit zwischen Geschäftsobjekten und Geschäftstransaktionen der operativen Prozesse. Das ergibt eine lockere Sammlung (zeichnerisch als Skizze dargestellt) relevanter aber noch nicht untereinander organisierter Geschäftsobjekte. Durch die Methode der Generalisierung bzw. Spezialisierung modelliert man daraus hierarchische Beziehungen zwischen den gefundenen Geschäftsobjekten und erhält 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 Abschluss verbindet man die untersten Hierarchielevel der so gefundenen Dimensionen durch Kennzahlenobjekte (Transaktionen der operativen Prozesse).

Drei Etappenziele sind jetzt erreicht:

  1. Wir haben genau die Informationen strukturiert, die der Anwender auch wirklich benötigt. Wir sind nicht abhängig von einer Vorsystemanalyse oder sonstigen Vermutungen über Anwenderbedürfnisse.
  2. Die Strukturierung von potenziellen Auswertemodellen für die Anwender liegt jetzt bereits vor: Wir haben alle nur denkbaren Objekte, die durch Kennzahlen bemessen werden sollen, zusammenhängend an einer Stelle (Dimension) gruppiert und
  3. wir besitzen die Information über alle Varianten von möglichen Drillpfaden und können diese dem Anwender als Aggregat-Ebenen anbieten.

Alles, was jetzt folgt, ist nur noch technische und mechanische Umsetzung. Das konzeptionelle Modell zur Beschreibung von Strukturen und Inhalten liegt ja vor.

Mit Blick auf die Virtualisierung der Data Marts nutzen wir das entstandene konzeptionelle Modell an zwei Stellen der 3-Schichten-Architektur: zum einen ganz klassisch für den Entwurf der Star Schemen in den Data Marts. Auch wenn wir Star Schemen jetzt virtuell in Form von Views auf die zentrale Warehouse-Schicht abbilden. Die Struktur einer multidimensionale Sicht für Anwender und ihre Tools wollen wir beibehalten.

Zum anderen nutzen wir die Informationen des konzeptionellen Modells aber auch als Input für die Modellierung der Kern-Warehouse-Schicht. Bei der hier vorgestellten Vorgehensweise bilden zunächst nur die Levelobjekte des konzeptionellen Modells die Grundlage für die Tabellen der zentralen Schicht. Diese müssen nicht zwingend normalisiert sein. In dieser Weise modelliert, 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 multidimensionalen Sichten für Benutzerabfragen sind damit bereits in der zentralen Schicht vorbereitet [6].

Das so entstandene "Rumpfdatenmodell" der zentralen Warehouse-Schicht kann man jetzt z. B. durch Referenzdatentabellen oder weitere relevante Vorsystemdaten ergänzen.

Wo liegen die Vorteile des Konzeptes?

Der wichtigste Vorteil ist die gewonnene Flexibilität und damit die Schnelligkeit, geänderte Auswertestrukturen für Anwender bereitzustellen: In der zentralen Warehouse-Schicht ist die maximale Informationsmenge auf granularstem Level "wie in einem Regal" übersichtlich sortiert abgelegt. Jede aus dieser Informationsmenge ableitbare multidimensionale Sicht (jede Anwendersicht) kann man bei Bedarf und ohne besonderen Aufwand über View-Definitionen daraus ableiten. Die "Anleitung zu dieser Ableitung" (oder zu der Art der View-Definition) liefert das oben beschriebene konzeptionelle Modell. Das Definieren der View-DDLs (z. B. mit grafischen Werkzeugen oder sogar direkt aus den eingesetzten BI-Tools heraus) ist weit weniger aufwändig als z. B. das Neubauen physischer ETL-Strecken für die Data Marts.

Sogenannte analytische Datenbanken sind nicht mehr nötig. Deren Hauptzweck – die Bereitstellung von einer besonders guten Abfrageperformance – wird bereits durch die in der klassischen relationalen Datenbank integrierte In-Memory-Funktionalität abgedeckt. Der Beschaffungsweg der Informationen verkürzt sich, denn es muss keine separate Datenbank zwischen Warehouse-Datenbank und Business Intelligence-Tool geschaltet werden.
Konsequent angewendet führt die Vorgehensweise auch zu einer inhaltlichen, fachlichen Konsolidierung der Analysedaten. Sie verhindert das inhaltliche Auseinanderdriften der Data Marts, denn die Ausgangsbasis aller abgeleiteten Data Marts ist in jedem Fall die gleiche: die zentrale Warehouse-Schicht. Auf Data Mart-Ebene entstehen keine neuen Informationen und damit auch keine potenziell falschen Informationen. Für die Data Marts wird nicht mehr neu modelliert. Diese Vorgehensweise stärkt die Bedeutung der zentralen Warehouse-Schicht innerhalb der Gesamtarchitektur und "Schichtengrenzen" lösen sich auf.

Teurer Plattenplatz wird geschont: In Warehouse-Systemen benötigen oft 90 Prozent aller Tabellen nur weniger als 10 Prozent der Speicherressourcen. Die restlichen 10 Prozent aller Tabellen (transaktionale Tabellen der zentralen Schicht und Faktentabellen in den Data Marts) beanspruchen aber den großen 90 Prozent-Speicheranteil. Durch das Virtualisieren der Data Marts entfallen Tabellen der zuletzt genannten Gruppe. Es sind die Faktentabellen, die nicht mehr persistent auf den Speicherplatten liegen. Die Faktentabellen sind in diesem Konzept Views auf In-Memory-Transaktionstabellen (Partitionen und Spalten-Extrakte) der zentralen Warehouse-Schicht. Berücksichtigt man noch den Wegfall von Indexen in den Data Marts, so kann man eine Speicherplatzreduzierung von 20 bis 50 Prozent schätzen. Das ist eine ganze Menge. 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, 50 TB auf 30 usw.

Fazit: In-Memory schafft nicht nur Performance

In-Memory-Technologie kann neben der Verbesserung der Abfrage-Performance auch zu einer strafferen und übersichtlicheren Architektur führen. In vielen Data Warehouse-Installationen ist die Art, wie man das 3-Schichten-Modell praktiziert, eine der Hauptursachen für redundanten 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 – kürzere – Architekturen, in denen die Schichten "zusammenrücken". Endbenutzersichten müssen dabei zunehmend in die zentrale Warehouse-Schicht hineinmodelliert werden.

Quellen
  1. Der Autor beruft sich auf Erfahrungen mit den etwa 500 meist größten Warehouse-Systemen deutscher Oracle-Kunden, die in dem Data Warehouse Community-Kreis zusammengefasst sind.
  2. Siehe [1]
  3. Befragt man in Reviews Warehouse-Verantwortliche nach der Eindeutigkeit von zentralen Warehouse-Daten, erntet man meist Achselzucken. Verfahren zur Stimmigkeit und Eindeutigmachung von Daten sind wenig bekannt.
  4. Referenzdaten sind Daten, die nicht direkt aus dem eigenen Unternehmen stammen, sondern zu Orientierungszwecken extern erworben wurden.
  5. Die Performance-Optimierung der Oracle-In-Memory-Option gegenüber dem Lesen von bereits im Bufferpool-Hauptspeicher liegenden Daten liegt bei Faktor 2 bis weit über 50. Die Performance-Optimierung gegenüber dem Lesen von Festplattendaten liegt im Bereich von mehreren Tausend.
  6. Als Nebeneffekt erhalten wir automatisch auch eine Einschränkung der Tabellen- und Tabellenspaltenanzahl. Wir minimieren den Größenumfang der Warehouse-Schicht. In vielen Warehouse-Systemen verfügen die Tabellen über die gleichen Spalten wie die Vorsysteme, d. h., es ist eine hohe Anzahl Spalten vorhanden, die kein Anwender nutzt.
  7. W.H. Inmon (1996): Building the Data Warehouse, Verlag John Wiley & Sons, Inc.

Autor

Alfred Schlaucher

Alfred Schlaucher startete Mitte der 1980er Jahre mit der Programmierung von Datenbanken auf Großrechnern von Siemens und IBM. In den 1990er Jahren beschäftigte er sich mehrere Jahre mit Datenmodellierung und Metadatenmanagement...
>> Weiterlesen
botMessage_toctoc_comments_9210