Auteur
Dans leurs activités quotidiennes, les ingénieurs Data et les analystes Data doivent améliorer les processus d'ingestion de data . Au-delà des tests unitaires habituels, il peut être intéressant de comparer facilement et rapidement deux ensembles de données (c'est-à-dire des tables, des vues, des requêtes, etc.) à des fins différentes telles que l'analyse d'impact ou les tests de non-régression. De même, l'identification des divergences entre deux points de vue d'une table instantanée est très utile pour l'analyse adhoc ou le débogage.
Dans cette optique et pour les praticiens de SQL, un script préconstruit et réutilisable prend tout son sens, d'où l'objet de cet article.
Explication du modèle SQL prêt à l'emploi
Entrons dans le vif du sujet avec la question attendue :
Maintenant, expliquons-le :
Remarque : il est évident qu'il faut disposer de deux ensembles de données avec des champs comparables pour pouvoir utiliser la requête ci-dessus.
Exemple illustré
Assez de théorie, passons à la pratique ! Supposons qu'un supermarché veuille récupérer tous les produits éligibles à une promotion dans un seul tableau en fonction des conditions de la promotion hebdomadaire.
Dans un premier temps, nous considérons que les produits ci-dessous sont en stock :
Selon les conditions de promotion de la semaine 1 :
le dataset_1 est :
Au cours de la deuxième semaine, les conditions de promotion évoluent :
L'évolution du pipeline data génère l'ensemble de données_2 :
Mais... sommes-nous vraiment sûrs des résultats ? Les questions les plus fréquentes sont les suivantes :
Note : même s'il semble facile de répondre intuitivement aux questions ci-dessus en raison d'un exemple trivial sur un petit ensemble de données, dans les cas d'utilisation réels, nous sommes généralement confrontés à de nombreuses lignes et colonnes provenant de requêtes complexes (transformations, jointures, agrégats, fonctions de fenêtres, ...), ce qui donne tout son sens à cette requête.
Essayons de répondre aux 3 questions en interprétant les résultats de la requête de comparaison :
Observations :
Finalement, tout se présente bien :
Conseils et astuces
Dans le CTE, même si vous pouvez copier-coller votre requête SQL d'ingestion avant/après l'évolution, il peut être judicieux de stocker les résultats dans des tables temporaires pour simplifier la comparaison, améliorer les performances de la requête et bénéficier de la mise en cache si vous l'exécutez plusieurs fois.
Dans le monde réel, les divergences entre deux ensembles de données peuvent être désordonnées. Dans ce cas, le tri des résultats par clé (la granularité des ensembles de données) et par drapeau peut grandement faciliter l'interprétation et la comparaison des lignes équivalentes provenant des deux ensembles de données.
Pour faciliter les investigations et identifier l'origine de l'écart, les champs communs des ensembles de données suspects peuvent être supprimés (c'est-à-dire commentés dans l'ETC) de la comparaison : s'il n'y a pas de résultat, cela signifie que tous les champs comparés sont égaux. Vous pouvez alors vous concentrer sur les champs suspects restants pour la prochaine comparaison et l'effectuer étape par étape.
Note : une analyse équivalente aurait pu être effectuée en utilisant la stratégie LEFT JOIN mais aurait été beaucoup plus difficile à maintenir (gestion des NULLs et des comparaisons de champs) et moins efficace car les opérateurs de set sont plus puissants que les jointures.
Résumé
Cette requête modélisée permet donc aux développeurs de valider rapidement les modifications apportées aux pipelines data complexes. Elle est utile en complément des tests unitaires plus traditionnels, et peut même être considérée de manière plus générale lors de la comparaison de deux ensembles de données ayant des structures similaires. Enfin, la logique de cette requête est même facile à apprendre par cœur !
Merci d'avoir lu, j'espère que c'était clair et je serais heureux d'entendre vos commentaires :)
