Chargement de dimensions à variation lente avec Pentaho Data Integration

Dans cet article, je vais vous présenter un composant de l’outil Pentaho Data Extraction (PDI), anciennement appelé Kettle. Ce logiciel est un ETL Open Source de la firme Pentaho. Je vais principalement vous présentez l'utilisation d'un composant permettant d'alimenter des tables historisées. Ce genre de composant est beaucoup utilisé dans les bases de données, suivant une modélisation dimensionnelle, pour alimenter des dimensions à variation lente, d’où le nom du composant : « Dimension à variation lente ». Une transformation de dimension à variation lente coordonne la mise à jour et l'insertion d'enregistrements dans des tables de dimension d'entrepôts de données.

Prenons un exemple pour illustrer le paramétrage du composant, ce qui vaut toutes les explications.

Partons d'un fichier CSV simple comportant une liste de produits, ainsi que leur prix à partir d'une date donnée.

csv.png

On remarque que l'imprimante a changé deux fois de prix et le scanner une seule fois. On voudrait qu'une fois en base de données, les informations soient historisées avec une date de début et une date de fin, pour avoir un intervalle de validité du prix du produit.
Nous avons donc une dimension produit dans notre base de données représentée par la table "dim_produit" (Chaque champs de la table sera précédé de "dpro_").

dim_produit.png

On remarque qu'un champ "version" a fait son apparition, ce champ sera d’une grande utilité pour l'utilisation du composant.

Le but étant d'arriver au résultat suivant, pour la transformation du fichier CSV en une table dans une base de données :

resultat_voulu.png

C'est-à-dire une table historisant les produits, en partant du 1er janvier 2000 et en mettant les dates de fin indéterminées au 31 décembre 2199. Chaque nouvelle ligne représente un changement du prix du produit.

Pour cela nous allons créer une transformation avec Pentaho Data Integration (PDI) . Cette transformation est très simple et ne contient que deux étapes. La première pour l'extraction des données du fichier CSV et la seconde pour l'insertion en base de données grâce au composant de chargement de dimension à variation lente. Ce qui donne ceci :

transformation.png

Abordons le paramétrage du composant de chargement d'une dimension à variation lente.
La configuration se compose en trois parties distinctes.
La première concerne la configuration générale du composant, connexion à la base de données, table de la base à remplir, plus divers champs de configuration pour la taille du commit en base, etc…

config_1.png

La deuxième partie se décompose en deux onglets. Le premier permet la configuration du ou des champs clé. Dans notre cas le champ clé est le nom du produit c'est-à-dire le champ "dpro_nom" en base de données.

config_2.png

L'onglet numéro deux lui permet de configurer les champs que le composant doit surveiller pour détecter un changement à historiser. Nous pouvons aussi choisir plusieurs façons pour gérer le changement. Dans notre cas, il n'y a qu’un seul champ à surveiller, le champ "dpro_prix" et nous allons utiliser la gestion par insertion qui permet pour chaque nouveau changement d'insérer une nouvelle ligne en incrémentant la version du produit (c'est à ce moment que le champ version est important). Il existe plusieurs autres systèmes pour gérer le changement, comme la mise à jour de la dernière version ou la mise à jour de toute les versions et encore plusieurs autres.

config_3.png

La dernière partie de la configuration permet la gestion la clé technique de la base de données pour l'incrémentation de celle-ci. On peut gérer l'incrémentation de plusieurs façons, le maximum incrémenté, l'utilisation d'une séquence en base, ou un champ auto-incrémenté. Dans notre exemple la clé technique est "dpro_id" et nous allons utiliser la gestion par maximum incrémenté.
Cette partie permet de choisir le champ représentant la version. Pour notre cas, ce sera le champ "dpro_version".
Et enfin nous avons une série de champs à configurer pour la gestion des dates. La première étape est de choisir le champ du flux représentant la date d'effet, ainsi que le champ de la date de début et date de fin. Il nous faut aussi définir l'année de la date minimale et la date maximale, dans notre cas nous prenons l'an 2000 pour la date minimale et 2199 pour la date maximale.
Il existe aussi plusieurs autres façons de gérer la date de début, comme prendre la date courante du système, la date de démarrage du script, la valeur d'un champ date de la table, etc...

config_4.png

Ainsi le composant est configuré, il ne nous reste plus qu’à lancer le script. Ce qui donne le résultat suivant :

resultat_final.png

On remarque l'apparition d'une ligne d'id zéro et de version 1 avec tous les autres champs à null. Cette ligne est automatiquement insérée par le composant.

En conclusion je dirais que ce composant est d’une simplicité remarquable et qu’il permet une gestion de l’historique dans une table de façon très simple.

Ce composant s’avère redoutable dans presque toutes les façons que l’on peut avoir de chargé des dimensions historisées. En jouant avec les différentes méthodes de gestion du changement sur un champ donnée on peut arriver au résultat que l’on souhaite sans compliquer sa transformation.

En contrepartie, son inconvénient majeur est qu'il ne permet pas de gérer les intervalles de date qui ne se recoupent jamais. C'est-à-dire que les dates de fin et de début de deux versions d'une ligne sont identiques.

Quelques liens utiles pour PDI :

  • Document d'introduction à Pentaho Data Integration : http://forums.pentaho.com/archived_att/kettle/Introduction_PDI.pdf
  • Article explicatif du composant « Dimension à variation lente » (Anglais) : http://wiki.pentaho.com/display/EAI/Dimension+Lookup-Update

2 commentaires

  1. Bonjour Pierrick,
    Merci bien pour ce super tuto. Je suis débutant dans le monde BI et ce à titre perso donc je galère quand même pas mal et moi qui me demandait comment mettre en place ma table de dimension produit (à variation lente), j’ai mes réponses 🙂
    Par contre, je ne comprends pas ta phrase lorsque tu parles du défaut majeur : « il ne permet pas de gérer les intervalles de date qui ne se recoupent jamais. C’est-à-dire que les dates de fin et de début de deux versions d’une ligne sont identiques. »
    Bodays

  2. Encore moi,
    Une dernière question STP: en ce qui concerne ma table de dimension produit (et client aussi), elle peut être modifiée sur plusieurs critères: adresse (client), ville (client), prix (client et produit), unité d’œuvre (produit)… Dans ces cas là, peut on plusieurs « clés » et plusieurs « champs » dans l’etape de transformation?
    Merci d’avance.
    Bodays

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.