Im letz­ten Jahr haben wir hier im Blog beschrie­ben, wie in der Azure Data Fac­tory Java Code bzw. JARs aus­ge­führt wer­den kön­nen. Wie das Java-zen­trierte Data Inte­gra­tion Tool von Tal­end dies bewerk­stel­ligt, ist pro­blem­los ohne Tuto­rial ver­ständ­lich und daher kei­nen gan­zen Blog­bei­trag wert. Statt­des­sen soll hier eine Idee ver­mit­telt wer­den, was Tal­end für wei­tere Mög­lich­kei­ten bie­tet und außer­dem, an wel­chen Stel­len sich Fall­stri­cke ver­ste­cken kön­nen. Der Fokus die­ses Bei­trags liegt auf dem klas­si­schen Data Inte­gra­tion Tool.

Feel free!

Tal­end bie­tet für die ein­zel­nen Pro­dukte, wie bei­spiels­weise Data Inte­gra­tion (DI), Big Data (BD), Enter­prise Ser­vice Bus (ESB), Data Cata­log oder Data Pre­pa­ra­tion, nicht nur kos­ten­lose “Open Stu­dio” Ver­sio­nen zum Down­load an, son­dern ver­öf­fent­licht auch deren Source Code. Einem ers­ten Ein­blick steht also nichts im Wege. Jedes Tool lässt sich direkt auf dem Lap­top instal­lie­ren und aus­pro­bie­ren, Vor­aus­set­zung ist ledig­lich die pas­send instal­lierte Java Laufzeitumgebung.

Ähn­lich offen sind die selbst ent­wi­ckel­ten Tal­end DI Jobs gestrickt: Die Ent­wick­lung der Daten­stre­cken erfolgt größ­ten­teils gra­fisch, indem ein­zelne Kom­po­nen­ten ver­bun­den wer­den. Diese gra­fi­sche Dar­stel­lung der Daten­stre­cke lässt sich per Knopf­druck in nati­ven Java-Code über­set­zen. Das ist nicht nur für neu­gie­rige Ent­wick­ler sinn­voll, die wis­sen wol­len wie Tal­end intern den Job über­setzt, son­dern auch wich­tig, um bei­spiels­weise schnell her­aus­zu­fin­den, wo die Ursa­chen für Kom­pi­lie­rungs­feh­ler lie­gen. In die­sem Sinne ver­hält sich Tal­end wie ein Java-Code-Gene­ra­tor. Die­ser Code lässt sich theo­re­tisch auf belie­bi­gen Ser­vern deployen und aus­füh­ren. Die­ses Prin­zip ist Ken­nern des mitt­ler­weile abge­lös­ten Ora­cle Ware­house Buil­ders (OWB), der aus der gra­fi­schen Dar­stel­lung der Daten­stre­cke per Knopf­druck ein Ora­cle PL/SQL Paket gene­riert, geläufig.

Dem Auf­bau der Tal­end Jobs sind eben­falls kaum Ein­schrän­kun­gen gesetzt. Es gibt keine strikte Tren­nung zwi­schen orches­trie­ren­den und ver­ar­bei­ten­den Abläu­fen wie man es zum Bei­spiel von Infor­ma­tica (work­flow vs. map­ping) oder Data­S­tage (sequen­ces vs. jobs) kennt. Ein ein­zel­ner Tal­end Job kann belie­big viele wei­tere eigen­stän­dige Jobs sequen­zi­ell oder par­al­lel auf­ru­fen. Wei­ter­hin kann ein Tal­end Job meh­rere interne Sub­jobs (zusam­men­hän­gende Kom­po­nen­ten) ent­hal­ten, die eben­falls sequen­zi­ell oder par­al­lel bear­bei­tet wer­den. Schließ­lich stellt Tal­end DI die kleine bzw. inte­grier­bare Ver­sion von Jobs zur Ver­fü­gung: Joblets. Diese sind nur inner­halb eines Jobs aus­führ­bar und kön­nen einen Daten­fluss Ein- und Aus­gang besitzen.

Talend Jobdesign: Jeder Job (Rechtecke) besteht aus verknüpften Komponenten (Kreise). Diese können zum Beispiel Daten aus einer Datenbank, einer Datei oder REST Schnittstelle laden, bearbeiten, wegschreiben oder ähnliches. Weiterhin lassen sich andere Jobs oder Joblets (gestricheltes Rechteck) einbinden. Hierbei können die Jobs entweder in der gleichen jvm Umgebung gestartet werden oder in einer separaten und somit unabhängigen jvm. Paralleles Ausführen von Komponenten oder Jobs (gestrichelte Pfeile) ist ebenfalls möglich.
Abbil­dung 1 Tal­end Job­de­sign: Jeder Job (Recht­ecke) besteht aus ver­knüpf­ten Kom­po­nen­ten (Kreise). Diese kön­nen zum Bei­spiel Daten aus einer Daten­bank, einer Datei oder REST Schnitt­stelle laden, bear­bei­ten, weg­schrei­ben oder ähn­li­ches. Wei­ter­hin las­sen sich andere Jobs oder Joblets (gestri­chel­tes Recht­eck) ein­bin­den. Hier­bei kön­nen die Jobs ent­we­der in der glei­chen jvm Umge­bung gestar­tet wer­den oder in einer sepa­ra­ten und somit unab­hän­gi­gen jvm. Par­al­le­les Aus­füh­ren von Kom­po­nen­ten oder Jobs (gestri­chelte Pfeile) ist eben­falls möglich.

Frei­heit durch Gene­rik: Bei Tal­end DI ist man nicht durch etwa­ige Unter­schiede in Tabel­len­sche­mata gezwun­gen, für jede Tabelle einen eige­nen Job zu schrei­ben, son­dern kann einen ein­zel­nen Job mit Hilfe eines dyna­mi­schen Sche­mas wie­der­ver­wen­den. Es ist also mög­lich eine Viel­zahl von Tabel­len mit nur einem Job, Joblet oder einer Job­kette zu laden. Soll­ten doch meh­rere Jobs nötig sein, kön­nen diese immer­hin durch einen ein­zel­nen dyna­mi­schen Job­au­fruf kom­for­ta­bel zusam­men­ge­fasst wer­den. Wäh­rend der Lauf­zeit ist es außer­dem mög­lich zu ent­schei­den, ob alle oder nur ein Teil der Jobs aus­ge­führt wer­den soll.

Wie wer­den Para­me­ter ver­wen­det? Ganz so wie man möchte! Es gibt zahl­rei­che Mög­lich­kei­ten Kon­zepte für Para­me­ter zu erstel­len, wodurch eine opti­male Pas­sung an Pro­jekt und die (Unter­neh­mens-) Umge­bung sicher­ge­stellt wer­den kann. Grund­sätz­lich kön­nen in einem Stan­dard Tal­end DI Job soge­nannte Kon­text­pa­ra­me­ter defi­niert wer­den. Diese Para­me­ter las­sen sich unter frei wähl­ba­ren Kon­tex­ten (Umge­bun­gen) ver­schie­den defi­nie­ren. Bei­spiels­weise könnte man die Umge­bun­gen „Ent­wick­lung“, „Test“ und „Pro­duk­tion“ defi­nie­ren und für den Para­me­ter „datenbank_benutzer“ in jeder Umge­bung einen sepa­ra­ten Wert ein­tra­gen. Mit solch einem Ansatz sind die Werte dem Para­me­ter pro Umge­bung fest zuge­wie­sen. Die Umge­bung lässt sich anschlie­ßend beim Pro­gramm­auf­ruf frei wäh­len.
Ein Über­schrei­ben der defi­nier­ten Para­me­ter ist jeder­zeit beim Pro­gramm­auf­ruf über das Tal­end Admi­nis­tra­tion Cen­ter (TAC) oder per CLI bzw. Meta­Ser­v­let mög­lich.
Ein impli­zi­tes Laden der Kon­text­pa­ra­me­ter stellt eine Erwei­te­rung zu dem fes­ten Ein­tra­gen im Job dar: In den Job­ein­stel­lun­gen lässt sich eine Datei oder eine Daten­bank­ta­belle ange­ben, aus der bei jedem Pro­gramm­start die Para­me­ter gela­den wer­den. Diese über­schrei­ben dann die even­tu­ell schon gesetz­ten Werte im Job.
Sollte die­ses noch nicht aus­rei­chen, kön­nen mit Hilfe eines selbst gebau­ten Tal­end Jobs die Para­me­ter auch expli­zit gela­den wer­den. So las­sen sich die Para­me­ter bei­spiels­weise aus einer hier­ar­chi­schen Datei wie xml oder json laden. Soll die Para­me­ter­da­tei beim Pro­gramm­start direkt aus dem Git mit einem defi­nier­ten Git-tag oder aus einer fir­men­in­ter­nen REST-Schnitt­stelle gela­den wer­den? Kein Pro­blem. Hierzu könnte man bei­spiels­weise ein Joblet ent­wi­ckeln und die­ses in jedem Job zu Beginn einbinden.

Java-Code lässt sich direkt im Job mit Hilfe einer Aus­wahl von drei Kom­po­nen­ten einbinden:

  • Soll der Code nur ein­mal aus­ge­führt wer­den? Hierzu ist die pri­mi­tive tJava-Kom­po­nente zu ver­wen­den. Anwen­dungs­bei­spiele sind das Set­zen von Trig­ger­punk­ten, Abzwei­gungs­punkte für if-then-else Anwei­sun­gen oder schnelle Debug-Ausgaben.
  • Soll der Java-Code für jede Zeile im Daten­strom ange­wen­det wer­den? Hierzu kann die tJa­va­Row-Kom­po­nente ver­wen­det wer­den. Im Gegen­satz zu tMap ist tJa­va­Row sehr fle­xi­bel ein­setz­bar und für gewisse Auf­ga­ben auch über­sicht­li­cher und bes­ser wartbar.
  • Die dritte Kom­po­nente ver­bin­det 1. und 2.: In der tJa­va­Flex lässt sich für den Start und für das Ende eine Art tJava und für den mitt­le­ren Teil eine tJa­va­Row in einer Kom­po­nente ver­bin­den. Bei­spiels­weise las­sen sich so zum Start Para­me­ter ein­ma­lig initia­li­sie­ren und zum Ende Logs schreiben.

Kom­ple­xer bzw. wie­der­ver­wend­ba­rer Java-Code lässt sich in einem glo­bal erreich­ba­ren Ort im Tal­end Repo­si­tory able­gen. Hier las­sen sich Java-Klas­sen defi­nie­ren und über­all mit­tels Funk­ti­ons­auf­ruf ein­bin­den. Über die tLi­bra­ry­load-Kom­po­nente lässt sich direkt im Job eine JAR ein­bin­den und direkt nut­zen. Für klick­bare UI-Lieb­ha­ber las­sen sich eigene Kom­po­nen­ten erstel­len. Even­tu­ell hat die Tal­end Com­mu­nity schon eine Kom­po­nente auf der Tal­end Exch­ange Platt­form zum Down­load bereitgestellt.

Moni­to­ring: Auch beim Moni­to­ring sind dem Ent­wick­ler keine Gren­zen gesetzt. Stan­dard­mä­ßig wird nur wenig geloggt und der Log­ger gibt nicht viel mehr als Job Start- und End­zeit, sowie dem return code preis. Es las­sen sich aber auch aus­ge­wählte Daten­ströme über­wa­chen, indem die mit­ge­lie­ferte Acti­vity Moni­to­ring Con­sole (AMC) ver­wen­det wird. Über die AMC las­sen sich ver­schie­dene Aus­wer­tun­gen fah­ren und so zum Bei­spiel die His­to­rie der letz­ten Job­läufe (Lauf­zei­ten oder Daten­men­gen) gra­fisch dar­stel­len. Dar­über hin­aus lässt sich natür­lich auch ein cus­tom Moni­to­ring auf­bauen, wel­ches alle rele­van­ten Infor­ma­tio­nen weg­schreibt und kom­for­ta­bel aus­wer­ten lässt.

Zum Thema Con­ti­nuous Inte­gra­tion / Con­ti­nuous Deli­very sei an die­ser Stelle auf unsere White­pa­per ver­wie­sen. Tal­end bie­tet jedoch durch Ver­wen­dung des Meta­Ser­v­lets und Git-Inte­gra­tion opti­male Bedin­gun­gen, um Code auto­ma­ti­siert zu mocken, deployen und testen.

Sei gewarnt!

Große Daten­men­gen im Batch zu ver­ar­bei­ten ist prin­zi­pi­ell sehr gut mög­lich, man muss sich jedoch Gedan­ken um das Spei­cher­ma­nage­ment machen. Eines der ers­ten doings offi­zi­el­ler Tal­end Tuto­ri­als besteht aus dem Erhö­hen des maxi­mal zuweis­ba­ren Spei­chers und das nicht ohne Grund. Eine der­ar­tige Erhö­hung ist solange unkri­tisch, bis der phy­si­sche Arbeits­spei­cher ins­ge­samt nicht mehr aus­reicht. Auch hier gibt es Abhilfe: Die meis­ten Kom­po­nen­ten, die eine Gesamt­sicht auf die Daten benö­ti­gen, müs­sen die Daten­menge nicht zwin­gend im Arbeits­spei­cher vor­hal­ten, son­dern kön­nen Daten auf der Platte aus­la­gern. Die andere Mög­lich­keit ist auf eine sor­tierte Ein­gangs­da­ten­menge zu set­zen und dann ledig­lich Vor­gän­ger und Nach­fol­ger zu ver­glei­chen. Hier­für gibt es zum einen native Kom­po­nen­ten, wie zum Bei­spiel tAg­gre­ga­te­Sor­te­d­Row, und zum ande­ren kann auch auf Java-Kom­po­nen­ten gesetzt werden.

Vor­sicht ist immer gebo­ten, wenn ein Tool sehr viele Frei­hei­ten bie­tet. Ohne klare Kon­zepte, zum Bei­spiel zur Namens­kon­ven­tion von Jobs, ist nicht direkt ersicht­lich, wel­cher Job denn nun der zu star­tende Job ist. Wei­ter­hin ist die Feh­ler­su­che bei lan­gen Job­ket­ten unter Umstän­den sehr kom­plex. Es ist immer abzu­wä­gen, wie generisch/komplex oder sim­pel die Jobs gebaut wer­den, um für mög­lichst viele Berei­che, wie zum Bei­spiel Ent­wick­lung, War­tung, Feh­ler­su­che oder Deploy­ment, eine kom­for­ta­ble und zukunfts­ori­en­tierte Lösung zu bieten.

Eine Migra­tion oder eine Teil­mi­gra­tion aus einem ande­ren ETL-Tool kann bei einem Tal­end Pro­jekt­start meis­tens eine Hilfe lie­fern. Hier­bei stößt man jedoch schnell an die Gren­zen der Mög­lich­keit eines 1:1 Nach­baus des Job­de­signs. Das heißt i.d.R. nicht, dass die Logik nicht abbild­bar ist, son­dern dass eine andere Her­an­ge­hens­weise ent­wi­ckelt wer­den muss, wie in einem frü­he­ren Blog­bei­trag am Bei­spiel des Auf­tei­lens und Zusam­men­füh­rens des Daten­stroms schon gezeigt wurde.

Zusam­men­ge­fasst bie­tet Tal­end eine offene und fle­xi­ble ETL/ELT-Ent­wick­lungs­um­ge­bung. Eine Viel­zahl von nati­ven Kom­po­nen­ten und Kon­nek­to­ren kön­nen mit Hilfe eige­ner Java-Kom­po­nen­ten ein­fach erwei­tert und schließ­lich durch Ver­knüp­fung und Orchestra­tion zu hoch­per­for­man­ten Daten­stre­cken auf­ge­baut wer­den, die per­fekt auf das eigene Pro­jekt bzw. die Fir­men­struk­tur ange­passt sind.