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?
Stefan,
Ongelooflijk dat je nog een lans moet breken voor controles op dit niveau! Je zegt dat de technische controles niet veel tijd kosten, maar eigenlijk kosten ze vaak helemaal geen tijd. Je krijgt ze gratis bij de ETL-tool of DB. Die kunnen vaak niet tegen afwijkende formaten en dumpen. Je moet dus extra functionaliteit bouwen om het verwerken van bestanden te laten doorgaan. Om in jouw analogie te blijven; de kok zegt: “Och het zal zo’n vaart wel niet lopen….”. Dat is wat mij betreft nog erger.
Verder vindt ik dat je nog een stap verder moet gaan en (belangrijke) gegevens moet controleren op onverwachte significante afwijkingen van aanlevering in het verleden. Bijvoorbeeld: een potje pindakaas heeft altijd EUR 1,53 gekost, maar wordt nu aangeleverd met een prijs van EUR 15,80. Zou dit wel correct zijn….?
Dit is natuurlijk wel lastig, maar als je hiermee bezig bent, uiteraard in samenspraak met de gebruiker (bijv. planning
Stefan,
Je gaat volgens mij voorbij aan een zeer belangrijk punt: de business bepaalt! In jouw analogie, als de klant biefstuk wil zal de kok ook een mindere kwaliteit biefstuk op tafel zetten, ook al is de zalm van betere kwaliteit. Ik heb in mijn praktijk voldoende vaak meegemaakt dat willens en wetens “slechte” data is opgeladen omdat het in overleg met de eindgebruiker belangrijker was om ?berhaupt te kunnen rapporteren ondanks data van, aantoonbaar, mindere kwaliteit. Over het algemeen is bij de business voldoende bekend over de data om een inschatting te kunnen doen van de kwaliteit van de data. Veel fouten zijn door henzelf tenslotte ingevoerd in de basissystemen. Het herstellen van deze fouten in het ETL ? proces is vaak niet wenselijk (maakt het ook nodeloos complex) en niet mogelijk in de basissystemen (te ingrijpend, ondoorzichtig).
Ik denk wel dat we met zijn allen moeten streven naar het leveren van de best mogelijke kwaliteit met de aangeleverde bestanden en dus veel controles moeten inbouwen zoals je terecht opmerkt. Daarnaast is het van belang dat we samen met de klant een minimale kwaliteit van het DWH afspreken en dat we inzichtelijk maken wat de consequenties zijn indien we niet aan de minimale kwaliteitseis kunnen voldoen. Let hierbij wel op dat het niet leveren van data dodelijker kan zijn voor (het gebruik van ) BI dan het leveren van data met een mindere kwaliteit.
Zoals vaker het geval staat of valt alles met de communicatie naar de klant en de data – aanleverende partijen. Wat hebben we toch een mooi vak ;-)).