Für viele Unter­neh­men ist ein zen­tra­les Stamm­da­ten-Manage­ment (MDM) unver­zicht­bar, um die Qua­li­tät und Kon­sis­tenz der Daten als Grund­lage für alle wei­te­ren Ana­ly­sen zu gewähr­leis­ten. Dupli­kate-Erken­nung, Daten­säu­be­rung, Ermitt­lung eines “Gol­den Records”, der sich wie­der mit allen ange­schlos­se­nen Sys­te­men syn­chro­ni­siert, gehö­ren daher zu den essen­ti­el­len Auf­ga­ben eines MDM Sys­tems. Eine Anfor­de­rung ist dabei, dass dies mög­lichst in Echt­zeit pas­siert.
Der Use Case, den wir uns in die­sem Blog­bei­trag näher anschauen möch­ten, folgt daher einer – ich möchte schon fast sagen “klas­si­schen” – Event-basier­ten Strea­ming-Archi­tek­tur mit Kafka. In unse­rem kon­kre­ten Fall kommt noch ein Web­Ser­vice Frame­work dazu.

DataStage & WebService Calls Bild1
Abbil­dung 1 Strea­ming Architektur

Ein Change Data Cap­ture (CDC) Tool erkennt Ände­run­gen an einer Daten­bank und schreibt diese in Kafka Topics. IBM TCC (Trans­ca­tio­nally Con­sis­tent Con­su­mer) hilft mit­tels Book­marks dabei, Ände­run­gen wie­der einer gemein­sa­men Trans­ak­tion zuord­nen zu kön­nen. Andere MDM Part­ner­sys­teme kön­nen ihre Daten direkt nach Kafka schrei­ben. Der MDM Kafka Con­su­mer “abon­niert” diese Kafka Topics und spielt diese über Web­Ser­vice Calls in das MDM-Sys­tem ein. In unse­rem Bei­spiel wird dies über Spec­trum und Neo4J rea­li­siert. Bei die­ser Archi­tek­tur wer­den im Live-Betrieb Ände­run­gen sehr schnell erkannt, wei­ter­ge­lei­tet und im MDM ver­ar­bei­tet. Schwie­ri­ger mit der Per­for­mance wird es aller­dings, wenn ein gesam­ter Daten­be­stand trans­fe­riert wer­den soll. Alle Ände­run­gen wer­den als ein­zelne Inserts über den Web­Ser­vice geschickt. Die Bela­dung für den Initial-Load von etwa 7 Mil­lio­nen Records hätte uns bei einem Durch­satz von etwa 4 Records/Sekunde Wochen gekostet.

Initial Load: Web­Ser­vice Calls mit DataStage

Warum Data­S­tage? In unse­rem Use Case lässt sich die Frage recht ein­fach beant­wor­ten. Es lag auf der Hand, da Data­S­tage bereits als ETL-Tool bei unse­rem Kun­den im Ein­satz war. Damit gab es schon ein per­for­man­tes und mäch­ti­ges Tool, das zudem bereits Zugang zur Quell­da­ten­bank besass. Mit fol­gen­der Archi­tek­tur haben wir den Initial-Load mit Data­S­tage umgesetzt:

DataStage & WebService Calls Bild2
Abbil­dung 2 Archi­tek­tur des Initial Load mit DataStage

Data­S­tage liest bis zu einem bestimm­ten Zeit­punkt alle gül­ti­gen Daten aus ver­schie­de­nen Tabel­len der Quell­da­ten­bank und berei­tet diese für die Ziel­da­ten­bank vor. Um nicht je Zeile einen Insert im MDM aus­zu­lö­sen, wer­den 1000er Pakete gebil­det und in ein JSON For­mat umge­wan­delt. Inner­halb von Data­S­tage wer­den die Pakete und REST Ser­vice Auf­rufe par­al­lel ver­ar­bei­tet und kön­nen auf die Per­for­mance des MDM-Sys­tems ange­passt wer­den. Gibt der Web­Ser­vice einen Feh­ler als Ant­wort zurück, oder geht ein Paket bei der Über­mitt­lung kom­plett ver­lo­ren (Time­out), dann wird dies geloggt und das Paket gespei­chert. Diese Daten kön­nen in einer Nach­ver­ar­bei­tung erneut geschickt werden.

Hands On: Data­S­tage Ganz Praktisch

Wie wurde das kon­kret mit Data­S­tage umge­setzt? Dazu möch­ten wir die fol­gen­den Punkte näher betrach­ten: (1) 1000er Pakete erstel­len (2) JSON Kom­po­si­tion (3) Web­Ser­vice Calls (4) Log­ging & Error Hand­ling (5) Nachverarbeitung

DataStage & WebService Calls Tabele1
Abbil­dung 3 Data­S­tage Komponenten
Wave Gene­ra­tor Stage (1)

Wie kön­nen wir trotz DataStage’s Pipe­lining-Funk­tio­na­li­tät meh­rere Records zu Pake­ten zusam­men­fas­sen?
In Data­S­tage gibt es dafür zwei Mög­lich­kei­ten, meh­rere Zei­len in soge­nann­ten Waves zusam­men­zu­schi­cken. Waves kön­nen mit einer Daten­bank Con­nec­tor-Stage aus­ge­löst wer­den oder es kann, wenn man die Wave erst ab einem bestimm­ten Punkt erzeu­gen möchte, die Wave Gene­ra­tor Stage benut­zen wer­den. Bei einer Wave wird alle X Rows ein End-Of-Wave (EOW) Signal wei­ter­ge­ge­ben. Alle nach­fol­gen­den Stages soll­ten mit die­sem Signal umge­hen können.

Hier­ar­chi­cal Data Stage (2,3)
DataStage & WebService Calls Icon2

Um Daten über Web­Ser­vices zu ver­schi­cken, ist JSON ein geeig­ne­tes Daten­for­mat, wel­ches auch von vie­len Ser­vices erwar­tet wird. Mit der Hiera­chi­cal Data Stage stellt Data­S­tage eine recht mäch­tige Funk­tio­na­li­tät zur Ver­fü­gung. Diese Stage öff­net eine eigene Appli­ka­tion. Mit ihr kann man sowohl Daten auf ein JSON-Schema-File map­pen, als auch Web­Ser­vice Calls durch­füh­ren. Die Hier­ar­chi­cal Data Stage (HDS) hat noch viele andere Funk­tio­nen, wie z.B. die Mög­lich­keit, eigene Test-Daten erstel­len zu kön­nen. Nach Abspra­che mit dem Ziel-Sys­tem, wird ein JSON Schema File erstellt, wel­ches der Web­Ser­vice ver­ar­bei­ten soll. Im Anschluss war­ten wir auf die Ant­wort und geben das Ergeb­nis als Out­put der Stage aus. Wir geben aber nicht nur die Ant­wort des Ser­vers zurück, son­dern auch unser gesam­tes Paket, das wir geschickt haben.

DataStage & WebService Calls Bild4
1 JSON Schema File
DataStage & WebService Calls Bild3.2
2 Data Map­ping to JSON File
DataStage & WebService Calls Bild3.3
3 REST Web­Ser­vice Call
Data­S­tage Re-Pro­zes­sie­rung (4,5)
DataStage & WebService Calls Icon3

Ein feh­ler­haf­tes Paket ent­hält nun 1000 Records und ist als JSON for­ma­tiert. Die­ses Paket kommt vom Out­put der HDS-Stage in einer Zeile. Eine Anpas­sung der Umge­bungs­va­ria­ble “APT_DEFAULT_TRANSPORT_BLOCK_SIZE” hilft dabei, dass wir die Zeile auch wei­ter­ver­ar­bei­ten und spei­chern kön­nen. Um Feh­ler für meh­rere Jobs stan­dar­di­siert aus­zu­ge­ben, eig­net sich ein Shared Con­tai­ner sehr gut. Da die Feh­ler bereits im JSON For­mat vor­lie­gen, braucht man für eine Nach­ver­ar­bei­tung kei­nen “JSON_Composer Step” mehr, son­dern kann ein­fach die Feh­ler-JSON ein­le­sen und erneut an das MDM-Sys­tem schi­cken. Mit Hilfe von DataStage’s Sequence Jobs ist es nicht mehr schwie­rig, meh­rere Jobs und ihre auto­ma­ti­sche Nach­ver­ar­bei­tung im Feh­ler­fall zu steuern.

Per­for­mance: Data­S­tage Tuning

Data­S­tage ist von Haus aus dar­auf aus­ge­legt, par­al­lel auf ver­schie­de­nen Kno­ten zu arbei­ten. In unse­rem Use Case besteht der Eng­pass jedoch nicht in der Ver­ar­bei­tung der Daten, son­dern beim Sen­den der Daten an den Web­Ser­vice. Wir brau­chen daher nicht unbe­dingt mehr Kno­ten. Diese wür­den auch hel­fen, aber wir benö­ti­gen vor allem mehr Web­Ser­vice Ver­bin­dun­gen, über die Daten raus­ge­schickt wer­den kön­nen. Die fol­gende Lösung kann auch auf andere Sze­na­rien ange­wen­det wer­den, wo ein ähn­li­ches Pro­blem vor­liegt: Wir par­ti­tio­nie­ren und tei­len den Daten­strom auf wei­tere HDS-Stages auf. Das Auf­tei­len des Daten­stroms wird dabei über Para­me­ter gesteu­ert. So kann man den Durch­satz an die Per­for­mance des Ziel­sys­tems anpas­sen. In unse­rem Bei­spiel haben wir auf 2 Kno­ten mit je 3 Streams eine 6‑fache Par­al­le­li­sie­rung der Web­Ser­vice Auf­rufe geschaf­fen. Wir konn­ten damit die Per­for­mance noch­mals um 100% ver­bes­sern und brauch­ten am Ende für den Initial-Load von etwa 7 Mil­lio­nen Records nur noch eine Stunde.

DataStage & WebService Calls Bild5
Abbil­dung 4 Par­al­le­li­sie­rung in DataStage

Her­aus­for­de­run­gen: Data­S­tage Trou­ble Shooting

Bei der Imple­men­tie­rung gab es einige tech­ni­sche Her­aus­for­de­run­gen, deren wich­tigste Lösun­gen im Fol­gen­den auf­ge­führt sind:

  • “Flash Player Error”: Die Hier­ar­chi­cal Data Stage funk­tio­niert nicht.
    Der Assem­bly Edi­tor kann nicht gespei­chert oder gar nicht erst geöff­net wer­den.
    Lösung: IBM hat dafür HIER einen loka­len Fix mit der Anlei­tung bereitgestellt.
  • “CDIER0961E: The REST step is unable to invoke the REST ser­vice”: Authen­ti­fi­zie­rung.
    Es gibt hier unter­schied­li­che Gründe, warum die Authen­ti­fi­zie­rung fehl schla­gen kann. Die genau Feh­ler­mel­dung erhält man erst bei einem erwei­ter­ten Log­ging: TRACE aktivieren.
    • “The cer­ti­fi­cat is not trus­ted”
      Lösung: Das kor­rekte Zer­ti­fi­kat zum Java Key­s­tore hin­zu­fü­gen, HIER eine IBM Anlei­tung dazu.
    • “Hand­shake fail­ure”
      Es gibt keine gemein­same Ver­sion des SSL/TLS-Pro­to­kolls, die von Data­S­tage und dem Rest APi-Ser­ver unter­stützt wird. Wir brau­chen Sup­port für TLS 1.2.
      Lösung: Inner­halb der HDS-Stage “-Dcom.ibm.jsse2.overrideDefaultTLS=true” in Optio­nal Argu­ments hinzufügen.
    • “HTTP/1.1 500 Ser­ver Error”
      Der Ser­ver ist nicht ansprech­bar. In unse­rem Fall lag dies an der Fire­wall.
      Lösung: Fire­wall-Frei­schal­tung beantragen
  • “OutOf­Me­mo­ry­Er­ror”: zu wenig Spei­cher.
    Das Erstel­len des JSON Files benö­tigt rela­tiv viel Spei­cher. Eine Anlei­tung, um die Uli­mit Set­ting von Data­S­tage zu prü­fen, fin­det sich HIER.
    Lösung: Uli­mits von Data­S­tage erhö­hen und den Ser­ver neu starten.

Zusam­men­fas­sung & Ausblick

Web­Ser­vice Calls mit Data­S­tage – das ist nicht nur mög­lich, son­dern eine per­for­mante Alter­na­tive. Wir haben anhand von einem Use Case gezeigt, wie ein Initial Load mit Web­Ser­vice Calls in ein auf Kafka basie­ren­des MDM-Sys­tem erfolg­reich umge­setzt wer­den konnte.

Anzu­mer­ken ist, dass die­ses Jahr Pit­ney Bowes von Pre­cis­ely auf­ge­kauft wurde und dass Data­S­tage wohl zukünf­tig mit in das IBM Cloud Pak wan­dert. Der neue Flow Desi­gner ver­spricht nicht nur viele Erwei­te­run­gen, son­dern auch Back­wards-Kom­pa­ti­bi­li­tät. Den­noch bleibt die wei­tere Ent­wick­lung in die Cloud span­nend und wei­ter zu ver­fol­gen. Ein Weg, den wir gerne und wohl mit vie­len Kun­den in Zukunft gemein­sam gehen und neu gestal­ten werden.