DBT Test : fiabiliser vos données grâce aux tests

Les tests effectués sur les données sont un processus qui ne reçoit que peu d’attention, pourtant ils sont essentiels.

Avec 5 modèles, corriger une erreur est encore gérable, mais que dire lorsque vous déployez 180 modèles de données ? C’est comme chercher une aiguille dans une botte de foin.  

Si vous n’effectuez pas de tests actuellement, ne vous inquiétez pas, vous n’êtes pas le seul ! L’objectif de ce billet est de vous éclairer sur l'importance des tests dans le processus de transformation des données et de vous fournir des méthodes et des bonnes pratiques pour intégrer efficacement les tests dans vos flux de travail de données via Data Build Tool. 

‍

L’importance des tests pour le Data Engineering

Le processus de Data Engineering s'appuie sur de nombreuses hypothèses pour garantir l’intégrité et la pertinences des données utilisées :

• Que les données sont à jour.
• Que le modèle est solide.
• Que les données transformées sont exactes.

Si aucune de ces hypothèses n’est testée, vous fonctionnez dans un état d’ignorance. Or l’ignorance ne conduit jamais à de bons résultats. Si vous n’effectuez aucun test, vous pourriez exécuter d’innombrables modèles sans jamais identifier les défaillances ou les incohérences qui pourraient compromettre vos analyses. 

En testant activement les données à chaque étape, de la collecte à la transformation et jusqu'à la livraison, vous pouvez vous assurer que les données sont non seulement précises et à jour, mais aussi pertinentes pour vos besoins analytiques.

Quel test implémenter via DBT Test ? 

Si vous avez un doute concernant vos données, il est temps d’utiliser DBT Test. 

DBT Test est une commande de Data Build Tool qui permet d’effectuer des tests automatisés sur les modèles de données pour vérifier leur qualité et leur intégrité. Cette fonctionnalité permet de s'assurer que les transformations de données produisent les résultats attendus et que les bases de données respectent certaines contraintes et règles métier.

Alors que tester avec DBT Test ? 

• Tests de validation de données : ces tests vérifient l'intégrité et la validité des données. Par exemple, s'assurer qu'une colonne ne contient pas de valeurs nulles ou que les valeurs d'une colonne sont uniques.
• Tests de cohérence des données : ils permettent de vérifier la cohérence des données à travers différentes tables ou modèles, par exemple, en s'assurant que les clés étrangères correspondent à des clés primaires valides dans une autre table.
• Tests personnalisés : DBT permet de créer des tests personnalisés pour répondre à des exigences spécifiques, utilisant des requêtes SQL personnalisées pour valider des règles métier ou des conditions particulières.

Selon le type de test que vous avez exécuté dans DBT, un test échoué vous indiquera : 

• Le SQL dans le modèle n’a pas fait ce que vous vouliez faire, 
• Une hypothèse concernant vos données sources est incorrecte,
• Une hypothèse sur vos données sources qui était vraie autrefois n’est plus valable. 

Attention à bien prendre en compte les messages d’erreurs générés par un test échoué pour identifier précisément les problèmes au sein de vos modèles de données, corriger les erreurs de manière ciblée, et assurer l'intégrité et la qualité de vos données sur le long terme. 

Comment mettre en place un test avec Data Build Tool ? 

Si DBT offre une bibliothèque de tests prêts à l’emploi, si vous souhaitez des tests personnalisés il vous faudra suivre les étapes suivantes : 

• Définition de tests : les tests sont définis dans des fichiers YAML, associés aux modèles de données. Pour chaque test, on spécifie le type de test (par exemple, unique, not_null, relationships, etc.) et les paramètres applicables (comme les colonnes à tester).
• Exécution de tests : les tests sont exécutés après la transformation des données, en utilisant la commande DBT Test. DBT exécute les tests définis contre les modèles de données transformés et rapporte les résultats, indiquant si les données répondent aux critères définis.
• Intégration dans le workflow : les tests automatisés peuvent être intégrés dans le workflow de CI/CD pour automatiser l'exécution des tests à chaque fois que des modifications sont apportées aux modèles de données ou aux scripts de transformation.
  

Limpida vous recommande d'intégrer vos tests aux deux points critiques de votre chaîne de traitement des données : à proximité immédiate de vos sources de données initiales et juste avant le stade d'analyse finale.

Trop de test, tue le test 

Vous vous êtes un peu laissé emporter par les tests ? Vous avez essayé d'ajouter un test sur chaque colonne, mais maintenant vous êtes noyé sous les messages d'erreur ?

Il vous faut monitorer vos tests, et cela commence par un audit complet. 

Examinez vos tests récemment échoués : ont-ils vraiment besoin d’exister ? Si tel est le cas, hiérarchisez-les dans l’ordre et corrigez-les en conséquence. Vous pouvez faire la même chose dans tous les domaines : existe-t-il des modèles obsolètes ou des colonnes jamais utilisées dans lesquelles vous pouvez supprimer des tests ? 

Pour les tests non critiques, changer la gravité de « erreur » à « avertissement ». Cette distinction permet de maintenir une alerte sur ces points sans pour autant bloquer le processus de développement ou de déploiement en raison de leur échec. Appliquez cette même logique aux tests plus anciens qui, bien qu'utiles à un moment donné, peuvent ne plus être pertinents dans le contexte actuel de votre projet.

Un système de tests bien géré est un composant clé de toute stratégie réussie de Data Engineering, permettant à votre équipe de rester agile tout en maintenant un haut degré de fiabilité des données.