Supprimer les régressions : supprimer les tables et vues inutiles !

 

Supprimer les régressions entre environnements IT Supprimer les tables et vues inutiles !

La profusion de tables et vues

Beaucoup d’entreprises se rêvent « data driven ». Et à juste titre.  De plus en plus de données sont collectées par des moyens toujours plus nombreux en profitant des architectures Cloud, scalables à l’infini. Ces données sont en grande partie exploitées par des data scientists qui doivent construire de nouveaux « business insights », et qui demandent légitimement à l’IT de mettre à disposition toujours plus de données. Souvent, les données sont répliquées, en retouchant à la marge et ce phénomène est accentué lors de la mise en œuvre des architectures « data mesh » dans le Cloud. Côté IT, les data engineers ne reprennent pas toujours le travail de leurs prédécesseurs, recommencent souvent les développements "from scratch". Et les impératifs de vitesse accroissent cette dérive.

L'impact sur les déploiements

Forester indique dans une enquête de 2022 qu’entre 60 % et 73 % de toutes les données d’une entreprise n’ont pas d’utilité pour l’analytics !

Quand il s’agira d’organiser des déploiements, les équipes IT se retrouveront à déplacer de la « matière morte » inutilement d'un environnement à l'autre. Dommage.  C'est du temps, des ressources humaines, qui pourraient servir ailleurs...

Notre approche technique

"Le data lineage"                     &   "les usages de l'information",                          pour identifier     les tables & vues inutiles !

{openAudit} est spécialisé dans le reverse engineering dynamique des technologies de processing de la données et dans l'analyse des logs. 1 - L'analyse des logs pour identifier les tables qui ont un usage :  {openAudit} va détecter au travers des logs toutes les tables et vues qui alimentent réellement des solutions de dataviz. Le scan des solutions de dataviz permet de savoir quelles données "physiques" sont en source (i.e un table/champ d'une DB, un doc Excel, un webservice etc...) des dashboards,  qui sont interrogées via des requêtes adhocs. 2 - Le data lineage pour identifier toutes les sources des tables qui ont un usage :  {openAudit} analyse les vues; les vues de vues, etc.,  {openAudit} gère les procédures dynamiques en traitant le SQL construit dynamiquement en se basant sur les logs de la DB, ou de l'outil qui génère ces requêtes, {openAudit} fixe d’autres générateurs de ruptures dans le lineage : les transferts par FTP, les curseurs, les subqueries, etc., par divers mécanismes internes, {openAudit} traite le SQL encapsulé dans les jobs ELT/ETL qui créent énormément d'opacité,  Même lorsque les technologies de processing sont entremêlées (ELT/ETL, langages objets / procédural, Cloud / on prem'), {openAudit} permet de recréer une cohérence d'ensemble. Certains outils (ETL/ELT) proposent du data lineage sur leur périmètre, mais sont incapables d'y raccorder d'autres outils de data lineage, voir même d'associer les analyses entre projets. Ainsi à travers ce data lineage, couplé à l'analyse des logs, toutes les  les tables | vues utiles vs celles qui sont des "impasses informationnelles" sont identifiées (jusqu'à 50 % !), ...  ... Et peuvent être décommissionnées !

... pour des changements d'environnements toujours plus simples

Nous avons vu qu’il était possible de générer un hash unique par table | vue en incluant l’ordre des champs, les types de champs, la normalisation du script des vues pour contrôler les changements d’environnement.

Ce contrôle précis, associé à la détection et à l’éviction en masse des tables & vues qui n’ont pas d’utilité, permettra de simplifier très sensiblement ces switchs d'environnements.

Film : Réduite la dette IT - 1'