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)

Wie können wir trotz DataStage’s Pipelining-Funktionalität mehrere Records zu Paketen zusammenfassen?
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)

Um Daten über WebServices zu verschicken, ist JSON ein geeignetes Datenformat, welches auch von vielen Services erwartet wird. Mit der Hierachical Data Stage stellt DataStage eine recht mächtige Funktionalität zur Verfügung. Diese Stage öffnet eine eigene Applikation. Mit ihr kann man sowohl Daten auf ein JSON-Schema-File mappen, als auch WebService Calls durchführen. Die Hierarchical Data Stage (HDS) hat noch viele andere Funktionen, wie z.B. die Möglichkeit, eigene Test-Daten erstellen zu können. Nach Absprache mit dem Ziel-System, wird ein JSON Schema File erstellt, welches der WebService verarbeiten soll. Im Anschluss warten wir auf die Antwort und geben das Ergebnis als Output der Stage aus. Wir geben aber nicht nur die Antwort des Servers zurück, sondern auch unser gesamtes Paket, das wir geschickt haben.

1) JSON Schema File	2) Data Mapping to JSON File	3) REST WebService Call

DataStage Re-Prozessierung (4,5)

Ein fehlerhaftes Paket enthält nun 1000 Records und ist als JSON formatiert. Dieses Paket kommt vom Output der HDS-Stage in einer Zeile. Eine Anpassung der Umgebungsvariable “APT_DEFAULT_TRANSPORT_BLOCK_SIZE” hilft dabei, dass wir die Zeile auch weiterverarbeiten und speichern können. Um Fehler für mehrere Jobs standardisiert auszugeben, eignet sich ein Shared Container sehr gut. Da die Fehler bereits im JSON Format vorliegen, braucht man für eine Nachverarbeitung keinen “JSON_Composer Step” mehr, sondern kann einfach die Fehler-JSON einlesen und erneut an das MDM-System schicken. Mit Hilfe von DataStage’s Sequence Jobs ist es nicht mehr schwierig, mehrere Jobs und ihre automatische Nachverarbeitung im Fehlerfall zu steuern.

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:

1. “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.
2. “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.
   1. “The certificat is not trusted”
      Lösung: Das korrekte Zertifikat zum Java Keystore hinzufügen, HIER eine IBM Anleitung dazu.
   2. “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.
   3. “HTTP/1.1 500 Server Error”
      Der Server ist nicht ansprechbar. In unserem Fall lag dies an der Firewall.
      Lösung: Firewall-Freischaltung beantragen
3. “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.