Talend Interview Questions und Antworten: ETL, tMap, Context und Debugging

Talend-Interviews testen normalerweise zwei Dinge: ob du einen sinnvollen Data-Integration-Job entwerfen kannst und ob du herausfinden kannst, warum einer langsam oder fehlerhaft ist. Erwarte Fragen zu den Bausteinen (Komponenten, Subjobs, tMap, Kontextvariablen) und dann Szenarien zu Fehlern, Performance und Deployment.

Talend gehört inzwischen zu Qlik, und die Produktlinie hat sich über die Jahre verändert. Prüfe die Stellenbeschreibung, um zu sehen, ob das Team Talend Studio mit einer Data-Integration- oder Big-Data-Lizenz, Talend Cloud oder ein älteres Open-Source-Setup verwendet. Die folgenden Konzepte gelten für alle, aber Komponentennamen und Deployment-Details unterscheiden sich.

Die Fragen, die du am häufigsten hören wirst

Was ist Talend und wie generiert es Code?

Talend ist ein Data-Integration-Tool. Du baust Jobs auf einer Arbeitsfläche, indem du Komponenten verbindest, und Talend Studio generiert Java-Code aus dem Design. Wenn du einen Job ausführst, wird dieser Code kompiliert und ausgeführt. Das ist im Interview wichtig, weil es erklärt, warum du eigenen Java-Code in eine tJava- oder tJavaRow-Komponente einfügen kannst, warum Routinen Java-Klassen sind und warum Speichereinstellungen JVM-Einstellungen sind.

Was ist der Unterschied zwischen einem Job, einem Subjob und einem Joblet?

Ein Job ist der gesamte Workflow. Ein Subjob ist eine Gruppe von Komponenten, die durch Datenfluss-Verbindungen verbunden sind, und ein Job besteht normalerweise aus mehreren Subjobs, die durch Trigger verbunden sind. Ein Joblet ist eine wiederverwendbare Gruppe von Komponenten, die einmal gespeichert und in vielen Jobs verwendet wird, ähnlich wie eine Funktion.

Was ist der Unterschied zwischen OnSubjobOk und OnComponentOk?

Beides sind Trigger-Verbindungen, die ausgeführt werden, nachdem etwas erfolgreich war. OnSubjobOk wird ausgelöst, wenn der gesamte Subjob erfolgreich abgeschlossen ist. OnComponentOk wird ausgelöst, sobald eine einzelne Komponente fertig ist, was mitten in einem Subjob passieren kann. Es gibt auch OnSubjobError und OnComponentError für Fehlerfälle sowie Run if für bedingte Pfade.

Was macht tMap?

tMap ist die zentrale Transformationskomponente. Sie verknüpft einen Hauptfluss mit einem oder mehreren Lookup-Flüssen, wendet Ausdrücke an, filtert Zeilen und leitet Daten an mehrere Ausgaben weiter. Wichtige Funktionen, die du erwähnen solltest:

• Inner Join und Left Outer Join bei Lookups
• Reject-Ausgaben für Zeilen, die einen Join oder Filter nicht bestehen
• Filterausdrücke auf Eingaben und Ausgaben
• Variablen, sodass eine Berechnung einmal geschrieben und wiederverwendet wird
• Lookup-Modell-Optionen: einmal laden, bei jeder Zeile neu laden oder bei jeder Zeile mit einem Schlüssel neu laden

Wie gehst du mit einem großen Lookup in tMap um?

Standardmäßig werden die Lookup-Daten in den Speicher geladen. Bei einem großen Lookup aktiviere „Store temp data“, damit tMap sie auf die Festplatte schreibt, erhöhe den JVM-Speicher oder vermeide das Problem, indem du stattdessen in der Datenbank joinst. Du kannst auch „Reload at each row“ für einen Lookup verwenden, der von der eingehenden Zeile abhängt, auf Kosten einer Abfrage pro Zeile, was nur für kleine Hauptflüsse sinnvoll ist.

Was sind Kontextvariablen und warum verwendet man sie?

Kontextvariablen enthalten Werte, die sich zwischen Umgebungen ändern, wie Hostnamen, Schemas, Dateipfade und Zugangsdaten. Du definierst sie einmal, gruppierst sie in Kontexte (Dev, Test, Prod) und wählst den Kontext zur Laufzeit aus. Eine gute Antwort ergänzt, dass Passwörter nicht im Klartext im Job gespeichert werden sollten und dass derselbe exportierte Job in jeder Umgebung laufen sollte, wobei nur die Kontextdatei geändert wird.

Wie übergibst du Werte zwischen Jobs?

Mit tRunJob kannst du Kontextparameter an einen untergeordneten Job übergeben, und ein untergeordneter Job kann Werte an den übergeordneten Job zurückgeben, indem er die tBufferOutput-Komponente oder globale Variablen verwendet. Innerhalb eines Jobs werden Werte in der globalMap gespeichert, einer Java-Map, die du mit (String) globalMap.get("key") liest und mit globalMap.put schreibst.

Was ist der Unterschied zwischen tFlowToIterate und einem normalen Fluss?

Ein normaler Fluss bewegt alle Zeilen gemeinsam durch die Komponenten. tFlowToIterate verwandelt jede Zeile in eine Iteration, sodass die nächsten Komponenten einmal pro Zeile ausgeführt werden. Das ist nützlich, um über eine Liste von Dateinamen oder Tabellen zu schleifen, aber es ist langsam bei großen Datenmengen, weil jede Iteration einen Subjob startet.

Wie gehst du mit Fehlern in Talend um?

Nenne mehrere Ebenen:

1. Trigger-Verbindungen wie OnSubjobError und OnComponentError, um Fehler auf einen separaten Pfad zu leiten
2. tDie, um den Job mit einem Fehlercode zu stoppen, und tWarn, um eine Warnung zu protokollieren
3. tLogCatcher, um Warnungen und Fehler zu sammeln, die von tDie, tWarn und Java-Ausnahmen ausgelöst werden
4. Reject-Verbindungen bei Komponenten wie tMap und Datenbank-Ausgabekomponenten für fehlerhafte Zeilen
5. tPreJob und tPostJob, um Ressourcen zu öffnen und immer aufzuräumen

Wie würdest du einen fehlschlagenden Job debuggen?

Führe ihn im Debug-Modus aus oder füge tLogRow hinzu, um die Daten zwischen den Komponenten zu sehen. Prüfe den genauen Fehler und den Komponentennamen in der Konsole und kontrolliere dann die Verbindungseinstellungen und die verwendeten Kontextwerte. Bei Datenproblemen leite Rejects in eine Datei und untersuche sie. Mit tStatCatcher oder den Statistiken des Jobs siehst du außerdem Zeilenanzahlen und Timings pro Komponente.

Performance-Fragen

Ein Job, der eine Million Zeilen lädt, ist langsam. Was prüfst du?

1. Wo die Zeit hingeht. Zeilenanzahl und Timings pro Komponente zeigen den Engpass.
2. Ob die Arbeit überhaupt in die Datenbank gehört. Joins und Aggregationen sind in SQL oft schneller als in tMap.
3. Commit-Größe. Jede Zeile einzeln zu committen ist langsam, also in Batches committen.
4. Bulk-Komponenten. Viele Datenbanken haben Bulk-Load-Komponenten, die deutlich schneller sind als einzelne Zeilen-Inserts.
5. tMap-Lookups. Ein großer In-Memory-Lookup kann zu Garbage-Collection-Pausen oder Out-of-Memory-Fehlern führen.
6. JVM-Einstellungen. Erhöhe den maximalen Heap (den Xmx-Wert), wenn der Speicher der limitierende Faktor ist.
7. Parallelität. Manche Komponenten und Jobs können parallel laufen, aber nur wenn die Arbeit nicht von der Reihenfolge abhängt.

Wie lädst du nur neue oder geänderte Datensätze?

Halte einen High-Water-Mark fest, etwa einen Last-Modified-Zeitstempel oder eine aufsteigende ID, speichere ihn in einer Control-Tabelle oder einer Context-Variable und extrahiere nur Zeilen oberhalb davon. Für Updates im Ziel vergleichst du die Keys und nutzt Insert- oder Update-Aktionen, oder du verwendest ein Merge-Statement in der Datenbank. Für Deletes brauchst du möglicherweise einen vollständigen Key-Vergleich oder einen Change-Data-Capture-Feed.

Wie entfernst du Duplikate?

tUniqRow entfernt Duplikate anhand ausgewählter Spalten und kann Duplikate an einen separaten Output schicken. tAggregateRow kann gruppieren und einen Wert auswählen. Bei riesigen Datenmengen ist es oft besser, das in der Datenbank mit einer Window-Funktion zu erledigen.

Komponenten, die man namentlich kennen sollte

Deployment und Scheduling

Sei darauf vorbereitet zu beschreiben, wie du einen Job vom Studio in die Produktion bringst. Typische Schritte sind: den Job als eigenständiges Paket bauen oder in ein Repository veröffentlichen, den Produktions-Context setzen und ihn mit dem Scheduler des Teams einplanen, egal ob das Talends eigenes Management-Tool, cron oder ein anderer Orchestrator ist. Versionskontrolle, Namensstandards und Dokumentation für Jobs gehören alle zu einer guten Antwort.

Ein Szenario zum Üben

"Du bekommst täglich eine Kundendatei. Einigen Zeilen fehlen E-Mails, und manche Kunden existieren bereits im Warehouse. Entwirf den Job."

Eine starke Gliederung:

1. Lies die Datei mit tFileInputDelimited und einem definierten Schema.
2. Filtere in tMap Zeilen mit fehlenden E-Mails in eine Reject-Datei und schlage den Customer-Key in der Warehouse-Tabelle nach.
3. Schicke bestehende Kunden auf einen Update-Pfad und neue auf einen Insert-Pfad.
4. Schreibe in Batches mit einer passenden Commit-Größe in die Datenbank.
5. Nutze tLogCatcher und eine Control-Tabelle, um Zeilenanzahl und Fehler pro Lauf zu protokollieren.
6. Verwende eine Context-Variable für den Dateipfad und die Datenbankverbindung, damit derselbe Job in jeder Umgebung läuft.

Sprich deine Annahmen laut aus, etwa zur Dateigröße und ob Historie erhalten bleiben muss, denn Interviewer wollen sehen, wie du denkst.

Wie du dich vorbereitest

Baue wenn möglich einen kleinen Job von Anfang bis Ende: eine Datei lesen, sie in tMap mit einer Tabelle joinen, Rejects behandeln und in eine Datenbank schreiben. Sei in der Lage zu erklären, was du tust, wenn er bei Zeile 500.000 fehlschlägt. Kenne ein oder zwei echte Beispiele aus deiner Erfahrung, mit Zahlen wie Zeilen pro Lauf oder eingesparter Zeit. Für verwandte Data-Engineering-Themen sieh dir unsere Guides zu Databricks und Snowflake Interviews an.

Lautes Üben hilft. Nutze ein Mock-Interview, um ein Job-Design zu erklären, und lies dann das Transkript, um zu sehen, wo deine Erklärung Schritte übersprungen hat. Befolge die Regeln des Arbeitgebers zu KI-Tools in jedem Live-Interview.