Supposons que vous soyez en charge de la maintenance d'un grand nombre de pipelines de données à partir du stockage dans le cloud ou de la diffusion de données dans un entrepôt de données. Comment pouvez-vous vous assurer que vos données répondent aux attentes après chaque transformation ? C'est là qu'interviennent les tests de qualité des données. Les tests de données utilisent un ensemble de règles pour vérifier si les données sont conformes à certaines exigences.

Les tests de données peuvent être mis en œuvre tout au long d'une pipeline de données, du point d'ingestion à la destination, mais certains compromis sont nécessaires.

D'autre part, il y a la surveillance des données, un sous-ensemble de observabilité des données. Au lieu d'écrire des règles spécifiques pour évaluer si les données répondent à vos besoins, une solution de surveillance des données vérifie en permanence les métriques prédéfinies des données tout au long de votre pipeline par rapport à des seuils acceptables pour vous alerter des problèmes. Ces métriques peuvent être utilisées pour détecter les problèmes dès le début, à la fois manuellement et de manière algorithmique, sans tester explicitement ces problèmes.

Bien que les tests et la surveillance des données fassent partie intégrante du sous-domaine de l'ingénierie de la fiabilité des données, ils sont clairement différents. 

Cet article détaille les différences entre eux et approfondit comment et où vous devez implémenter des tests et des moniteurs. Dans la première partie de l'article, nous discuterons en détail des tests de données, et dans la deuxième partie de l'article, nous nous concentrerons sur les meilleures pratiques de surveillance des données. 

Tester ou surveiller les pipelines de données

Le test de données consiste à évaluer un objet unique, comme une valeur, une colonne ou un tableau, en le comparant à un ensemble de règles métier. Étant donné que cette pratique valide les données par rapport aux exigences de qualité des données, elle est également appelée test de qualité des données ou test de données fonctionnelles. La qualité des données comporte de nombreuses dimensions, mais un test de données auto-explicatif, par exemple, évalue si un champ de date est au format correct.

En ce sens, les tests de données sont délibérer en ce sens qu'ils sont mis en œuvre avec un seul objectif spécifique. En revanche, la surveillance des données est indéterminé. Vous pouvez établir une ligne de base de ce qui est normal en enregistrant les métriques au fil du temps. Ce n'est que lorsque les valeurs s'écartent que vous devez prendre des mesures et éventuellement effectuer un suivi en développant et en mettant en œuvre un test qui empêche les données de dériver en premier lieu.

Le test des données est également groupe de neurones, car un seul test valide un objet de données à un point particulier du pipeline de données. D'un autre côté, la surveillance ne devient utile que lorsqu'elle peint une holistique image de vos canalisations. En suivant diverses métriques dans plusieurs composants d'un pipeline de données au fil du temps, les ingénieurs de données peuvent interpréter les anomalies par rapport à l'ensemble de l'écosystème de données.

Mise en œuvre des tests de données

Cette section détaille la mise en œuvre d'un test de données. Il existe plusieurs approches et certaines choses à considérer lors du choix d'un.

Approches de test de données

Il existe trois approches pour tester les données, résumées ci-dessous.

La validation des données après l'exécution d'un pipeline est une solution rentable pour détecter les problèmes de qualité des données. Dans cette approche, les tests ne s'exécutent pas dans les étapes intermédiaires d'un pipeline de données ; un test vérifie uniquement si les données entièrement traitées correspondent aux règles commerciales établies.

La deuxième approche consiste à valider les données de la source de données à la destination, y compris le chargement final. Il s'agit d'une méthode de test de données qui prend beaucoup de temps. Cependant, cette approche permet de retracer tout problème de qualité des données jusqu'à sa cause première.

La troisième méthode est une synthèse des deux précédentes. Dans cette approche, les données brutes et de production existent dans un seul entrepôt de données. Par conséquent, les données sont également transformées dans cette même technologie. Ce nouveau paradigme, connu sous le nom de ELT, a conduit les organisations à intégrer des tests directement dans leurs efforts de modélisation des données.

Considérations sur les tests de données

Il y a des compromis à prendre en compte lors du choix d'une approche.

Faible coût initial, coût de maintenance élevé

Opter pour la solution avec le coût initial le plus bas, exécuter des tests uniquement à la destination des données présente un ensemble d'inconvénients allant de fastidieux à carrément désastreux.

Premièrement, il est impossible de détecter les problèmes de qualité des données dès le début, de sorte que les pipelines de données peuvent se rompre lorsque la sortie d'une transformation ne correspond pas aux critères d'entrée de l'étape suivante. Prenons l'exemple d'une étape de transformation qui convertit un horodatage Unix en une date tandis que l'étape suivante change la notation de jj/MM/aaaa à aaaa-MM-jj. Si la première étape produit quelque chose d'erroné, la deuxième étape échouera et générera très probablement une erreur.

Il convient également de noter qu'il n'existe aucun test permettant de signaler la cause première d'une erreur de données, car les pipelines de données sont plus ou moins une boîte noire. Par conséquent, le débogage est difficile lorsque quelque chose se casse ou produit des résultats inattendus.

Une autre chose à considérer est que le test des données à la destination peut entraîner des problèmes de performances. Lorsque les tests de données interrogent des tables individuelles pour valider les données dans un entrepôt de données ou un Lakehouse, ils peuvent surcharger ces systèmes avec des charges de travail inutiles pour trouver une aiguille dans une botte de foin. Cela réduit non seulement les performances et la vitesse de l'entrepôt de données, mais peut également augmenter ses coûts d'utilisation. 

Comme vous pouvez le constater, les conséquences de la non-implémentation des tests de données et des imprévus dans un pipeline peuvent affecter une équipe de données de diverses manières désagréables.

Piles héritées, haute complexité

En règle générale, la technologie d'entrepôt de données héritée (comme la technologie répandue mais obsolète Cube OLAP) ne s'adapte pas correctement. C'est pourquoi de nombreuses organisations choisissent de n'y charger que des données agrégées, ce qui signifie que les données sont stockées et traitées par de nombreux outils. Dans cette architecture, la solution consiste à mettre en place des tests tout au long du pipeline en plusieurs étapes, couvrant souvent diverses technologies et parties prenantes. Il en résulte une opération longue et coûteuse.

D'un autre côté, l'utilisation d'un entrepôt de données moderne basé sur le cloud comme BigQuery, Snowflake ou Redshift, ou d'un data lakehouse comme Delta Lake, pourrait rendre les choses beaucoup plus faciles. Non seulement ces technologies font évoluer le stockage et la puissance de calcul indépendamment, mais elles traitent également des données semi-structurées. En conséquence, les organisations peuvent jeter leurs journaux, vidages de base de données et extraits d'outils SaaS sur un seau de stockage cloud où ils s'assoient et attendent d'être traités, nettoyés, ainsi que le testé à l'intérieur de l'entrepôt de données. 

Cette approche ELT offre plus d'avantages. Tout d'abord, les tests de données peuvent être configurés avec un seul outil. Deuxièmement, il vous offre la liberté d'intégrer des tests de données dans le code traité ou de les configurer dans l'outil d'orchestration. Enfin, du fait de ce haut degré de centralisation des tests de données, ils peuvent être paramétrés de manière déclarative. Lorsque des modifications en amont se produisent, vous n'avez pas besoin de parcourir des pans de code pour trouver le bon endroit pour implémenter de nouveaux tests. Au contraire, cela se fait en ajoutant une ligne dans un fichier de configuration.

Outils de test de données

Il existe de nombreuses façons de configurer des tests de données. Une solution homebrew serait de mettre en place gestion des exceptions ou des assertions qui vérifient les données pour certaines propriétés. Cependant, ce n'est pas standardisé ou résilient.

C'est pourquoi de nombreux fournisseurs ont proposé des solutions évolutives, notamment dbt, Great Expectations, Soda et Deequ. Un bref aperçu:

• Lorsque vous gérez une pile de données moderne, il y a de fortes chances que vous utilisiez également dbt. Ce chouchou de la communauté, proposé en open source commercial, dispose d'un module de test intégré.
• Un outil populaire pour implémenter des tests en Python est Great Expectations. Il offre quatre façons différentes de mettre en œuvre des tests prêts à l'emploi ou personnalisés. Comme dbt, il a une offre open source et commerciale.
• Soda, un autre outil open source commercial, est livré avec des capacités de test conformes aux fonctionnalités de Great Expectations. La différence est que Soda est une solution d'ingénierie de fiabilité des données plus large qui englobe également la surveillance des données.
• Lorsque vous travaillez avec Spark, toutes vos données sont traitées comme un Étincelle DataFrame à un moment donné. 
• Deequ offre un moyen simple d'implémenter des tests et des métriques sur Spark DataFrames. La meilleure chose est qu'il n'a pas à traiter un ensemble de données complet lors de la réexécution d'un test. Il met en cache les résultats précédents et les modifie.

Restez à l'écoute pour la deuxième partie, qui mettra en évidence les meilleures pratiques de surveillance des données.

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• PlatoAiStream. Intelligence des données Web3. Connaissance Amplifiée. Accéder ici.
• Frapper l'avenir avec Adryenn Ashley. Accéder ici.
• Achetez et vendez des actions de sociétés PRE-IPO avec PREIPO®. Accéder ici.
• La source: https://www.dataversity.net/testing-and-monitoring-data-pipelines-part-one/