Data Engi­nee­ring mit Talend

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.

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.