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.

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.