Data quality tracking tool Stageproject Over data cleansing werk Eén van de onderdelen van werk rond datakwaliteit uitgevoerd door Kapernikov is het systematisch oplossen van gedetecteerde datafouten in databanken. Dit gebeurt door een team van mensen die een (vaak grote) lijst van fouten gestructureerd moeten verwerken. Enkele voorbeelden van lijsten met (mogelijke) datafouten: Inconsistenties tussen 2 databanken die het Belgische wegennet beschrijven, maar die op een aantal punten van elkaar verschillen In een databank van werknemers: alle personen die ouder zijn dan 120 jaar, of alle werknemers met een geboortejaar in de toekomst. De lijst van personen die volgens de databank van het sales-departement iets gekocht hebben, maar die niet voorkomen in de databank van boekhouding/facturatie. De inhoud van een mailbox waar gebruikers problemen konden melden met de inhoud van een bepaalde databank. Het oplossen van dergelijke fouten dient juist maar ook snel en efficiënt te gebeuren. De snelheid waarmee men datafouten kan oplossen hangt sterk af van de manier waarop men het werk structureert: zo is het beter om gelijkaardige problemen samen te behandelen, en kan door het slim sorteren van de fouten vaak een hoop opzoekwerk worden uitgespaard, en is het zelfs mogelijk dat door één enkele correctie een heel aantal fouten samen worden opgelost. Het team dat de data cleansing uitvoert maakt wijzigingen aan operationele databanken, en kan later gevraagd worden om uitleg te geven bij gedane wijzigingen. Daarom is het belangrijk dat een audit trail wordt bijgehouden voor alle datafouten en hun oplossing, maar dit moet gebeuren zonder dat het team te zwaar belast wordt met administratieve overlast. KAPERNIKOV B VBA Wilselsesteenweg 361, 3010 Kessel-Lo BTW BE-0837.602.918, RPR Leuven IBAN BE95 9730 3056 7158, BIC ARSPBE22 tel. +32 16 36 99 07 info@kapernikov.com www.kapernikov.com
Omschrijving Tool We willen een tool bouwen die een team van datawerkers ondersteunt bij het oplossen / controleren van grote aantallen datafouten (of anomalieën). De tool moet datafouten bijhouden en inzichtelijk maken via zoekmogelijkheden en rapporten, en staat in voor het loggen en beschikbaar maken van audit trails (wanneer is een bepaalde fout verschenen, wanneer en door wie is die opgelost). Qua principe komt de werking van een dergelijke tool goed overeen met een issue tracker (e.g. JIRA, redmine, ), maar er zijn enkele belangrijke verschillen: Datafouten komen in grote volumes en worden vaak in groep behandeld. De tijd die aan één fout wordt gespendeerd is typisch klein. Daarom moet de nadruk gelegd worden op categorisering, zoek, efficiënte invoer (met een minimum aan overhead) en massamanipulaties. Datafouten worden in veel gevallen niet ingevoerd door een persoon, maar worden gegenereerd door een query of een rapport, of door een softwaretool die semi-automatisch fouten detecteert. Het verschijnen en verdwijnen van datafouten in/uit deze rapporten/tools moet automatisch verwerkt worden. Mogelijkheden om issues te groeperen, te filteren, zijn zeer belangrijk voor de efficiëntie: meerdere issues voor éénzelfde record in de databank dienen best samen te worden behandeld, en bij het behandelen van een issue kan tijd worden gewonnen indien men direct zicht heeft op alle verwante issues. K AP E RNI K O V B VB A info@kapernikov.com www.kapernikov.com 2
Proof of concept Om te zien of een dergelijke tool het werk van een data quality team substantieel zou kunnen vergemakkelijken wensen we een proof of concept uit te bouwen. Daarbij willen we zoveel mogelijk bestaande technologieën gebruiken. We willen absoluut vermijden dat we het wiel opnieuw uitvinden, gezien het feit dat er al meerdere issue trackers en workflow engines op de markt zijn (waaronder een aantal als open source software). Enkele mogelijke pistes qua technologie: Het gebruik van een workflow engine (zoals Activiti) samen met een GUI framework (zoals vaadin) dat snelle ontwikkeling van data-aware applicaties toelaat Het aanpassen van een open source issue tracker aan de specifieke noden voor data cleansing. Doelstellingen stage Het evalueren van de technologische mogelijkheden en het maken van een technologiekeuze, waarbij het snel behalen van resultaat een belangrijk criterium is (het gaat immers om een proof of concept) Het uitwerken van een proof of concept van de tool met de volgende onderdelen: Een Gebruikersinterface voor de datawerker Een mogelijkheid om anomalierapporten in te lezen (vb. in een vast XML of CSV formaat), of een simulatie hiervan (vb via een SQL script). Een mogelijkheid om een bepaalde workflow toe te kennen aan geïmporteerde data-issues, of een simulatie hiervan (vb via een SQL script). In tweede instantie (indien er tijd over is): Een gebruikersinterface om zelf anomalierapporten handmatig toe te voegen K AP E RNI K O V B VB A info@kapernikov.com www.kapernikov.com 3
Ondersteunen beperkte uitrol van de proof of concept bij het data team om de haalbaarheid van het idee te toetsen. Integratie met een bestaande ETL tool om records te identificeren en om anomalierapporten recurrent te kunnen genereren Een gebruikersinterface voor een beheerder Een eerste inschatting van de werklast: Taak Aantal dagen Technologiestudie en technologiekeuze 3 Basisopzet (IDE, versiebeheer, databank, buildsysteem, ) 2 Ontwerp en implementatie gegevensmodel (setup ORM, databank,...) 2 Opzetten workflowbeheersysteem 5 User interface datawerker 15 Afhankelijk van de beschikbare tijd zal de functionaliteit breder of minder breed worden uitgewerkt. Appendix: enkele types anomalieën en het verwachte gedrag van het systeem Louter ter illustratie geven we enkele types van anomalieën mee die met een dergelijke tool zouden kunnen worden opgevolgd. Deze lijst is niet exhaustief: bij andere problemen zijn andere scenario s mogelijk. EENVOUDIG OP TE SPOREN DATA-ANOMALIEËN Via een query of een (externe) softwaretool wordt er een lijst met anomalieën gegenereerd. Een issue is pas opgelost indien ze bij het opnieuw inlezen van de resultaten van de externe softwaretool niet meer in de lijst verschijnt Voorbeeld: alle werknemers ouder dan 120 jaar. K AP E RNI K O V B VB A info@kapernikov.com www.kapernikov.com 4
Taak van het systeem: Integreren met de query of de softwaretool die de anomalieën opspoort en regelmatig automatisch een geactualiseerde lijst met anomalieën inlezen. Anomalieën zijn pas bevestigd indien ze meerdere dagen in het anomalierapport terugkeren. We willen ons data-team immers niet belasten met foutjes die door anderen direct worden opgemerkt en gecorrigeerd. Onbevestigde anomalieën worden getoond in een overzicht maar zijn nog geen deel van de op te lossen problemen. Issues groeperen per object of per record. Een issue zelf afsluiten in het systeem kan niet, de anomalie is pas opgelost indien deze niet langer in de gegenereerde lijst voorkomt. Een gebruiker moet een issues te kunnen parkeren voor een bepaalde tijd (tot de volgende keer dat de lijst wordt getrokken), zodat hij een overzicht behoudt over welke issues nog uit te voeren zijn Wanneer (bij het inlezen van de geactualiseerde lijst van anomalieën) blijkt dat een geparkeerde issue nog steeds bestaat, dient deze terug de status TO DO te krijgen. VERDACHTE CASES Via een query of rapport komen er mogelijke anomalieën binnen die onwaarschijnlijk maar niet onmogelijk zijn Een issue kan op 2 manieren opgelost worden: Doordat deze niet meer in het nieuwste rapport is opgenomen Doordat deze is gecontroleerd en bevestigd als waarheid (en dus geen fout) Voorbeeld: Een lijst met alle elektriciteitskabels ouder dan 50 jaar, of met een maximaal vermogen groter dan 1000MW Een lijst met alle werknemers met meer dan 45 jaar dienst. Taak van het systeem: Alles beschreven bij de eenvoudig op te sporen categorie Het markeren van een verdacht geval als geen fout. Hierdoor wordt dit geval niet opnieuw als verdacht gepresenteerd K AP E RNI K O V B VB A info@kapernikov.com www.kapernikov.com 5
TIJDELIJKE SITUATIES Via een query of rapport komen er situaties binnen die maar tijdelijk mogen bestaan (vb gepland maar niet in dienst ), en die al verdacht lang in een bepaalde tijdelijke situatie zitten Een anomalie kan op 2 manieren opgelost worden: Doordat deze niet meer in het nieuwste rapport is opgenomen Doordat deze anomalie werd gecontroleerd en geverifieerd. Hierdoor verdwijnt deze anomalie voor een bepaalde tijd uit de rapportage, maar na een vastgelegde periode komt de anomalie terug tevoorschijn (indien deze nog steeds bestaat) Voorbeeld: Een lijst van alle indienstnames van nieuw materiaal die gepland waren voor 2013 en nog steeds niet zijn uitgevoerd. K AP E RNI K O V B VB A info@kapernikov.com www.kapernikov.com 6