Les origines de la data observability
Commençons par donner un peu de contexte. La qualité de la donnée est le nerf de la guerre pour beaucoup d’équipes data et représente d’ailleurs la majeure partie du travail des Data Engineers. À travers le développement de pipelines de données et la gestion de la Modern Data Platform, ces derniers sont chargés de s’assurer que la data qu’ils fournissent aux consommateurs est disponible, accessible, correcte, complète et fiable. Leur but est finalement de réduire au maximum, voire éliminer, le data downtime, c’est-à-dire les périodes de temps pendant lesquelles la data est erronée, manquante, imprécise ou inaccessible.
Les conséquences du data downtime se ressentent à différentes échelles. Ces périodes représentent une perte de temps pour les équipes Data qui vont devoir identifier la source du problème et la corriger et une perte de confiance de la part des consommateurs de la donnée qui récupèrent alors des chiffres et analyses incorrects. Le data downtime peut même conduire à des décisions erronées et avoir d'importantes répercussions financières.
Oui mais comment assurer cette qualité et cette disponibilité lorsque vous avez des dizaines de data pipelines, manipulant plusieurs téraoctets de données ? Et avant cela, comment mesurer cette qualité pour savoir si la donnée que vous fournissez à vos équipes est bonne ?
Qu’est-ce que la data observability ?
C’est là qu’intervient la Data Observability. Derrière ce terme se cache un objectif simple : mesurer “l’état de santé” de la donnée et des systèmes de données à travers l’intégralité d’une organisation.
La Data Observability fait référence à l’ensemble des pratiques qui sont mises en place pour garantir la qualité, la disponibilité et la fiabilité des données.
Le concept d’observabilité est un concept qui existe déjà depuis des années dans le DevOps et qui concerne le suivi de l’état des software. La Data Observability est en quelques sortes l’application de ces concepts de monitoring aux data pipelines et aux systèmes data en général.
Les Cinq Piliers de la Data Observability
Pour évaluer l’état de santé de votre donnée, la data observability s’appuie sur cinq piliers : la fraîcheur, la distribution, le volume, le schéma et le lineage.
Freshness (fraîcheur)
La fraîcheur des données consiste à mesurer à quel point les données sont à jour et à quelle fréquence est-ce qu’elles sont actualisées. Mesurer la fraîcheur des données consiste également à s’assurer qu’il n’y a pas eu de trou dans l’actualisation des données.
Distribution
Ce pilier consiste à évaluer la qualité de la donnée au niveau des champs et des valeurs. Une méthode classique est d’analyser la proportion de valeurs null dans un champ par rapport à la normale ou de définir des plages de valeur attendues au niveau d’un champ.
Par exemple, si la valeur d’un de vos KPIs clés comme le NPS passe de 9 à 1 en une journée, sans contexte particulier, il est fort probable qu’une erreur soit apparue quelque part dans votre pipeline.
Volume
Le volume des données doit être surveillé pour détecter les anomalies, telles que des pics inattendus ou des baisses dans le nombre de lignes qui pourraient indiquer des problèmes dans les processus de collecte ou de traitement.
Schéma
Le schéma de données correspond à la structure et l’organisation de la donnée (nom des tables, des colonnes, type des champs…).
Pour éviter des problèmes ou des comportements inattendus, ces schémas doivent être formalisés et cadrés. En effet, une colonne supplémentaire et non attendue dans une table ou un champ “chiffre d’affaires” contenant tout à coup des valeurs textuelles peuvent avoir des répercussions sur des systèmes en aval.
Lineage
Suivre le trajet de la donnée durant son cycle de vie est essentiel, que ce soit pour comprendre comment et par qui est-ce qu’elle est manipulée et utilisée ou pour identifier rapidement qui est impacté par un downtime. Ce suivi de la donnée est appelé data lineage.
Intégrer de la Data Observability dans sa Data Platform
Intégrer de la data observability à sa Modern Data Platform ne se résume pas qu’à configurer un outil et à le connecter à ses systèmes en place. Pour tirer pleinement partie de ce framework, l’implémentation doit s’inscrire dans une démarche complète vous permettant d’établir une vue complète et précise de votre Data Platform et mettre en place les bons contrôles aux bons endroits.
D’après Monte Carlo, un acteur incontournable du domaine, les principales étapes pour implémenter la Data Observability sont :
1. Répertoriez vos cas d’usage data
La qualité de la donnée est contextuelle et les exigences (sur les 5 piliers listés précédemment) seront différentes pour de la recommandation de contenu ou pour un reporting financier. Certains cas d’utilisation privilégieront la précision de la donnée alors que d’autres auront surtout besoin de la dernière version des données.
Ensuite, estimez approximativement les performances de vos systèmes et équipes data en listant les incidents répertoriés, les temps d’intervention, les évolutions futures des cas d’usage data… Bien sûr, cette étape peut paraître abstraite au début, mais elle permet de figer un état au démarrage pour mesurer sa progression par la suite.
2. Sensibilisez à la Data Observability et listez les besoins et frustrations des équipes
Maintenant que vous êtes convaincu•e qu’il vous faut mettre en place de la Data Observabilité, il est temps d’aller sensibiliser le reste des équipes et de récupérer leurs demandes.
Pour ce faire, faites le tour des services consommateurs de données et récoltez leurs frustrations et leurs besoins.Cela vous permettra d’y répondre le plus efficacement possible, d’évaluer le niveau de confiance qu’ils ont et quels sont les risques d’une mauvaise qualité de données pour leurs usages.
3. Implémentez un suivi global de la Data Quality
Une fois que vous avez une bonne connaissance de votre environnement Data et une compréhension des besoins des consommateurs, vous pouvez enfin mettre en place un premier contrôle de données générique à large échelle !
Monte Carlo conseille d’appliquer ces premiers contrôles (fraîcheur, volume et schéma) à l’intégralité des cas d’usage data plutôt qu’à un périmètre réduit pour accélérer le time to value et l’identification de points critiques. De plus, l’interdépendance des données fait que la data quality d’une application peut être altérée par celle d’une autre dans un autre service.
4. Améliorez et optimisez la résolution de vos incidents
Ça y est, les premiers contrôles sont en place et tournent correctement, il faut maintenant que vous (re)voyiez la façon dont vous intervenez pour résoudre les incidents détectés.
La première étape est alors de définir un périmètre de responsabilité et d’intervention clair pour chaque équipe. De cette façons, plus de doute possible sur qui fait quoi quand un problème de data quality est remonté.
Maintenant que vous savez qui intervient sur quel périmètre, vous pouvez mettre en place les canaux d’alerting (Slack, Teams, mail, dashboard…) et configurer les alertes pour prévenir les bonnes personnes et ne pas perdre leur intérêt et leur efficacité en les inondant de message qui ne les concerne pas.
5. Créez des systèmes de monitoring spécifiques
Maintenant que vous avez bien avancé dans l’implémentation de votre Data Observability, vous pouvez désormais vous focaliser sur du monitoring spécifique à des cas d’usage. Cela peut être fait manuellement ou en utilisant des fonctionnalités de Machine Learning, de plus en plus proposées dans les outils du marché.
Ce suivi spécifique peut par exemple vérifier que la colonne chiffre d’affaires d’une table de reporting remonte bien uniquement des valeurs non nulles, ou qu’une autre table est bien actualisée tous les jours à 6h du matin.
6.Réduisez le nombre d’incidents
À cette étape, vous pouvez être certain·e que vous avez amélioré la qualité de la donnée au sein de votre entreprise et ainsi, apporter de la valeur et de la confiance aux métiers en ayant considérablement réduit le temps de détection et de résolution de vos incidents data.
Pour aller plus loin encore dans la Data Observability, il vous faut maintenant réduire le nombre d’incidents.
Comment ? En les anticipant et en les empêchant de se produire. Cela peut se faire par une analyse de l’historique des incidents et l’identification de facteurs de déclenchement communs, la mise en place de contrôle dans les data pipelines et dans les pipelines de CI/CD, l’identification de requêtes “instables”...
Et maintenant ?
Les conséquences d’une mauvaise data quality peuvent être considérables pour toute entreprise, que vous soyez une startup ou un grand groupe. De nombreux rapports et études confirment que la Data Quality est LE problème majeur de toutes les équipes Data.
La Data Observability est la clé pour assurer la pérennité de vos systèmes data et faire évoluer sereinement vos cas d’usage. C'est pourquoi chez Modeo, nous mettons ces bonnes pratiques au cœur de la conception d'une Modern Data Platform, en utilisant les outils les plus performants de la Modern Data Stack.