Journal Pentaho Data Integration, un ETL libre qu'il est bien

Pour ceux qui ne connaissent pas les ETL :
Un ETL (Extract-Transform-Load) est un outil de manipulation de données qui, comme son nom l'indique, permet de prélever des données d'un ou plusieurs sources (fichier CSV, base de données, fichier XML, requete http/webservice...), de les triturer (tris, filtres, recherches, jointures, éclatements de valeurs...) et de les injecter ailleurs (autres bases/fichiers, ou mise à jour des données sources)

+d'infos : http://fr.wikipedia.org/wiki/ETL

Pentaho Data Integration (PDI) (anciennement Kettle) est l'un de ces ETL. Il fait partie de la solution de "Business Intelligence" libre Pentaho, dans laquelle on retrouve également un générateur d'univers décisionnel, des outils de reporting... PDI est une collection d'outils : un moteur/éditeur graphique (Spoon), un scheduleur (Kitchen). C'est plus précisément de Spoon dont je vais vous parler.

Voilà le problème qui se posait à moi, et que j'ai pu résoudre grâce à PDI :
j'ai une application qui permet de gérer des boites de chocolats (exemple fictif, hein, le "vrai" cas de figure et moins simple à comprendre). Pour remplir mes boites, je peux mettres des chocolats "standard" (fournis avec l'appli) ou créer/personnaliser mes propres chocolats.
On me demande de sortir une liste des boites contenant des chocolats personnalisés, en précisant lesquels. Simple.

Seulement voilà :
- dans la base de données, c'est le bordel. J'ai bien 1 table "boite", 1 "chocolat_standard" et une "chocolat_perso", mais certains chocolats standard sont aussi recopiés dans les perso, et parmi eux certains ont été modifiés, d'autres pas
- la formule de composition des chocolats est stockée dans un champ de type CLOB (texte long), sur lequel le SGBD utilisé ne sait quasiment rien faire (pas de comparaisons...)
- j'ai pas non plus dans mes commandes SQL pour permettre des groupements sur des chaines (un peu comme SUM() quoi, sauf que SUM ne fait que les nombres)

Rapidement, on voit bien que c'est pas avec une super requete SQL que je vais m'en sortir.

Alors qu'avec Spoon, c'est presque automagique : l'interface est composée principalement d'une bibliothèque de composants et d'un espace de travail. Je peux faire glisser les composants, les paramétrer, les lier entre eux et exécuter le tout.

Récupérer des données SQL se fait très simplement grâce au composant "extraction de table". Je paramètre ma connexion au SGBD, je lui donne une requete et il détecte les champs récupérés et leur type (chaque étape en fera autant : on peut voir les données reçues en entrée et transmises en sortie). Une prévisualisation est également disponible.

Le composant "comparaison" me servira à faire le tri entre chocolats standard et perso. J'ai fait 2 composants "extraction de table", chacun avec une des 2 tables de chocolats. Je fais de liens de chacune d'elle vers ma comparaison, puis j'édite les propriétés de celle-ci. J'indique une source "de référence" et une "à comparer", ainsi que la clé commune, et optionnellement 1 ou plusieurs champs à comparer. En sortie de ma comparaison, je vais récupérer les données de ma source de référence, augmentées d'une colonne dont la valeur m'indiquera les différents cas possibles : données identiques, données différentes, présentes que d'un côté...

Un filtre me permet de garder que les lignes nouvelles ou différentes. Clic je pose ma boite, clic je fais le lien, clic je crée ma règle de filtre.

Je passe les détails, mais en gros avec mes chocolats personnalisés je fais une jointure (clicclic) avec mes boites. Un peu plus loin, un composant "groupe" ne me gardera qu'une ligne par boite, en concaténant les noms de mes chocolats séparés par une virgule.
Enfin je récupère mon travail en sortant le tout dans un fichier (csv, le xls est aussi dispo, par contre pas de format OpenDocument).

Y'a plus qu'à exécuter le tout et le fichier se génère. En cas d'erreur, une console essaie de m'en donner les origines.

Conclusion : j'ai pu obtenir mon résultat, presque sans écrire de code (j'ai écrit 3 SELECT pour récupérer mes données au départ). Je me retrouve avec une représentation visuelle de la transformation que je fais, avec des libellés que j'ai pu écrire en bon français. Plutôt qu'un paquet de 15 lignes de SQL infâme, je me retrouve avec un schéma facile à lire, à comprendre, à modifier... Je sens que je vais très vite étendre ça à toutes mes tâches d'extraction, de migration, de reprise de données, etc. !


Pentaho http://www.pentaho.com/
PDI http://www.pentaho.com/products/data_integration/ et http://kettle.pentaho.org/