Modèles de conception des jobs Talend et bonnes pratiques : 2e partie

J'ai été ravi de recevoir des réactions aussi positives à mon article de blog Modèles de conception des jobs Talend et bonnes pratiques. À tous ceux qui l’ont lu, un grand merci ! Si vous ne l’avez pas encore lu, je vous invite à en prendre connaissance avant de poursuivre la lecture du présent article, dans la mesure où cette 2e partie s’appuie sur cet article initial et complète son analyse. J'en profite en particulier pour aborder certains sujets très avancés, alors... cramponnez-vous !

Comment concevoir un job – Considérations initiales

Malgré mon expérience considérable en qualité de développeur Talend, je ne cesse de m'intéresser aux solutions adoptées par d’autres personnes pour élaborer leurs jobs. Utilisent-ils correctement les fonctionnalités disponibles ? Ont-ils tendance à adopter un style reconnaissable ? Un style que je n’ai jamais rencontré auparavant ? Sont-ils capables de penser à une solution unique et efficace ? Ou est-ce que la nature abstraite de la toile de conception (canvas), des données des composants et des workflows est quelque peu insurmontable pour certains d'entre eux, les amenant à emprunter une voie obscure vers... nulle part ? Quelle que soit votre réponse à toutes ces questions, j'estime qu'il est essentiel de limiter chaque outil aux tâches pour lesquelles il a été conçu. Pour partager mes positions, je vous propose d'aborder les modèles de conception des jobs Talend et les meilleures pratiques qui sont suggérées dans ce domaine. Il me semble que, même après avoir appris toutes les caractéristiques et toutes les fonctionnalités des outils Talend, les fondamentaux restent les mêmes : vous devez déterminer les solutions les mieux adaptées à la conception et à l'élaboration de vos jobs !

En toute logique, le cas d'usage est le facteur essentiel et fondamental pour tout job Talend. En réalité, j’ai été témoin de nombreuses variations sur le même workflow et de nombreux types de workflow. La plupart de ces cas d'usage s'appuient sur un workflow élémentaire : dans sa forme la plus simple, un job d’intégration des données consiste à extraire les données requises d’une source et à les traiter, parfois à les transformer à certaines étapes du parcours et enfin à les charger dans une cible. Autrement dit, le code ETL (Extract-Transform-Load) est notre pain quotidien. C’est ce que nous faisons déjà, nous les développeurs de produits Talend. Donc je ne vais pas vous ennuyer avec ce que vous savez déjà. Essayons plutôt d'élargir notre perspective...

Sans conteste, la dernière version de Talend (v6.1.1) est la meilleure version avec laquelle j’ai jamais travaillé. Comme elle tient compte de nombreuses tendances, dont big data, Spark, machine learning, interface modernisée et automatisation de l'intégration et du déploiement en continu, je pense que cette version propose la technologie la plus performante et la plus riche en fonctionnalités pour l'intégration des données. Difficile de ne pas montrer un peu de parti pris, mais je pense très très fort à vous, notre client, et j’espère que vous pourrez me croire sur parole tout en acceptant que vous jugiez par vous-même.

Les trois piliers nécessaires à la réussite d’un projet d'intégration des données (DI)

Vous en convenez : un tabouret ne peut pas tenir debout s'il n'a pas trois pieds, n'est-ce pas ? Il en va de même avec le développement logiciel. Trois aspects essentiels sont requis pour builder et livrer un projet DI de qualité :

• Cas d'usage – Un scénario clairement défini (workflow + données).
• Technologie – Les outils nécessaires lors des phases de conception, de déploiement et d'exécution de la solution.
• Méthodologie – Un mode de travail sur lequel tous les acteurs peuvent s'accorder.

Si vous avez déjà rédigé des directives de développement clairement établies (Avez-vous lu mon article de blog précédent à ce sujet ? Avez-vous rédigé des directives de ce type pour votre projet ?), nous pouvons travailler sur la base de ces prérequis.

Principes de base

Si les jobs Talend incluent la technologie nécessaire dans un workflow de type cas d'usage, les modèles de conception des jobs constituent alors la méthodologie et les bonnes pratiques pour la réalisation de ces jobs. Si vous devez retenir une seule chose de mes articles de blog : soyez cohérent dans la définition de vos jobs ! Si vous avez identifié une autre solution/une meilleure solution et que celle-ci vous convient, c'est parfait ! Ne changez rien ! Par contre, si vous rencontrez des difficultés en matière de performances, de réutilisabilité ou de maintenabilité, ou si vous devez modifier le code constamment pour vous adapter à des exigences fluctuantes, alors ces bonnes pratiques sont là pour vous aider et aider tous les développeurs Talend !

Voici neuf autres bonnes pratiques à envisager :

Cycle de vie du développement logiciel (SDLC)

Les personnes, les produits et les processus – Selon le milliardaire Marcus Lemonis, star du programme The Profit (sur la chaîne américaine CNBC), ce sont les trois clés qui conditionnent le succès ou l'échec d'une entreprise ou d'un projet. Et je suis entièrement d'accord avec lui ! Le processus SDLC est généralement un élément clé pour les équipes de développement logiciel. Un processus SDLC clairement défini est indispensable ; si vous le négligez, vous vous exposez aux pires difficultés dans vos projets et c'est souvent la manière la plus « efficace » de finir par un échec désastreux. Notre guide des bonnes pratiques SDLC (Talend’s SDLC Best Practices Guide) examine en détail les concepts, principes, spécifications et détails des fonctionnalités de déploiement et d'intégration en continu mises à la disposition des développeurs Talend. Je conseille fortement à toute équipe de développement logiciel d'intégrer des meilleures pratiques SDLC dans le document Directives de développement (j'ai décrit ce document dans l'article de blog précédent de cette série). Et pensez à suivre mon blog !

Gestion des espaces de travail

Lorsque vous installez Talend Studio sur une station de travail ou un ordinateur portable (opération exigeant les droits d’administrateur), un sous-dossier Workspace par défaut est créé sur le disque dur local (dans le dossier des fichiers exécutables). Je ne pense vraiment pas qu'il s’agisse d’une bonne pratique. Et voici pourquoi :

Des copies locales des fichiers de projet (tâches et référentiel de métadonnées) sont stockées dans cet espace de travail (Workspace) et, lorsque ces copies sont prises en compte par un système de contrôle de code source de type SVN ou GIT via le Talend Administration Center (TAC), elles sont synchronisées chaque fois que vous ouvrez un projet ou enregistrez un objet. Je pense que ces fichiers doivent résider dans un emplacement où vous pouvez facilement les identifier et les gérer – autrement dit, un autre emplacement du disque local ou même une autre unité locale.

Reprenons : un espace de travail est utilisé chaque fois que vous établissez une connexion dans Talend Studio, et il peut s'agir d'une connexion locale ou distante (la différence étant que les connexions locales ne sont pas gérées par le TAC, alors que c'est le cas des connexions distantes). Pour nos clients avec abonnement, la connexion distante est normalement le seul type utilisé.

La structure des dossiers doit être clairement décrite dans le document Directives de développement, et elle doit être suivie par toute l’équipe pour garantir une collaboration et une coopération optimales. L'essentiel consiste à définir une structure qui convient à tous, qui est adaptée aux travaux de votre équipe, qui impose une discipline et qui est cohérente.

Projets de référence

Utilisez-vous des « projets de référence » ? Savez-vous de quoi il s'agit ? J’ai constaté que certains de nos clients ne connaissent pas cet aspect à la fois très simple et très productif. Nous avons tous pour objectif de créer du code réutilisable (commun ou générique) qui pourra être partagé entre différents projets. Je constate très souvent que les développeurs ouvrent un projet, copient un fragment de code dans ce projet et le collent dans un autre projet (ou parfois dans le même projet) ou dans un job. Dans d'autres cas, ils exportent des objets d’un projet et les importent dans un autre. Accusé, levez vous ! Je reconnais avoir utilisé ces deux méthodes dans le passé. Même si elles fonctionnent correctement, elles sont fortement déconseillées : elles peuvent vous entraîner dans un cauchemar de maintenance – et je suis convaincu que certains d'entre vous s'en sont déjà rendus compte à leurs dépens ! En réalité, il existe une solution beaucoup plus efficace : les projets de référence ! Je me souviens avec bonheur du jour où j'ai découvert ce concept !

Si vous avez déjà utilisé le TAC pour créer des projets, vous avez peut-être remarqué la case à cocher Reference (Référence). Mais vous êtes-vous demandé quel était son rôle ? Eh bien, si vous créez un projet et cochez cette case pour en faire un projet de référence, il devient alors disponible pour inclusion (Include) ou liaison (Link) avec tout autre projet. Le code créé dans ce projet de référence est disponible (en lecture seule) dans tous les projets liés ; il est donc hautement réutilisable ! Le projet de référence est l’emplacement adéquat pour centraliser les objets communs et le code partagé

Toutefois, il est conseillé de limiter le nombre des projets de référence : les meilleures pratiques suggèrent de se limiter à un projet même si certains contextes (discutables) peuvent justifier deux ou trois projets. ATTENTION : si vous créez un trop grand nombre de projets de référence, vous risquez de réduire leur efficacité ! Par ailleurs, la gestion des projets de référence est très importante ; les conditions et règles à respecter pour leur utilisation doivent être clairement spécifiées dans le document Directives de développement, et adoptées par toute l’équipe pour garantir une collaboration et une coopération optimales.

Conventions de nommage des objets

La Juliette de Shakespeare a peut-être dit « Qu'y a-t-il dans un nom ? La fleur que nous nommons la rose, sentirait tout aussi bon sous un autre nom. »,

mais dans Talend, les conventions de nommage SONT TRÈS IMPORTANTES ! Toute équipe de développement digne de ce nom le sait et applique les pratiques adaptées en la matière. Peu importe les circonstances d'utilisation des objets Talend, là encore la cohérence est essentielle au succès de vos projets. Les conventions de nommage des objets Talend doivent être spécifiées très clairement dans le document Directives de développement, et adoptées par toute l’équipe pour garantir une collaboration et une coopération optimales (cette idée revient très souvent...).

Référentiel des projets

Lorsque vous ouvrez un projet dans Talend Studio (dans l’IDE Eclipse ou dans l'éditeur que vous utilisez pour vos jobs) le panneau de gauche correspond au référentiel du projet : cette zone présente tous les objets de votre projet. Les paragraphes qui suivent décrivent les sections les plus importantes. Vous connaissez sans doute les sections « Job » qui ont été modifiées dans la version 6.1.1 pour recevoir les trois types de job que vous pouvez créer (intégration des données, traitement par lots, streaming), mais il existe d'autres sections que vous devez connaître et utiliser.

• Groupes contextuels – Au lieu de créer des variables contextuelles de job intégrées, il est conseillé de créer ces variables dans un groupe contextuel qui sera stocké dans le référentiel et de les réutiliser selon les besoins dans différents jobs (et dans différents projets lorsque ceux-ci sont inclus dans un projet de référence). Ces groupes doivent être alignés efficacement ; les bonnes pratiques suggèrent de créer des groupes pour différents environnements : SBX/DEV/TEST/UAT/PROD, où DEV est la valeur par défaut (vous devez supprimer le groupe contextuel « default »)

Notez que j’ai ajouté la variable contextuelle « SysENVTYPE » qui contient la valeur de programmabilité dynamique de l'environnement sélectionné. Autrement dit, j’utilise cette variable dans un job pour spécifier (au moment de l'exécution) l'environnement qui est actif, ce qui me permet de modifier le flux de données par programme à l'aide d'une instruction conditionnelle.

• Métadonnées – Les métadonnées se présentent sous différentes formes : n'hésitez pas à les utiliser toutes ! Connexions avec les bases de données, schémas des tables, fichiers non relationnels (.csv, .xml, .json, etc.). Sans oublier le schéma qui peut intervenir dans tellement de situations... Je préfère ne pas en dresser la liste, sinon cet article de blog ne finirait jamais...
• Documentation – Créez un wiki de projet et distribuez-le à votre équipe. Vous disposerez ainsi d'un outil de référence complet et facile à consulter (fichiers html) pour votre projet : un vrai plus, et qui ne prend que quelques minutes.

N'oubliez pas d'inclure les meilleures pratiques dans le document Directives de développement et rappelez à votre équipe de... les respecter ! Vous pouvez adapter ces documents à vos besoins spécifiques, mais vous devez impliquer tous les membres de l'équipe.

Contrôle des versions (branches et tags)

Les propriétés d'un job permettent de définir un système de numérotation Mm : Major et minor. Par ailleurs, vous pouvez définir le statut de votre choix. Les possibilités par défaut sont development, test et production. ATTENTION :ces statuts doivent être réservés aux développeurs qui travaillent dans Talend Open Studio/TOS et qui n'ont pas accès à des référentiels SVN/GIT de développement coopératif et de contrôle du code source (SCC). IMPORTANT : chaque fois que vous utilisez ces propriétés internes au job, une copie complète du job est générée dans votre espace de travail local et synchronisée avec le système SCC : j’ai connu quelques projets dans lesquels des copies de jobs étaient générées après plus d’une douzaine de changements de version internes. N'oubliez pas que TOUTES les copies du job sont incluses dans les copies ultérieures, ce qui entraîne un effet boule de neige et la multiplication de sous-fichiers qui sont TOUS synchronisés par le SCC. Cette situation se traduit par des projets de volume considérable et par de graves problèmes de performances lors de leur ouverture et de leur fermeture. Si vous rencontrez cette situation, vous devez nettoyer votre espace de travail en exportant et réimportant uniquement la version supérieure du job. Je sais, c'est une corvée, mais elle en vaut la peine.

Pour éviter cette situation, les meilleures pratiques de contrôle de version (dans les contextes d’abonnement payant) suggèrent d’utiliser les mécanismes natifs de branches/tags du SCC. C’est généralement la meilleure solution pour gérer les versions d'un projet, dans la mesure où le SCC tient compte uniquement du différentiel d'informations (delta) à chaque enregistrement de job. Cette pratique a pour effet de réduire considérablement l’espace occupé par l’historique de chaque job. Définissez un système de gestion des versions à base de numéros ou/et de dates (ou autres informations pertinentes), décrivez-le en détail dans le document Directives de développement, et demandez à toute votre équipe de l'adopter et le respecter (air connu...).

Gestion de la mémoire

Vous êtes prêt à exécuter votre travail, mais... avez-vous tenu compte de ses besoins en mémoire ? Le traitement des données porte-t-il sur plusieurs millions de lignes et/ou sur un nombre élevé de colonnes, et/ou exige-t-il de nombreuses recherches dans la tMap ? Avez-vous tenu compte du fait que, lorsqu'un job s’exécute sur le serveur de jobs, il est possible que d'autres jobs s'exécutent en parallèle ? Avez-vous tenu compte du nombre de cœurs et de la quantité de RAM du serveur de jobs ? Comment avez-vous configuré les jointures tMap ? Load Once ou Row by row ? Le job appelle-t-il des jobs enfants ou est-il appelé par un job parent ? Combien de niveaux de jobs imbriqués ? Les jobs enfants s'exécutent-ils dans une JVM dédiée ? Si vous créez des jobs ESB (Enterprise Service Bus), savez-vous combien de chemins sont créés ? Utilisez-vous des techniques de parallélisation (voir ci-après) ? Alors ? Avez-vous tenu compte de tous ces points ? Je suis prêt à parier que non...

Les valeurs par défaut permettent de disposer automatiquement de valeurs de base pour les paramètres configurables. Les jobs Talend en proposent plusieurs, dont l’allocation de mémoire. Mais les valeurs par défaut ne sont pas toujours adéquates ; elles peuvent même être carrément fausses et dangereuses. La quantité de mémoire utilisée est déterminée par les valeurs Use Case Job Design, Operational Ecosystem et Real Time JVM Thread Count. Autrement dit, vous devez définir ces valeurs en fonction des caractéristiques de vos projets et vos jobs.

Vous pouvez spécifier les paramètres de mémoire des JVM au niveau du projet ou pour certains jobs seulement :

Preferences > Talend > Run (Préférences > Talend > Exécuter)

Cette configuration est essentielle pour éviter les mauvaises surprises ! La gestion de la mémoire est souvent négligée : pour votre équipe, les phases Développement et Opérations doivent suivre les directives qui conviennent (et celles-ci doivent être clairement documentées). ~ Alors, cet article de blog contenant la 1re partie, enfin prêt à le consulter ?

Syntaxe SQL en mode dynamique

La plupart des composants d’entrée des bases de données exigent une syntaxe SQL adéquate, à spécifier dans l'onglet Basic Settings. Vous pouvez vous contenter de spécifier cette syntaxe directement dans le composant tMyDBInput. S'il s'agit d'une requête SQL complexe qui doit être construite en mode dynamique au moment de l’exécution (runtime) et reposer sur un algorithme complémentaire contrôlé par le job (ou par son job parent), la solution est assez simple : il suffit de créer des variables contextuelles pour la structure de base de la requête SQL, de les spécifier dans le flux de travail avant d’atteindre la valeur tMyDBInput et d'utiliser la variable contextuelle à la place d'une requête codée en dur.

Par exemple, j'ai développé le groupe Context Group dans le référentiel de projet Referenced ; dans ce groupe que j'ai nommé SystemVARS, je centralise différentes variables réutilisables. En SQL dynamique, je définis les variables String ci-dessous (initialisées à null).

J'ai défini ces variables dans un composant tJava (en fonction de mes besoins spécifiques), puis je les assemble dans le champ de requête tMyDBInput, par exemple :

SELECT + Context.sqlCOLUMNS + Context.sqlFROM + Context.sqlWHERE

Remarque : j'inclus toujours un espace à la fin des valeurs de variable pour obtenir des concaténations propres et claires. Si un contrôle supplémentaire est nécessaire, j’utilise également la variable sqlSYNTAX, et les instructions conditionnelles nécessaires pour contrôler la concaténation des clauses de la syntaxe SQL : il suffit d'insérer Context.sqlSYNTAX dans le champ de requête tMyDBInput. Et le tour est joué ! Je vous concède qu'il ne s'agit plus de SQL dynamique pour l'hôte de la base de données, mais... de SQL généré en mode dynamique pour votre job !

À vous de jouer maintenant : insérez cette directive dans votre documentation et persuadez tous les membres de votre équipe de la respecter !

Options de parallélisation

Talend propose plusieurs mécanismes pour la parallélisation du code. Lorsque ces mécanismes sont utilisés correctement, efficacement et avec un examen attentif de leur impact potentiel sur les cœurs de processeur et l’utilisation de la RAM, ils permettent de créer des modèles de conception de jobs très performants. Examinons la pile des options :

• Execution Plan (Plan d'exécution) – Plusieurs jobs ou tâches peuvent être configurés pour s’exécuter en parallèle à partir du TAC.
• Multiple Job Flows (Flux de jobs multiples) – Plusieurs flux de données peuvent être lancés dans un même job et partager le même thread – à condition qu'il n'existe aucune dépendance entre eux. Cette technique peut se prêter à certains cas d'usage (assez rares), mais en général, je l'évite et préfère créer des jobs distincts.
• Parent/Child Jobs (jobs Parent/Enfant) – Si le composant tRunJob appelle un job enfant, vous pouvez cocher la case « Use an independent process to run subjob » (Utiliser un processus indépendant pour exécuter le sous-job.). Cette configuration crée une JVM distincte au niveau de la mémoire et des threads pour traiter le job enfant. Il ne s'agit pas vraiment de parallélisation, mais cette solution reste efficace.
• Components (Composants) – Le composant tParallelize relie plusieurs flux de données pour traitement. Les composants tPartitioner, tDepartitioner, tCollector et tRecollector assurent le contrôle direct des threads parallèles affectés à un flux de données.
• DB Components (Composants de bases de données) – La plupart des composants d'entrée/sortie des bases de données (DB) proposent des réglages avancés qui permettent de spécifier un nombre de threads de parallélisation adapté à certaines instructions SQL. Les configurations obtenues peuvent être très efficaces, mais si le nombre de threads est trop élevé, vous risquez également d'obtenir des effets indésirables (les bonnes pratiques suggèrent 2-5 threads).

Il est possible de combiner ces différentes méthodes de parallélisation, mais une certaine prudence est recommandée – et vous devez avoir une parfaite connaissance de votre pile d’utilisation de mémoire ! Attention, vous devez aussi connaître parfaitement la séquence d’exécution de votre modèle de conception de job. Notez que ces options de parallélisation peuvent être incluses dans les offres de plates-formes Talend, mais seulement sous forme de fonctionnalités avancées. Enfin, votre documentation de projet doit absolument éviter les directives de parallélisation : VERBOTEN !

Les secrets de la réussite pour vos jobs Talend

J’espère que ces meilleures pratiques applicables à vos modèles de conception de job sauront alimenter votre réflexion sur la meilleure façon de créer des jobs Talend. À la base, la création de jobs efficaces repose sur trois piliers : des directives, de la discipline et de la cohérence. Il suffit de décider d'un projet et de le réaliser. Pendant que vous « peignez » votre code sur la toile de conception (canvas) avec des données et des workflows, vous n'êtes pas le seul artiste :

L'action est la clé fondamentale de tout succès !»- Pablo Picasso

Pour conclure, je vous propose la liste de mes secrets pour la réussite de vos jobs Talend (ou, plus prosaïquement, la liste des actions recommandées/déconseillées) :

• - Utilisez à la fois les composants tPreJob et tPostJob.
• - Ne surchargez pas la toile/canvas avec des composants trop regroupés : un peu d'espace vital !
• - Efforcez-vous d'agencer le code de manière classique et claire (de haut en bas et de gauche à droite).
• - N'espérez pas trop obtenir un code sans défauts dès votre première tentative !
• - Identifiez la boucle principale du job et contrôlez la sortie !
• - N'hésitez pas à appliquer des techniques de gestion des erreurs !
• - N'hésitez pas à utiliser des groupes contextuels (DEV/QA/UAT/PROD), mais avec la prudence qui s'impose.
• - Évitez les structures de jobs monolithiques.
• - Créez plutôt des modules de job discrets
• - Ne forcez pas la complexité : privilégiez la simplification.
• - N'hésitez pas à utiliser des schémas génériques partout (sauf peut-être le schéma à colonne unique).
• - N’oubliez pas de nommer vos objets
• - N'hésitez pas à utiliser des joblets partout où ils sont supportés (mais en limitant leur nombre).
• - N'exagérez pas votre utilisation du composant tJavaFlex (vous pourrez généralement vous contenter du composant tJava ou tJavaRow).
• - Dès que vous avez terminé la rédaction de documentation du projet, empressez-vous de la diffuser aux membres de votre équipe.
• - N'oubliez pas de définir la taille de la mémoire runtime.

Conclusion

Ouf ! ~ Sera-ce suffisant ? Ai-je répondu à toutes vos interrogations ? J’espère que non, parce que je prévois d'autres articles dans cette série, en particulier : « Sample Use Cases / Exemples de cas d'usage » ! Le présent article de blog

a abordé les principes fondamentaux de la conception des jobs Talend et introduit certains concepts avancés qui devraient vous être utiles. N’hésitez pas à faire des commentaires et à décrire les meilleures pratiques que VOUS avez adoptées. Merci de privilégier les conversations constructives plutôt que le flaming ! À très bientôt, et merci de votre attention !

Ressources connexes

Intro to Talend Open Studio for Data Integration (Introduction à Talend Open Studio for Data Integration)

Produits mentionnés

Talend Data Integration