Eén nummer controleren is een interactie. Vijftigduizend controleren is een batchproces met zijn eigen economie: de kosten per rij moeten klein zijn, de faalwijzen moeten leesbaar zijn zonder dat een mens elke regel leest, en de uitvoer moet goed genoeg zijn zodat iemand er de volgende ochtend mee aan de slag kan.
De verleiding is om de interactieve routine over het bestand te laten lopen en de fouten af te drukken. Dat werkt voor een paar honderd rijen en stort daarna in, want het levert ongedifferentieerde ruis op en verbergt de twee feiten die een beoordelaar werkelijk nodig heeft: welke rijen fout zijn, en op welke manier.
Hoe verschilt bulkvalidatie van het controleren van één waarde?
De verschillen gaan allemaal over wat er na de rekenkunde gebeurt. Een interactieve controle geeft één uitspraak terug aan één persoon die de waarde op het scherm kan zien. Een batchcontrole geeft een uitspraak terug voor elke rij van een bestand dat nog niemand heeft bekeken, en het rapport is het enige dat iemand zal lezen.
Schaal verandert ook de vorm van het werk. Een groot bestand in één keer in het geheugen lezen zal falen bij de grootste invoer, dus de pijplijn moet streamen. Gedeelde voorbereiding voor elke rij opnieuw berekenen verspilt het grootste deel van de looptijd, dus schemaopzoekingen moeten één keer worden opgelost. En dezelfde rij kan twee keer worden verwerkt als een taak opnieuw start, dus de bewerking moet veilig te herhalen zijn.
Ten slotte is het publiek anders. Een batchrapport wordt gelezen door iemand die beslist wat er moet worden gerepareerd, wat betekent dat het geordend, gecategoriseerd en specifiek over de locatie moet zijn. De melding bij één waarde die zegt dat een controlecijfer faalde, is technisch correct en praktisch nutteloos in een bestand met veertigduizend rijen.
Elke waarde waarnaar in dit artikel wordt verwezen wordt beschreven in plaats van geciteerd. Een batchrun over echte data moet zulke waarden maskeren voordat er iets naar een rapport wordt geschreven, en de voorbeelden hier zijn alleen illustratieve vormen.
Eerst opschonen, dan valideren: de pijplijn
De volgorde van bewerkingen is wat de rest van het werk mogelijk maakt, en het is dezelfde volgorde als bij een controle van één veld, alleen per rij toegepast.
- Lees het bestand als tekst en bewaar de originele waarden precies zoals aangeleverd.
- Normaliseer elke waarde — verwijder scheidingstekens, voeg witruimte samen, normaliseer de lettervorm — en bewaar beide vormen.
- Bepaal het schema of de schema’s voor elke rij, op basis van de kolom waar de waarde vandaan kwam en, waar de kolom gemengd is, op basis van de waarde zelf.
- Voer de passende controle uit, of registreer dat er geen regel van toepassing is.
- Wijs elke rij aan een categorie toe en schrijf dan het rapport.
Het hele bestand normaliseren voordat je valideert, betekent dat één codepad zowel de controle als de duplicaatanalyse afhandelt. Het betekent ook dat het rapport beide vormen naast elkaar kan tonen, wat voor een beoordelaar de snelste manier is om een systematisch probleem op te merken, zoals een hele kolom die met een extra scheidingsteken aankomt.
Doe de schemaopzoeking één keer per onderscheiden patroon in plaats van één keer per rij. Een bestand met één soort identificator heeft maar één opzoeking nodig, en zelfs een gemengd bestand bevat meestal een handvol onderscheiden vormen, dus het cachen van de oplossing verandert een kostenpost per rij in een kostenpost per bestand.
Welke categorieën moet een resultatenset bevatten?
De categorieën zijn wat een lijst fouten in een diagnose verandert, en ze moeten overeenkomen met de uitspraken die de validator al produceert in plaats van een nieuw vocabulaire te verzinnen.
| Categorie | Wat ze betekent | Typische oorzaak |
|---|---|---|
| Gecontroleerd en geldig | Het gepubliceerde algoritme is toegepast en het afsluitende teken komt overeen | Echte waarden, of waarden die voor testen zijn gegenereerd |
| Gecontroleerd en ongeldig | Het algoritme is toegepast en het afsluitende teken komt niet overeen | Een typefout in het lichaam of in het afsluitende teken |
| Alleen formaat | De vorm is bevestigd; er is geen algoritme gepubliceerd | Een schema in de middelste dekkingslaag |
| Onbekend schema | Niets dat het hulpmiddel implementeert komt overeen met de vorm | Een gemengde kolom, een losse kopregel, of een waarde uit een ander systeem |
| Duplicaat | De genormaliseerde waarde komt elders in het bestand voor | Hetzelfde record twee keer geëxporteerd |
Duplicaten verdienen hun eigen categorie ook al zijn het geen validatiefouten. In een import zijn ze vaak de meest ingrijpende bevinding, en ze tussen misvormde rijen begraven garandeert dat ze worden gemist.
Houd alleen formaat en onbekend ook gescheiden. Ze leiden tot verschillende acties: een formaat-only-resultaat betekent dat de data zo goed zijn als ze kunnen worden beoordeeld, terwijl een onbekend schema iemand nodig heeft om uit te zoeken wat de kolom werkelijk bevat.
Duplicaten, lege cellen en zeer grote bestanden
Drie gewone situaties veroorzaken het meeste van de moeilijkheid in echte bestanden.
Duplicaten moeten op de genormaliseerde waarde worden gedetecteerd, want twee verschillend geïnterpungeerde kopieën van één nummer zijn hetzelfde nummer. Meld de eerste keer dat iets voorkomt als de locatie en vermeld de andere als verwijzingen, zodat een beoordelaar kan zien of de herhaling toevallig of structureel is.
Lege cellen zijn geen fouten. Een leegte waar een waarde vereist was is een volledigheidsprobleem, en het in de ongeldige categorie stoppen zal het foutenaantal opblazen en iemand op zoek sturen naar een controlecijferbug die niet bestaat. Tel lege cellen apart, en laat de afnemer beslissen of ze aanvaardbaar zijn.
Grote bestanden vereisen streaming en een stabiel geheugenprofiel. Lees rij voor rij, houd alleen de deduplicatie-index en de tellers bij, en schrijf rapportrijen in batches weg zodat de uitvoer niet de flessenhals wordt. Als de deduplicatie-index zelf groter wordt dan het geheugen, val dan terug op een gesorteerde externe samenvoeging of een tijdelijke opslag in plaats van te proberen alles tegelijk vast te houden.
Wat maakt een rapport bruikbaar?
Een beoordelaar om negen uur ’s ochtends heeft vier dingen nodig van de uitvoer: het rijnummer, de waarde zoals ze aankwam, de categorie en een korte reden. Al het andere is versiering.
Rijnummers moeten verwijzen naar iets dat de beoordelaar kan vinden. Zeg ronduit of het bestandsregels of datarijen zijn, want een kopregel verschuift ze met één en een beoordelaar die de verkeerde conventie vertrouwt, bewerkt het verkeerde record. Neem de originele waarde precies zoals aangeleverd op, want dat is wat hij zal zoeken, en neem de genormaliseerde vorm op wanneer die verschilt.
Orde doet er ook toe. Groeperen op categorie zet elke keer dat één probleem voorkomt bij elkaar, wat een beoordelaar een patroon laat herkennen in plaats van veertigduizend regels te lezen. Sorteer binnen een categorie op rij zodat het bestand van boven naar beneden kan worden bewerkt.
Maak de samenvatting ten slotte eerlijk. Een aantal geldige rijen moet zeggen welke uitspraak het heeft opgeleverd, want een bestand waarin de meeste rijen alleen formaat zijn, is alleen in vorm bevestigd, en een samenvatting die ze als geldig rapporteert, zal uit zijn verband worden geciteerd.
Voor ontwikkelaars: chunking, gelijktijdigheid en idempotentie
De batchlaag is waar een werkend script een betrouwbare taak wordt.
- Verwerk in blokken die op geheugen zijn afgestemd in plaats van op ronde getallen, en maak de blokgrootte configureerbaar.
- Paralleliseer de rekenkunde, niet de uitvoer. Elke werker moet resultaten teruggeven, en één enkele schrijver moet het rapport samenstellen zodat de ordening deterministisch blijft.
- Maak de run idempotent: hetzelfde invoerbestand moet dezelfde uitvoer opleveren, inclusief ordening, zodat twee runs kunnen worden vergeleken.
- Registreer de versie van de regelset en de checksum van de invoer in de kop van het rapport, zodat een resultaat maanden later kan worden gereproduceerd.
- Schrijf nooit volledige waarden in logs. Rapporten zijn bestemmingen voor waarden, logs niet, en de maskeerregel moet worden toegepast voordat er iets het proces verlaat.
Maskeren is niet optioneel wanneer het bestand echte waarden bevat. Een batchrun leest alles in één keer, dus één niet-gemaskeerd rapport is een veel grotere blootstelling dan één mislukte formulierinzending. Beslis vóór de eerste run welke kolommen mogen worden weergegeven en welke moeten worden afgekapt. De link tussen een batchrun en de API die hem voedt is het volgende lezen waard: validatie op API-grenzen behandelt wat de ontvangende service moet doen wanneer het bestand aankomt, en hoe nummervalidatie werkt is de logica per rij waarop deze pijplijn is gebouwd.
Volgende stappen
Draai je huidige proces over een bestand dat bewust één van elke categorie bevat — een geldige rij, een ongeldige rij, een formaat-only-rij, een onbekende vorm en een duplicaat — en ga na of het rapport alle vijf duidelijk maakt zonder het bronbestand te openen. De nummervalidatietool is een handige plek om de tekst van elke uitspraak te bevestigen voordat je die in het rapportformaat vastlegt.