Comment assurer la qualité des données de l'entrepôt de données ?

Youzan Data Report Center fournit aux commerçants des indicateurs de données riches, y compris plus de 30 pages, plus de 100 rapports de données et plus de 400 types d'indicateurs de données différents, qui aident les commerçants à exploiter les magasins de manière plus rationnelle et scientifique, et fournissent également directement des méthodes d'analyse et de prise de décision. Utilisation commerciale. De plus, les tâches de bas niveau et les tables de données impliquées dans l'exécution quotidienne ont atteint des milliers de niveaux.

Face à un tel système de données, comment formuler une stratégie d'assurance qualité en guise de test ? Cet article commencera par quatre aspects : 1. Liaison de données Youzan, 2. Test de la couche de données, 3. Test de la couche d'application et 4. Planification du suivi.

1. Liaison de données Youzan

1. Présentation de la liaison de données

Tout d'abord, je vais présenter le schéma de structure de données global de Youzan :

De haut en bas, il peut être grossièrement divisé en couche de service d'application, couche de passerelle de données, couche de stockage d'application et entrepôt de données.Des plates-formes telles que le développement de tâches et la gestion des métadonnées fournissent des fonctionnalités de base pour le calcul des données, la planification des tâches et la requête de données.

Ce qui précède a fait une introduction préliminaire à l'architecture globale.Pour le contrôle de la qualité, les deux parties principales sont : l' entrepôt de données et la partie application de données . Étant donné que ces deux parties appartiennent aux liens principaux de la liaison de données, par rapport aux autres niveaux, les changements quotidiens sont plus fréquents et le risque de problèmes est également relativement important.

Deuxièmement, le test de la couche de données

1. Aperçu général

Premièrement, l'assurance qualité de la couche de données peut être divisée en trois aspects : actualité, intégrité et précision des données.

2. Actualité des données

L'actualité des données, comme son nom l'indique, signifie que les données de test doivent être produites à temps. Les trois éléments clés de la ponctualité sont : le temps de planification, la priorité et la date limite des données . La priorité de la tâche détermine la quantité de ressources informatiques de données qu'elle obtient et affecte le temps d'exécution de la tâche. La date limite des données est une norme unifiée pour la dernière heure de sortie des données, qui doit être strictement respectée.

Parmi ces trois éléments, celui qui appartient à la « règle universelle » et sur lequel il faut se concentrer dans l'étape d'assurance qualité est la date limite des données. Ensuite, en fonction de l'échéance des données, les stratégies de garantie d'actualité peuvent être divisées en deux types :

Surveille si la tâche de données hors ligne est terminée. Cette méthode s'appuie sur la surveillance et l'alarme de la plate-forme de développement d'emploi Youzan. Si la tâche de données n'est pas terminée à la date limite, il y aura des alarmes sous forme d'e-mail, de micro d'entreprise, de téléphone, etc. pour avertir le personnel correspondant.

Vérifiez le nombre d'entrées de table complètes ou vérifiez le nombre d'entrées de partition. Cette méthode s'appuie sur la plate-forme d'automatisation de l'interface. En appelant l'interface dubbo, il est déterminé si l'index de données renvoyé par l'interface est 0 et si les données de surveillance sont sorties.

Deuxièmement, nous pouvons prêter attention au nombre d'échecs et de tentatives.Lorsque la situation anormale d'échecs et de tentatives multiples se produit pendant l'exécution de la tâche, une alarme peut être déclenchée pour que le personnel concerné puisse s'en apercevoir. Cette partie de l'alarme est un complément à l'alarme d'échéance, et il existe également une intégration de fonction sur la plateforme de développement d'emplois Youzan.

3. Intégrité des données

L'intégrité des données, comme son nom l'indique, dépend du fait que les données sont complètes ou non, et se concentre sur deux points : pas beaucoup de données et pas beaucoup de données.

Il n'y a pas beaucoup de données : vérifiez généralement les données complètes de la table et les valeurs d'énumération importantes pour voir si les données sont redondantes, dupliquées ou si la clé primaire des données est unique.
Il y a beaucoup de données : vérifiez généralement les données complètes de la table, les champs importants (tels que les champs de clé primaire, les valeurs d'énumération, les dates, etc.) pour voir si la valeur du champ est vide, nulle, etc.

On peut voir que la corrélation entre l'intégrité des données et l'entreprise elle-même n'est pas si étroite, et plus est la vérification générale du contenu de la table de l'entrepôt de données. Ainsi, à partir de certaines dimensions de base, nous pouvons diviser le focus du test en deux directions : au niveau de la table et au niveau du champ.

Intégrité au niveau de la table :

Pour la dimension du tableau complet, en vérifiant le nombre total de lignes/taille du tableau de l'ensemble du tableau, si le nombre total de lignes/taille totale du tableau reste inchangé ou a diminué, cela indique qu'il peut y avoir un problème avec les données du tableau .
Pour la dimension de partition, vous pouvez vérifier le nombre/la taille des lignes de données dans la table partitionnée le jour en cours. Si la différence est trop importante (plus grande ou plus petite) par rapport à la partition précédente, il peut y avoir un problème avec les données de la table .

À l'heure actuelle, la plate-forme de gestion des métadonnées Youzan a intégré des vues de données connexes :

Intégrité au niveau du champ :

Jugement d'unicité : pour garantir l'unicité de la clé primaire ou de certains champs, afin d'éviter la duplication et le doublement des données après la jonction avec d'autres tables, ce qui entraîne des statistiques finales importantes.

Par exemple, pour déterminer si le numéro de commande dans la table de commande de la couche ods est unique, écrivez sql :

select 
count(order_no)
,count(distinct order_no) 
from ods.xx_order

Si les deux sont égaux, cela signifie que la valeur order_no est unique dans la table ; sinon, cela signifie que la valeur order_no n'est pas unique dans la table et qu'il y a un problème avec les données de la table.

Jugement non vide : assurez-vous que les champs importants ne sont pas vides pour éviter la perte de données après une jointure de données et de tables vides, ce qui entraîne moins de statistiques finales.

Par exemple, pour déterminer si le numéro de commande dans la table de commande de la couche ods est nul, écrivez sql :

select 
count(*) 
from ods.xx_order 
where order_no is null

Si le résultat est égal à 0, cela signifie qu'il n'y a pas de valeur nulle dans order_no ; si le résultat est supérieur à 0, cela signifie qu'il y a une valeur nulle dans order_no et qu'il y a un problème avec les données de la table.

Jugement du type d'énumération : assurez-vous que les valeurs des champs d'énumération se situent dans la plage attendue pour éviter que les données commerciales ne soient modifiées, ce qui entraînerait des types de données manquants/superflus dans les résultats statistiques finaux.

Par exemple, pour juger si toutes les valeurs d'énumération du champ shop_type de la table de commande de la couche ods répondent aux attentes, écrivez sql :

select shop_type from ods.xx_order group by shop_type

Analysez si les résultats de la requête répondent aux attentes pour vous assurer qu'il n'y a pas de types d'énumération manquants/redondants.

Jugement de la validité des données : juger si le format des données répond aux attentes et empêcher le format de données incorrect du champ de provoquer des erreurs et des statistiques de données manquantes. Les plus courants sont les formats de date yyyymmdd.

Une fois qu'un problème d'intégrité des données survient, il a un impact important sur la qualité des données. Par conséquent, la stratégie d'intégrité est plus adaptée à la couche ods, car nous nous attendons à trouver et à résoudre le problème des données déraisonnables à partir de la source, à arrêter la perte de temps et à éviter l'expansion de la pollution des données après l'entrée de données sales dans l'aval.

De plus, nous voyons que la logique du contenu du contrôle d'intégrité est simple et relativement fixe, et qu'elle peut être modélisée avec une petite abstraction simple. Ensuite, à titre de test, nous sommes plus enclins à faire des outils de vérification de l'intégrité des données. À l'heure actuelle, Youzan "Data Shape Tool" a été implémenté. Voici quelques-unes de mes idées :

Pour toutes les tables, règles universelles, telles que l'unicité de la clé primaire de la table.
Pour différents types tels que les types de format numérique, de chaîne, d'énumération et de date, des règles de jugement de données courantes sont répertoriées.
Classez chaque règle. Par exemple, si la clé primaire d'une table n'est pas unique, enregistrez-la comme critique. La proportion de valeurs nulles dans les champs de type String est supérieure à 70 %, ce qui est enregistré comme avertissement.
Selon que les données du tableau répondent ou non aux règles ci-dessus, un rapport visuel est finalement mis en œuvre et les testeurs peuvent évaluer la qualité des données en fonction du contenu du rapport.

4. Exactitude des données

Exactitude des données, comme son nom l'indique, les données doivent être "exactes". Le concept de "précision" est relativement abstrait, car il nous est difficile d'utiliser un jugement logique fort pour expliquer la précision des données, et la plupart d'entre elles existent dans la cognition perceptive. Par conséquent, les tests d'exactitude sont également une direction dans laquelle la réflexion est relativement divergente dans le processus d'assurance qualité des données.

Après avoir résumé, nous pouvons contrôler l'exactitude des données à partir des aspects de l'auto-vérification sur le terrain, de la comparaison horizontale des données, de la comparaison verticale, de la révision du code, etc. Ces points de test sont également étroitement liés à l'entreprise.

4.1 Autocontrôle

L'auto-vérification des données consiste à vérifier l'exactitude des données avec ses propres données sans les comparer avec d'autres données, ce qui est le type de vérification le plus élémentaire. Les auto-vérifications courantes incluent : vérifier que l'indice numérique est supérieur à 0 et que l'indice de rapport est compris entre 0 et 1. Ces règles de base, comme l'intégrité des données, peuvent également être combinées avec des "outils de mise en forme des données" pour faciliter les tests.

Par exemple, pour la table des commandes, le montant du paiement doit être supérieur ou égal à 0, et il n'y aura pas de nombres négatifs.

select 
count(pay_price) 
from 
dw.dws_xx_order 
where par = 20211025 and pay_price<0

Si le résultat est 0, cela signifie que le montant du paiement est supérieur à 0, ce qui correspond aux attentes ; sinon, si le résultat du comptage est supérieur à 0, cela signifie qu'il y a un problème avec les données.

4.2 Comparaison horizontale des données dans le tableau

La comparaison horizontale dans une table peut être comprise comme deux champs ou plus dans la même table qui sont liés à l'entreprise, et ils ont une certaine relation logique, de sorte qu'ils peuvent être utilisés pour la comparaison de données.

Par exemple, pour la table des commandes, selon l'analyse commerciale réelle, il est facile d'obtenir : pour n'importe quel produit dans n'importe quel magasin, le nombre de commandes >= le nombre de personnes qui passent des commandes, écrivez sql :

select 
kdt_id
,goods_id
,count(order_no)
,count(distinct buyer_id) 
from dw.dws_xx_order
where par = '20211025'
group by kdt_id,goods_id
having count(order_no)<count(distinct buyer_id)

S'il n'y a pas d'enregistrement dans le résultat de la requête, cela signifie qu'il n'y a pas de nombre de commandes<nombre de commandes passées, et l'inverse signifie que le nombre de commandes>=nombre de commandes passées, ce qui est conforme aux attentes ; sinon, si l'enregistrement dans le résultat de la requête est supérieur à 0, il n'est pas conforme aux attentes.

4.3 Comparaison horizontale des données entre les tableaux

La comparaison horizontale entre les tables peut être comprise comme deux tables ou plus avec des champs avec des associations professionnelles ou la même signification commerciale, qui peuvent être utilisées pour la comparaison de données :

Comparaison entre tables du même type : Pour la table de paiement A et la table de paiement B dans la ruche, il y a des champs de montant de paiement dans celles-ci, puis la table A. montant de paiement sous la même dimension = table B. montant de paiement.
Comparaison entre plusieurs ensembles de stockage : par exemple, le centre de rapport de données Youzan utilise mysql et kylin pour la table de paiement, et le stockage de la couche d'application utilise respectivement mysql et kylin, qui sont utilisés pour le commutateur maître-veille, puis la table kylin A .Montant du paiement sous la même dimension = mysql-table B .Montant du paiement.
Comparaison entre plusieurs systèmes : entre les systèmes, tels que le centre de rapport de données et le système crm, les deux systèmes ont des données d'indicateur client, puis le centre de rapport de données sous la même dimension - tableau A. indicateurs client = crm - tableau B. Métriques client.

Nous analysons en profondeur la logique sous-jacente de la comparaison horizontale des données. L'essentiel est de comparer les différents champs des deux tables et de comparer les opérateurs logiques, ce qui est également plus facile à résumer dans un outil. À l'heure actuelle, "l'outil de comparaison de données" de Youzan a été implémenté. Voici quelques-unes de mes idées :

Entrez deux tables et définissez les clés primaires des deux tables respectivement.
Entrez les champs à comparer dans les deux tables et définissez les opérateurs de comparaison, tels que >, =, <.
Selon les règles définies, les données finales sont comparées aux enregistrements de réussite et d'échec, et un rapport visuel est mis en œuvre, et le testeur peut évaluer la qualité des données en fonction du contenu du rapport.

4.4 Comparaison des données longitudinales

La comparaison longitudinale est la comparaison des données en amont et en aval, le but est de s'assurer qu'il n'y a pas de problèmes dans le traitement en amont et en aval des champs importants.

Par exemple, la couche dw de l'entrepôt de données a une liste détaillée des commandes et la couche dm du produit de données a un tableau agrégé du nombre de commandes, de sorte que les résultats statistiques des deux données sous la même dimension doivent être cohérents.

4.5 revue de code

Tout d'abord, dans l'étape de revue des exigences avant la revue de code, nous devons d'abord clarifier le calibre détaillé des statistiques de données.Voici deux exemples d'exigences réelles.

Exigence 1 : (exemple d'erreur) Le montant du paiement de tous les utilisateurs du magasin pendant la période statistique. Le problème est le suivant : la description des exigences est trop succincte, et la dimension temporelle et les conditions de filtrage des statistiques de données ne sont pas clairement expliquées, ce qui entraîne un calibre statistique peu clair, nécessitant que les produits aient un calibre clair.
Exigence 2 : (Exemple correct) Il existe un montant de paiement hors ligne dans la dimension de la boutique de domaine du marchand du réseau entier Zan. Prend en charge les jours naturels, les semaines naturelles et les mois naturels. Au cours de la période statistique, la somme de tous les ordres de paiement (hors tirage au sort, cartes cadeaux et commandes de fournitures de distribution).

Après avoir clarifié les exigences, certaines préoccupations courantes de la révision du code sont décrites en détail ci-dessous :

1) Relation d'association et conditions de filtrage

Que la table associée utilise une jointure externe ou une jointure dépend si les données doivent être filtrées.
Dans la clause on de la relation d'association, si les types de valeur gauche et droite sont cohérents.
Si la relation d'association est 1:1, alors si les clés d'association des deux tables sont uniques. Si elle n'est pas unique, l'association produira alors un cartésien entraînant un gonflement des données.
Si la condition where est correctement filtrée, en prenant les exigences ci-dessus comme exemple, faites attention à ce que le groupe de loterie, la carte-cadeau et la commande de distribution soient correctement exclus dans SQL.

2) Traitement de calibre statistique des indicateurs

Les statistiques des indicateurs de données impliquent deux concepts de base :

Indicateurs cumulatifs : tels que le montant du paiement, les pages vues, etc., indicateurs qui peuvent être comptés en ajoutant simplement des valeurs numériques.Pour de tels indicateurs, la fonction utilisée en sql est généralement la somme.
Indicateurs non cumulatifs : par exemple, le nombre de visiteurs ne peut pas être simplement additionné, mais doit être dédupliqué puis additionné pour les statistiques. Pour de tels indicateurs, count(distinct) est généralement utilisé en SQL.

3) insérer insérer des données

Que ce soit pour prendre en charge la réexécution. Cela équivaut à voir s'il existe un mot-clé de remplacement lors de l'insertion. Si ce mot-clé n'existe pas, les données modifiées ne seront pas écrasées lors de la réexécution des données (le flux de travail est exécuté plusieurs fois), mais les données seront insérées de manière incrémentielle dans le tableau, qui peut conduire au résultat final. Les statistiques ont doublé.
Si l'ordre des données insérées est exactement le même que l'ordre de la structure de table insérée. Nous devons nous assurer qu'il n'y a pas d'erreur dans l'ordre d'écriture des champs de données, sinon les valeurs insérées seront chaotiques.

3. Test de la couche application

1. Aperçu général

Le test de base de la page frontale + interface côté serveur est le même que celui des tests commerciaux généraux et ne sera pas répété ici. Cet article se concentre sur les domaines où les tests "d'application de données" nécessitent une attention supplémentaire.

2. Stratégie de rétrogradation

Lors de l'ajout d'une nouvelle fiche technique sur la page, il est nécessaire de confirmer si la fonction "barre bleue" doit être prise en charge dans l'étape des exigences et de l'examen technique, qui appartient au "test de décalage à gauche".

Introduction de la barre bleue : Il y a une barre bleue en haut de la page où Youzan informe le commerçant que les données hors ligne n'ont pas encore été produites, et le "temps de production" = temps d'accès actuel + 2 heures, qui est calculé dynamiquement.

Lorsque vous testez des indicateurs de type ratio, concentrez-vous sur le cas particulier où dividende = 0. Faites attention à ce point lors des étapes de révision du code back-end et de la fonction de page de test. À l'heure actuelle, il y a des éloges pour cette situation, et l'affichage unifié frontal est "-".

3. Stratégie active/veille

Lorsqu'il existe une stratégie de commutation active/en veille, veuillez noter que les données sont normalement écrites en double pendant le test, et grâce à la configuration, vous pouvez basculer entre les sources de données actives et en veille lors de la récupération des données.

4. Sécurité des données

Faites attention à la gestion des autorisations et au contrôle de la requête de données, et concentrez-vous sur le test des scénarios d'ultra-autorité horizontale et verticale.

4. Planification du suivi

À l'heure actuelle, dans la comparaison de l'exactitude des données de projets réels, l'outil de comparaison de données ne peut remplacer que 50 % des tests manuels car il ne prend pas en charge les fonctions SQL pour le moment. Certaines comparaisons de données horizontales et verticales complexes nécessitent encore d'écrire du SQL. Le plan de suivi prend en charge les fonctions SQL telles que la somme, le compte, le max, le min, etc., ce qui augmente la couverture des outils à plus de 75 % et réduit considérablement le coût de la comparaison des données.

À l'heure actuelle, "Rapport de formulaire de données" et "Outil de comparaison de données" sont utilisés dans davantage de tests de projet. Dans le plan de suivi, l'inspection du formulaire et la comparaison des données seront transformées en inspections en ligne, et les outils d'automatisation et de données seront combinés assurer en permanence la qualité de la table de l'entrepôt de données. .

À l'heure actuelle, la méthode de révision du code SQL repose principalement sur le travail manuel. Nous prévoyons d'effectuer certaines vérifications SQL de base, telles que l'insertion dans le contrôle, la vérification de l'unicité de la jointure sous condition, la vérification de l'ordre d'insertion des champs, etc., dans l'analyse statique SQL et intégrez-les dans le service de test de données volumineuses et responsabilisez d'autres secteurs d'activité.