Post on 30-Oct-2019
transcript
Realtime Data Warehousing
integration-factory White Paper
Daniel Feidieker, Marc Martschei
23.03.2018
Abstract: Das vorliegende Dokument befasst sich mit diversen Problemstellungen beim Aufbau und
dem Betrieb eines Active Data Warehouse mit einem speziellen Fokus auf Datenintegration unter
Verwendung etablierter, ausgereifter Datenintegrationswerkzeuge und relationaler Datenbank-
Systeme. Im Rahmen des Projektes zum Aufbau des EEX Business Data Warehouse wurden
verschiedene Herausforderungen im Umgang mit der Verarbeitung und sofortigen Bereitstellung von
Realtime-Informationen gelöst. Die Herausforderungen und die entwickelten Lösungen sollen hier
dargestellt werden.
integration-factory INTF White Paper - Realtime Data Warehousing 1.0 (final).docx
März 23, 2018 Daniel Feidieker, Marc Martschei Pages 1 / 23
Inhalt
1 Motivation ....................................................................................................................................... 2
2 Fokus des Artikels ........................................................................................................................... 3
3 Einordnung ...................................................................................................................................... 4
3.1 Bewirtschaftung eines Data Warehouse .................................................................................. 4
3.2 Realtime-Daten – Erörterung .................................................................................................. 5
4 Realtime Datenintegration ............................................................................................................... 6
4.1 Receive .................................................................................................................................... 6
4.2 Integrate / Calculate ................................................................................................................. 7
4.3 Gesamtkomposition Receive-Integrate ................................................................................. 11
4.4 Package/ Deliver .................................................................................................................... 13
4.5 Betrieb ................................................................................................................................... 14
5 Fallbeispiel Active DW der European Energy Exchange AG ....................................................... 16
5.1 Übersicht verwendeter Schnittstellen .................................................................................... 16
5.2 Fallbeispiel PEGAS ............................................................................................................... 18
5.3 Fallbeispiel Eurex EMDI ....................................................................................................... 19
5.4 Fallbeispiel ComXerv ............................................................................................................ 21
5.5 Fallbeispiel Reporting Layer ................................................................................................. 22
6 Über integration-factory ................................................................................................................ 23
Tabellenverzeichnis
Tabelle 1: Klassifizierung der Schnittstellen im Fallbeispiel-Active DW ............................................ 17
Abbildungsverzeichnis
Abbildung 1: DW Referenzarchitektur ................................................................................................... 4
Abbildung 2: Latenzzeiten bei der Realtime Datenintegration ............................................................... 5
Abbildung 3: Aufbau eines Konnektors zu einer Echtzeitdatenquelle .................................................... 7
Abbildung 4: Abhängigkeit Prozesslaufzeit Anzahl Läufe ................................................................... 10
Abbildung 5: Aufbau eines Continuous Batch Workflows ................................................................... 10
Abbildung 6: Gesamtablauf Receive und Integrate mit Continuous Batch ........................................... 12
Abbildung 7: Bildung eines konsistenten Snapshots ............................................................................. 13
Abbildung 8: Vierstufiges Modell zu Überwachung des Load Status .................................................. 14
Abbildung 9: Schnittstellenübersicht im Fallbeispiel-Active DW ........................................................ 16
Abbildung 10: Informatica Workflow zur Verarbeitung von EMDI Marktdaten ................................. 19
Abbildung 11: EMDI Recovery Prozess ............................................................................................... 20
Abbildung 12: EMDI Prozess Performance .......................................................................................... 20
Abbildung 13: ComXerv Process Performance .................................................................................... 21
integration-factory INTF White Paper - Realtime Data Warehousing 1.0 (final).docx
März 23, 2018 Daniel Feidieker, Marc Martschei Pages 2 / 23
1 Motivation
Das Data Warehouse (DW) stellt heute die kanonische Lösung zur Sammlung, Organisation und vor
allem zur Integration historischer operativer und weiterer geschäftskritischer Daten in einem
konsistenten, homogenen Datenhaushalt dar. Die hohe Integrationsleistung des DW, mit seinem i.d.R.
von hoher Datenqualität geprägten Datenhaushalt, hat das DW auch wertvoll für operative Aufgaben
gemacht. Business Intelligence, Data Analytics und die operative Einbindung des DW werden auf
täglich getakteten Informationen des letzten Tages ausgeführt.
Der Bedarf, diese Aufgaben auch auf aktuellsten Informationen auszuführen, gewinnt vor dem
Hintergrund eines exponentiell steigenden Datenvolumens und eines schnelllebigen Geschäftsumfelds
immer mehr an Bedeutung. Es erscheint also ganz natürlich, dass Data Warehouse- und Business
Intelligence-Systeme Echtzeitdaten bzw. aktuellste Daten integrieren. Im Folgenden wird dies das
Active Data Warehouse genannt.
Realtime Data Integration, das Kernstück des Active DW, ist notwendig zur Schaffung eines
integrierten, chronologisierten und persistenten Datenhaushalts mit aktuellsten Daten. Die
Aktualisierungsfrequenz soll dabei auf ein sinnvolles Minimum reduziert werden und sich im Idealfall
an der möglichen Bereitstellungsfrequenz der operativen Zuliefersysteme orientieren. Realtime Data
Integration ist auch eine Lösung zur Bewältigung der weiter steigenden Datenvolumina. Des Weiteren
sind in einem 24/7-Arbeitsumfeld traditionelle Nightbatch-Verarbeitungen immer schwieriger aufrecht
zu erhalten.
integration-factory INTF White Paper - Realtime Data Warehousing 1.0 (final).docx
März 23, 2018 Daniel Feidieker, Marc Martschei Pages 3 / 23
2 Fokus des Artikels
Das vorliegende Dokument befasst sich mit diversen Problemstellungen beim Aufbau und dem Betrieb
eines Active Data Warehouse. Dabei liegt der Fokus auf der Datenintegration unter Verwendung
etablierter, ausgereifter Datenintegrationswerkzeuge und relationaler Datenbanksysteme. Im Rahmen
des Projektes zum Aufbau des EEX Business Data Warehouse wurden verschiedene Herausforderungen
im Umgang mit der Verarbeitung und sofortigen Bereitstellung von Realtime-Informationen gelöst. Die
Herausforderungen und die entwickelten Lösungen sollen hier im Allgemeinen dargestellt werden.
Das hier zugrunde gelegte Active DW hat im Wesentlichen die Eigenschaften eines klassischen DW mit
einem normalisierten, fachlich motivierten Datenmodell, das auf technischen Surrogate Keys und einem
starken Harmonisierungsansatz beruht. Objekt-, Versions- und Fremdschlüsselbeziehungen werden
technisch über den Datenintegrations-Prozess (ETL) bestimmt. Informationen, welche erst durch
komplexere Berechnungsverfahren auf der Grundlage der Basisdaten berechnet werden, werden als
Ergebnisse dieser internen Methoden persistiert und für das weitere analytische Arbeiten verfügbar
gemacht. Anders als in herkömmlichen DW-Systemen erfolgt die vollständige Integrationskette nicht
nur in geplanten Batch-Fenstern, sondern auf jüngsten veröffentlichten Daten. Dabei wächst der
komplette Datenhaushalt kontinuierlich und bis zu einem gewissen Grad auch stetig an.
Die wichtigsten Basisdaten werden in sehr kurzen Zyklen aktualisiert. Ebenso verhält es sich mit
wichtigen Methodenergebnissen wie beispielsweise rekonstruierte und schließlich bewertete
Orderbuchlagen. Somit lässt sich analytisch und auch in operativen Geschäftsapplikationen auf
aktuellen Daten arbeiten. Des Weiteren werden die operativen Basisdaten rund um die Uhr ohne
Unterbrechung bereitgestellt.
Durch die kontinuierliche Datenbereitstellung und die Notwendigkeit, empfangene Daten möglichst
schnell zu integrieren und abgeleitete Informationen in ähnlicher Geschwindigkeit zu berechnen,
ergeben sich besondere Anforderungen die gelöst werden müssen:
• Akquisition der Basisdaten
• Reihenfolge- und Ladezustandsprobleme der Integrationskette
• kombinierbare Datenausschnitte für das Reporting
integration-factory INTF White Paper - Realtime Data Warehousing 1.0 (final).docx
März 23, 2018 Daniel Feidieker, Marc Martschei Pages 4 / 23
3 Einordnung
3.1 Bewirtschaftung eines Data Warehouse
Die typische Integrationskette von Daten in ein DW umfasst folgende Schritte:
• Receive
o Akquisition der Daten über verschiedene Konnektoren, Bereitstellungsformen und -
mechanismen
• Integrate
o Harmonisierung der Daten
o Einordnung in den DW-Kontext, d.h. Überführung in das Unternehmensdatenmodell
o Datenqualitätsprüfung und -messung
o Ablage der Daten im Core Layer
• Calculate
o Veredlung der Daten zu weiteren unternehmensrelevanten und –kritischen
Informationen und Geschäftskennzahlen
o Ableitung weiterer Sichten auf die Core Layer-Daten
• Package
o Adressatengerechte Zusammenstellung von Daten und Informationen, bspw. für ein
Berichtswesen oder eine entsprechende Geschäftsapplikation
• Deliver
o Bereitstellung von Informationen an verschiedene Informationsnutzer in diversen
Formaten und Zugriffsvarianten
Die folgende Abbildung zeigt eine Referenzarchitektur für ein DW, das hier durch die Anbindung von
Echtzeitdatenströmen zu einem Active DW wird. Die neuralgischen Punkte sind hier die Akquisition
(Receive) und Übergabe der Daten in die nachfolgende Integrationskette (Integrate und Calculate), die
weiterhin auf bewährten Verfahren und insbesondere auf der etablierten Integrationslogik aufsetzen soll.
Abbildung 1: DW Referenzarchitektur
integration-factory INTF White Paper - Realtime Data Warehousing 1.0 (final).docx
März 23, 2018 Daniel Feidieker, Marc Martschei Pages 5 / 23
3.2 Realtime-Daten – Erörterung
Es gibt verschiedene Begriffe zur Beschreibung des Begriffs Realtime Daten:
- On-demand data – Anfragen von bestimmten Informationen mittels Request-Reply-Verfahren
- Right-time data – Daten stehen zeitlich adäquat für Analysen und Auslieferungen an
nachgelagerte Systeme zur Verfügung
- Near-realtime data – Daten stehen kurze Zeit nach der Entstehung zur Verfügung
- True-realtime data – Daten stehen mit dem Zeitpunkt der Entstehung zur Verfügung
- Continuous streams of data – Daten werden in Datenströmen kontinuierlich bereitgestellt
- Streaming data – Daten werden über ein Queuing-System mit der Entstehung verteilt
Die Begriffe sind nicht überschneidungsfrei, arbeiten aber verschiedene Eigenschaften von Realtime
Daten heraus:
- Realtime Daten zeichnen sich durch eine gewisse Kontinuität in der Zulieferung aus. I.d.R.
werden Daten häufig von einem Quellsystem geliefert oder abgefragt.
- Dies kann in Form eines Datenstroms, der für das DW eher zufällig und ohne echte planbare
Taktung mehr oder weniger Daten zur Verfügung stellt.
- Daten können aber auch in Form von Dateien über ein File-Liefersystem zu mehr oder weniger
planbaren Zeitpunkten auftreten.
- Realtime Daten sind für das DW relevant und stellen v.a. durch ihre Aktualität einen echten
Nutzen dar. Der Wert nimmt mit dem Alter der Veröffentlichung ab: Ein Datum ist umso
wertvoller, je jünger es ist. Dennoch muss nicht jede Anfrage immer tatsächlich auf den
aktuellsten, ggf. noch nicht vollständig integrierten Daten basieren. In diesem Fall zeigt sich,
welcher Aktualisierungszyklus zu „Right Time“ führt. Über „Right Time“ richtet in der Regel
eine Deadline, bis wann Daten nach der Ankunft integriert sein sollen.
- Die Aktualität kann gemessen werden anhand eines Transaktions-, Veröffentlichungs- und
Integrationszeitpunktes. Ggf. sind Informationen, die für nachgelagerte Geschäftsapplikationen
wichtig sind, erst durch Kombination von Basisdaten, die in unterschiedlichen
Geschwindigkeiten integriert werden, herstellbar. In diesem Fall ist der
Veröffentlichungszeitpunkt der jüngste Integrationszeitpunkt aller involvierter Basisdaten.
Die folgende Abbildung stellt die zeitlichen Aspekte der Integration dar:
Abbildung 2: Latenzzeiten bei der Realtime Datenintegration
integration-factory INTF White Paper - Realtime Data Warehousing 1.0 (final).docx
März 23, 2018 Daniel Feidieker, Marc Martschei Pages 6 / 23
4 Realtime Datenintegration
4.1 Receive
Das Data Warehouse muss über Konnektoren verfügen, die Echtzeitdatenströme abnehmen können. Es
kann in der Regel keinen Lieferstandard vorgeben, sondern muss über bereits existierende
Schnittstellensysteme versorgt werden. Der Zugriff auf Echtzeitdaten ist damit häufig eine Frage von
Konnektoren, die nicht standardmäßig vorliegen. Spezifische Konnektoren sind i.d.R. auf das
Schnittstellensystem, das die Basisdaten bereitstellt, zugeschnitten und müssen empfangene Daten so
aufbereiten, dass die Weiterverarbeitung mit dem etablierten Datenintegrationswerkzeug möglich ist.
Eine grobe Einteilung der klassischen Schnittstellen kann wie folgt vorgenommen werden:
- Bereitstellung von Dateien – Dies ist der normale Anwendungsfall in klassischen DW-
Systemen.
- Snapshot Feed, i.d.R. von Dateien – Dateien werden fortlaufend über den Tag zur Verfügung
gestellt. Die gelieferten Datenobjekte können Snapshots der letzten Periode, d.h. seit letztem
Snapshot-Zeitpunkt, sein oder enthalten überlappend Daten auch aus bereits ausgelieferten
Perioden.
Eine grobe Einteilung der Echtzeitschnittstellen kann wie folgt vorgenommen werden:
- Streaming Data – Die Basisdaten werden von der Quelle als Nachrichten mit oder kurz nach
der Entstehung über ein Message Bus-/ Queuing System veröffentlicht. Das DW-System muss
i.d.R. über das Queuing System die Daten konsumieren. Dabei können die folgenden Verfahren
unterschieden werden:
o Kontinuierlicher Datastream mit Retransmission
o Kontinuierlicher Datastream ohne Retransmission
o Kontinuierlicher Datastream mit garantierter Lieferung
o Kontinuierlicher Datastream auf „best effort“-Basis
- Request-Reply-Interface – Die Basisdaten werden aktiv vom Konsumenten über ein Message
Bus-/ Queuing System mittels Frage-Antwort-Schnittstelle abgefragt
- Broadcast-Interface – Die Basisdaten werden aktiv vom DW über ein Message Bus-/ Queuing
System zur Verfügung gestellt. Dabei kann dies zeit- oder ereignisgesteuert erfolgen.
Diese modernen Schnittstellen sind im klassischen DW-Anwendungsfall nicht enthalten und gehören
nicht zum Funktionsstandard etablierter Datenintegrationswerkzeuge. Die Beschaffenheit der
Echtzeitschnittstellen hat direkten Einfluss auf die Komplexität und Umsetzung entsprechender
Konnektoren.
Bei der Akquisition von Echtzeitdaten werden die Verfügbarkeit und das vollständige Vorliegen von
Informationen zu einem nichttrivialen Problem, das zumeist autark vom DW-System und nicht vom
Lieferanten gelöst werden muss. Der Konnektor zu einer Echtzeitdatenquelle hat somit häufig auch
sicherzustellen, dass alle Daten vorliegen und bei Lücken nachgeordert werden. Der Konnektor muss
i.d.R. also über Gap Detection- und Recovery- bzw. Retransmission-Request-Funktionen verfügen. Je
nach Beschaffenheit des Quellsystems sind diese Funktionalitäten unterschiedlich und bedingen
spezielle Absicherungsmaßnahmen, wenn das Quellsystem keine Recovery- bzw. Retransmission-
Requests unterstützt.
Bei der Integration von Echtzeitdaten kommt der Receive-Phase also eine erhebliche Bedeutung zu. Die
in diesem Lieferszenario anfallenden Aufgaben dieser Phase gehen über die Bereitstellung von
Basisdaten für die Datenintegration im klassischen DW hinaus. Um eine Überfrachtung zu vermeiden,
integration-factory INTF White Paper - Realtime Data Warehousing 1.0 (final).docx
März 23, 2018 Daniel Feidieker, Marc Martschei Pages 7 / 23
sind die Konnektoren idealerweise schlank zu halten und sollten keine Datenintegrationsaufgaben im
Rahmen der Bewirtschaftung des Core Layers übernehmen. Erstes Ziel muss die robuste, gesicherte und
vollständige Abnahme der Quelldaten sein.
Die folgende Abbildung zeigt den möglichen Aufbau eines Konnektors mit den beschriebenen
Funktionen:
Abbildung 3: Aufbau eines Konnektors zu einer Echtzeitdatenquelle
Best Practices
• Übernahme der Message-Payloads in Rohformaten in einem Message-Payload-Feld vom
Typ CLOB oder RAW
• Speicherung von Binärdaten in CLOB-Feldern nach HEX-Konvertierung
• Speicherung der Wasserstandsmeldung in separater Tabelle (siehe auch Kapitel 4.2)
• Wasserstandmeldung über „Insert Timestamp“ (ITS)
• ITS als Oracle-Standardwert SYSTIMESTAMP als TIMESTAMP(9)
• Index auf ITS, ggf. eignen sich auch Partitionierungen, für die nachgelagerte Integrate-
Phase
4.2 Integrate / Calculate
Häufig werden Echtzeitnachrichten möglichst schlank übertragen. D.h. der Nachrichteninhalt,
manchmal auch Message Payload oder Message Body genannt, ist in einem Nachrichtenformat, das nur
das Nötigste und zumeist komprimiert transportiert. Neben der gesicherten und vor allem robusten
Abnahme der Echtzeitdaten müssen häufig die Nachrichten in ein für die weitere Integrationskette
lesbares bzw. interpretierbares Format übersetzt werden.
Naturgemäß existieren im DW-Umfeld bereits bewährte Verfahren und insbesondere eine etablierte
Integrationslogik zur Schaffung eines harmonisierten Unternehmensdatenhaushalts. Die
Integrationsarbeit leisten häufig Metadaten-getriebene Datenintegrationswerkzeuge wie beispielsweise
Informatica PowerCenter oder Oracle Data Integrator. Die im Rahmen der Integration der Basisdaten in
das DW und anschließenden weiteren Veredlung eingesetzten Datenmodelle und Integrationslogik
integration-factory INTF White Paper - Realtime Data Warehousing 1.0 (final).docx
März 23, 2018 Daniel Feidieker, Marc Martschei Pages 8 / 23
zielen auf die Schaffung eines zeitorientierten und persistenten Datenhaushalts ab. Entsprechend müssen
die nun teilweise in Echtzeit verfügbaren Daten an die Integrationskette übergeben werden.
Folgende Architekturen können dabei unterschieden werden:
• Batch
o täglich
o Daten werden vollständig oder als Delta Load außerhalb der Spitzenlastzeiten geladen
• Mini-Batch
o stündlich, halbstündlich
o Daten werden inkrementell während des Tages geladen
• Continuous Batch (Micro-Batch)
o minütlich (1-15 Minuten)
o Daten werden kontinuierlich von der Quelle abgegriffen bzw. konsumiert und in
Intervallen geladen
• Realtime
o Sekundenbruchteile
o Daten werden direkt mit der Veröffentlichung konsumiert und ins DW geladen
Wenn einmalig oder gut planbar Dateien bereitgestellt werden, kann auf das Ereignis des Eintreffens
dieser Datenobjekte auch die Integrationskette im Rahmen eines Batches angestoßen werden. Der Batch
kann ggf. auch zurückgehalten werden, wenn weitere funktionale oder technische Voraussetzungen
vorliegen müssen. Dies ist das klassische Beladungsszenario eines DW. Idealerweise findet die
Verarbeitung zu „Off-Peak“ Zeitpunkten statt.
Bei einem Snapshot-Feed kommen beispielsweise Dateien in einem weniger gut planbaren Zyklus, so
dass es sich lohnt, die Aufgaben der Entgegennahme der Datenobjekte und der Datenintegration
orthogonal anzuordnen. Der Konnektor erkennt neue Datenobjekte und legt diese für die weitere
Integrationskette in einer Inbox ab. Aus dieser bedient sich die Integrationskette über Listen neuer, noch
nicht verarbeiteter Datenobjekte. Nach erfolgreichem Durchlauf des Workflows, wird die Kette wieder
neu gestartet.
Bei einem kontinuierlichen Datastream gibt es keine kanonische Vorgehensweise. Beispielsweise
erfordert die Datenintegration von Stammdaten, die eine Versionierung und Historisierung verlangen,
Zugriffe auf Bestandsdaten und neu eingetroffene Daten, um eine Delta Detection zu ermöglichen. Auch
können komplexere Regelwerke bzgl. der Verarbeitung der Basisdaten vorliegen, die aus der
Harmonisierungsaufgabe erwachsen. Ein natürlicher Ansatz ist also, die etablierten Datenintegrations-
und Modellierungsansätze zu bewahren, und in einer kurzen Abfolge auf neusten Daten anzuwenden.
Ansatz 1:
Verzicht auf True Realtime, stattdessen Etablierung eines Near-Realtime-Bewirtschaftungsszenarios:
Mini-Batches. Außerhalb der Bewirtschaftungsperiode steht der Datenhaushalt für (komplexe)
Abfragen/ das Berichtswesen oder andere Datenzugriffe zur Verfügung.
Ansatz 2
Direkter Trickle Feed, d.h. ein Messaging System liefert Nachrichten über ein Queuing System, die von
einem Konnektor entgegengenommen und schließlich direkt in der Datenbank, beispielsweise in der
Faktentabelle abgelegt werden. Hierbei kann es zu Konflikten zwischen Bewirtschaftung und Query-
Performance bei komplexen Abfragen kommen. Des Weiteren eignen sich direkte Load-Strategien nur
bei einer einfachen Integrationsaufgabenstellung. Insgesamt besteht generell die Gefahr, dass die
integration-factory INTF White Paper - Realtime Data Warehousing 1.0 (final).docx
März 23, 2018 Daniel Feidieker, Marc Martschei Pages 9 / 23
Konkurrenz zwischen Bewirtschaftung und Abfrage/ OLAP zu einer Verlangsamung der
Gesamtperformance des Systems führt.
Ansatz 3
Um das Skalenproblem zu lösen, kann man auch den Trickle Feed zunächst in eine temporäre
Faktentabelle (Staging Area) schreiben und zu definierten, getakteten Zeitpunkten die Daten in die
historische, endgültige Faktentabelle fluten. Dies induziert also einen Continuous Batch. Somit stehen
Informationen tatsächlich in Echtzeit im DW zur Verfügung, wobei je nach Quelle die Frage nach der
Übersetzung der Nachrichten in direkt interpretierbare Formate bleibt.
Ansatz 4
Die Integration der Echtzeitdaten erfolgt zunächst in eine separate Datenbankinstanz als Realtime Data
Cache. Damit werden das DWH, das die Ausgangsbasis für OLAP/ das Berichtswesen darstellt, von
kontinuierlichen bzw. häufigen Ladeprozessen entkoppelt. Des Weiteren können auch spezielle
Strategien, z.B. In-Memory Datenbanken für einen optimalen Zugriff auf zuletzt entstandene Daten,
eingesetzt werden.
Im Rahmen des EEX-BDWH-Projektes ist der Ansatz 3 die gebräuchlichste Lösung. Die in Echtzeit
empfangenen Nachrichten werden als Rohdaten in einer Kollektor-Tabelle des Konnektors ohne
Zeitverzug geladen. Aus dieser Kollektor-Tabelle liest ein instanziierter Integrations-Workflow das
Delta seit letztem Run und durchläuft mit diesem Snapshot die Kette und startet nach erfolgreichem
Abschluss wieder eine neue Instanz dieses Workflows.
Dieser Ansatz zerlegt die vollständige Integrationsaufgabe aus Receive und Integrate/ Calculate in
sinnvolle Untereinheiten, die orthogonal angeordnet werden können, und vermeidet insgesamt die
Überfrachtung einer Komponente mit Aufgaben aus der jeweils anderen Phase. Insbesondere kann im
Wesentlichen die etablierte Integrationslogik und das Datenmodell wie im klassischen DW-Szenario
beibehalten werden, was aus Investitionsgesichtspunkten eher günstig ist. Des Weiteren lässt sich die
„right-time“ Auslieferung von DW-Informationen an nachgelagerte Systeme bzw. für OLAP-
Anwendungen relativ einfach steuern und insbesondere auch von der Integrationsaufgabe entkoppeln.
Gleichzeitig skaliert dieser Ansatz mit der zur Verfügung stehenden Systemausstattung.
Die Systemlast steigt durch die vielen Instanziierungen der Workflows stark an. Ist der Durchlauf einer
Workflow-Instanz schnell, kann dies zu sehr vielen Prozessen während des Tages führen. Die folgende
Tabelle verdeutlicht den Zusammenhang zwischen Prozesslaufzeit und Anzahl von
Prozessausführungen.
integration-factory INTF White Paper - Realtime Data Warehousing 1.0 (final).docx
März 23, 2018 Daniel Feidieker, Marc Martschei Pages 10 / 23
Abbildung 4: Abhängigkeit Prozesslaufzeit Anzahl Läufe
Es ist also sinnvoll, Leerläufe zu vermeiden. Durch eine Scope-Ermittlung kann man die Notwendigkeit
eines Durchlaufs berechnen und die Prozesskette direkt terminieren bzw. in eine kurze Ruhezeit
versetzen und im Anschluss wieder starten.
Die folgende Abbildung zeigt einen möglichen Aufbau eines Continuous Batch, der auf einer Kollektor-
Tabelle als Quelle für die über den Konnektor empfangenen Nachrichten aufsetzt:
Abbildung 5: Aufbau eines Continuous Batch Workflows
Von zentraler Bedeutung ist der Prozess „Flatten Src Msg“. Dieser ist verantwortlich für das Erkennen
neuster, noch nicht weiterverarbeiteter Datensätze, die in der Kollektor-Tabelle vorliegen. Dies kann
beispielsweise über eine Wasserstandsmarke erfolgen: Der Prozess ermittelt zunächst den maximalen
Timestamp der zuletzt verarbeiteten Basisdaten bzw. Nachrichten. Alle Nachrichten, die seither in die
Kollektor-Tabelle geschrieben wurden, sind im Scope der aktuellen Verarbeitung, d.h. alle Datensätze,
die der folgenden Bedingung genügen, werden zur Weiterverarbeitung herangezogen:
ITS > (SELECT MAX(ITS) FROM WATERMARK_TABLE)
480 720 9601440
2880
8640
0
2000
4000
6000
8000
10000
180 120 90 60 30 10
Prozesslaufzeit / Häufigkeit
Anzahl von Prozessen
integration-factory INTF White Paper - Realtime Data Warehousing 1.0 (final).docx
März 23, 2018 Daniel Feidieker, Marc Martschei Pages 11 / 23
Der Name „Flatten Src Msg“ hebt die wichtigste Aufgabe dieses Prozesses hervor. Die Nachrichten
müssen übersetzt bzw. dekodiert und schließlich für die weitere Verarbeitung und Ablage in einer
relationalen Datenbank aufbereitet werden. Dieser Vorgang ist naturgemäß vom Nachrichtenprotokoll
und -format abhängig.
Der hier dargestellte Ablauf nimmt an, dass zunächst bestimmte Referenzdaten verarbeitet werden
(Process RD), bevor mit der Integration von Transaktions- bzw. Faktdaten (Process Fct1, 2, 3) begonnen
werden kann. In dieser Darstellung bleibt unberücksichtigt, dass die Reihenfolge bestimmter Entitäten
bei der Realtime Datenintegration nicht durchgängig kontrolliert werden kann. Es kann beispielsweise
in Bezug auf die Lieferreihenfolge von Referenzdaten und diese referenzierenden Fakten zu einer
invertierten Bereitstellung kommen: Evtl. kommen bestimmte Fakten zuerst, während die
Referenzdaten erst verspätet eintreffen. In diesem Fall wäre der „Process RD“-Schritt ohne Daten
gelaufen. Um nicht Rejects in den Prozessen „Process Fct1“ und „Process Fct2“ zu erleiden und damit
ggf. abgestandene/ veraltete und unvollständige Daten in Kauf zu nehmen, kann auch die Anlage von
Rumpfobjekten zu den Referenzdaten beispielsweise durch die Verwendung dynamischer Lookups mit
Ablage in den Objekttabellen der Referenzdaten-Entitäten sinnvoll sein.
Best Practices
• Auswahl des passenden Ansatzes anhand der Anforderungen, nur so aktuell wie nötig und
nicht so aktuell wie möglich
• Verhindern von Prozess-Leerläufen
• Erstellung performanter Prozesse
• Nutzung von Oracle Partitionierung anhand des FACT_DATE der Daten
• Bevorzugung eines continuous Workflows, statt Steuerung aller Prozessschritte mittels
Schedulingtool
4.3 Gesamtkomposition Receive-Integrate
Der Gesamtablauf aus Versorgung (Receive) und Bewirtschaftung (Integrate und Calculate) des DW in
einem Echtzeitszenario kann folgendermaßen angeordnet werden:
- Start des Jobnetzes zum Empfangen und Integrieren von Echtzeit-Basisdaten.
- Prüfen, ob die Startbedingungen für den Konnektor gegeben sind; beispielsweise kann evtl.
geprüft werden, ob das Jobnetz für die vorherige Integrationsperiode erfolgreich und vollständig
beendet wurde. In einem 24/7-Szenario gibt es in der Regel aufgrund technischer Gegebenheiten
eine kurze Sequenz zum Abschluss und zur Neuinitialisierung des Jobnetzes. Da die
gleichzeitige Abnahme einer Echtzeitquelle mit zwei parallelen Konnektor-Instanzen
problematisch sein kann, ist dies ein wichtiger Zwischenschritt.
- Setzen relevanter Parameter, beispielsweise des Geschäftstags.
- Durchführen von Verwaltungsaufgaben, beispielsweise Partition Exchange oder Truncate der
Kollektor- und Stage-Tabellen.
- Start des Konnektor-Clients. Dieser läuft nun solange und ununterbrochen bis zum Ende der
Integrationsperiode.
- Mit dem Start des Konnektor-Clients wird auch der Continuous Batch-Workflow gestartet. Ggf.
ist ein erweiterter Monitorprozess erforderlich. Dies kann zum Beispiel im Rahmen einer
Implementierung mit Informatica als Datenintegrationswerkzeug und BMC Control-M als
Scheduling-Werkzeug sinnvoll sein: Der Continuous Workflow meldet nach dem ersten
erfolgreichen Durchlauf den abschließenden OK-Status an Control-M zurück, was aber
natürlich nicht zum Abschluss des restlichen Jobnetzes führen darf. Daher prüft ein weiterer
Monitorprozess, ob der Continuous Batch-Workflow noch nicht im Status „unscheduled“ ist.
integration-factory INTF White Paper - Realtime Data Warehousing 1.0 (final).docx
März 23, 2018 Daniel Feidieker, Marc Martschei Pages 12 / 23
- Solange noch keine Exit-Bedingung zur Beendigung der Integrationssequenz vorliegt, werden
kontinuierlich in kurzen Abständen Instanzen des Continuous Batch-Workflows durchlaufen.
Jede Instanz greift über eine Wasserstandsmarke auf neuste, noch nicht weiterverarbeitete
Datensätze zu.
- Bei Vorliegen der Exit-Bedingung wird ein Exit-Kommando für den Konnektor-Client erzeugt.
Es ist wichtig, dass zunächst die Receive-Phase abgeschlossen wird. Nur so kann sichergestellt
werden, dass alle empfangenen Daten auch tatsächlich durch die Integrationsphase
weiterverarbeitet wurden.
- Nach Abschluss des Konnektor-Clients wird ein Token gesetzt, die der Monitorprozess erkennt
und sich schließlich mit OK beendet.
- Zuletzt finden die restlichen Verwaltungsmaßnahmen statt, bevor es in den nächsten Gesamtlauf
gehen kann.
Die folgen Abbildung zeigt einen solchen Gesamtablauf.
Abbildung 6: Gesamtablauf Receive und Integrate mit Continuous Batch
Neben der reinen Abnahme und Integration von Echtzeit-Basisdaten ergeben sich noch weitere
Herausforderungen, wenn beispielsweise Daten mit einer bestimmten Integrationsfrequenz durch Daten
mit einer abweichenden Frequenz kombiniert und veredelt werden sollen. In diesem Fall kann die
Weiterverarbeitung (Calculate) nur auf der Schnittmenge erfolgen. Die Daten mit der langsameren
Frequenz bestimmen die Geschwindigkeit, wie die veredelten Daten aktualisiert werden. In diesem
Rahmen muss das Zusammenspiel aus neu empfangenen und noch nicht vollständig integrierten Daten
geregelt werden: Während neu empfangene Daten in der nächsten Instanz eines Continuous Batch
herangezogen werden müssen, müssen auch weiterhin solche Daten geprüft und verarbeitet werden, die
noch nicht vollständig geladenen werden konnten. Diese Daten werden in entsprechenden Rückhalte-
Tabellen mit einem Verarbeitungszustand abgelegt. Noch nicht als abgeschlossen markierte Daten
stehen regelmäßig bei anstehenden Integrationsläufe vor den neusten Daten zur Verarbeitung an.
Best Practices
• Prüfen, ob die Vortagesverarbeitung abgeschlossen wurde
• Verhindern, dass ein Client doppelt gestartet wurde
• Überwachung von Continuous Workflows
• Überwachung der Prozesskette mittels Scheduling Tool
• QS Prozesse, welche prüfen, ob Daten von der Quelle geliefert werden
integration-factory INTF White Paper - Realtime Data Warehousing 1.0 (final).docx
März 23, 2018 Daniel Feidieker, Marc Martschei Pages 13 / 23
• Die Quelle mit der langsameren Frequenz bestimmt die Geschwindigkeit bei der
Kombination zweier Realtime Quellen
4.4 Package/ Deliver
Die im DW integrierten, qualitätsgesicherten und harmonisierten Daten sind die Grundlage für die
Zulieferung nachgelagerter Geschäftsapplikationen im Sinne eines operational Delivery Channels und
natürlich auch für das Berichtswesen, das i.d.R. auf einem OLAP-Server basiert. Im klassischen DW
sind Bewirtschaftung und Zugriff auf den Datenhaushalt zeitlich und damit auch ressourcentechnisch
getrennt. Bei einem Active DW erfolgt die Bewirtschaftung kontinuierlich während der Betriebszeit des
Systems und damit parallel zu den Zugriffen auf aktuellste Daten.
Der Continuous Batch zur Integration der Basisdaten und zur weiteren Veredlung mildert den Konflikt
permanenter Bewirtschaftung und gleichzeitiger OLAP Analysen. Eine weitere Entkopplung ergibt sich
durch Überführung der Basisdaten und Methodenergebnisse in eigene für das Berichtswesen optimierte
Datenstrukturen im Rahmen von Mini-Batches. Implikationen aus der verbreiteten Eigenschaft von
OLAP-Werkzeugen, Abfragen über Multi-Pass SQL Statements abzuarbeiten, sprechen gegen das
Arbeiten eines OLAP-Werkzeugs auf Datenstrukturen, die durch Continuous Batches beladen werden.
Bei der Berechnung der Reporting-Datenstrukturen muss die Bestimmung eines konsistenten Snapshots
erfolgen: Das Unternehmensdatenmodell modelliert verschiedene Entitäten, die aus verschiedenen
Quellen bewirtschaftet werden. Teilweise wird sogar eine Entität aus verschiedenen Quellen beladen,
die unterschiedlichen Frequenzen unterliegen. Somit muss quell- und entitätsbezogen ein Load Status
erhoben und kontinuierlich während des Beladungsprozesses bestimmt werden. Dies kann nicht alleine
auf Grundlage gelieferter und integrierter Transaktionen erfolgen. Es kann auch Perioden geben, in
denen keine Daten empfangen wurden, weil keine Daten vorlagen. Wenn es keine Störung gab, ist also
der Load Status auch ohne Daten fortgeschritten. Dies ist wichtig, da ein konsistenter Snapshot über
zwei Entitäten immer den kleinsten Load Status beider Entitäten als Periodenendpunkt anerkennen
muss.
Die folgende Abbildung stellt die Bildung eines konsistenten Snapshots dar:
Abbildung 7: Bildung eines konsistenten Snapshots
Ein Datenausschnitt, der sich für die Aufbereitung im Reporting-Mart eignet, wird also bestimmt durch
alle integrierten und berechneten Daten im Unternehmensdatenmodell, die seit dem zuletzt geladenen
allgemeinen Load Status bis zum aktuellen Load Status angefallen sind. Dies kann für bestimmte
integration-factory INTF White Paper - Realtime Data Warehousing 1.0 (final).docx
März 23, 2018 Daniel Feidieker, Marc Martschei Pages 14 / 23
Entitäten natürlich unterschiedlich sein, um auch im Reporting verschiedene Geschwindigkeiten
abbilden zu können, ohne besonders schnell integrierte Daten zulange vom Reporting auszusperren.
Zur Berechnung des Load Status müssen diverse Integrationsergebnisse fachlich und technisch
ausgewertet werden. Es gibt im Wesentlichen vier Prüfpunkte:
• Füllstand der Fakten Tabelle(n) – Hieraus wird ein fachlicher Zeitstempel aus mindestens
einer Tabelle, die für die jeweilige Load Group beobachtet werden soll, bezogen.
• Zeitstempel der Quelldatei- oder Quell-Message-Metadaten – Unter Umständen liegen
keine fachlichen Daten vor, aber trotzdem ist die Information „up-to-date“. Dies kann dann aus
den Begleitinformationen herausgelesen werden, z.B. Sequence Marker, Heartbeat Messages
oder die Ableitung aus dem Anlieferungsstand der Dateien
• Durchgängig erfolgreiche Prozesskette - Wenn es einen Abbruch gab, ist ein Load Status
NOT OK abzuleiten. Wenn ein Rerun und schließlich für einen Beobachtungslauf alle
zugehörigen Prozesse durchgelaufen sind, wechselt der Status auf OK, wenn nicht andere
Probleme fortbestehen.
• Füllstand der Reject Tabelle(n) - Hieraus wird ein fachlicher Zeitstempel aus mindestens einer
Tabelle, die für die jeweilige Load Group beobachtet werden soll, bezogen. Der Zeitpunkt eines
nicht gelösten Rejects blockiert den Load Status solange, bis der Reject aufgelöst wurde.
Die folgende Abbildung stellt diesen Prozess bildlich dar:
Abbildung 8: Vierstufiges Modell zu Überwachung des Load Status
Best Practices
• Physische Trennung von OLTP und Reporting Datenstrukturen
• Bildung eines Load Status pro Entität zur Schaffung eines konsistenten Snapshots
4.5 Betrieb
Die Bedeutung und der Nutzen des Active DW steigt mit der Aktualität der integrierten Daten. Da kleine
Störungen auch sehr schnell zu wahrnehmbaren Verzögerungen führen, müssen Störungen frühzeitig
erkannt und schnell behoben werden können. Während der gesamten Betriebszeit müssen sowohl
Datenintegrationsprozesse als auch Ausleitungen und OLAP-Anwendungen beobachtet und ggf.
entstört werden. Entsprechend muss das Alarmierungsverfahren automatisiert ungünstige Situationen
Prozesskette
Rejects
Zeitstempel der Drivin
Table
Quell-Message-
Metadaten
integration-factory INTF White Paper - Realtime Data Warehousing 1.0 (final).docx
März 23, 2018 Daniel Feidieker, Marc Martschei Pages 15 / 23
erkennen und aktiv dem Betriebsmanager anzeigen. Die Folgenden Prüfungen sollten zur Absicherung
der Verarbeitung unternommen werden:
• Rote/ abgebrochene Prozesse
• Abgebrochene Kommunikationen zu Schnittstellensystemen
• Fehlende Datenobjekte
• Verlangsamte Datenverarbeitungen, schlechte Durchsatzraten
• Schlechte Abfragegeschwindigkeit
• Nicht gelaufene Prozesse
In der Regel lassen sich diese Aufgaben durch ein Zusammenspiel des Werkzeugs für Scheduling und
Monitoring und für Datenintegration implementieren.
Die Robustheit des Systems zeichnet sich auch dadurch aus, dass Störungen nicht nur schnell erkannt,
sondern auch schnell behoben werden können. In diesem Zusammenhang kommt dem Aufbau eines
Jobnetzes und verschiedener Rerun-Eigenschaften von Datenintegrationsprozessen eine erhebliche
Bedeutung zu. Echtzeitdatenquellen sind in der Regel einzigartig für den jeweiligen Anwendungsfall.
Allerdings ist oben ein generelles Verfahren zur Anbindung einer Echtzeitdatenquelle beschrieben, das
sich auch in einem einheitlichen Job-Ablaufplan implementieren lässt, der adaptierbar für verschiedene
Anwendungsfälle ist. Der Schulungsaufwand reduziert sich im generellen Teil auf ein oder wenige
Ablaufmuster.
Des Weiteren müssen Recovery- und Retransmission-Aufgaben möglichst vollautomatisch durch den
Konnektor selbst ausgelöst werden. Es gibt aber auch Anwendungsfälle, in denen keine Retransmission-
Funktionalität zur Verfügung steht.
Best Practices
• Automatisierte Alarmierungsverfahren
• Automatisierte QS-Prüfungen
• Automatisierte Retransmission-Aufgaben
• Prozesse müssen rerun-fähig sein
• Einheitliches Layout und Verfahren zur Jobsteuerung
• Monitoring sämtlicher Prozesse zur Minimierung der Downtime bei einem Fehler
integration-factory INTF White Paper - Realtime Data Warehousing 1.0 (final).docx
März 23, 2018 Daniel Feidieker, Marc Martschei Pages 16 / 23
5 Fallbeispiel Active DW der European Energy Exchange AG
Im Folgenden wird kurz auf das Business Data Warehouse (BDWH) der EEX Gruppe eingegangen, um
eine Beispielimplementierung einiger der vorgenannten Punkte zu skizzieren. Das Business Data
Warehouse (BDWH) ist die zentrale Komponente in der Informationsarchitektur der EEX-Gruppe und
empfängt Daten aus unterschiedlichen operativen Quellsystemen und bereitet diese für Business
Applikationen und das EEX-Berichtswesen auf.
5.1 Übersicht verwendeter Schnittstellen
Im Rahmen der Bewirtschaftung des EEX-BDWH gibt es u.a. folgende Inbound- und Outbound-
Schnittstellen:
Abbildung 9: Schnittstellenübersicht im Fallbeispiel-Active DW
Das BDWH wird mehrheitlich durch Echtzeitsysteme mit Basisdaten versorgt. Über solche
Echtzeitsysteme sind die Handelssysteme für den Termin- und Spotmarkt angebunden. Wesentliche
Stammdaten werden teilweise am Tagesende mit Gültigkeit für den kommenden Geschäftstag im Batch-
Modus geliefert und verarbeitet.
Die folgende Tabelle ordnet die verschiedenen Schnittstellen in den zuvor entworfenen Kontext ein:
Inbound
Streaming Data
Interface Technologie/
Protokoll
Payload Format Receive Weiterverarbeitung
CIL AMQP (QPID) GPB RT in Konnektor-
Tabelle
Cont. Batch
CAS AMQP (RabbitMQ) XML RT in Konnektor-
Tabelle
Cont. Batch
EMDI UDP FIX over FAST RT in Konnektor-
Tabelle
Cont. Batch
integration-factory INTF White Paper - Realtime Data Warehousing 1.0 (final).docx
März 23, 2018 Daniel Feidieker, Marc Martschei Pages 17 / 23
OFI TCP/IP binary LTV Umwandlung in
csv-Files pro
Entität und Minute
Mini-Batch
Files
Interface Technologie/
Protokoll
Payload Format Receive Weiterverarbeitung
PEGAS SFTP, cont. File
Bereitstellung
XML File Interface
Modul
Mini-Batch
IRIS SFTP, cont. File
Bereitstellung
XML File Interface
Modul
Mini-Batch
Batch SFTP (einmalig) XML, csv File Transfer Batch
Request-Reply
Interface Technologie/
Protokoll
Payload Format Receive & Deliver Verarbeitung
BDWH MI AMQP (RabbitMQ) XML RT in Konnektor-
Tabelle und
Response-Tabellen
bzw. in Queues
Aus dem Receive-
Prozess
Outbound
Streaming Data
Interface Technologie/
Protokoll
Payload Format Deliver Verarbeitung
ADAL AMQP (RabbitMQ) GPB Direkt in
entsprechende
Topic-Queue
Getaktete
Auslieferung
Files SFTP (einmalig) XML, csv File Transfer Batch, Mini-Batch
Tabelle 1: Klassifizierung der Schnittstellen im Fallbeispiel-Active DW
integration-factory INTF White Paper - Realtime Data Warehousing 1.0 (final).docx
März 23, 2018 Daniel Feidieker, Marc Martschei Pages 18 / 23
5.2 Fallbeispiel PEGAS
Im Jahr 2013 haben die deutsche European Energy Exchange (EEX) und die französische Powernext
ihre Gasmärkte zu einem Pan-Europäischen Angebot für Gas-Produkte (PEGAS) verbunden. Im
Rahmen von PEGAS können Handelsteilnehmer die Gasprodukte beider Börsen auf einer gemeinsamen
Handelsplattform, dem Trayport® Exchange Trading System, handeln. Teilnehmer haben über diese
gemeinsame Handelsplattform Zugang zu allen Spot- und Terminmarktprodukten, die die beiden Börsen
für die Marktgebiete Deutschland, Frankreich und die Niederlande anbieten. Darüber hinaus sind auch
Spread-Produkte zwischen diesen Marktgebieten auf der Plattform handelbar.
Beim PEGAS-Interface werden XML-Dateien rund um die Uhr an allen Tagen (24/7) in untertägiger
Frequenz mit unterschiedlicher Taktung pro Entität bereitgestellt.
• Stammdaten 1x
• Best Limits alle 2-3 Minuten
• Trades alle 5 Minuten
• Orders alle 15 Minuten
• Preise gelegentlich, nur beim Entstehen in der Quelle
Das File Interface arbeitet als Zustandsverwaltungsmaschine und sorgt für das Erkennen, Validieren und
Replizieren der empfangenen Dateien. Eine Datei wird als vollständig bearbeitet angesehen, wenn die
Daten im DW im Staging- bzw. Reject-Layer geladen wurden.
Für PEGAS-Daten existiert eine komplexe Integrationskette, beispielsweise verweisen Trades und
Orders gegenseitig aufeinander. In PEGAS kann eine Order-Update-Transaktion mehrere Ursachen
haben. Einerseits kann diese aus einer User- oder System-induzierten Modifikation (Change, Delete)
resultieren. Andererseits kann auch eine Order-(Teil-)Ausführung die Ursache der Transaktion sein. Um
das zu bestimmen, muss eine Order-Transaktion mit dem zum relevanten Zeitpunkt vorliegenden Trade-
Bestand verknüpft werden. Ebenso müssen aufgrund von Anforderungen der Marksteuerung Trade-
Transaktionen mit Informationen der unterliegenden Order angereichert werden. Da Orders und Trades
unabhängig und in unterschiedlichen Frequenzen bereitgestellt werden, muss die Integrationskette diese
Ungleichgewichte ausgleichen.
Des Weiteren bestehen unterschiedliche Anforderungen an die Integrations- bzw. Harmonisierungstiefe
und Geschwindigkeiten, ggf. existiert eine Deadline für die Bereitstellung von empfangenen Quelldaten.
So mag es Anforderungen geben, die einerseits die nahezu unverzügliche Weitergabe von Informationen
an abnehmende Entitäten erfordern aber gleichzeitig auf eine „tiefe“ Integration/ Harmonisierung
verzichten können. Diese sind im Fast Track schnell zur Verfügung zu stellen und erfordern nur die
Prüfung auf eine Mindestqualität der zugelieferten Daten. Eine vollständige Integration/
Harmonisierung der Informationen erfolgt dann aus einem Vorhaltebestand, wenn konsistente
Snapshots über die verschiedenen Informationen hergestellt werden konnten.
integration-factory INTF White Paper - Realtime Data Warehousing 1.0 (final).docx
März 23, 2018 Daniel Feidieker, Marc Martschei Pages 19 / 23
5.3 Fallbeispiel Eurex EMDI
Die Eurex ist weltweit eine der größten Terminbörsen für Finanzderivate. Um Kunden einen Zugang zu
diesen Marktdaten zu gewähren, steht die Schnittstelle Eurex Enhanced Market Data Interface (Eurex
EMDI) zur Verfügung. EMDI stellt unsaldierte, auf Preisebene aggregierte Marktdaten mithilfe der
UDP-Multicast-Technologie zur Verfügung. Der unidirektionale Empfang der Marktdaten ist geprägt
durch einen hohen Durchsatz und eine niedrige Latenz.
Diese Daten werden als Streaming Data kontinuierlich und direkt ohne Zeitverzug in die Konnektor-
Tabelle geladen. Ein Continuous Batch iteriert über diese Tabelle und integriert pro Instanz die Daten,
die bisher noch nicht weiterverarbeitet wurden. Dies erfolgt über eine Wasserstandsbestimmung über
den Insert Timestamp. Die folgende Abbildung stellt den mit Informatica PowerCenter umgesetzten
Datenintegrationsprozess dar.
Abbildung 10: Informatica Workflow zur Verarbeitung von EMDI Marktdaten
Bei EMDI müssen Recovery-Strategien abnehmerseitig implementiert werden. Das Interface bietet zwar
eine Live-Live-Abnahme-Möglichkeit, die es dem Empfänger ermöglicht, beide Streams miteinander
zu vergleichen. Allerdings wird die tatsächliche Auslieferung nicht garantiert und eine Möglichkeit zur
Anforderung von Nachlieferungen existiert nicht. Daher erfolgt also eine redundante Anmeldung und
Abnahme aus zwei getrennten Umgebungen. Der Konnektor-Client versucht schon während der
Abnahme, Lücken bzw. verpasste Daten zu erkennen und diese selbständig zu lösen. Bei nicht
schließbaren Lücken wird aus der Backup-Umgebung der relevante Datenausschnitt inklusive kleiner
Überhänge in die Konnektor-Tabelle geladen und vom Continuous Batch transparent als neuste Daten
erkannt und weiterverarbeitet. Die folgende Abbildung stellt diesen Prozess exemplarisch dar.
integration-factory INTF White Paper - Realtime Data Warehousing 1.0 (final).docx
März 23, 2018 Daniel Feidieker, Marc Martschei Pages 20 / 23
Abbildung 11: EMDI Recovery Prozess
Der Konnektor-Client schreibt die Daten nahezu verzögerungsfrei in die Staging-Area: Der Mittelwert
zwischen der Entstehung der Daten im Handelssystem und der Persistierung in der Staging-Area liegt
bei 500ms. Die weitere Verarbeitung erfolgt wie bereits beschrieben orthogonal zum Konnektor-Client
über einen Continuous Workflow. Der Mittelwert zwischen der Entstehung der Daten in der Staging-
Area und der Decodierung liegt bei 30 Sekunden. Weitere 25 Sekunden vergehen im Mittel bis zur
vollständigen Ausleitung der Daten. Ab diesem Zeitpunkt stehen alle empfangenen Daten den
Abnehmersystemen des BDWH zur Verfügung oder werden proaktiv über einen AMQP Broker zur
Verfügung gestellt.
Die folgende Abbildung zeigt die Verarbeitungsgeschwindigkeit in Sekunden eines EMDI-Realtime-
Zyklus von 8:00 bis 23.00 Uhr:
Abbildung 12: EMDI Prozess Performance
0
10
20
30
40
50
60
70
80
KONNEKTOR
FLATTEN
FACTS
Überhang Überhang
EMDI UDP Stream EMDI UDP Stream
Abbruch Start nach Abbruch verpasste Daten
Backup UDP Stream Daten
Vollständiger Stream
benötigte Daten
integration-factory INTF White Paper - Realtime Data Warehousing 1.0 (final).docx
März 23, 2018 Daniel Feidieker, Marc Martschei Pages 21 / 23
5.4 Fallbeispiel ComXerv
Die europäische Strombörse European Power Exchange (EPEX SPOT SE) ist eine Börse für
kurzfristigen Stromgroßhandel. EPEX SPOT betreibt darüber hinaus Intraday-Strommärkte für
Deutschland, Frankreich, Österreich und die Schweiz. Die Intraday-Märkte funktionieren über einen
kontinuierlichen Handel: Gebote der Handelsteilnehmer werden laufend in das Orderbuch eingegeben.
Ermöglicht wird dies durch das von EPEX SPOT genutzte Handelssystem, M7 (ComXerv). M7 ist eine
Handelsplattform für Rohstoffmärkte, die von Börsen und Brokern für Intraday-Futures, Forwards,
Clearing- und OTC-Märkte genutzt wird.
Die ComXerv Systeme verwenden eine AMQP-basierte Schnittstelle für die Veröffentlichung der
wesentlichen Handels- und Marktdaten. Diese Daten werden als Streaming Data kontinuierlich und
direkt ohne Zeitverzug in die Konnektor-Tabelle geladen. Ein Continuous Batch iteriert über diese
Tabelle und integriert pro Instanz die Daten, die bisher noch nicht weiterverarbeitet wurden. Dies erfolgt
über eine Wasserstandsbestimmung über den Insert Timestamp. Im Fall von identifizierten Lücken im
Datenmaterial werden Requests zur Nachlieferung der fehlenden Daten an den AMQP-Broker gestellt.
Dies ist ein vollständig automatisierter Prozess und erfolgt auf Basis einer kontinuierlichen Beobachtung
der empfangenen Basisdaten.
Abbildung 13: ComXerv Process Performance
Stammdaten werden als separate Nachrichten ebenfalls als Streaming Data übertragen und müssen
orthogonal zu den Fakten verarbeitet werden. Ggf. ist die Anlage von Stammdaten-Rümpfen aus der
Faktenverarbeitung erforderlich, um Rejects bei der Faktenverarbeitung zu vermeiden. Die
Nutzinformationen zu diesen Rümpfen mögen verspätet erscheinen, was aber zu keiner generellen
Aussperrung der Fakten führen darf. Unter Einsatz von dynamischen Lookups wird dies erreicht.
integration-factory INTF White Paper - Realtime Data Warehousing 1.0 (final).docx
März 23, 2018 Daniel Feidieker, Marc Martschei Pages 22 / 23
5.5 Fallbeispiel Reporting Layer
Der BDWH-Reporting Layer basiert auf einem OLAP-Werkzeug, das auf einem Datamart, dem
sogenannten Business Data Access Layer (BDAL) aufsetzt.
Die Basisdaten und Methodenergebnisse werden für das Berichtswesen optimiert aufbereitet. Um das
OLAP-Werkzeug optimal zu unterstützen, werden Join-Pfade durch Anlegen abkürzender
Fremdschlüssel vereinfacht. Die Komplexität eines historisierten und versionierten Stammdatenmodells
wird durch Verwendung von Objektversions-IDs gekapselt.
Durch die Auslagerung in einem Datamart werden die Aufgaben aus Berichtswesen und
Bewirtschaftung entkoppelt. Der Datamart wird durch einen effizienten Delta Refresh-Mechanismus
aktualisiert. Es wird der Ansatz zur Bewirtschaftung bis zu einem konsistenten Snapshot verfolgt, wobei
ein Delta Refresh eine echte Zeitscheibe mit fachlichem Start- und Endzeitpunkt darstellt. Des Weiteren
kann der Datamart jederzeit durch einen Full-Refresh wiederhergestellt bzw. initialisiert werden.
integration-factory INTF White Paper - Realtime Data Warehousing 1.0 (final).docx
März 23, 2018 Daniel Feidieker, Marc Martschei Pages 23 / 23
6 Über integration-factory
Die integration-factory ist ein stark wachsendes Unternehmen mit dynamischen Berater-Teams, das sich
durch langjährige Projekterfahrung, Flexibilität im Denken und einem Höchstmaß an Motivation
auszeichnet.
Seit 2004 gehört integration-factory zu den gefragten Experten für die Integration von
Unternehmensdaten. Mit derzeit 48 Mitarbeitern werden namhafte Kunden aus der Finanz- und
Automobil-Industrie seit Jahren in vertrauensvoller Partnerschaft erfolgreich beraten und betreut. Zu
unseren Kunden gehören u.a. die EEX AG, Deutsche Börse AG, Daimler AG, Deutsche Bank AG und
DZ Bank AG.
Der Fokus unserer Arbeit liegt auf Business Information Integration, also der Integration von internen
und externen Unternehmensdaten, der Transformation zu nachhaltig wertvollen Informationen und
deren Verteilung auch über System- und Unternehmensgrenzen hinweg. Darüber hinaus entwickeln wir
umfassende Business Applikationen, die die komplexen fachlichen Problemstellungen unserer Kunden
lösen und entscheidende Mehrwerte im analytischen als auch im operativen Bereich erzeugen. Wir sind
verantwortlich für Geschäftsprozessanalysen, Erstellung von IT-Konzepten, IT- und
Unternehmensberatung sowie Projektmanagement. Ziel ist immer die perfekte technische Umsetzung
der entworfenen Datenintegrationslösungen und Business Applikationen. Unser wichtigster
Differentiator ist dabei das belegbar überragende Verhältnis zwischen Kosten und Ergebnis unserer
Arbeit, sowohl in quantitativer als auch qualitativer Hinsicht. Dieser Vorteil für unsere Kunden basiert
auf erprobter Vorgehensweise, Methoden und Pattern mit automatisierter Umsetzung sowie einer
äußerst vitalen Know-How-DNA.
In unseren Projekten lösen wir die Aufgaben in einem interdisziplinären Kontext und setzen State-of-
the-Art-Technologien ein. Damit sind wir immer am Puls der Zeit bei neuen Technologien und Trends
der Branche, wie aktuell Big Data und Realtime Data Warehousing.
Die internationalen Auszeichnungen TDWI-Best-Practice- und Leadership Award als auch Informatica
Partner of the Year Central Europe belegen unsere erfolgreiche Arbeit.
integration-factory GmbH & Co. KG
Windmühlstraße 2
60329 Frankfurt am Main
Telefon: +49 69 25669269-0
Web: www.integration-factory.de
E-Mail: info@integration-factory.de
Daniel Feidieker
Partner
Marc Martschei
Manager