Introduction
Pour exploiter les données et en tirer de la valeur métier, il est primordial qu'elles soient au bon niveau de qualité.
Aussi, mesurer le niveau de qualité des données et restituer les résultats des tests aux utilisateurs est un atout dans une démarche de démocratisation de l'accès aux données. Le suivre dans le temps informe sur la fiabilité du jeu de données. Une notification en cas de changement de statut de qualité d'un jeu de données permet de prendre les dispositions nécessaires le plus rapidement possible afin de réduire le temps de remédiation des éventuels problèmes.
La démarche démarre par la définition de règles métier, qui caractérisent le niveau de qualité des données. Selon les usages et les contraintes métier, ces règles peuvent concerner plusieurs aspects des données, comme leur intégrité, leur fraîcheur ou encore leur complétude. L'expression de ces règles en langage naturel permet d'impliquer tous les acteurs, notamment les profils métier et techniques, dans ce processus de gouvernance des données.
Présentation du suivi de la qualité des données dans DataGalaxy

Fonctionnement
La fonctionnalité de suivi de la qualité des données dans DataGalaxy va vous permettre de remonter dans la plateforme des résultats de tests de qualité effectués par un outil externe. DataGalaxy n'accède pas à vos données et n'effectue pas directement de tests de qualité. Il s'agit de restituer les résultats des tests de chaque règle de qualité dans la plateforme, afin de partager cette information aux utilisateurs et de permettre de lancer les actions nécessaires dans le cadre d'une démarche de gouvernance de la qualité des données.
Actuellement, les règles et tests de qualité sont présentés dans un onglet supplémentaire sur les objets Table et Vue du Dictionnaire.
Les règles de qualité et résultats de tests
Lorsque l'on crée une règle de qualité sur une Table ou une Vue, les informations suivantes sont demandées :
- code : l'identifiant externe de la règle, provenant de votre outil de tests, unique dans un espace de travail ;
- règle : expression de la règle (en langage naturel de préférence afin que tous les utilisateurs puissent la comprendre) ;
- type : une des 6 dimensions de la qualité de données :
- complétude,
- précision,
- cohérence,
- validité,
- unicité,
- intégrité.
Lorsque l'on remonte un résultat de test de qualité de données se rapportant à une règle sur un objet, les informations suivantes sont demandées :
- statut : le résultat du test :
- "Ok" lorsque le résultat du test est bon,
- "Attention" lorsque le résultat mérite une attention sans pour autant être en échec,
- "Critique" lorsque le résultat est en échec,
- "Inconnu" lorsque le test n'a pas pu s'effectuer correctement et que l'on ne connait pas son résultat,
- message : un message court permettant de donner des informations supplémentaires sur le résultat du test ;
- détail : des informations plus détaillées pour aider à la résolution du problème, par exemple un extrait des données en erreur ou un message d'erreur plus complet.
Le statut de qualité des données
Chaque résultat de test remonté dans la plateforme se rapporte à une règle de qualité (elle-même liée à un objet de type Table ou Vue). Chaque règle porte un statut, qui correspond au dernier résultat de test remonté pour cette règle.
Tous les statuts des différentes règles de qualité sont agrégés pour déterminer le statut global de qualité de l'objet (Table ou Vue). Ce statut est un attribut du méta-modèle DataGalaxy et peut donc être utilisé comme tous les autres attributs.
Ce statut peut prendre quatre valeurs :
- "Inconnu" lorsque l'on n'a pas d'information sur le statut de qualité (aucun résultat de test n'est connu) ;
- "Ok" lorsque le statut de chaque règle de qualité est "Ok" ;
- "Attention" lorsqu'au moins une règle est au statut "Attention" ;
- "Critique" lorsqu'au moins une règle est au statut "Critique".
Réagir rapidement en cas de problème de qualité des données
Le statut de qualité des tables et vues peut être utilisé pour exposer le niveau de qualité de la table (ou de la vue) aux utilisateurs, par exemple en l'ajoutant à l'en-tête de la fiche objet, en l'affichant comme colonne d'une vue tabulaire d'une liste d'objets, ou encore comme filtre d'une liste d'objets.
Il devient alors simple et rapide d'avoir une vision globale de l'ensemble des tables et vues qui ne seraient pas au bon niveau de qualité, par exemple en créant une vue filtrée affichant tous les objets dont le statut est "Attention" ou "Critique".
Pour être alerté d'un changement de statut de qualité des données, il suffit d'utiliser la fonction "Suivre" de l'objet qui permet de déclencher des notifications lorsqu'une modification est apportée à l'objet, incluant l'attribut de qualité.
Utilisation de la fonctionnalité de suivi de la qualité des données dans DataGalaxy
Étapes de mise en place
Voici les étapes pour mettre en place la fonctionnalité :
- Ajouter l'attribut "Qualité des données" ("Data Quality") dans la section de votre choix sur vos écrans Table et Vue du Dictionnaire
- Définir et implémenter des règles de qualité de données dans un outil externe, du marché ou solution maison
- Utiliser l'API DataGalaxy pour développer l'interface permettant de remonter les règles et résultats de tests dans la plateforme
- Planifier l'exécution des tests dans vos systèmes et bénéficier des résultats dans DataGalaxy
L'API REST
Actuellement, l'interface permettant de créer des règles et de remonter des résultats de tests de qualité est une API REST. Cela permet une intégration de type programmatique avec toute solution de tests de qualité de données que vous pourriez avoir implémenté dans votre contexte, comme Sifflet, Soda, Great Expectations, ou tout autre éditeur ou solution maison.
Les règles sont représentées par l'entité "Rule" et les résultats de tests par l'entité "Check".
Vous trouverez les informations utiles pour démarrer avec notre API dans ce guide de démarrage : l'API publique DataGalaxy.
L'API REST de qualité de données est décrite dans la documentation de l'API DataGalaxy.
Note: pour l'authentification de votre client API data quality, nous vous conseillons d'utiliser un token d'intégration plutôt qu'un token personnel afin de bénéficier de toutes les fonctionnalités (notamment pour l'usage de la fonction "suivre" de l'objet). Le token utilisé doit avoir accès à l'espace de travail concerné et bénéficier des permissions de Contributeur sur les sources du dictionnaire sur lesquelles vous souhaitez créer des règles et des résultats de tests.
En créant un token d'intégration dédié pour cet usage, cela vous permettra également de personnaliser son nom et son logo, afin qu'il reflète l'outil de data quality que vous utilisez pour effectuer les tests, dans notre exemple il s'agit de Sifflet :

Note: l'url de base des routes API est disponible dans votre menu Profil > API DataGalaxy dans la plateforme. Elle est généralement sous la forme https://[instance].api.datagalaxy.com/v2 . Consultez le guide de démarrage pour plus d'informations.
Note: à ce jour, le modèle de permissions n'a pas été implémenté dans le module data quality. La seule permission nécessaire pour créer/supprimer des règles et des checks est une licence Steward. Les permissions ne sont pas liées aux permissions des objets du métamodèle. Nous sommes conscients de cette limitation et avons ce sujet en visibilité pour les évolutions du produit.
Toutefois, si le token utilisé pour créer les checks n'a pas de permission de contribution sur les objets liés aux règles, le check sera bien créé/supprimé, mais le statut data quality de l'objet ne sera pas mis à jour car c'est un attribut du métamodèle et c'est pourquoi l'API renverra une erreur.
Fonctionnement de l'API Data Quality
Toutes les routes sont décrites dans la documentation de l'API DataGalaxy.
Questions fréquentes
Quelle est la durée de rétention des tests de qualité de données ?
Actuellement, les tests de qualité de données ne sont pas purgés. Les routes API permettent de supprimer les tests ou les règles que l'on ne souhaite plus présenter dans la plateforme
Comment fonctionne le suivi de qualité des données sur un espace de travail versionné ?
Sur les espaces de travail versionnés, le service de qualité de données interagit avec la version "par défaut", qui est votre version officielle si elle est disponible
Le statut de la règle et le statut de l'objet ne correspondent pas au dernier résultat de test sur cette règle, pourquoi ?
Un problème connu de rafraîchissement peut arriver lorsque vous ouvrez la liste des résultats de tests et que vous supprimez le dernier manuellement depuis l'interface. Le statut de la règle sera mis à jour, mais ni la liste des derniers résultats de tests ni le statut de l'objet n'apparaîtront à jour. Ce n'est qu'un problème d'affichage, rafraîchir la page résoudra le problème. Le statut enregistré dans la plateforme est le bon.
Un comportement similaire peut se produire si, pour tester, vous envoyez de multiples résultats de tests avec différents statuts mais le même timestamp. Comme le "dernier" résultat de test est déterminé par la date, avoir les mêmes timestamps pour plusieurs résultats peut conduire à des incohérences. Cela ne se produira pas dans un usage réel donc nous ne considérons pas cela comme un problème bloquant.