• Arnaud Mauduit

Talend for Data Integration : Les Bonnes Pratiques - Part 2


1 - Préambule


Dans le premier volet nous avons vu les bases sur lesquelles s'appuyer pour démarrer dans de bonnes conditions nos projets Talend.


Dans ce second volet, nous allons aborder des notions plus avancées...


2 - Suivi d'alimentation


Le suivi des traitements permet notamment en production de connaître l'ordre de passage des traitements, la durée d'exécution et éventuellement des informations supplémentaires telles que le nombre d'enregistrements traités.


Le suivi peut s'effectuer à différents niveaux selon les besoins.


Le premier niveau est réalisé à travers la gestion des logs, il permet en cochant l'option statistiques de connaitre l'heure de début et de fin de chaque job voire plus finement sur certains composants.


Il est aussi possible de monitorer les exécutions et d'y accéder avec la vue "Activity Monitoring Console" de la TAC (cf. Documentation "Talend Activity Monitoring Console" de Talend sur leur site TalendForge).


Le suivi d'alimentation peut aussi être géré au sein des développements pour des besoins spécifiques techniques et fonctionnels.


3 - Archivage de fichiers


Dans le cas de traitements sur des fichiers, ou si des fichiers ont à être créés temporairement, la méthodologie de sauvegarde et d'archivage doit être dûment documentée.


Leur récupération (fichiers d'entré récupérés par exemple depuis un serveur FTP distant) doit être effectuée par l'ETL. Leur sauvegarde sur les serveurs d'exécution Talend est à motiver auprès du service Architecture.


La création (et donc la suppression) des fichiers créés pendant le traitement et la durabilité limitée le temps du traitement doivent être créés (respectivement supprimés) par l'ETL.


La production de fichiers à destination d'autres systèmes doivent se faire au travers de l'ETL jusqu'au dépôt final (cas d'un upload vers un FTP distant par exemple).


En cas d'archivage des fichiers, cet archivage doit se faire au sein de l'ETL.


Il est donc intéressant de prévoir un archivage dans un nouveau job du type :


  1. Création d'un répertoire au nom composé de la date du jour.

  2. Compression de ce dossier à l'aide d'un tFileArchive.

  3. Suppression des fichiers sources.

Ainsi, on garde un réel historique des fichiers chargés, horodatés, tout en évitant un gâchis d'espace de stockage. De plus, une étape de purge des très anciens chargements peut être prévue dans ce job dans le cas où les archives sont trop volumineuses.


Un exemple de hiérarchie :

  • /input

  • /work

  • /temp

  • /output

  • /archives

Le workflow étant le suivant :

  1. On lit les fichiers (si par exemple ils doivent être téléchargés depuis une source à distance) depuis le répertoire "input".

  2. Lorsqu'il y a des traitements intermédiaires qui produisent des fichiers, nous pouvons utiliser "work" si nous avons besoin de persistance (cas d'utilisation : rejet & rejeu de flux) [optionnel].

  3. Lorsqu'il y a des traitements intermédiaires qui produisent des fichiers qui ne doivent pas être persistés alors nous pouvons utiliser un répertoire dédié (temp" [optionnel].

  4. Les fichiers finaux (avant transfert vers un autre endroit à distance, y compris s'il s'agit de fichiers de bulk load) sont à déposer dans le répertoire "output".

  5. Enfin, si un archivage est nécessaire, il peut se faire dans le répertoire "archives".

4 - Gestion des connexions


La gestion des connexions aux bases de données dans un job peut s'effectuer en plusieurs étapes.


un prejob ou un job peut vérifier la disponibilité de la base et renvoyer un message en cas d'erreur.


Ce test est à effectuer une seule fois en amont du premier chargement ou de la première lecture sur cette connexion.


Le composant t<NomDeLaBase>Connection permet de créer une connexion à la base si elle est disponible.


Dans le cas où plusieurs composants se connectent ou alimentent le même schéma, les connexions dédiés permettent d'avoir une connexion attribuée à chaque composant et ainsi une gestion indépendante (par exemple l'une peut faire de la lecture et l'autre de l'insertion et terminer avant l'autre) à l'inverse d'une connexion partagée.


Il faut cependant veiller aux risques d'inter-blocages si une même connexion est utilisée pour la lecture et l'écriture de données.


Il est préconisé d'utiliser une seule connexion (connexion partagée) dans les cas suivants :

  • Gestion transactionnelle du traitement.

  • Besoin de décider des points de commit et de rollback.

  • Si la connexion est réutilisée plusieurs fois au sein du même job ou de plusieurs jobs qui enchaînent des traitements.

Il est nécessaire cependant de tester la connexion à chaque composant de connexion afin de remonter les éventuelles erreurs au plus tôt.


5- Gestion des contextes


5.1 - Création de groupes de contextes


Les groupes de contextes correspondent à un ensemble de variables de contextes.


La création des groupes de contexte permet de valoriser les propriétés d'une connexion à une base de données spécifique, un web service, ou alors un sous-job par exemple.


Il suffit par la suite d'importer le groupe de contexte nécessaire au déroulement du job.


Un seul environnement doit être créé pour chaque groupe de contexte : par défaut celui-ci s'appelle "Default" et ne doit pas être changé.


5.2 - Chargement de contextes


Les contextes seront chargés dans le job père depuis un fichier de paramètre [nomProjet].properties de la façon suivante :

  • Lecture du fichier [nomProjet].properties à l'aide d'un tFileInputProperties dont l'emplacement sera prévu dans la variable de contexte : fileParameters (exemple /opt/context/Project1.properties).

  • Chargement des données de contexte depuis le fichier à l'aide d'un tContextLoad. Le rapprochement des valeurs entre le fichier et le contexte s'effectue par le nom des variables qui doivent être identiques.

  • Transmettre tout le contexte à tous les jobs fils.

Exemple d'élément dans le job père :


Exemple de paramétrage des tRunJob permettant le lancement des jobs fils :


6 - Documentation


Talend offre la possibilité de générer une documentation par job, joblet. Cette documentation, au format HTML, permet une description technique du job. L'intérêt se port sur l'énumération des composants, avec les différents paramètres (requêtes, schémas, etc.), des contextes utilisés, etc. La documentation générée peut s'exporter avec les divers éléments du projet, ou être de manière "autonome" et être positionnée dans le référentiel de gestion des versions (SVN, GIT, etc.).


La documentation générale du projet (STD, BL) peut quant à elle faire l'objet d'une entrée dans le Wiki du projet dans Gitlab, les liens hypertextes sont possibles pour toujours pointer vers la dernière version de la documentation générée.


6.1 - Création


La génération de la documentation est simple, un simple clic-droit sur Documentation\Jobs permet la génération des documents de tous les jobs :


6.2 - Visualisation, export et mise à jour de la documentation


L'interface de Talend permet d'un simple clic-droit sur la documentation voulue d'effectuer soit une visualisation, soit un export, soit une mise à jour de la documentation :


6.3 Génération de la documentation


Bien que la documentation soit générée automatiquement, il faut bien renseigner certaines informations.

Au niveau des éléments créés sur le repository, il est important de bien renseigner es Objectifs et Description. Ces informations se retrouvent dans la documentation générée.


Au niveau des composants, il faut aller dans l'onglet "Documentation" du composant pour expliciter les particularités, objectif du composant :



113 vues

Posts récents

Voir tout