Staging Area dans le Processus ETL

0
2195


La notion de staging area ( zone de préparation ) n’est rien d’autre qu’une composante qui porte souvent à la confusion, surtout pour les personnes débutantes dans le domaine ! Qu’est ce que le staging Area ? qu’est ce que le « Persistant Staging Area » ? L’ODS est-il un staging Area ?… Bref une multitude de questions…

Pour comprendre ce que c’est le staging area, le persistant staging area, je vous invite à lire les étapes suivantes qui présentent l’approche que nous préconisons ( compte tenu des outils ETL et BI utilisés ) :

1 – Je dispose de plusieurs systèmes sources, les données dans ces systèmes sources sont des données transactionnelles ou opérationnelles. Par exemple la paie, la gestion des ressources humaines, la gestion des commandes…

2 – Je dispose de ce que j’appelle un staging area temporaire, ou je transfère les données à partir des systèmes sources avec des transformations minimales… l’avantage d’utiliser ce statging temporaire est de ne pas faire de transformation en même temps que les extractions… Ce qui a moins d’impact sur les systèmes sources ( En général les gens des systèmes sources veulent qu’on passe le moindre de temps possible à lire leurs données). Les experts appellent cela l’extract window ( c’est à dire le temps que le responsable du système source vous alloue pour faire les extractions). Ce qui répond au E de l’Etc ( Les systèmes sources sont soit des bases de données Oracle accessibles via SqlNet, soit des fichiers plats via FTP ). En général le modèle physique de la base de données du staging area temporaire est identique à celui des systèmes sources, j’ajoute par contre une colonne pour savoir la provenance des données ( de quel système source). Avec un peu de recul, ce staging temporaire ne doit pas forcèment pas être une base de données, des fichiers plats peuvent suffire à condition que votre outils ETL permet de traiter ces fichiers comme des tables de données ( Oracle permet depuis la version 8i de créer des tables externes (External tables) qui sont en fait des vues sur des fichiers plats ).

3 – Je dispose aussi de ce que Kimball appelle ­ »the persistant staging Area » ou Inmon appelle « the Entreprise Datawarehouse » ou je stocke mes tables aprés transformation, nettoyage, conformance et standardisation sous forme de l’un des deux modèles connus à savoir le « star schema = schéma en étoile » ou « snowflake = flocons de neige ». Ca c’est le T de L’eTc. Ce qu’il faut noter c’est que c’est dans ce stade que l’on associe des surrogate key au business key qui nous proviennent du système source. Aussi on gère ce qu’on appelle l’évolution lente ou rapide dans les dimensions, on définit les règles d’agrégation, on gère les faits et les dimensions qui arrivent en retard… En général les outils ETL prennent en charge ce genre de fonctionnalités .
Je fais donc un premier chargement des données dans l’entrepôt de données (La premier partie du C de l’etC).

4 – Une fois toutes les données chargées dans mon data warehouse, je fais appelle à des programmes qui font le chargement ( La deuxième partie du C de l’etC) dans les cubes cognos ( Molap).

Voici quelques raisons pour lesquelles dans mon cas il est préférable d’utiliser le persistant staging area (EDW, entrepôt de données) :

1 – Extract Once, transform many : ce qui veux dire que l’on fait une seule extraction des systèmes sources, et autant de transformations et de chargement dans le présentation area.

2 – Ne pas impacter le fonctionnement des systèmes sources, surtout dans les cas des systèmes 24/7. Ce qu’on appelle ‘extract window’, ou encore le temps necessaire à extraire les données, devrait être minimale, donc en général les gens ne font pas de transformation en même temps que l’extraction : On extrait les données le plus rapidement possible,on les mets dans un staging, puis on transforme à partir du staging area.

3 – Ou cas ou on a des problèmes de transformation (plantage lors de la transformation, erreur BD…), on ne sera pas obligé de refaire l’extraction, du moment ou la source de ta transformation est le staging area.
4 – Dans le cas ou on aura à intégrer les données de plusieurs sources, le
staging area est en quelques sortes, un endroit de synchronisation, avant de
commencer à transformer les données. Imaginons le cas ou pour alimenter un
Cube cela prends les données des 3 systèmes. si l’un des trois systèmes
n’est pas disponible au moment de l’extraction, on pourrait faire l’extraction des deux autres systèmes, garder les données sans faire de transformation jusqu’a ce que l’extraction du troisième système sera fait, et on fera la transformation des données des trois systèmes en même temps, et puis on alimentera le Cube correctement.

Personnellement je préconise l’architecture suivante :
– Disposer d’une zone de préparation de données que j’appelle le staging area tout cours. La structure de cette zone est semblable à celle des systèmes sources avec quelques modifications prêt. les données dans cette zone peuvent être stockées dans des fichiers plats. Le seul rôle de cette zone est de stocker ces données temporairement en attendant de les faires passer dans la moulinnette de la transformation.
– Disposer d’une zone de stockage de données que j’appelle le Data Warehouse. Ce Data warehouse est principalement une base de données, modélisée en dimensionnel ou en relationnel. Le choix dépend, selon moi, d’une série de critères entre autres la suite décisionnelle utilisée, l’expertise de l’équipe de dévellopement, la nature des utilisateurs finaux… Cette zone est appellée Persistent Staging Area par Kimball et Entreprise Data Warehouse par Inmon. cette zone à plusieurs rôles : Historiser les données, représenter les données d’une façon à rendre la tache facile aux créateurs de cubes, de rapports et aux utilisateurs finaux lors des fouilles dans l’historiques des données.