realtime data warehousing - integration-factory.de · realtime data warehousing integration-factory...

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



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.



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



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



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



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,



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



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



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.



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



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.



- 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



• 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



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



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



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



OFI TCP/IP binary LTV Umwandlung in

csv-Files pro

Entität und Minute

Mini-Batch

Files


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


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


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



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.



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.



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



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.



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.



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: [email protected]

Daniel Feidieker

Partner

Marc Martschei

Manager

realtime data warehousing - integration-factory.de · realtime data warehousing integration-factory...

Documents