Controles bij de poort

Laatst ben ik weer tegen een data warehouse aangelopen, waar zeer veel issues spelen met betrekking tot de kwaliteit van de brondata. Verkeerde bestanden aangeleverd of wijzigingen in masterdata of domeinen, issues waarmee processen stuklopen of – erger – foutieve data wordt ingelezen. De gevolgen voor de eindgebruikers zijn soms desastreus en het analyseren en herstellen van dit soort situaties kost enorm veel inspanning.

Problemen in de brondata zijn een normaal fenomeen voor data warehouses. Wat we ook in Gegevens Leverings Overeenkomsten vastleggen, fouten gebeuren. Veel data warehouses lezen meer dan honderd bestanden in, waarvan enkele tientallen dagelijks. Zelfs als maar in een procent van de gevallen een fout optreedt in de brondata, heb je er dus maandelijks meerdere keren mee te maken. Niets bijzonders dus.

Veel data warehouse-teams hanteren dan de quote "garbage in is garbage out" als excuus om de verantwoordelijkheid voor data kwaliteit exclusief bij de aanleverende partij te leggen. Ze bedoelen daarmee dat, als er foutieve brondata wordt geleverd, zij ook niet kunnen helpen dat het data warehouse foute resultaten oplevert. Zij zijn tenslotte slechts de verwerkers. Degene die daar nog mee weg denkt te komen zou standrechtelijk uit zijn ambt gezet moeten worden. Alsof de kok zonder meer bedorven ingrediënten in je voedsel mag stoppen, met het argument dat "hij slechts transformeert wat hem wordt aangeleverd". Had de leverancier maar op moeten letten… Je zult niet veel Michelin sterren halen met zo'n instelling.

Nee, als data warehouse team heb je de verantwoordelijkheid te doen wat je kunt doen om data kwaliteit te garanderen. En je kunt heel veel doen. Elk ETL-proces moet daarom het principe van controle bij de poort toepassen. Dit houdt in dat voor elk bestand dat wordt aangevelerd of ingelezen, een controleproces wordt geïmplementeerd dat de kwaliteit van het bronbestand controleert voordat het verder wordt verwerkt.

Typische controles hierin kunnen zijn:

• Bestandstructuur (veldlengtes, scheidingstekens et cetera)
• Basis domeincontroles ("veld bevat alleen M, V of O"), eventueel tegen lookup-tabellen
• Aantallen, op basis van header/footer records en/of hashtotalen
• Aantallen, op basis van verwachting of historische aantallen
• Eventueel verbandscontroles en relationele integriteit tegen andere bestanden

Op basis van de uitkomst van een controle kan een waarschuwing gegenereerd worden, of zelfs een afwijzing van het bestand (waarbij het proces stopt) als de business rule dat specificeert.

Het bouwen van een dergelijk controleproces is niet veel werk, zeker niet als de bestandsspecificaties goed zijn gedocumenteerd. Het levert in mijn ervaring enorm veel op, zowel tijdens ontwikkel/testfases (zeker als met real-life data ontwikkeld wordt: de werkelijkheid blijkt nog al eens af te wijken van de specificatie) als tijdens productie. Je voorkomt dat foutieve bestanden ver het proces inkomen. Als er wijzigingen optreden in de bronbestanden, die men "vergeten" is door te geven, dan wordt het proces vroegtijdig gestopt en vindt een snelle signaalfunctie plaats.

Het controleproces kan tevens registratie verzorgen van de ontvangen bestanden: welk bestand is wanneer ontvangen, hoeveel records zaten er in en zijn er afwijkingen in gevonden? Nog iets geavanceerder kunnen onderlinge afhankelijkheden tussen bestandsleveringen worden bijgehouden (maandbestand X kan pas worden verwerkt als alle dagbestanden Y van de voorliggende maand zijn ontvangen en verwerkt), op basis waarvan ETL processen kunnen worden gestart (start als bestand X is ontvangen en de processen die Y verwerken succesvol zijn afgerond).

De "trigger" van het controleproces zou de bestandsontvangst moeten zijn (ik ga voor het gemak uit van push, maar vergelijkbaar kan natuurlijk ook met pull). De reden hiervoor is dat er soms een periode (enkele uren of soms zelfs dagen) tussen het moment van ontvangst en verwerken kan zitten. Door bij ontvangst te controleren worden fouten sneller gesignaleerd en wellicht al opgelost zonder de productierun te vertragen.

Uiteraard is niet elke bronfout hiermee op te lossen, een transactie die aan de verkeerde klant is gekoppeld sporen we hier niet mee op. En uiteraard blijft de leverancier primair verantwoordelijk voor de kwaliteit van zijn data, dit kun je als data warehouse gewoon niet overnemen. Maar we voorkomen wel de domme fouten: de fouten die voorkomen hadden kunnen worden door simpele controles.

Voordat de kok de ingrediënten in de pan doet, kijkt, voelt en ruikt hij er even aan. Natuurlijk gaat hij er van uit dat de leverancier dat ook gedaan heeft en -net als altijd- kwalitatief goede spullen levert. Maar hij weet ook dat de gevolgen van een fout zeer groot kunnen zijn en hij wil achteraf niet het verwijt krijgen dat hij had kunnen weten dat hij met bedorven waar werkte.

Als dit betoog voor de lezer een open deur is: gefeliciteerd, het data warehouse is bij jou in goede handen. Maar aan de praktijkcases te zien, met functioneel beheerteams die met het zweet op het voorhoofd tot diep in de avond bezig zijn de gevolgen van foute brondata te herstellen, zijn we nog niet allemaal overtuigd.

Hebben jullie nog aanvullende ideeën of praktijkvoorbeelden?