• Arnaud Mauduit

Talend for Data Integration - Les Bonnes Pratiques


1 - Préambule


Dans la grande majorité des cas, les développeurs découvrent les outils Talend par la version communautaire, et bien souvent avec la brique Data Integration pour traite leurs problématiques d'intégration.


Si certains ont déjà un gros background de développeur, et donc les normes de développement qui vont avec, force est de constater que beaucoup de "Talend Developpers" ne possèdent pas ces normes ; là est le point faible de Talend, ce qui précisément en fait sa force : sa facilité de prise en main !


Je vous propose donc de traiter ces bonnes pratiques dans un diptyque d'articles ; le présent article traite de la mise en place des normes "simples", tandis que le second traitera des normes plus avancées.


Ces deux articles n'ont pas vocation à être parole d'évangile mais plus se vouloir un guide pour tous ceux qui débutent sur les outils Talend ...


2 - Les bonnes pratiques


La lisibilité et l'homogénéité des jobs Talend sont des éléments primordiaux tant pour une compréhension des développements optimale, que pour une maintenabilité et une évolution durable dans le temps.


Talend permet une personnalisation du design des jobs de manière complète (non exhaustif) :

  • Nommage des projets

  • Organisation des développements en dossiers et sous-dossiers.

  • Nommage des jobs

  • Renommage des composants

  • Renommage des flux de données et des flux conditionnels

  • Nommage des sous-jobs et coloration

2.1 - Organisation du projet


Le nom du projet doit être unique de façon à être identifié clairement.


La définition d'un projet au sens "Talend" est un ensemble structuré d'éléments techniques et de leurs métadonnées associées, et affichés de la manière suivante :













Parmi ces éléments, les jobs doivent être organisés en dossiers ou sous-dossiers (hiérarchie possible) de façon à regrouper de manière logique les éléments communs.


2.2 - Nommage des composants et liens


Les composants doivent être renommés afin de faciliter la compréhension de leur fonction au sein du job.


Dans un job comportant plusieurs fois la même source/cible, le renommage doit permettre l'identification rapide du composant concerné en cas d'erreur lors des traitements par exemple.


Une nuance peut être apportée aux composants tMap où les modifications sont diverses et parfois importantes. On peut tolérer de ne pas les renommer dans la mesure où leurs liens entrants et sortants sont clairement explicités.


Les sous-jobs doivent être renommés s'ils ne sont pas clairs dans leur utilisation.


Le renommage du composant doit être succinct car les propriétés "description" et "objectif" servent à expliciter les choix de développement retenus et sont reportés dans la documentation technique.


Les liens entre deux composants (exemple row1, row2, row3 ...) doivent être renommés afin d'indiquer leurs objectifs.


Ci-dessous un scénario expliquant les résultats attendus et ceux n'ayant pas atteint leurs objectifs :

Sur l'exemple fourni ci-dessus, on remarque que :

  • Le sous-job a été normé permettant la compréhension simple et rapide de l'objectif de celui-ci

  • Certains composants (encadré vert) ont été nommés de façon explicite permettant une bonne lisibilité, et d'autres n'ont pas été renommés (encadré rouge). Les composants tMap ne sont pas assujettis à la remarque, étant donné le nombre important de modifications que l'on peut effectuer dans celui-ci

  • Les flux sont correctement nommés permettant l'identification rapide du type de données qui y transfèrent

2.3 - Maîtriser la complexité des développements


Eviter les jobs complexes, privilégier :

  • Les changements simples qui peuvent intégrer dans des sous-jobs

  • Les tables ou fichiers intermédiaires

Eviter la multiplication des flux distincts dans un même job :

  • Faire des jobs séparés quand il n'existe pas de liens fonctionnels forts entre les flux

  • Talend possède de nombreux éléments et des composants standards permettant la réalisation de traitements prévus. Toutefois, si un de ces éléments est amené à être modifié, l'équipe d'architecture doit être prévenue et les modifications facilement identifiables par le préfixe MODIF_USER et si possible être dans un dossier séparé des éléments standards. Ceci permet de les identifier également lors d'une migration ou mise à jour ETL.

2.4 - Utilisation de la mémoire


La mémoire alloué à un job est définie par avance en allouant la taille de la machine virtuelle Java (JVM).

La consommation de la mémoire d'un job doit être maîtrisée car elle dépend du nombre de composants et de la volumétrie (aussi bien en nombre d'enregistrements que leurs propriétés ex : colonnes de tables ou de fichiers) de données traitées par l'ETL.

  • Eviter la multiplication des objets consommateurs de mémoire principalement les composants tSortRow; tAggregateRow, tJoinRow, etc.

  • Volumes élevés et moyens : Privilégier l'utilisation de la base de données pour les opérations lourdes (les tris, les jointures, les agrégations et autres)

  • Cependant il faut veiller à ne pas déporter toute la logique côté base de données et transformer le job ETL en job ELT.

Les Lookups, par défaut, sont d'abord chargés en mémoire et ensuite utilisés par le flux principal. Cela peut générer une forte consommation de mémoire jusqu'à la saturation et faire planter les traitements.

Dans le cas de Lookupp consommatrice et pour éviter la saturation de mémoire, il faut avec l'accord des architectes et en argumentant le besoin, privilégier l'écrire sur le disque en précisant l'emplacement et en acceptant la dégradation de performance du traitement.


Dans le cas d'un Lookup sur une base de données tierce, il est possible dans le tMap de spécifier une variable de Lookup qui pourra être utilisée par le composant Lookup dans sa clause "WHERE".


Pour les raisons évoquées ci-dessus, l'utilisation des schémas en mode "built-in" est privilégié car il permet de ne sélectionner que les champs qui seront utilisés dans le job. C'est également dans ce mode que les requêtes peuvent être modifiées. Au contraire du mode référentiel, les modifications de schéma ne sont pas répercutées dans tous les composants du projet et l'analyse d'impact doit être vérifiée pour chaque composant.


Exemple ci-dessous à éviter voire à proscrire, les tMap gèrent de nombreux composants Lookup et s'enchaînent pour alimenter la table finale :

Il est donc intéressant de décomposer ce flux en plusieurs jobs qui alimenteront des tables temporaires nécessitant moins de tMap successifs et de mémoire pour chaque job).


Le regroupement dans la mesure du possible des Lookup permet de simplifier le nom d'entrée des tMaps (généralement 2 ou 3 par tMap).


D'une manière générale, les temps de chargement long d'un Lookup sont des pistes à surveiller pour la suite du flux.


Il en est de même pour l'indicateur du nombre de lignes par seconde traité par un lien entre 2 composants.

Un point d'attention est à porter en dessous de 200 lignes/seconde pour un traitement de lecture ou faisant transiter les données. Pour l'écriture, mise à jour ou suppression ce paramètre donne une indication mais peut être influencé par des actions multiples sur la cible.


Afin de pouvoir surveiller dans le temps l'évolution de la volumétrie des données traités ainsi que le temps nécessaire pour les traiter, il est impératif d'activer la remontée des statistiques des composants d'entrée et de sortie.


Il peut aussi être utile de remonter les statistiques de composants de traitements, mais c'est à faire au cas par cas. En cas de doute, faire valider sa demande par l'équipe Architecture.


2.5 - Réutilisabilité et mutualisation


Les routines, joblets, les jobs réutilisables (déclenchés par tRunJob) ou les références de projets (cf. référence de projets) sont à privilégier lorsque les traitements sont mutualisables. L'utilisation des contextes dans ces composants permet de s'adapter aux spécificités du job en cours (cf. contextes).


Par exemple, le contrôle de toutes les données au format de date d'une application source peut être spécifié par une routine afin d'obtenir un format valide en sortie.


On peut effectuer ces contrôles dans une routine qui est appelés pour chaque utilisation de cette source.


Note : La création, modification ou évolution d'un projet référence doit être validée par l'équipe Architecture.


2.6 - Cas du Travail collaboratif (référence de projet)


Talend permet le travail collaboratif en permettant à plusieurs utilisateurs de se connecter au référentiel et d'y effectuer les modifications.


Dans ce référentiel, lorsqu'un projet référence un autre projet, tous les éléments du projet référencé peuvent être réutilisés. Par exemple, l'utilisateur a la possibilité de créer une bibliothèque des sous-routines réutilisables dans un projet, ou de créer des paramètres de projet similaires à réutiliser dans d'autres projets. Lorsqu'on ajoute une référence au projet sélectionné, les paramètres du projet référencé sont disponibles dans le projet sélectionné et peuvent être utilisés.


La figure ci-dessous illustre l'arborescence du projet Project2 dans le Studio Talend :


















Toutes les ressources du Project1 et du Project3 sont disponibles à partir du Porject2. Les ressources des deux projets référencés sont en lecture seule : elles peuvent être réutilisées mais ne peuvent être modifiées.


2.7 - Paralléliser les traitements


Une optimisation importante peut être réalisée par la mise en place de parallélisassions quand les capacités du serveur le permettent (CPU, RAM).


Dans les développements de l'ODS, les itérations sont fortement utilisées. Il est donc intéressant de paralléliser les exécutions :



2.8 - Paralléliser les composants cibles


Talend Studio permet d'exécuter les chargements en mode parallèle. En effet, on peut, pour les chargements lourds, gagner du temps de chargement :

A noter que cette option n'est pas disponible pour tous les serveurs de bases de données.


Cette option est fortement déconseillée du fait de la multiplicité des connexions qui vont être faites sur la base de données cible et du risque d'interblocage (verrous multiples sur la même table).



80 vues

Posts récents

Voir tout