Lösungen mit den CustomCode-Komponenten von Talend

Am Beispiel von Apache Kafka

Angenommen man befindet sich in einem Projekt. Dieses erfordert die Integration mit einer Technologie, die Talend zwar kennt, aber in der vorliegenden Lizenz nicht enthalten ist. Das Interesse ist da, die Lizenz zu bestellen und das Lizenz-Upgrade wird erworben. Aber interne Bestellprozesse sind langsam und brauchen Wochen, wenn nicht sogar Monate.

Das Projekt kann aber darauf nicht warten. Was kann gemacht werden, um den Projektverlauf nicht zu verzögern und gleichzeitig nicht auf eine andere neue Technologie zu wechseln? Wie sieht ein gutes Job Design aus, um einen Interims-Job mit tJavaFlex zu bauen?

Einleitung

Für das Thema Daten Integration begegnen uns in Data Warehouse Projekten eine Vielzahl von Technologien auf Seiten der Quellen und Zielsysteme. Aber auch die Technologien für die Übertragungen selbst wachsen und werden mehr. Um dieser Vielzahl von Technologien gerecht zu werden bieten sich Plattformen an, die wiederum eine Vielzahl Konnektoren bieten können.

Eine dieser Plattformen ist Talend Data Integration. Talend bietet einen universellen und flexiblen Software Stack, um diesen Anforderungen nachzukommen.

Doch was ist, wenn es die gesuchte Komponente in der aktuellen Talend Data Integration Lizenz nicht gibt, aber mit einem Lizenz-Upgrade zu erwerben wäre. Der Anforderer des Change Requests ist aber davon überzeugt, dass noch viele Schnittstellen in der Technologie kommen werden.

Super, die Lizenz wird bestellt. Und wann kommt der Lizenzschlüssel? – Interne Budget- und Bestellprozesse verzögern leider die Bestellung. Das Projekt kann aber nicht warten. Die Deadline ist bereits vom Projektmanagement gesetzt und wird vom C-Level erwartet.

Nun kann aber mit Talend mit ein wenig Kniff eine stabile, robuste und wartbare Lösung bereitgestellt werden, die entweder als Interims-Lösung so lange funktioniert, bis die Standard-Komponenten da sind und benutzt werden können oder gar als dauerhafte Lösung. Um das aber zu erreichen, müssen im Talend Job Design ein paar Punkte beachtet werden.

Vorausschauendes Job-Design in Anlehnung an die Komponenten

Bevor es darum geht den Talend-Job umzusetzen, ist es wichtig das Verständnis der später kommenden Komponenten zu haben. Dafür sollten drei Sachen gemacht werden:

1. Wiki/Doku der Technologie, um ein Basis-Verständnis zu haben
2. help.talend.com -> die Dokumentation zu der gewünschten Technologie anschauen
3. Talend Open Studio – Profitieren von dem Studio als Open Source Konzept – vom Code inspirieren

Die globalMap

Komponenten wie eine tDBConnection und eine tDBInput funktionieren durch die Verwendung gemeinsamer Objekte, zum Beispiel Datenbankverbindungen. Diese werden üblicherweise durch eine Komponente instanziiert und von anderen Komponenten (des gleichen Typs) wiederver­wendet. Um solche geteilten Objekte verfügbar zu machen existiert die globalMap. Die globalMap ist im Grunde genommen nur eine HashMap, in der Talend seine und man eigene Objekte mit einem Schlüssel ablegen und darauf zugreifen kann.

Um Konflikte mit anderen Komponenten zu vermeiden ist es wichtig, eindeutige Schlüssel zu wählen.

Talend-Komponenten verwenden hierfür die Komponenten-ID (bspw. „tDBConnection_1“) – diese ist innerhalb eines Jobs eindeutig.

Die globalMap in ihrer Funktionsweise ist daher nicht nur essenziell, sondern auch ein nützlicher Helfer, da diese auch von einem beliebigen Java-Code genutzt werden kann.

Unsere Helfer: tJava, tJavaFlex und tJavaRow

Diese drei Talend-Komponenten gehören zur Familie CustomCode. Alle drei Komponenten sind sich sehr ähnlich. Die tJava-Komponente wird in der Regel nur einmal ausgeführt. Die tJavaRow bietet die Möglichkeit, zeilenbasiert Operationen auf den Daten durchzuführen. Die tJavaFlex ist wiederum in drei Bereiche aufgeteilt. Sie bietet die Möglichkeit, den Code in Start, Main und End aufzuteilen. Der Start-Teil wird während der Initialisierungsphase ausgeführt, ein Main-Code pro durchlaufender Row und ein End-Code am Ende.

Grundsätzlich ist es empfehlenswert, die Nutzung der Komponenten auf ein Minimum zu reduzieren, da der Großteil der gewünschten Funktionen mit Bordmitteln gelöst werden kann!

Konsumieren aus Apache Kafka

Nehmen wir als Beispiel an, dass wir Kafka als Technologie einsetzen wollen. Wie auch schon bei anderen Technologien bekannt, nutzt Talend-Komponenten wie: tKafkaConnection, tKafkaInput, tKafkaOutput, tKafkaCommit und weitere, die uns aber erstmal nicht interessieren sollen, denn diese lassen sich in unserem Szenario nicht einsetzen.

Die Anforderung ist es, Daten aus Kafka zu lesen. Es sollen die Key-Value-Paare sowie die Header-Informationen ausgewertet werden. Zum aktuellen Zeitpunkt (November 2021) können die Talend-DI-Komponenten das nicht vollumfänglich. Daher kommen nun die Custom-Code-Kompo­nenten ins Spiel.

Die folgende Darstellung zeigt eine einfache, transparente und leicht zu verstehende Lösung.

Code-Beispiele für Begin, Main und End

Ganz in der Logik der tJavaFlex oder auch der anderen Talend-Komponenten sollte man mit jeweils einer Start-, Main- und End-Komponente arbeiten. In diesem Fall 2 x tJava für Begin und End sowie eine tJavaFlex für den Main.

Das Design ist angelehnt an die tatsächlichen Talend-Komponenten. So repräsentiert die in der Abbildung zu sehende tKafkaBegin (tJava_1) die tKafkaConnection, die tKafka_consumer_main (tJavaFlex_1) repräsentiert wiederum die tKafkaInput und abschließend ist die tKafkaEnd (tJava_2) der Teil, der die tKafkaCommit widerspiegelt. Anbei noch der Ausschnitt des Contexts.

Der Rückbau auf Talend-Komponenten

Einige Zeit ist vergangen und die Talend-Komponenten stehen zur Verfügung. Zunächst sollte geprüft werden, ob die Komponenten die Anforderungen vollständig erfüllen. Sollte dies der Fall sein, kann man nun mit dem Rückbau beginnen.

Bibliotheken nachladen

Drei Komponenten gilt es nun auszutauschen. Abhängig davon, ob ein Job als Big Data Streaming verwendet wird, oder ob der Standard DI Job genutzt wird, müssen folgende Komponenten eingesetzt werden:

Standard Job

Selbstredend werden in der Connection/Configuration die Parameter hinterlegt und die tKafkaInput und tKafkaCommit mit der tKafkaConnection in dem Standard-Job verbunden. Sobald das TOPIC und die zuvor genutzt CONSUMERGROUPID eingetragen ist, kann es im Grunde auch schon losgehen. Zwei wichtige Tipps für den Einsatz von Kafka:

Beispiel für die Standard Job Variante

Fragen sowie Vor- und Nachteile

Warum nicht alles in eine tJavaFlex?

Das würde dem klassischen Design: t*Connection, t*Input, t*Commit widersprechen. Viele Zeilen Code und somit Logik wären in einer Komponente versteckt. Auch wenn hier der Start- und End-Teil der tJavaFlex genutzt werden könnte, sei davon abgeraten, da dies an Übersichtlichkeit verliert und später keinen Mehrwert bringt.

Warum muss es eine tJavaFlex als Main-Komponente sein?

Es wird eine Schleife benötigt. Das lässt sich mit der tJavaFlex am besten realisieren.

Was spricht für die Custom-Code-Variante?

Bezogen auf die Umsetzung mit Kafka: Man kann hier sowohl die Header als auch die Keys auslesen1. Außerdem kann man den Job pausieren und potenziell die Offsets zurücksetzen.

Das bedeutet faktisch: Die aktuelle Anforderung erlaubte es nicht die Standard-Komponenten von Talend zu nutzen. Aber dafür sind die Custom-Code-Komponenten da. Sie bieten einem die Flexibilität und einfache Nutzbarkeit, um in Talend-Projekten jeglicher Anforderung gerecht zu werden.

Was spricht gegen die Custom-Code-Variante?

Jeder vielzeilige Code, der in Java geschrieben steht, ist erstmal vor dem Talend-Entwickler versteckt. Verwendet keine tJava*, wenn es nicht anders geht. Talend bietet schließlich viele bereits optimierte Komponenten.

Ist es absehbar, dass es später die tKafka-Komponenten geben wird, kann auch nur das umgesetzt werden, was auch die tKafka-Komponenten können. Es muss abgesichert sein, was können die tKafka Komponenten und was können sie nicht.

Es sollte auch insbesondere beachtet werden, dass es zwischen den Standard DI Jobs und Big Data Streaming Jobs Unterschiede gibt (im Beispiel wird nur auf die Standard DI Jobs eingegangen). So können Big Data Streaming Jobs mit Kafka Header und Key-Value-Paaren arbeiten, die Standard DI Jobs hingegen können dies nicht.

Was spricht gegen die tKafka-Variante?

Die tKafka-Komponenten können in der aktuellen Version die einen oder anderen Dinge nicht ausleiten. Talend gibt zwar an, das noch nachzureichen, aber nennt kein „Wann“.

Diese Features gibt es teilweise in den BigData-Streaming-Komponenten, aber diese fehlen noch in den Standard DI Jobs. Talend wollte viele der Features für die Talend DI Jobs nachreichen, aber dies wurde nun rejected (siehe Talend Forge: [TDI-45460] [Kafka] Function to get key, topic and partition – Input & Output – Talend Open Integration Solution (talendforge.org)).

1: in der Standard Job Version funktioniert dies nicht. In der Big Data Streaming hingegen schon (Stand 2021 November).

Fazit

Ein Stück Java Code in Talend ist schnell implementiert. Aber ist dies auch sinnvoll? Die Lieblingsantwort eines Entwicklers: Kommt darauf an!

Implementiert nur das, was man auch im Zweifel zurückbauen, einfach interpretieren und was insbesondere warten kann. Talend spielt seine Vorteile in seiner Transparenz und einfachen Nutzbarkeit aus. Man muss nicht viel im Code wühlen, um die Logik zu verstehen. Kafka als Transportweg zu nutzen ist nicht kompliziert. Dennoch sei hier Vorsicht geboten. Nicht zu viel Logik implementieren, zum Bespiel in Header- oder Offset-Logik, wenn die Talend-Komponenten verwendet werden sollen.

Wenn es jedoch darum geht, einfach „nur“ Daten aus den Topics zu laden, dann kann euch Talend hier sehr wohl dienen und dies auch schnell umsetzen. Entscheidend ist eine sinnvolle Bauweise.

Kontakt

Rouven Homann
Telefon: +49 (0)40 53302-444
E-Mail: rouven.homann@cimt-ag.de

cimtAcademy

Jetzt registrieren und keine Veranstaltungen mehr verpassen.​



    Nach oben scrollen