La spécification des flux ETL en BI, un combat au quotidien

Partager : 
Flux ETL

Tous les jours, les organisations cherchent à se rendre plus efficaces. Une des meilleures façons de lancer ce processus est de simplifier et agiliser le travail au quotidien de vos équipes.

DataGalaxy vous propose une série d’articles concernant la facilitation des projets BI, depuis la phase de cadrage/conception jusqu’à l’exploitation de votre solution décisionnelle.

Le data mapping

Nous avions vu dans un précédent article que la phase de cadrage permettait notamment de définir quelles sources de données étaient pertinentes pour alimenter le système décisionnel.

A ce stade l’architecture, flux ETL reste très « macro » : on connaît la source, mais souvent très peu de détails sur les informations à récupérer (emplacement/tables/…, format, mode de récupération, fréquence de mise à jour), et par ailleurs les informations sur la cible sont également mouvantes (voir notre prochain article sur le Data Modeling).

Difficile donc de définir précisément les étapes d’Extraction, Transformation et chargement (Load).

Ainsi, il est nécessaire de pouvoir procéder de manière « agile » sur cette phase de spécifications des flux. Par rapport à la phase de cadrage, nous retrouvons forcément le même besoin de centralisation et de partage que pour un dictionnaire de données.

Mais il existe aussi une spécificité qui concerne ces flux de données : lors de l’étape de transformation, il sera nécessaire de croiser des données, les combiner, les filtrer, …

Et, par définition, ces opérations ne s’effectuent pas en mode de chargement « 1 pour 1 », c’est-à-dire qu’à une ou plusieurs informations en entrée peuvent correspondre une ou plusieurs colonnes en sortie.

Un tableur pour faire le data mapping ?

Avec les anciennes méthodes, et en l’absence d’outil adapté ou abordable, de nombreux acteurs des projets BI ont mis en place des spécifications en s’appuyant sur l’outil le plus flexible à leur disposition : le tableur (bien souvent Excel).

Or, nous l’avons vu précédemment dans l’article : Projets BI, ses méthodes et outils ont changés, et vous ?, si ce type d’outil permet de faire des spécifications « a minima », il n’est pas adapté pour gérer certains aspects de la gestion des métadonnées, notamment :

  • Les modifications des systèmes sources et cibles ne sont pas automatiquement pris en compte dans le data mapping,
  • Les versions des flux, qui évoluent particulièrement vite durant les phases de spécification ne sont pas gérées de manière adéquate.

Cette spécificité de chargement « n-n » entre les informations sources et cibles n’est pas adressée (le système tabulaire ne permet pas d’y répondre).

Bref, utiliser un tableur pour spécifier des flux se transforme rapidement en une tâche aussi ardue que faire rentrer des ronds dans des carrés (ou inversement).

Designer des flux ETL d’alimentations

Recensons les besoins auxquels un bon outil de spécifications de flux doit permettre de répondre.

D’abord nous l’avons vu la spécificité des chargements « n-n » est primordial. Le seul moyen compréhensible de répondre à cet enjeu consiste en un affichage graphique des données. Cet état de fait est d’ailleurs bien compris dans la plupart des logiciels de Data Transformation, qui proposent pour la plupart des liens graphiques entre les objets dans leurs interfaces de développement.

Dès lors, pourquoi se priver d’une solution qui a fait ses preuves ? Les outils de Métadata management qui gèrent le data mapping doivent intégrer ce type d’interface ; de facto, plusieurs d’entre eux en sont effectivement équipés.

Ensuite, la traçabilité dans l’utilisation des objets doit également être au cœur de cet outil. Les liens notamment avec le Data Modeling, doivent pouvoir être suivi en temps réel entre les collaborateurs. Nous retrouvons ici la problématique de centralisation et partage des données comme pour la phase de cadrage.

Cette traçabilité est désormais présente dans plusieurs plateformes de gestion des métadonnées, permettant de générer des lineages et des analyses d’impacts sur les objets de votre système décisionnel.

Finalement, la question de la collaboration et du versionning pourrait bien faire la différence pour la collaboration des équipes. En effet, toutes les plateformes de Métadata Management ne proposent pas la même simplicité pour gérer cet aspect des spécifications.

Quoi qu’il en soit, il n’existe aujourd’hui plus de freins quant à la migration de toute votre documentation de vos tableurs vers un format qui sera finalement plus pratique à utiliser au quotidien (gain de productivité), à exploiter (analyses d’impact et lineage) et qui proposera donc un bien meilleur retour sur investissement (ROI) que « cette bonne vieille feuille Excel ».

Partager :