Audit de performance sur des flux ETL SAP BODS sur MS SQL Server
-
Secteur d'activité
Assurance -
Contexte client
Project décisionnel -
Enjeux client
Evaluer la charge portée la l'ETL et les bases de données sources et cibles des interfaces ETL -
Contexte technologique
- SGBD : MSSQL Server 2008R2 puis 2016 Enterprise Edition
- ETL : SAP BODS 4.2
- Reporting : SAP BO XI puis SAP BO BI 4
-
Délais
25 jours -
Résultat
Changement d'infrastructure disques pour supporter la charge très lourde demandée par les traitements ETL sur la base de données MSSQL.
Optimisation des extractions depuis les sources Progress. Optimisations des traitements ETL pour utiliser la nouvelle plateforme SQL renforcée.
Réduction de certaines tables par 1000 en changeant la modélisation des données
==> Les traitements se terminent à 5h du matin au lieu de midi et la volumetrie des bases est réduite de 600Go
Tout d’abord, dans cet audit de performance sur l’ETL SAP BODS, nous appliquons notre méthodologie :
- écoute des acteurs (chef de projet, ingénieur système et stockage, développeurs, directeur du SI, DBA des bases Progress…)
- pose de sondes et des traces
- études des configurations hardware et logicielles
- analyses des flux
- analyses des structures de bases de données
Malheureusement pas de repository centralisé pour ce compte mais un repository pour chaque domaine fonctionnel. Ce qui complique un peu la tâche.
Premièrement, nous avons donc récupéré et centralisé les logs des traitements ETL. Puis nous avons essayé de définir le nombre de traitements tournant en parallèle. Finalement, l’objectif est de déterminer si le taux de parallélisme ETL est important afin de savoir si les optimisations hardware permettront ensuite de gagner du temps. Le résultat est très intéressant :
Un autre phase de l’analyse est de déterminer le taux de croissance des données opérationnelles. Ceci est faisable en se basant sur la taille des sauvegardes SQL Server. Cette croissance est comparée aux autres bases de données et permet de voir les purges éventuelles et le rythme de la croissance :
Enfin il faut déterminer ce qui fait que la base de données attends (ici surtout les IOs/Disques).
Les requêtes les plus lourdes ou ayant de ratio d’efficacité faible sont analysées en détail. Ceci pour éviter des requêtes « mutantes » qui phagocyteraient les ressources machines à elles-seules.
Au final nous fournissons un dashboard continuellement mis à jours pour mieux dégager les informations utiles pour le l’audit de performance BODS. Les données d’audit des différents repository BODS sont centralisées dans une base unique et restituée sur des tableaux de bords comme celui-ci :
En conclusion, nous avons convaincu la DSI d’investir dans une machine physique et un stockage dédié capable de supporter les charges importantes de la bases de données datawarehouse. Pour un budget très raisonnable, les problèmes de performances en ont été considérablement réduit.
Nous avons migré la base MS SQL de 2008R2 vers 2016 pour profiter des améliorations liées à cette version.
Nous avons également optimisé des dixaines de flux BODS très lourds en les passant en mode ELT plutôt que ETL : moins de crash de flux et une performance grandement améliorée.
Ces optimisations ont été réalisées en travaillant en binôme avec le client pour que celui-ci comprenne et s’approprie les techniques d’optimisations SAP BODS.