Vérifier un seul numéro est une interaction. En vérifier cinquante mille est un processus par lots avec sa propre économie : le coût par ligne doit être faible, les modes de défaillance doivent être lisibles sans qu’un humain lise chaque ligne, et la sortie doit être assez bonne pour que quelqu’un puisse agir dès le lendemain matin.
La tentation est de faire tourner en boucle sur le fichier la routine interactive et d’imprimer les échecs. Cela fonctionne pour quelques centaines de lignes puis s’effondre, car cela produit un bruit indifférencié et masque les deux faits dont un relecteur a réellement besoin : quelles lignes sont fausses, et de quelle manière.
En quoi la validation en masse diffère-t-elle de la vérification d’une seule valeur ?
Les différences tiennent toutes à ce qui se passe après l’arithmétique. Un contrôle interactif renvoie un verdict à une personne qui peut voir la valeur à l’écran. Un contrôle par lots renvoie un verdict pour chaque ligne d’un fichier que personne n’a encore regardé, et le rapport est la seule chose que quiconque lira.
L’échelle change aussi la forme du travail. Lire un grand fichier en mémoire d’un coup échouera sur les entrées les plus volumineuses, si bien que le pipeline doit fonctionner en flux. Recalculer une préparation partagée pour chaque ligne gaspille la majeure partie du temps d’exécution, donc les recherches de schéma devraient être résolues une seule fois. Et la même ligne peut être traitée deux fois si une tâche redémarre, donc l’opération doit pouvoir être répétée sans danger.
Enfin, le public est différent. Un rapport par lots est lu par quelqu’un qui décide quoi corriger, ce qui signifie qu’il doit être ordonné, catégorisé et précis quant à l’emplacement. Le message à valeur unique qui dit qu’un chiffre de contrôle a échoué est techniquement correct et pratiquement inutile dans un fichier de quarante mille lignes.
Chaque valeur citée dans cet article est décrite plutôt que reproduite. Une exécution par lots sur des données réelles devrait voir ces valeurs masquées avant que quoi que ce soit ne soit écrit dans un rapport, et les exemples ici ne sont que des formes illustratives.
Nettoyer d’abord, valider ensuite : le pipeline
L’ordre des opérations est ce qui rend le reste du travail possible, et c’est le même ordre que dans une vérification à champ unique, appliqué ligne par ligne.
- Lisez le fichier sous forme de texte, en conservant les valeurs d’origine exactement telles que fournies.
- Normalisez chaque valeur — retirez les séparateurs, réduisez les espaces, pliez la casse — et conservez les deux formes.
- Résolvez le ou les schémas de chaque ligne, en fonction de la colonne d’où vient la valeur et, lorsque la colonne est mixte, de la valeur elle-même.
- Exécutez le contrôle approprié, ou consignez qu’aucune règle ne s’applique.
- Attribuez chaque ligne à une catégorie, puis écrivez le rapport.
Normaliser tout le fichier avant de valider signifie qu’un seul chemin de code gère à la fois le contrôle et l’analyse des doublons. Cela signifie aussi que le rapport peut montrer les deux formes côte à côte, ce qui est le moyen le plus rapide pour un relecteur de repérer un problème systématique tel qu’une colonne entière arrivant avec un séparateur supplémentaire.
Faites la résolution du schéma une fois par motif distinct plutôt qu’une fois par ligne. Un fichier d’un seul type d’identifiant n’a besoin que d’une recherche, et même un fichier mixte ne contient généralement qu’une poignée de formes distinctes, si bien que mettre en cache la résolution transforme un coût par ligne en un coût par fichier.
Quelles catégories un jeu de résultats doit-il contenir ?
Les catégories sont ce qui transforme une liste d’échecs en diagnostic, et elles doivent correspondre aux verdicts que le validateur produit déjà plutôt que d’inventer un nouveau vocabulaire.
| Catégorie | Ce qu’elle signifie | Cause typique |
|---|---|---|
| Vérifié et valide | L’algorithme publié a été appliqué et le caractère final correspond | Des valeurs authentiques, ou des valeurs générées pour les tests |
| Vérifié et invalide | L’algorithme a été appliqué et le caractère final ne correspond pas | Une faute de frappe dans le corps ou dans le caractère final |
| Format uniquement | La forme a été confirmée ; aucun algorithme n’est publié | Un schéma du niveau de couverture intermédiaire |
| Schéma inconnu | Rien de ce que l’outil implémente ne correspond à la forme | Une colonne mixte, un en-tête parasite, ou une valeur venue d’un autre système |
| Doublon | La valeur normalisée apparaît ailleurs dans le fichier | Le même enregistrement exporté deux fois |
Les doublons méritent leur propre catégorie même s’ils ne sont pas des échecs de validation. Dans un import, ils sont souvent la constatation la plus lourde de conséquences, et les enfouir parmi des lignes mal formées garantit qu’ils passeront inaperçus.
Gardez aussi « format uniquement » et « inconnu » séparés. Ils mènent à des actions différentes : un résultat uniquement formel signifie que les données sont aussi bonnes qu’on peut en juger, tandis qu’un schéma inconnu nécessite que quelqu’un découvre ce que contient réellement la colonne.
Doublons, cellules vides et fichiers très volumineux
Trois situations ordinaires expliquent la majeure partie de la difficulté des fichiers réels.
Les doublons doivent être détectés sur la valeur normalisée, car deux copies d’un même numéro ponctuées différemment sont le même numéro. Signalez la première occurrence comme emplacement et listez les autres comme références, afin qu’un relecteur puisse voir si la répétition est accidentelle ou structurelle.
Les cellules vides ne sont pas des échecs. Un blanc là où une valeur était requise est un problème de complétude, et le fondre dans la catégorie « invalide » gonflera le nombre d’erreurs et enverra quelqu’un chercher un bogue de chiffre de contrôle qui n’existe pas. Comptez les blancs séparément, et laissez le consommateur décider s’ils sont acceptables.
Les fichiers volumineux nécessitent un traitement en flux et un profil de mémoire stable. Lisez ligne par ligne, ne conservez que l’index de déduplication et les compteurs, et videz les lignes de rapport par lots afin que la sortie ne devienne pas le goulot d’étranglement. Si l’index de déduplication lui-même dépasse la mémoire, revenez à une fusion externe triée ou à un stockage temporaire plutôt que d’essayer de tout garder en mémoire d’un coup.
Ce qui rend un rapport exploitable
Un relecteur à neuf heures du matin a besoin de quatre choses de la sortie : le numéro de ligne, la valeur telle qu’elle est arrivée, la catégorie et une raison courte. Tout le reste est de la décoration.
Les numéros de ligne doivent renvoyer à quelque chose que le relecteur peut trouver. Dites clairement s’il s’agit de lignes du fichier ou de lignes de données, car un en-tête les décale d’un rang et un relecteur qui se fie à la mauvaise convention modifiera le mauvais enregistrement. Incluez la valeur d’origine exactement telle que fournie, car c’est ce qu’il recherchera, et incluez la forme normalisée lorsqu’elle diffère.
L’ordre compte aussi. Regrouper par catégorie place chaque occurrence d’un même problème ensemble, ce qui permet à un relecteur de reconnaître un motif au lieu de lire quarante mille lignes. À l’intérieur d’une catégorie, triez par ligne afin que le fichier puisse être corrigé de haut en bas.
Enfin, rendez le résumé honnête. Un décompte de lignes valides doit dire quel verdict l’a produit, car un fichier où la plupart des lignes sont uniquement formelles n’a été confirmé que dans sa forme, et un résumé qui les présente comme valides sera cité hors contexte.
Pour les développeurs : découpage, concurrence et idempotence
La couche de traitement par lots est l’endroit où un script qui fonctionne devient une tâche fiable.
- Traitez par blocs dimensionnés selon la mémoire plutôt que selon des nombres ronds, et rendez la taille des blocs configurable.
- Parallélisez l’arithmétique, pas la sortie. Chaque travailleur doit renvoyer des résultats, et un unique rédacteur doit assembler le rapport afin que l’ordre reste déterministe.
- Rendez l’exécution idempotente : le même fichier d’entrée doit produire la même sortie, ordre compris, afin que deux exécutions puissent être comparées.
- Consignez la version de l’ensemble de règles et la somme de contrôle de l’entrée dans l’en-tête du rapport, afin qu’un résultat puisse être reproduit des mois plus tard.
- N’écrivez jamais de valeurs complètes dans les journaux. Les rapports sont des destinations pour les valeurs, les journaux ne le sont pas, et la règle de masquage doit être appliquée avant que quoi que ce soit ne quitte le processus.
Le masquage n’est pas facultatif lorsque le fichier contient des valeurs réelles. Une exécution par lots lit tout d’un coup, si bien qu’un seul rapport non expurgé représente une exposition bien plus importante qu’une seule soumission de formulaire échouée. Décidez avant la première exécution quelles colonnes peuvent être reproduites et lesquelles doivent être tronquées. Le lien entre une exécution par lots et l’API qui l’alimente mérite d’être lu ensuite : la validation aux frontières d’API traite de ce que le service récepteur doit faire à l’arrivée du fichier, et comment fonctionne la validation de numéros est la logique par ligne sur laquelle ce pipeline est bâti.
Étapes suivantes
Exécutez votre processus actuel sur un fichier contenant délibérément un exemple de chaque catégorie — une ligne valide, une ligne invalide, une ligne uniquement formelle, une forme inconnue et un doublon — et vérifiez si le rapport rend les cinq évidentes sans ouvrir le fichier source. L’outil de validation de numéros est un endroit commode pour confirmer le libellé de chaque verdict avant de le fixer dans le format du rapport.