Kriterien für Datenpersistenz bei Enterprise Data Warehouse Systemen auf In-Memory Datenbanken Thorsten Winsemann Veit Köppen Otto-von-Guericke-Universität Magdeburg Otto-von-Guericke-Universität Magdeburg Kanalstraße 18 Universitätsplatz 2 D-22085 Hamburg D-39106 Magdeburg +49(0)160/90819410 +49(0)391/67-19351 thorsten.winsemann@t-online.de veit.koeppen@ovgu.de ABSTRACT Die Verbesserung der Datenzugriffsgeschwindigkeit ist oftmals Persistente Datenhaltung über mehrere Schichten innerhalb eines der Hauptgrund zusätzlicher Datenhaltung. Setzt man voraus, dass Enterprise Data Warehouse Systems ist notwendig, um den dort dies in einer IMDB weniger wichtig ist, so kommt die Frage auf: vorhandenen, sehr großen Datenbestand nutzen zu können, z.B. Wieviel Persistenz, d.h. nicht-flüchtige Datenspeicherung, ist in für Reporting und Analyse. Die Pflege und Wartung solcher meist IMDB-basierten DWS überhaupt noch notwendig? Dies gilt redundanten Daten ist jedoch sehr komplex und erfordert einen insbesondere für Enterprise Data Warehouses (EDW). Ist es hohen Aufwand an Zeit und Ressourcen. Neueste In-Memory- möglich, jede Art von Analyseanfrage direkt auf dem Technologien ermöglichen gute Performanz beim Datenzugriff, so Rohdatenbestand abzusetzen, welcher „on-the-fly“ transformiert dass sich die Frage stellt, welche Daten aus welchem Grund bzw. wird? Oder gibt es dennoch gewichtige Gründe der für welchen Zweck überhaupt noch persistent abgelegt werden Datenspeicherung? Um diese Fragen zu beantworten, erläutern müssen – und wie sich dies effizient entscheiden lässt. In diesem wir Persistenzgründe in EDW-Systemen und potentielle Konflikte Papier präsentieren wir eine Übersicht von Gründen für zwischen Datenspeicherung und -verwendung. Zudem definieren Datenpersistenz, welche als Entscheidungsgrundlage bei der wir Indikatoren zur Entscheidungsunterstüzung, ob Daten Problematik dient, Daten in Enterprise Data Warehouses auf In- gespeichert werden sollen oder nicht. Memory Datenbanken zu speichern. Abschnitt 2 erläutert einführend die Besonderheiten von Enterprise Data Warehouses und einer Schichtenarchitektur. In Kategorien und Themenbeschreibung Abschnitt 3 führen wir Gründe der Datenpersistenz in heutigen H.2.7 [Database Management]: Datenbank-Administration – EDW auf und beschreiben mögliche Konflikte, welche aufgrund Data Warehouse und Repository. der Anforderungen der Datennutzung und der hierfür notwendigen Aufwände entstehen. Abschnitt 4 erläutert Allgemeine Begriffe Datenpersistenz auf IMDB-basierten EDW sowie Management, Design. entscheidungsunterstützende Faktoren. Abschnitt 5 fasst die Teile zusammen und gibt einem Ausblick auf zukünftige Arbeiten. Schlüsselwörter Enterprise Data Warehouse, Persistenz, In-Memory Datenbank. 2. EINE SCHICHTENARCHITEKTUR FÜR 1. EINLEITUNG ENTERPRISE DATA WAREHOUSES Heutige Data Warehouse Systeme (DWS) sind gekennzeichnet Ein Enterprise Data Warehouse ist ein Business Data Warehouse durch sehr große Datenvolumina [1]. Der Aufbau und Betrieb [4], stellt also entscheidungsunterstützende Informationen für das solcher Systeme erfordert hohe Anforderungen an die Management in allen Geschäftsbereichen zur Verfügung. Darüber Datenbereitstellung, insbesondere hinsichtlich Performanz, hinaus stellen EDW eine wichtige Datenbasis für eine Vielzahl Datengranularität, -flexibilität und -aktualität. Außerdem von Anwendungen dar, wie zum Beispiel Business Intelligence erfordern solche Einschränkungen die Speicherung zusätzlicher (BI), Customer Relationship Management (CRM) und die Daten. Verdichtungsebenen werden verwendet, um die Planung. Innerhalb einer umfassenden Systemlandschaft stellen Geschwindigkeit des Datenzugriffs zu verbessern, z.B. bei EDW-Systeme die „Single Source of Truth“ (vgl. [3]) für alle Reporting und Analyse. Diese Datenredundanz wiederum analyse-relevanten Daten des Unternehmens dar. Das heißt, sie erfordert einen hohen Aufwand an Zeit und Ressourcen, um ermöglichen eine allgemein gültige Sicht auf einen zentralen, Datenkonsistenz zu gewährleisten Gleichzeitig wird eine zeitnahe harmonisierten, validen und konsistenten Datenbestand. Ein EDW Datenverfügbarkeit eingeschränkt. Neueste Ankündigungen integriert sehr große Datenbestände aus einer Vielzahl versprechen auf In-Memory Datenbanken (IMDB) basierende unterschiedlicher Quellsysteme des Konzerns – oftmals weltweit, Anwendungen, die auf größte Datenbestände – ohne zusätzliche so dass Daten verschiedener Zeitzonen zusammengeführt werden Verdichtungsebenen – performant zugreifen können [2,3]. müssen. Dies erfordert eine fortlaufende Datenverfügbarkeit mit gleichzeitigem Datenladen und -zugriff. Zudem gibt es weitere Anforderungen an den Datenbestand: Ad-hoc-Berichte, „near- real-time“ Verfügbarkeit und Anwendungen, wie beispielsweise CRM, mit einem Bedarf an detaillierten historischen Daten. Ein 23rd GI-Workshop on Foundations of Databases (Grundlagen von sich ändernder Informationsbedarf muss schnell und flexibel Datenbanken), 31.05.2011-03.06.2011, Obergurgl, Austria. Copyright is held by the author/owner(s). 97 gedeckt werden können. Zudem wird ein umfassendes In der Berichts- & Analyseschicht werden Daten hauptsächlich Berechtigungskonzept zur Sicherung sensibler Daten verwendungsbezogen transformiert, um performante Zugriffe zum vorausgesetzt. Somit sind verschiedene Gründe von Beispiel beim Reporting oder der Analyse zu gewährleisten. Datenpersistenz spezifisch in einem EDW. Innerhalb der Operationalen Datenversorgung werden Daten für Persistenz in einem Data Warehouse ist eng verbunden mit dessen sehr spezielle Anwendungsfälle und Anforderungen zur Architektur. Eine allgemeine Referenzarchitektur (vgl. z.B. Verfügung gestellt, zum Beispiel bei „near real-time Reporting“. [5,6,7,8]) definiert drei Bereiche, welche die drei Arten der Obwohl die Grenzen fliessend sind, können die fünf Schichten Datenverarbeitung darstellen: Datenbeschaffung in der „Staging den drei Bereichen der Datenverarbeitung wie folgt zugeordnet Area“, Datenbearbeitung in der Basisdatenbank, werden: Datenbeschaffung in der Datenempfangs- und der Datenbereitstellung im Data-Mart-Bereich. In diesem eher groben Qualitäts- & Harmonisierungsschicht, Datenbearbeitung in der Modell ist Datenspeicherung in jedem Bereich implizit [9]. Die in Datenverteilungs- und der Betriebswirtschaflichen [10] vorgestellte Schichtenarchitektur (Abb. 1) entwickelt diesen Modellierungsschicht, sowie Datenbereitstellung in den Data Ansatz hinsichtlich der bereits erwähnten Anforderungen an ein Marts der Berichts- & Analyseschicht. EDW weiter. Die Schichten werden zweckbestimmter; jede der fünf Schichten repräsentiert einen Bereich, in dem der Wert der 3. GRÜNDE FÜR DATENPERSISTENZ Daten hinsichtlich ihrer Verwendung gesteigert wird, wenn dies Zwei Gründe von Datenpersistenz im Data Warehouse werden notwendig ist. Eine Schicht bedeutet aber nicht zwangsläufig hauptsächlich genannt: Speicherung der bereits transformierten Datenspeicherung. Wird beispielsweise ein Datenbestand nach der Daten in der Basisdatenbank und Speicherung redundanter, Harmonisierung gespeichert und ist bereits für Analysezwecke aggregierter Daten im Data-Mart-Bereich. Darüber hinaus gibt es verwendbar, so muss er nicht auf die oberste Schicht allerdings noch eine Vielzahl von Persistenzgründen im EDW. „durchgereicht“ und dort nochmals gespeichert werden. In einem Hierzu zählen technische Einschränkungen, Governance- ersten Schritt muss entschieden werden, in welchem Format die Bestimmungen des Unternehmens und Gesetze, Vereinfachung Daten wo zu speichern sind. Deshalb ist zunächst der Zweck der der Datenhandhabung oder ein subjektives Sicherheitsbedürfnis. Datenverwendung als Grund der Datenspeicherung zu ermitteln. Sofern uns bekannt, werden Gründe für Datenpersistenz in der Literatur nur selten erwähnt; zudem vermissen wir eine vollständige Auflistung, wie im Folgenden beschrieben. Entkopplung des Quellsystems: Zur Entlastung des Quellsystems werden Daten direkt nach ihrer erfolgreichen Extraktion im Eingangsbereich des DW gespeichert; hierbei werden die Daten nicht oder nur in geringem Maße verändert (z.B. werden Herkunftsmerkmal oder Zeitstempel angefügt). Datenverfügbarkeit: Oftmals sind Daten nicht mehr oder nur in einem veränderten Zustand verfügbar; hierzu zählen z.B. Daten aus dem Internet, aus Dateien, welche regelmäßig überschrieben werden, oder aus Altsystemen. Zudem können Netzwerkprobleme dazu führen, dass auf Daten nicht zugegriffen werden kann. Die Speicherung im Warehouse garantiert die Datenverfügbarkeit. Komplexe Transformationen: Aufgrund ihrer Komplexität sind einige Transformationen sehr zeit- und ressourcenaufwendig, so dass die Daten gespeichert werden, um ein wiederholtes Transformieren zu vermeiden. Abhängige Transformationen: Unter „abhängige Transformation“ verstehen wir solche, deren Durchführung den Zugriff auf weitere Daten erfordert; z.B. erfordert die Verteilung eines Bonus‘ auf die einzelnen Mitarbeiter die Gesamtanzahl der Mitarbeiter. Diese Abb. 1. Schichtenarchitektur für EDW (nach [10]) notwendigen Daten werden im DW gespeichert, um das korrekte Die in Abb. 1 dargestellte Schichtenarchitektur für EDW unterteilt Durchlaufen der Transformation zu gewährleisten. sich in die folgenden Bereiche: Veränderte Transformationsregeln: Regeln können geändert Die Datenempfangsschicht stellt den „Posteingang“ des EDW dar; werden. Besitzen die Daten kein Zeitmerkmal und werden die extrahierte Daten werden ohne oder mit geringen Modifikationen Transformationen nicht „historisiert“, so ist eine identische entgegengenommen und abgelegt. Transformation nicht mehr möglich. Innerhalb der Qualitäts- & Harmonisierungschicht werden die Aufwendige Datenwiederherstellung: Sind Daten nicht mehr im Daten technisch und semantisch integriert. Das beinhaltet DWS verfügbar (z.B. weil sie archiviert sind), ist eine Dublettenerkennung, Aspekte der Informationsintegration (vgl. Wiederherstellung aufwendig, so dass sie gespeichert werden. [11]) etc., und entspricht der Transformation des ETL-Prozesses. Datenzugriffsgeschwindigkeit: Die redundante Speicherung von Die Datenverteilungsschicht enthält harmonisierte und integrierte Daten in Verdichtungsebenen oder materialisierten Sichten zum Unternehmensdaten ohne betriebswirtschaftliche Logik und bildet Zwecke der Performanzverbesserung beim Datenzugriff stellt somit die einheitliche Datenbasis für alle Anwendungen. einen der häufigsten Gründe für die Einführung einer weiteren In der Betriebswirtschaftlichen Modellierungsschicht werden Persistenzebene dar. Daten hinsichtlich der Geschäftsanforderungen transformiert; zum „En-bloc Datenversorgung“: Üblicherweise fliessen neue Daten, Beispiel werden Finanz- mit Logistikdaten verknüpft. aus verschiedenen, gegebenenfalls weltweiten Quellen, zeitlich 98 verteilt in ein EDW. Nachdem diese syntaktisch und semantisch und Ressourcen, die notwendigen Voraussetzungen hierfür zu integiert wurden, werden sie zwischengespeichert und erst zu schaffen. Im Folgenden beschreiben wir diese Anforderungen und einem bestimmten Zeitpunkt in die Datenbasis des Warehouse ihre Konsequenzen kurz. gespielt. Hierdurch wird ein zeitlich definierter, konstanter und in Wie bereits erwähnt, stellt ein EDW häufig die Datenbasis für sich plausibler Datenbestand für die darauf aufsetzenden verschiedene Anwendungen dar; das hohe Datenvolumen Anwendungen gewährleistet. resultiert aus den unterschiedlichen Anforderungen dieser Konstante Datenbasis: Einige, auf Daten des DWS aufbauende Applikationen an die Daten. Der Bedarf an Detailinformationen Applikationen, wie beispielsweise Planung, erfordern eine erfordert viele Daten feinster Granularität. Der Bedarf an konstante Datenbasis, welche sich während der Benutzung nicht historischen Informationen erfordert eine lange Historisierung der ändern darf und deswegen separiert gespeichert wird. Daten. Schließlich wird eine große Bandbreite an Daten „Single Version of Truth“: Transformierte Daten werden nach gesammelt, beispielsweise für Data-Mining-Szenarios. Dieser unternehmensweit gültigen Definitionen, aber ohne spezielle große Datenbestand muss für seine Verwendung aufbereitet Geschäftslogik gespeichert. Hierdurch wird ein einheitlicher, werden; z.B. ist eine gute Berichtsperformanz sicherzustellen. vergleichbarer Datenbestand geschaffen, auf den die jeweiligen Eine hohe Geschwindigkeit beim Datenzugriff wird zumeist durch Geschäftsbereiche und Anwendungen zugreifen können [10]. ein reduziertes Datenvolumen erreicht – durch den Aufbau „Corporate Data Memory“: Alle ins EDW extrahierten Daten materialisierter Sichten oder Verdichtungsebenen. Ein einfaches werden ohne oder nur mit minimaler Veränderung (z.B. durch Beispiel hierfür ist die Verdichtung tagesgenauer Daten auf Anfügen eines Herkunftsmerkmals) gespeichert, um eine Monat, mit einem Faktor von etwa 30. Pflege und Verwaltung größtmögliche Autarkie und Flexibilität von Datenquellen zu solcher Redundanzen erfordert nicht nur Speicherplatz, sondern ermöglichen. So können Datenbestände (wieder-)hergestellt auch zusätzlichen Aufwand, die Daten aktuell und konsistent zu werden, ohne auf die Quellsysteme zuzugreifen, in denen die halten (vgl. [15]). Da diese Aufwände Zeit kosten, ist die Daten möglicherweise schon gelöscht wurden oder nicht mehr Verfügbarkeit der Daten eingeschränkt. Außerdem beschränken zum Zugriff bereitstehen (vgl. [10]). die vordefinierten Datenbestände die Flexibilität der Daten Komplex-abweichende Daten: Zu integrierende Daten können in hinsichtlich geänderter und neuer Nutzungsanforderungen. Syntax und Semantik sehr von der im EDW üblichen abweichen; Ein komplexer Staging-Prozess mit mehreren Schichten eine (zumeist schrittweise) Eingliederung erfolgt erst nach persistenter Daten ist einer schnellen Datenverfügbarkeit vorheriger Speicherung. gegensätzlich. Dies ist insbesondere auch bei Konzepten für Data-Lineage: Daten in Berichten oder Analysen sind häufig „Near-Realtime Reporting“ zu beachten [16]. Ergebnis mehrstufiger Transformationsprozesse. Um eine Rückverfolgung zu den Urprungsdaten zu erleichtern oder zu 4. PERSISTENZ BEI IN-MEMORY ermöglichen, etwa zur Validierung, können gespeicherte EDW-Architekturen basieren gewöhnlich auf relationalen Zwischenergebnisse erforderlich sein (vgl. [12]). Datenbanken (RDBMS) mit Stern-, Snowflake- oder Galaxy- Komplexe Berechtigungen: Anstatt der Definition und Erstellung Schema als Grundlage der Datenmodellierung; siehe z.B. [15,17]. komplexer Benutzerberechtigungen (z.B. auf Merkmale oder auf Solche Modelle ermöglichen gute Performanz bei On-line Feldinhalte), werden bestimmte Data-Marts mit den Daten erstellt Analytical Processing. Große Datenbestände müssen aber auch und die Berechtigungen auf dem Data-Mart vergeben. hier mittels materialisierter Sichten und Verdichtungsebenen „Informationsgewährleistung”: Viele EDW haben zu reduziert werden – mit den bereits beschriebenen Konsequenzen. gewährleisten, dass die Daten den Benutzern in einem bestimmten Spaltenbasierte Datenbanken (vgl. [18,19]) werden aufgrund ihrer Zeitraum (oftmals sogar 24 Stunden pro Tag) zur Verfügung Vorteile bei der Datenkomprimierung und dem Lesezugriff stehen und für die Anwendungen genutzt werden können. Hierfür [20,21] im Data Warehousing genutzt (z.B. [22,23]). Seit einigen werden in der Regel besonders kritische Datenbestände zusätzlich Jahren wird spaltenbasierte In-Memory-Technologie in gespeichert. kommerziellen Data Warehouse Produkten verwendet (z.B. „SAP Corporate Governance: Daten werden gemäß den Compliance- NetWeaver® Business Warehouse Accelerator“ [24,25], Vorgaben des jeweiligen Unternehmens (Corporate Governance) „ParAccel Analytic DatabaseTM“ [26]), um verbesserte gespeichert; z.B., um eine aufgrund bestimmter Daten getroffene Antwortzeiten beim Zugriff auf sehr große Datenbeständen zu Managemententscheidung auch im Nachhinein beurteilen zu erzielen. Solche Technologien erlauben das Laden und Abfragen können. von Datenvolumina im Teradatenbereich mit guter Performanz. Gesetze und Bestimmungen: Zudem gibt es auch Gesetze und Es wurden bereits Installationen angekündigt, die On-Line Bestimmungen, die eine Datenspeicherung begründen; für Transactional und Analytical Processing in einem System mit bis Deutschland existieren solche beispielsweise im Finanzbereich zu 50 TB Daten im Hauptspeicher ermöglichen [27]. In diesem (Handelsgesetzbuch u.a., [13]) und bei der Produkthaftung [14]. Bereich ist SanssouciDB als ein erstes Produkt zu nennen [3]. Subjektive Sicherheit: Letzlich kann das sujektive Bedürfnis an Diese technologischen Veränderungen führen zu der Frage, in Sicherheit ein Grund für Datenspeicherung sein. welchem Maße Datenpersistenz in IMDB-basierten EDW- Systemen noch notwendig ist. Es wird suggeriert, dass bei In- Persistenz beinhaltet häufig redundante Datenhaltung, da sowohl Memory-Technologie keine Daten zusätzlich zu den Quell- als auch transformierte Zieldaten gespeichert werden; gespeicherten Urspungsdaten persistent gehalten werden müssen. ausschließliches Speichern der Zieldaten bedeutet in aller Regel Alle abgeleiteten Daten, insbesondere die für Analysezwecke Datenverlust. Hieraus entstehen hohe Anforderungen, nicht nur an aggregierten oder verdichteten, werden „on-the-fly“ ermittelt und die Hardware (Speicherplatz etc.), sondern auch an die zur Verfügung gestellt [3,27]. Dies gilt jedoch nur für einige der Datenpflege, um etwa die Datenbestände konsistent zu halten. o.g. Gründe, wie im folgenden deutlich wird. In diesem Der Betrieb produktiver DWS führt zwangsläufig zu Konflikten Zusammenhang fokussieren wir uns auf Datenbanken, die ACID- zwischen den Anforderungen der Datennutzung, wie z.B. fähig sind, inklusive Dauerhaftigkeit (z.B. SanssouciDB, solidDB Performanz bei Reporting und Analyse, und dem Aufwand an Zeit 99 von IBM und TimesTen von Oracle [3,28,29]). Persistenz ist hier Gruppe sind Daten, die gespeichert werden, um den Betrieb des zu unterscheiden von volatiler Speicherung, bei der die Daten in Warehouse oder einzelner Anwendungen zu vereinfachen; hierzu flüchtigem Speicher gehalten werden und verloren gehen, wenn zählen speziell abgelegte Plandaten oder Data-Marts mit das System heruntergefahren wird oder abstürzt. Berechtigungen für besondere Benutzer. Drittens begründet sich Persistenz mit spezieller Konzeption (Design) des EDW: „Single 4.1 Notwendigkeit der Datenpersistenz Version of Truth“, „Corporate Data Memory“ zählen u.a. hierzu. Eine Entscheidung für Datenpersistenz kann nicht ausschließlich Sicherheit, etwa zur Gewährleistung der Datenverfügbarkeit, stellt nach einem kostenbasierten Vergleich von „Plattenplatz und eine weitere Gruppe dar. Letztlich ist Datenspeicherung für eine Kosten des Updates versus Geschwindigkeitsgewinn der Analyse” hohe Performanz ein Grund; oftmals der, dem das größte getroffen werden. Zunächst ist der Grund der Datenspeicherung redundante Datenvolumen zugrunde liegt. (s. Abschnitt 3) zu berücksichtigen. Im RDBMS-basierten DWS Daten, deren Speicherung unterstützend ist, beinhalten solche, die ist diese Überlegung weniger ausgeprägt, da die geringere wegen subjektiver Sicherheitsüberlegungen abgelegt werden. Leistungsfähigkeit der Datenbank und der daraus resultierende Eine komplette Auflistung der Persistenzgründe, gruppiert nach Bedarf an aggregierten Daten das Speichern begründet. Um die Notwendigkeiten, zeigt Tab. 1. Notwendigkeit von Datenpersistenz zu ermitteln, führen wir eine Einteilung dieser Gründe ein: die Speicherung der Daten ist nur Abb. 2 zeigt ein vereinfachtes Entscheidungsdiagramm für unterstützend, essentiell oder sogar verpflichtend. Datenpersistenz, in dem z.B. unscharfe Begriffe wie „aufwendig“, „komplex“ und „häufig“ abhängig von der Domäne spezifiziert Tab. 1. Persistenzgründe, nach Notwendigkeit gruppiert werden müssen. Die ersten drei Abfragen betreffen verpflichtende Grund/Zweck Notwendigk. Gruppierung Gründe, d.h. die Daten sind – auch in IMDB-basierten EDW – zu speichern. Bei den aus anderen Gründen gespeicherten Daten sind Gesetze und Bestimmungen Verpflichtend - die Entscheidungsgrundlagen sehr vielfältig. Stellen die Daten Corporate Governance Verpflichtend - eine „Single Version of Truth“ dar oder umfasst das EDW-Design ein „Corporate Data Memory”, so sind diese Daten zu speichern. Datenverfügbarkeit Verpflichtend - Ist hingegen eine komplexe Reproduktion oder Transformation Veränderte Grund des Speicherns, so müssen z.B. Zugriffshäufigkeit und Verpflichtend - Sicherstellung der Verfügbarkeit in Betracht gezogen werden, um Transformationsregeln entscheiden zu können. Abhängige Transformationen Verpflichtend - Quellsystem-Entkopplung Essentiell Aufwand Aufwendige Essentiell Aufwand Datenwiederherstellung Komplexe Transformationen Essentiell Aufwand Konstante Datenbasis Essentiell Aufwand “En-bloc Datenversorgung” Essentiell Vereinfachung Komplex-abweichende Daten Essentiell Vereinfachung Data-Lineage Essentiell Vereinfachung Komplexe Berechtigungen Essentiell Vereinfachung „Single Version of Truth“ Essentiell Design „Corporate Data Memory“ Essentiell Design „Informationsgewähr” Essentiell Sicherheit Zugriffsgeschwindigkeit Essentiell Performanz Subjektive Sicherheit Unterstützend - Verpflichtend zu speichern sind Daten aufgrund von Gesetzen und Bestimmungen sowie Regeln der Corporate Governance. Zudem gilt dies für Daten, welche nicht wieder hergestellt werden können, weil sie nicht mehr oder nur verändert zur Verfügung stehen oder aufgrund geänderter Transformation nicht mehr erstellt werden können. Auch Daten, die bei der Transformation anderer Daten benötigt werden, sind zu speichern, wenn eine gleichzeitige Verfügbarkeit nicht gewährleistet werden kann. Essentielle Datenpersistenz kann in bestimmte Gruppen unterteilt werden: Zum einen Daten, deren Wiederherstellung nur mit sehr hohem Aufwand (an Zeit und Ressourcen) möglich ist, wie z.B. archivierte oder komplex transformierte Daten. Hierbei ist „sehr hoch“ allerdings subjektiv und näher zu untersuchen. Eine zweite Abb. 2. Entscheidungsdiagramm „Datenpersistenz“ 100 4.2 Bewertung der Persistenz in IMDBs für die Konsistenzsicherung der abgeleiteten Verdichtungsebenen, Alle nicht-verpflichtend gespeicherten Daten sind Gegenstand der geringer ist als der Geschwindigkeitsgewinn der Anwendung? Betrachtung bei der Frage nach Persistenz in IMDB-basierten Und: Wie aufwendig sind diese Änderungen? EDW. Insbesondere betrifft dies Daten, die zur Verbesserung der Untersuchungen dieser Art sind auch bei RDBMS-basierten DWS Zugriffsperformanz oder aufgrund komplexer Transformation valide. Hierbei lässt die Leistungsfähigkeit einer IMDB jedoch als redundant abgelegt werden. Das bedeutet aber nicht, dass allein Ergebnis erwarten, dass Transformationen eher „on-the-fly“ als die Geschwindigkeit der Datenverarbeitung in einem solchen mit redundanter Persistenz durchgeführt werden. System jede Art zusätzlicher Speicherung überflüssig machen Einige IMDB ermöglichen die Festlegung unterschiedlicher wird. Dies gilt beispielsweise für die „En-bloc Datenversorgung“ Kriterien zur Dauerhaftigkeit, z.B. durch Definition temporärer oder beim Aufbau einer konstanten Datenbasis für Planungsläufe. Tabellen [29,30]. Hierdurch können Daten, die nicht verpflichtend IMDB-Snapshot-Mechanismen, wie in [30] erläutert, halten den zu speichern sind, nur in flüchtigem Speicher gehalten werden. Da Datenbestand zumeist nicht über die benötigte Zeit von Stunden ein Herunterfahren oder Absturz der Datenbank relativ selten oder Tagen konstant. Hier kommt es nicht auf eine schnelle geschieht, sind die Wartungskosten für solche Daten gering. Ein Versorgung mit neuen Daten an, sondern auf die Herstellung eines beispielhafter Anwendungsfall hierfür ist die Ermittlung von über einen definierten Zeitraum unveränderten Datenbestands. RFM-Attributen (Recency, Frequency, Monetary) zur Zeitstempelverfahren in In-Memory-Konzepten [3,30] können ein Kundenkategorisierung im CRM-Umfeld [31]. Die Emittlung (s. Lösungsszenario sein. Für die Ersetzung eines „Corporate Data Abb. 3) basiert auf Kundenstamm- und Transaktionsdaten Memory“ jedoch sind diese Verfahren nicht geeignet, wenn Daten (Kassenbons, Aufträge, Fakturen) und umfasst Selektionen, verschiedener Quellsysteme integriert werden, was insbesondere Kalkulationen, Währungsumrechnungen, Look-Ups zu komplexen für ein EDW gilt. Auch werden Persistenzgründe wie komplexe Steuerungsdaten etc. Die berechneten Attribute werden zeitnah Berechtigungen oder Data-Lineage weiterhin gültig bleiben. aktualisiert benötigt, sowohl im DWS, als auch im CRM-System. Die Erfahrung zeigt, dass technische Beschränkungen meist früher Zu berücksichtigen ist, dass es sich hierbei um oft sehr große als erwartet eintreten, so dass die Systemressourcen für die an sie Mengen an Daten handelt, mehrere Millionen Kunden mit jeweils gestellten Aufgaben nicht mehr ausreichen werden. Die einer zweistelligen Anzahl Transaktionen. Diese Datenbestände Möglichkeit, auf sehr viele Daten mit sehr hoher Performanz ändern sich häufig, so dass auch die RFM-Attribute laufend zuzugreifen, wird neue Bedürfnisse wecken. Es werden neue aktualisiert werden müssen. Da die Ermittlung der Attribute Anforderungen aufkommen und die Datenmengen zunehmen. reproduzierbar ist, kann das Vorhalten dieser Daten ausschließlich Aufgrund dessen ist auch bei IMDB-basierten Systemen zu im flüchtigen Speicher einer Persistierung vorzuziehen sein. betrachten, ob wiederholte, gleichartige Zugriffe und Bearbeitung von Daten „on-the-fly“ nicht durch Vorhalten der Daten im benötigten Format günstiger ist. Dies gilt insbesondere für Datenbestände, auf die häufig zugegriffen wird und die sich nicht oder nur wenig ändern, wie beispielsweise die geschlossenen Jahres-, Quartals- oder Monatsabschlüsse der Finanzbuchhaltung. Eine weitere Frage in diesem Zusammenhang ist das Datenformat, in dem gespeichert wird, d.h. auf welcher Transformationsstufe die Speicherung optimal ist. Hierbei ist das Format zu ermitteln, welches eine möglichst flexible Verwendung der Daten bei einer größtmöglichen Vermeidung wiederholter, gleichartiger Transformationen darstellt. Dies kann durch kostenbasierte Laufzeitmessungen geschehen, wie folgendes Beispiel erläutert: Gegeben sei ein Rohdatenbestand (R), der über eine mehrstufige Transformation (Tn; n={1,2,3}) für Analysen (A) abgefragt wird. Zu vergleichen ist, ob es effizienter ist, die Daten nach den einzelnen Transformationen persistent zu speichern (P), sie volatil zu halten (V), oder sie jeweils „on-the-fly” neu zu ermitteln: (1) R  T1 + P  T2 + P  T3 + A (2) R  T1 + P  T2 + V  T3 + A (3) R  T1 + P  T2  T3 + A (4) R  T1 + V  T2  T3 + A (5) R  T1  T2  T3 + A Weitere Indikatoren, die hier betrachtet werden müssen, sind: Abb. 3. Ermittlung von RFM-Attributen Datenvolumen: Ist die Datenmenge so groß, dass die zur Nutzung notwendige, oftmals sehr komplexe Aufbereitung überhaupt bzw. Festzuhalten bleibt, dass in einem IMDB-basierten EDW viele in einer akzeptablen Zeit „on-the-fly“ durchgeführt werden kann? Daten nicht mehr gespeichert werden müssen, die in einem Häufigkeit der Datennutzung: Wird auf die Daten so häufig RDBMS-basierten aufgrund von Performanzgewinn redundant zu zugegriffen, dass der Nutzen einer zusätzlichen Materialisierung halten sind. Höhere Zugriffsgeschwindigkeiten werden es deren Kosten aufwiegt? ermöglichen, Daten „on-the-fly“ für die Nutzung aufzubereiten, Häufigkeit von Datenänderungen: Wird ein Datenbestand so oft insbesondere solche mit relativ einfacher Transformationslogik, geändert (durch Update, Insert, Delete), dass der Aufwand, z.B. wie z.B. Aggregation, Joins etc. Eine Vielzahl materialisierter Sichten wird zu virtuellen Sichten. 101 5. FAZIT UND AUSBLICK [9] B.A. Devlin: „Business Integrated Insight (BI²)”; Enterprise Data Warehouses sind komplexe Systeme mit www.9sight.com/bi2_white_paper.pdf {03.05.2011}; 2009. speziellen Anforderungen an Datenbestand und Datenhaltung, für [10] SAP: „PDEBW1 - Layered Scalable Architecture (LSA) for die eine Architektur dedizierter, zweckbestimmter Schichten BW“; Schulungsunterlagen, SAP AG; 2009. geeignet ist. Die Notwendigkeit von Datenpersistenz in solchen [11] U. Leser, F. Naumann: „Informationsintegration“; dpunkt- Systemen kann nur durch den Zweck der Daten begründet Verlag, Heidelberg; 2007. werden. Diese Sichtweise wird bei IMDB-basierten EDW noch entscheidender. Wir beschreiben Gründe der Datenpersistenz und [12] Y. Cui, J. Widom: „Lineage Tracing for General Data unterteilen sie in verpflichtende, essentielle und unterstützende. Warehouse Transformations”; in: The VLDB Journal 12(1), Darauf aufbauend nähern wir uns der Entscheidungsfindung, ob S.41-58; 2003. Daten in solchen Systemen gespeichert werden. [13] §§239,257 HGB (Stand: 01.03.2011); §25a KWG (Stand: Persistente Datenhaltung wird es auch in EDW-Systemen auf 01.03.2011); §147 AO (Stand: 08.12.2010). IMDB geben. Ein großer Anteil heutiger persistierter Daten wird [14] §13 ProdHaftG (Stand: 19.07.2002). allerdings nur flüchtig gespeichert oder „on-the-fly“ berechnet. Zudem wird die Frage aufkommen nach dem Format, in dem die [15] W. Lehner: „Datenbanktechnologie für Data-Warehouse- Daten abgelegt werden. Die Antwort hierauf wird nicht einfach zu Systeme“; dpunkt-Verlag, Heidelberg; 2003. ermitteln sein; es handelt sich hierbei vielmehr um eine [16] J. Langseth: „Real-Time Data Warehouses: Challenges and multidimensionale Gewichtung verschiedener Faktoren, wie: Solutions“; on: www.dssresources.com {03.05.2011}; 2004. Aufwand für Transformation, Speicherung und Updating, Anzahl [17] R. Kimball, M. Ross: „The Data Warehouse Toolkit”; Wiley und Zeit von Datenabfrage und -aktualisierung. Publishing Inc., Indianapolis, 2.Auflage; 2002. Zukünftige Arbeiten werden eine detaillierte Aufstellung von [18] G.P. Copeland, S.N. Khoshafian: „A Decomposition Storage Persistenzgründen mit ausführlichen Beispielen umfassen. Model”; in: SIGMOD`85, S.268-279; 1985. Darüber hinaus werden Indikatoren definiert und beschrieben werden, die die Entscheidungsfindung für/gegen Datenpersistenz [19] M.J. Turner et al.: „A DBMS for large statistical databases”; unterstützen. Dies umfasst sowohl messbare, wie beispielsweise in: 5th VLDB`79, S.319-327; 1979. Vergleiche von Laufzeiten und Wartungsaufwänden zwischen [20] D.J. Abadi et al.: „Integrating Compression and Execution in Datenbeständen in verschiedenen Speicherzuständen, als auch Column-Oriented Database Systems“; in: SIGMOD`06, nicht-messbare Indikatoren. So wird ermittelt, ob Entscheidungen S.671-682; 2006. durch Berechnungen getroffen oder hierdurch zumindest [21] D.J. Abadi: „Query Execution in Column-Oriented Database unterstützt werden können. Systems”; Dissertation, MIT; 2008. 6. DANKSAGUNG [22] M. Stonebraker et al.: „C-Store: A Column-oriented DBMS”; Diese Arbeit wird teilweise unterstützt vom Bundesministerium in: 31st VLDB`05, S.553-564; 2005. für Bildung und Forschung (BMBF) innerhalb des ViERforES-II- [23] D. Slezak et al.: „Brighthouse: An Analytic Data Warehouse Projekts (Nr. 01IM10002B). for Ad-hoc Queries“; in: PVLDB 1(2), S.1337-1345; 2008. 7. LITERATUR [24] T. Legler et al.: „Data Mining with the SAP NetWeaver BI [1] R. Winter: „Why Are Data Warehouses Growing So Fast?”; Accelerator“; in: 32nd VLDB`06, S.1059-1068; 2006. www.b-eye-network.com/print/7188 {03.05.2011}; 2008. [25] J.A. Ross: „SAP NetWeaver® BI Accelerator”; Galileo Press [2] H. Plattner et al.: „ETL-less Zero Redundancy System and Inc., Boston; 2009. Method for Reporting OLTP Data” (US 2009/0240663 A1); [26] ParAccel: „PARACCEL ANALYTIC DATABASETM“; US Patent Application Publication; 2009. www.paraccel.com/wp-content/uploads/2010/07/PA_DS.pdf [3] H. Plattner, A. Zeier: „In-Memory Data Management“; {03.05.2011}; 2011. Springer-Verlag, Berlin; 2011. [27] H. Plattner: „A Common Database Approach for OLTP and [4] B.A. Devlin, P.T. Murphy: „An architecture for a business OLAP Using an In-Memory Column Database”; in: and information system”; in: IBM Systems Journal 27(1), SIGMOD`09, S. 1-2; 2009. S.60-80; 1988. [28] IBM: IBM solidDBTM; www.ibm.com/software/data/soliddb [5] V. Poe: „Building a data warehouse for decision support”; {03.05.2011}; 2010. Prentice Hall PTR, Upper Saddle River; 1996. [29] Oracle: „Extreme Performance Using Oracle TimesTen In- [6] H. Muksch, W. Behme (Hrsg.): „Das Data Warehouse- Memory Database”; www.oracle.com/technetwork/database/ Konzept“; Gabler-Verlag, Wiesbaden, 4.Auflage; 2000. timesten/overview/wp-timesten-tech-132016.pdf {03.05.2011}; 2009. [7] P. Gluchowski; P. Chamoni: „Entwicklungslinien und Architekturkonzepte des On-Line Analytical Processing“; in: [30] A. Kemper, T. Neumann: „HyPer: Hybrid OLTP&OLAP Analytische Informationssysteme, Springer-Verlag, High PERformance Database System“; 3.Auflage, S.143-176; 2006. www3.in.tum.de/research/projects/HyPer/HyperTechReport. pdf {03.05.2011}; 2010. [8] T. Zeh: „Referenzmodell für die Architektur von Data- Warehouse-Systemen (Referenzarchitektur)“; [31] J. Stafford: „RFM: A Precursor of Data Mining”; www.tzeh.de/doc/gse-ra.ppt {03.05.2011}; 2008. www.b-eye-network.com/view/10256 {03.05.2011}; 2009 102