Für viele Unternehmen ist ein zentrales Stammdaten-Management (MDM) unverzichtbar, um die Qualität und Konsistenz der Daten als Grundlage für alle weiteren Analysen zu gewährleisten. Duplikate-Erkennung, Datensäuberung, Ermittlung eines “Golden Records”, der sich wieder mit allen angeschlossenen Systemen synchronisiert, gehören daher zu den essentiellen Aufgaben eines MDM Systems. Eine Anforderung ist dabei, dass dies möglichst in Echtzeit passiert.
Der Use Case, den wir uns in diesem Blogbeitrag näher anschauen möchten, folgt daher einer – ich möchte schon fast sagen “klassischen” – Event-basierten Streaming-Architektur mit Kafka. In unserem konkreten Fall kommt noch ein WebService Framework dazu.
Ein Change Data Capture (CDC) Tool erkennt Änderungen an einer Datenbank und schreibt diese in Kafka Topics. IBM TCC (Transcationally Consistent Consumer) hilft mittels Bookmarks dabei, Änderungen wieder einer gemeinsamen Transaktion zuordnen zu können. Andere MDM Partnersysteme können ihre Daten direkt nach Kafka schreiben. Der MDM Kafka Consumer “abonniert” diese Kafka Topics und spielt diese über WebService Calls in das MDM-System ein. In unserem Beispiel wird dies über Spectrum und Neo4J realisiert. Bei dieser Architektur werden im Live-Betrieb Änderungen sehr schnell erkannt, weitergeleitet und im MDM verarbeitet. Schwieriger mit der Performance wird es allerdings, wenn ein gesamter Datenbestand transferiert werden soll. Alle Änderungen werden als einzelne Inserts über den WebService geschickt. Die Beladung für den Initial-Load von etwa 7 Millionen Records hätte uns bei einem Durchsatz von etwa 4 Records/Sekunde Wochen gekostet.
Initial Load: WebService Calls mit DataStage
Warum DataStage? In unserem Use Case lässt sich die Frage recht einfach beantworten. Es lag auf der Hand, da DataStage bereits als ETL-Tool bei unserem Kunden im Einsatz war. Damit gab es schon ein performantes und mächtiges Tool, das zudem bereits Zugang zur Quelldatenbank besass. Mit folgender Architektur haben wir den Initial-Load mit DataStage umgesetzt:
DataStage liest bis zu einem bestimmten Zeitpunkt alle gültigen Daten aus verschiedenen Tabellen der Quelldatenbank und bereitet diese für die Zieldatenbank vor. Um nicht je Zeile einen Insert im MDM auszulösen, werden 1000er Pakete gebildet und in ein JSON Format umgewandelt. Innerhalb von DataStage werden die Pakete und REST Service Aufrufe parallel verarbeitet und können auf die Performance des MDM-Systems angepasst werden. Gibt der WebService einen Fehler als Antwort zurück, oder geht ein Paket bei der Übermittlung komplett verloren (Timeout), dann wird dies geloggt und das Paket gespeichert. Diese Daten können in einer Nachverarbeitung erneut geschickt werden.
Hands On: DataStage Ganz Praktisch
Wie wurde das konkret mit DataStage umgesetzt? Dazu möchten wir die folgenden Punkte näher betrachten: (1) 1000er Pakete erstellen (2) JSON Komposition (3) WebService Calls (4) Logging & Error Handling (5) Nachverarbeitung
NR. | DataStage Komponenten | |
---|---|---|
(1) | Wave Generator | ![]() |
(2), (3) | Hierarchical Data (HDS) | ![]() ![]() ![]() |
(4), (5) | DataStage Nachverarbeitung | ![]() ![]() |
Wave Generator Stage (1)
In DataStage gibt es dafür zwei Möglichkeiten, mehrere Zeilen in sogenannten Waves zusammenzuschicken. Waves können mit einer Datenbank Connector-Stage ausgelöst werden oder es kann, wenn man die Wave erst ab einem bestimmten Punkt erzeugen möchte, die Wave Generator Stage benutzen werden. Bei einer Wave wird alle X Rows ein End-Of-Wave (EOW) Signal weitergegeben. Alle nachfolgenden Stages sollten mit diesem Signal umgehen können.
Hierarchical Data Stage (2,3)
1) JSON Schema File | 2) Data Mapping to JSON File | 3) REST WebService Call |
![]() ![]() | ![]() ![]() | ![]() ![]() |
DataStage Re-Prozessierung (4,5)
Performance: DataStage Tuning
DataStage ist von Haus aus darauf ausgelegt, parallel auf verschiedenen Knoten zu arbeiten. In unserem Use Case besteht der Engpass jedoch nicht in der Verarbeitung der Daten, sondern beim Senden der Daten an den WebService. Wir brauchen daher nicht unbedingt mehr Knoten. Diese würden auch helfen, aber wir benötigen vor allem mehr WebService Verbindungen, über die Daten rausgeschickt werden können. Die folgende Lösung kann auch auf andere Szenarien angewendet werden, wo ein ähnliches Problem vorliegt: Wir partitionieren und teilen den Datenstrom auf weitere HDS-Stages auf. Das Aufteilen des Datenstroms wird dabei über Parameter gesteuert. So kann man den Durchsatz an die Performance des Zielsystems anpassen. In unserem Beispiel haben wir auf 2 Knoten mit je 3 Streams eine 6-fache Parallelisierung der WebService Aufrufe geschaffen. Wir konnten damit die Performance nochmals um 100% verbessern und brauchten am Ende für den Initial-Load von etwa 7 Millionen Records nur noch eine Stunde.
Herausforderungen: DataStage Trouble Shooting
Bei der Implementierung gab es einige technische Herausforderungen, deren wichtigste Lösungen im Folgenden aufgeführt sind:
- “Flash Player Error”: Die Hierarchical Data Stage funktioniert nicht.
Der Assembly Editor kann nicht gespeichert oder gar nicht erst geöffnet werden.
Lösung: IBM hat dafür HIER einen lokalen Fix mit der Anleitung bereitgestellt. - “CDIER0961E: The REST step is unable to invoke the REST service”: Authentifizierung.
Es gibt hier unterschiedliche Gründe, warum die Authentifizierung fehl schlagen kann. Die genau Fehlermeldung erhält man erst bei einem erweiterten Logging: TRACE aktivieren.- “The certificat is not trusted”
Lösung: Das korrekte Zertifikat zum Java Keystore hinzufügen, HIER eine IBM Anleitung dazu. - “Handshake failure”
Es gibt keine gemeinsame Version des SSL/TLS-Protokolls, die von DataStage und dem Rest APi-Server unterstützt wird. Wir brauchen Support für TLS 1.2.
Lösung: Innerhalb der HDS-Stage “-Dcom.ibm.jsse2.overrideDefaultTLS=true” in Optional Arguments hinzufügen. - “HTTP/1.1 500 Server Error”
Der Server ist nicht ansprechbar. In unserem Fall lag dies an der Firewall.
Lösung: Firewall-Freischaltung beantragen
- “The certificat is not trusted”
- “OutOfMemoryError”: zu wenig Speicher.
Das Erstellen des JSON Files benötigt relativ viel Speicher. Eine Anleitung, um die Ulimit Setting von DataStage zu prüfen, findet sich HIER.
Lösung: Ulimits von DataStage erhöhen und den Server neu starten.
Zusammenfassung & Ausblick
WebService Calls mit DataStage – das ist nicht nur möglich, sondern eine performante Alternative. Wir haben anhand von einem Use Case gezeigt, wie ein Initial Load mit WebService Calls in ein auf Kafka basierendes MDM-System erfolgreich umgesetzt werden konnte.
Anzumerken ist, dass dieses Jahr Pitney Bowes von Precisely aufgekauft wurde und dass DataStage wohl zukünftig mit in das IBM Cloud Pak wandert. Der neue Flow Designer verspricht nicht nur viele Erweiterungen, sondern auch Backwards-Kompatibilität. Dennoch bleibt die weitere Entwicklung in die Cloud spannend und weiter zu verfolgen. Ein Weg, den wir gerne und wohl mit vielen Kunden in Zukunft gemeinsam gehen und neu gestalten werden.