Minimale Latenz - Bedarfsgerechte Bereitstellung von Daten im DWH

Transkript

1 Minimale Latenz - Bedarfsgerechte Bereitstellung von Daten im DWH Andreas Ballenthin OPITZ CONSULTING Gummersbach GmbH Schlüsselworte: Oracle Data Integrator, Oracle GoldenGate, Oracle BI Suite Enterprise Edition 11g, ODI, OGG, OBIEE, Real-Time-DWH Einleitung In der Vergangenheit wurden Data Warehouse-Systeme hauptsächlich für die Unterstützung von strategischen Analysen konzipiert. Dabei werden historische Daten gesammelt, aufbereitet und zur Analyse zur Verfügung gestellt. Inzwischen werden Data Warehouse-Systeme verstärkt bei der Informationsversorgung von operativen Prozessen eingesetzt. Die Operationalisierung des klassischen Data Warehouses hat dazu geführt, dass die Grenzen zwischen analytischen und operativen Systemen fließend sind. Historische Daten ermöglichen zwar die retrospektive Analyse und sind somit von immenser Bedeutung für ein Unternehmen, jedoch können diese nicht die neuen Anforderungen der Unternehmen für eine aktuelle Tagesanalyse erfüllen. Bei kritischen Prozessen, die insbesondere im operativen Betrieb verstärkt auftreten, steigt die Anforderung nach zeitaktuellen Daten. Dadurch erhoffen sich Unternehmen eine beschleunigte Reaktion auf Geschäftsvorfälle. Das Ziel ist es dabei, die Effizienz und Effektivität der Informationsversorgung mit Hilfe von aktuellen Daten im gesamten Unternehmen zu steigern. Die neue Anforderung nach zeitaktuellen Daten hat dazu geführt, dass inzwischen Data Warehouse-Systeme verstärkt bei der Informationsversorgung von operativen Analysen eingesetzt werden, um ein reaktionsschnelles und proaktives Handeln zu ermöglichen. Gerade im operativen Bereich wird der größte Teil des Umsatzes eines Unternehmens generiert und somit ist dort mit kritischen Geschäftsprozessen zu rechnen. Eine Analyse, basierend auf aktuellen Daten, kann dabei helfen, Risiken frühzeitig zu erkennen und intelligent zu agieren. Unternehmen versprechen sich durch eine schnelle Reaktion auf Geschäftsereignisse gleichzeitig auch eine Effizienzsteigerung. Die Operationalisierung des Data Warehouses hat dazu geführt, dass sich im Laufe der Zeit alternative bzw. ergänzende Data Warehouse-Technologien entwickelt haben, die die Anforderung nach Echtzeitdaten erfüllen. Im Vortrag soll betrachtet werden, wie sich durch den Oracle Data Integrator einerseits und durch native Oracle-Mechanismen andererseits, jeweils im Zusammenspiel mit Oracle GoldenGate Latenzzeiten minimieren lassen. Zusätzlich wird betrachtet, wie sich über einen Data-Federation- Ansatz operationale Daten und historische Daten in der Oracle BI Enterprise Edition wieder zusammenführen lassen. Latenzzeit Die Latenzzeit lässt sich nach Kemper, Mehanna, Unger (Business Intelligence - Grundlagen und praktische Anwendungen) in folgende Teile klassifizieren: Datenlatenz: Die Datenlatenz bezeichnet den Zeitraum zwischen dem Erfassen des Geschäftsereignisses im Quellsystem und der Bereitstellung der Daten im Data Warehouse. Analyselatenz: Die Zeitspanne für den Transformationsprozess der Daten in Informationen und die anwenderspezifische Präsentation der Informationen wird als Analyselatenz verstanden. Entscheidungslatenz: Die Entscheidungslatenz beschreibt die Zeitdauer für die Generierung von handlungsanleitendem Wissen. Dabei werden die zu ergreifenden Maßnahmen definiert.

2 Umsetzungslatenz: Die Zeit, die von der getroffenen Entscheidung bis zur tatsächlichen Umsetzung vergeht, beschreibt die Umsetzungslatenz. Abb. 1: Wert-Aktionszeit-Kurve (vgl. Kemper, Mehanna, Unger (Business Intelligence - Grundlagen und praktische Anwendungen) Die Gesamtheit der Teillatenzzeiten wird als Aktionszeit verstanden. Sie beschreibt den Zeitraum vom Eintreffen eines Geschäftsereignisses im operativen System bis zur Umsetzung der Entscheidungen. Für das weitere Verständnis wird der Begriff Latenzzeit übergreifend für alle Teillatenzzeiten respektive für die Aktionszeit gewählt. Kritisch zu betrachten ist jedoch, dass nicht alle vier Teillatenzzeiten dieselbe Relevanz aufweisen, um für das Unternehmen nachhaltig einen Mehrwert zu leisten. Die Daten- und Analyselatenz sind für eine effizientere Informationsversorgung verantwortlich und haben die Unterstützungsfunktion für die nachfolgenden Latenzzeiten inne. Eine Reduzierung der Daten- und Analyselatenz lässt sich durch technische Werkzeuge realisieren. Die Entscheidungs- und die Umsetzungslatenz sind jedoch im Grunde die ausschlaggebenden Latenzzeiten für die potenzielle Effizienzsteigerung im Unternehmen. Hierbei sollen auf Basis der bereitgestellten Informationen die Aktionen durchgeführt werden. Der tatsächliche Nutzen für das Unternehmen durch eine Minimierung der Latenzzeit kann somit erst durch die Umsetzung der Maßnahmen ermittelt werden. Im Vortrag soll betrachtet werden, wie eine Minimierung der Daten- und Analyselatenz realisiert werden kann. Operational Data Store Als Ergänzung zur klassischen Data Warehouse (DWH)-Architektur existiert das Konzept des Operational Datastore (ODS). Ein ODS ist eine Datenbank, in der zeitpunktbezogene transaktionsorientierte Daten vorgehalten werden. Die Datenstruktur im ODS ermöglicht Analysen auf höchst aktuellen Daten. Direkte Abfragen auf den operativen Systemen durchzuführen ist zwar möglich, belasten diese jedoch in enormer Weise. Transaktionale Systeme sind für kurze und schreibende Zugriffe konzipiert. Für lange, lesende, meist aggregierte Abfragen wird zu viel Zeit benötigt. Das operative Tagesgeschäft wird durch diese Abfragen belastet und nachteilig beeinflusst. Mithilfe des ODS-Konzepts können Auswertungen auf aktuelle Daten durchgeführt werden, ohne die transaktionalen Systeme zu belasten. In einem ODS befinden sich die aus den operativen Systemen extrahierten Daten. Dabei wird bei der Bewirtschaftung des ODS die

3 Datenqualität eingeschränkt betrachtet, da hierbei der Fokus nicht, wie beim klassischen ETL- Prozess, auf dem Transformationsschritt liegt. Sachverhalte wie Harmonisierung und Datenbereinigung treten in den Hintergrund. Werden Daten in dem zugrunde liegenden operativen System geändert, so werden sie auch im ODS überschrieben. Diese Aktualisierung kann zu diversen Zeitpunkten stattfinden. Je nach Anwendungsbedarf kann die Datenaktualisierung im ODS synchron zum operativen System erfolgen, d. h. sobald eine Änderung im Quellsystem vorgenommen wird, wird der entsprechende Datensatz ebenfalls im ODS geändert oder zeitlich gesteuert, wie z. B. stündlich oder täglich. Im Gegensatz zum klassischen DWH werden die Daten in einem ODS über einen kürzeren Zeitraum, in der Regel mehrere Tage, vorgehalten. Es findet demzufolge keine Historienbildung wie im DWH statt. Des Weiteren ist der Detaillierungsgrad der im ODS gespeicherten Daten aufgrund ihrer Transaktionsorientierung sehr hoch. Die Charakteristika des ODS eignen sich insbesondere dazu, um Daten mit hoher Aktualität für eine schnelle Analyse bereit zu stellen. Um dennoch eine Aggregation der Daten zu erreichen, können Index-Techniken, Views oder zusätzliche Arbeitstabellen ergänzend im ODS eingesetzt werden. Kurzer Überblick über Oracle GoldenGate Eine naheliegende Art, Daten aus dem Quellsystem mit geringer Latenz in ein Data Warehouse zu überführen, ist die Benutzung von Oracle GoldenGate als Replikatmechanismus. Der Extraktions- und Ladeprozess zwischen Quell- und Zielsystem besteht im Wesentlichen aus den Komponenten Extraktion, Source Trail, Netzwerktransfer, Remote Trail und dem Replikationsprozess. Abb. 2: Architektur Oracle GoldenGate Im ersten Schritt werden die Transaktionen aus dem Quellsystem extrahiert und in die Traildatei der Quellseite (Source Trail) geschrieben. Dort werden die Daten für die Weiterleitung an das Zielsystem über das Netzwerk gespeichert. Der Source Trail dient dazu, dass die Daten im Quellsystem für die Weiterleitung gespeichert werden. Für die temporäre Speicherung der Daten verwendet OGG Dateien, die auf der Festplatte gespeichert werden. Diese Dateien werden als Trails bezeichnet. Der Nutzen der durch die Trails gewonnen wird liegt darin, dass OGG die Informationen für die zu replizierenden Daten aus diesen Traildateien liest. Dies bedeutet, dass OGG nicht direkt auf das Quellsystem zugreift und somit kaum belastet wird. Außerdem finden die Extraktion und Replikation unabhängig voneinander statt. Somit müssen Änderungen nicht kontinuierlich repliziert werden, sondern können erst in den Traildateien zwischengespeichert werden und später, wenn das Zielsystem diese benötigt, bedarfsgerecht repliziert werden. Traildateien werden in datenbankunabhängigen Datenformaten gespeichert, sodass sie zwischen verschiedenen Systemen ausgetauscht werden können. In der Remote Traildatei werden die Daten nach der Weiterleitung abgespeichert, bevor sie in das Zielsystem repliziert werden. Source Trail und Remote Trail werden benötigt, um im Falle von Netzwerkproblemen keine Daten zu verlieren. Wenn die Verbindung zwischen Quell- und Zielsystem ausfällt und dadurch die Replikation abgebrochen wird, werden die Änderungen weiterhin in das Source Trail geschrieben. Nach Wiederherstellung der Netzwerkverbindung können die Daten aus dieser Datei wieder gelesen und an das Zielsystem weitergeleitet werden.

4 Oracle Data Integrator im Zusammenspiel mit Oracle GoldenGate Der Oracle Data Integrator und Oracle GoldenGate können eng miteinander verwoben werden. Der Oracle Data Integrator bietet hierfür das Journalizing Knowledge Module JKM Oracle to Oracle Consistent (OGG) an. Ein Journalizing Knowledge Module erstellt das CDC-Framework für ein ODI-Modul. Dabei wird eine Reihe von Objekten angelegt: Generierung von Parameterfiles für Oracle GoldenGate: Extract, Datapump, Replicat Skripte zur Installation der Parameterfiles Generierung von Datenbankobjekten für die Verwaltung im Oracle Data Integrator Subscribertabelle (SNP_CDC_SUBS) Abb. 3: Ausschnitt aus der Subscribertabelle CDC-Set-Tabelle SNP_CDC_SET Abb. 4: Ausschnitt aus der CDC-Set-Tabelle CDC-Table-List-Tabelle SNP_CDC_SET_TABLE Abb. 5: Ausschnitt aus der CDC-Table-List-Tabelle CDC-Objekttabelle SNP_CDC_OBJECTS Abb. 6: Ausschnitt aus der CDC-Objekttabelle Journaltabellen (J$) Journalviews (JV$, JD$)

5 Der Oracle Data Integrator bestückt Oracle GoldenGate nicht direkt, sondern generiert ausschließlich Parameterfiles sowie die Handlungsanweisung, wie diese Parameterfiles zu aktivieren sind. Innerhalb eines Oracle-Data-Integrator-Interfaces kann definiert werden, dass aus einem Source Datastore nur die Daten seit der letzten Verarbeitung verarbeitet werden sollen. Abb. 7: Journalized Data only Daraufhin wird ein Filter erzeugt, in dem der Subscribername anzupassen ist. Für die Befüllung der Integrationstabelle (I$) wird die Journalview (JV$) benutzt. Um Journaldaten sinnvoll verwenden zu können, müssen vor dem Lesen der Journalviews das Selektionsfenster gesetzt sowie der Subscriber gesperrt werden. Dies implementiert man über ein Model-Objekt innerhalb des Packages. Sinnvollerweise pollt man aus dem Oracle Data Integrator heraus auf Logdaten des CDC-Sets. Abb. 8: Package zur Verarbeitung der Logdaten Wurden Logdaten gefunden, so werden zunächst die Dimensionsinterfaces und danach das Fakteninterface ausgeführt. Mit dieser Art der Kopplung von Quellsystem und Operational Data Store lässt sich im Laborsystem des Autors eine Latenzzeit (Datenlatenz + Analyselatenz) von 45 Sekunden beim Einsatz von Standard-Knowledgemodulen erreichen. Native Oracle-Mechanismen im Zusammenspiel mit Oracle GoldenGate Auf Replikattabellen von Oracle GoldenGate können Materialized Views sowie Trigger implementiert werden. Als erstes Beispiel soll ein Aggregat auf einem umfangreichend Vollreplikat dienen. Es soll angenommen werden, dass das Vollreplikat pro Tag 10 Millionen Sätze enthält und ein Aggregat Summe pro Tag ohne weitere Dimensionseinschränkungen signifikant häufig benutzt wird. Neben einer möglichen Implementierung über die zuvor geschilderten Mechanismen kann hier auch eine Materialized View mit Fast Refresh on Commit als Teil des Operational Data Stores implementiert werden. CREATE MATERIALIZED VIEW booking_mv1 REFRESH FAST ON COMMIT

6 AS SELECT td.date_of_day,td.day_desc,sum(paym_amount) sum_paym_amount,count(*),count(paym_amount) count_paym_amount FROM booking b INNER JOIN dw_time_day td ON b.paym_date = td.date_of_day GROUP BY td.date_of_day,td.day_desc; Materialized Views können auch weiterverwendet werden: CREATE OR REPLACE VIEW lags_v1 SELECT... FROM lags l INNER JOIN flight_schedule f ON f.flsc_id = l.flsc_id INNER JOIN booking_mv2 b ON b.flsc_id=f.flsc_id GROUP BY f.flsc_airc_id,l.rout_id,l.reas_id,f.flsc_aict_id, TRUNC(actu_dept_time); Mit dieser Art der Kopplung von Quellsystem und Operational Data Store lässt sich im Laborsystem des Autors eine Latenzzeit (Datenlatenz + Analyselatenz) von drei Sekunden erreichen. Ein weiterer sinnvoller nativer Mechanismus sind Trigger auf Replikattabellen. Wenn Transformationen nicht mehr durch einfaches SQL darstellbar sind, ist ein Trigger eine wertvolle Lösung. Dadurch wird zwar die Applizierung in die Replikattabellen verzögert, jedoch kann der Nutzen des Triggers diese Kosten bei weitem übersteigen. Natürlich ist eine Einzelfallprüfung zwingend erforderlich. Ein Spezialfall des Trigger-Mechanismus ist der Start eines ODI-Szenarios nach Einfügen eines Parametersatzes in eine Parametertabelle. Wenn beispielsweise zum Monatsabschluss Daten von einer Fachabteilung freigegeben werden und die Fachabteilung erwartet, dass die freigegebenen Daten unverzüglich verarbeitet werden, so ist ein triggerbasierter Start eines ODI-Szenarios über den ODI-Webservice eine optimale Lösung. Es sind eine Reihe weiterer Anwendungsfälle denkbar, in denen Daten im Zeitverlauf sehr selten verarbeitet werden müssen, dies aber unverzüglich passieren soll. Hier wäre ein Polling-Mechanismus keine optimale Lösung. Data Federation in der Oracle BI Enterprise Edition Operational Data Store und historischer Mart müssen getrennt und gemeinsam auswertbar sein; getrennt über ein Segmentierungsattribut der Zeitdimension und gemeinsam über alle Nicht- Zeitdimensionen sowie den Ebenen der Zeitdimension oberhalb der Ebene des Segmentierungsattributes. Diese Konvention erfüllt im Oracle-Produktstack die Oracle BI Enterprise Edition. Im betrachteten Beispiel sind die Echtzeitdaten aus dem Operational Data Store in einem operationalen Fakt OP_FACT_BOOKING, die historischen Daten in einem historischen Mart FACT_BOOKING abgelegt. Es ist eine gemeinsame Zeitdimension DW_TIME_DAY definiert, beide Faktentabellen sind per Physical Join mit der Zeitdimension verbunden. Die Daten des operativen und des historischen Faktes CURRENT_DAY_IND=1 bzw. CURRENT_DAY_IND=-1 voneinander abgrenzbar. Somit kann im Oracle BI Server mit Fragmentation Contexts gearbeitet werden.

7 Abb. 9: Geschäftsmodell und physischer Layer Abb. 10: Fragmentation Contexts Wird nun in einem Answers-Request beispielsweise per Filter auf CURRENT_DAY_IND=1 abgefragt, so wird ausschließlich der operative Fakt angesprochen, was dementsprechend zu geringen Antwortzeiten führt. Fazit Bei dem kombinierten Einsatz von Oracle GoldenGate und dem Oracle Data Integrator werden die Daten zunächst mit Hilfe von OGG aus den operativen Quellsystemen extrahiert und in das DWH geladen. Die weiterfolgende Transformation der Daten erfolgt daraufhin im ODI. Hierbei werden die Vorzüge beider Werkzeuge kombiniert. Dabei können durch verschiedene Methoden seit der letzten Datenladung geänderte Daten identifiziert und mit sehr geringer Latenz vom Quell- ins Zielsystem geladen werden. Sollte eine Latenz im Minutenbereich noch zu groß sein oder rechtfertigt die Anlieferungshäufigkeit von Quelldaten keinen Polling-Mechanismus, so kann auf oraclenative Verfahren ausgewichen werden. Die Oracle BI Enterprise Edition ist ein mögliches und gleichzeitig das wichtigste Werkzeug, um Operational Data Store und Mart gemeinsam oder getrennt auszuwerten. Insgesamt ist zu sagen, dass Oracle GoldenGate in Zusammenspiel mit dem Oracle Data Integrator über weitreichende Funktionalitäten zur Datenintegration in Echtzeit aufweisen.

8 Kontaktadresse: Andreas Ballenthin OPITZ CONSULTING Gummersbach GmbH Kirchstraße 6 D Gummersbach andreas.ballenthin@opitz-consulting.com Telefon: +49 (0) Fax: +49 (0) Internet: