L’éditeur français Talend sort régulièrement des nouveautés de son offre logicielle. Suite à une mission réalisée pour un client, je fais un petit point sur les fonctionnalités et particularités portées par l’architecture de la suite Talend. Des raccourcis peuvent être lourds de conséquence. Je vous propose donc de vous partager ma vision, et d’en discuter !
Talend Data Enterprise Integration est la version commerciale et d’entreprise du célèbre Talend Open Studio. L’éditeur met ici à disposition un outils de développement complet pour produire des programmes de traitements de données communément appelés Jobs. Ce produit fait partie de la famille des ETL (Extract, Transform and Load) comme DataStage d’IBM. Au sein de la suite Talend,il couvre donc la partie orientée données.
Les principales qualités de ce produit sont:
- la qualité de son IDE (basé sur eclipse)
- la facilité de déploiement des exécutables.
La version Entreprise en v5 ajoute les fonctionnalités nécessaires à :
- la collaboration du travail en équipe
- la gestion des déploiements
- la supervision des traitements
Dans cet article je vais aborder l’architecture de Talend Data Enterprise Integration afin de vous donner les clés pour un bon départ … ou les raisons d’une réorganisation si vous êtes mal parti.
Architecture logicielle
La solution TDI offre de nombreuses briques logicielles. Elles couvrent les phases majeures de la production et de l’exécution des Jobs ETL.
On retrouve:
- L’outils de développement (IDE): Studio
- La console d’administration: TAC
- Le référentiel de projets: Subversion
- L’agent de construction de projet: commandLine
- Le référentiel de binaires: Archiva ou Nexus
- L’agent d’exécution des Jobs: JobServer
- Le serveur de gestion des logs: Logstash
L’élément central est la TAC qui sert de référentiels de projets, administre les utilisateurs et leurs droits, contrôle les constructions des binaires et gère leur exécution.
Le Studio permet de définir et concevoir les Jobs.
Le cmdLine est une version sans IHM du Studio afin de construire sans “développeur” les projets référencés.
Les JobServer sont des agents qui contrôlent les Jobs exécutés localement.
La console de monitoring monitore 🙂 les exécutions de Jobs.
Archiva archive les binaires (si choix de ne garder que les binaires).
Le schéma suivant illustre les grandes interactions entre ces modules:
Mon objectif est, ici, de montrer comment les modules se coordonnent. Par exemple, le module cmdLine sert qu’à la compilation des sources. Il est piloté par la TAC lors de demandes de génération. Toutefois attention, les interactions montrées ne sont pas exhaustives.
Architecture d’exécution
La vision runtime ajoute 2 notions indispensables à la compréhension de l’ensemble:
- le serveur logique d’exécution (VM Linux par exemple)
- les jobs qui s’exécutent dans des JVM.
Enfin, pour gérer un ensemble de projets et de jobs cohérents en toutes situation, un second TAC est utilisée. Il a pour vocation de gérer les versions de Production.
Au final, le TAC de Production commande les JobServer déployés sur les serveurs distants afin qu’ils pilotent les exécutions de Jobs sur ces serveurs.
Cela donne donc:
Cette organisation est importante car elle garantie la performance, la montée en charge des flux et la robustesse de l’architecture de Production.
Synthèse
Au final, l’organisation que je vous propose n’a rien d’originale. Elle est simplement respectueuses de la philosophie du produit. Si vous suivez ces préconisations, vous aurez à disposition une plateforme organisée et efficace.
[li_card]