Des ERP à la visualisation de « gros » volumes de données

A mesure qu’une entité se développe, le volume de données généré par ses diverses parties prenantes (employés, clients, fournisseurs...) croît et se complexifie. Dès lors, développer des rapports et dashboards performants en requêtant directement la « data source » devient un défi au quotidien. 

Ainsi, nombreuses sont les entreprises qui optent pour l’utilisation de cubes OLAP afin d’optimiser les performances de leurs dashboards et par la même, disposer d’une historisation de leurs données. 

A travers ce poste, nous vous donnons un aperçu simple et accessible des différentes étapes nécessaires à l’intégration de données dans un cube (encore appelé modèle sémantique). Les détails techniques (outils, technos...) seront abordés dans nos prochaines publications. 

• Extraction des données : cette 1ère étape consiste à extraire de manière quotidienne les données de différents ERP (SAP, Salesforce, JIRA...) et à les stocker à l’état brut dans un « Data Lake ». Des ETL comme Talend , Adf... sont utilisés pour programmer des jobs capables de requêter automatiquement à des heures creuses les sources de données (en « full » ou « delta » selon le besoin), générer des fichiers (format parquet ou autre) tributaires des vues et objets présents dans les systèmes (Orders, Shipments, Tickets, User, Stock...)et les déposer dans le lac de données (Azure Datalake Storage par exemple) pour être traités par la BI. 

• Le Datawarehouse : A ce niveau, l’on commence par reproduire l’ossature des différents fichiers parquets dans la base de données. Une fois les tables DWH créées, l’on programme l’ETL afin qu’il puisse y déverser de manière régulière les données des fichiers parquets. Les différents traitements effectués à ce niveau ainsi qu’aux étapes suivantes doivent aussitôt être répliqués dans le Devops (via Azure Devops par exemple) afin d’automatiser les cycles de déploiement. 

A présent que les données sont extraites par l’ETL et l’ossature des fichiers parquets a été répliquée dans le Datawarehouse, il est question de les stocker en tenant compte des “besoins métier” et in fine, les présenter à travers un outil de DataViz. 

• Le Datamart : c’est là qu’atterrissent les passagers importants du Datawarehouse 😉Il correspond à une combinaison des tables du DWH, des « Foreign Keys » et des champs techniques (Creation Date, Modification Date, ProcessId...). Là également, l’on procède à la création de tables DMT ; des tables de faits et des dimensions, simples ou historisées selon les “besoins métier”. L’alimentation de ces tables peut se faire ensuite via l’ETL et les procédures stockées au niveau de la base de données. Des retraitements (filtre de données, ajout de champs, formats...) peuvent, selon le besoin, être effectués à cette étape ou directement au niveau du cube. 

• Le Cube / Semantic Model : il s’agit d’« une structure de données supérieure aux bases de données relationnelles grâce à une analyse rapide des données ». Il regroupe les champs des tables DMT (Dimensions et Fact Tables) utiles au métier (Finance, Support...) ou à l’IT pour des besoins de monitoring.  C’est à cette étape, qu’en fonction des besoins du métier, on crée les jointures, les perspectives, les sécurités (RLS...) et les partitions. 

Une fois cette étape achevée, le  « runbook »est lancé pour charger les partitions des différentes tables dans le cube. Et voilà, celles-ci peuvent être requêtées sans s’inquiéter d’éventuels problèmes de performance 😊 

• Visualisation : C’est la dernière étape du processus qui consiste à se servir d’outils BI (Power BI, Tableau...) pour créer des rapports et dashboard  user-friendly à destination du métier (finance, support ,logistics...). Il faudra ensuite former les utilisateurs et se préparer à « manger » les tickets y relatifs (incidents, demandes d’améliorations...). 

  
  

Alors, vous rajouteriez quelle(s) étape(s)?

hashtag#DataEngineering hashtag#BusinessIntelligence hashtag#Analytics