Staging Area dans le Processus ETL
La notion de staging area ou de zone de préparation n'est rien d'autre qu'une composante qui porte souvent à la confusion ! Qu'est ce que le staging Area ? qu'est ce que le "Persistant Staging Area" ?
Pour comprendre ce que c'est le staging area et le persistant staging area, nous vous invitons à lire les étapes suivantes qui présentent une des approches préconisées lors de la mise en place d'un entrepôt de données compte tenu de la suite ETL et BI utilisées :
1 - Nous disposons de plusieurs systèmes sources, les données dans ces systèmes sources sont des données transactionnelles. Par exemple la paie, la gestion des ressources humaines, la gestion des commandes...
2 - Nous disposons de ce que nous appelons un staging area temporaire, ou nous transférons les données à partir des systèmes sources avec des transformations minimales... l'avantage d'utiliser ce staging 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, nous ajoutons 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 - Nous disposons aussi de ce que Kimball appelle "the persistent staging Area" ou Inmon appelle "the Entreprise Datawarehouse" ou nous stockons les 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 à ce stade que l'on associe des surrogate key au business key (clé d'affaire) 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 .
Nous faisons donc un premier chargement des données dans l'entrepôt de données (La première partie du C de l'etC).
4 - Une fois toutes les données chargées dans le data warehouse, nous faisons appel à des programmes qui font le chargement ( La deuxième partie du C de l'etC) dans les cubes Molap.
Voici quelques raisons pour lesquelles dans notre 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 nécessaire à 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 temporaire.
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.
Nous préconisons donc 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 faire passer dans la moulinette de la transformation.
- Disposer d'une zone de stockage de données que nous appelons 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éveloppement, la nature des utilisateurs finaux... Cette zone est appelée Persistent Staging Area par Kimball et Entreprise Data Warehouse par Inmon. cette zone à plusieurs rôles : Historier 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.