Einsatz von In-Memory zur Virtualisierung im Data Warehouse

Transkript

1 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 Daten- Durchlauferhitzer für Business Intelligence-Tools 1. 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 Performance- Qualen verschaffen, aber nachhaltige Veränderungen bleiben aus: Strohfeuer-Effekt. Starten wir mit dem klassischen 3-Schichtenmodell 2, also 1. einer Stage-Schicht zum harmonisieren und integrieren von Unternehmensdaten, 2. einer Sachgebiets-neutralen Kern-Warehouse-Schicht mit granularen Stamm-, Bewegungs- und Referenzdaten, 3. 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.

2 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 IT- Abteilung, 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 Kern- Warehouse-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.

3 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

4 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. Es sind genau die Informationen strukturiert, die der Anwender wirklich benötigt. 2. 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 Benutzersicht sind damit bereits in der zentralen Schicht vorbereitet 3. 3 Nebeneffekt ist automatisch eine Einschränkung der Tabellen- und Tabellenspaltenanzahl. In viele Warehouse- Systemen verfügen die Tabellen über die gleichen Spalten, wie die Vorsysteme, d. h., es ist eine hohe Anzahl nich genutzter Spalten.

5 Virtualisierung im Data Warehouse mit In-Memory 5 Die Vorteile des Konzeptes? Herleitungsweg von Modellen im Data Warehouse 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 )

6 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