Waarom data lineage. Je ziet het veel in de supermarkt: ‘Aardbeien van boer Erik. Uit Loenen aan de Vecht’. Of ‘Mosselen uit de Oosterschelde, gekweekt door de mosselmannen van Neeltje Jans’. Klinkt goed. Betrouwbaar. Van Hollandse bodem en lekker dichtbij.

Dat er op elk versproduct in de supermarkt een verpakkings- of houdbaarheidsdatum staat zijn we inmiddels wel gewend, maar vandaag de dag wordt ook de sier gemaakt met een hippe plek van herkomst. Bij voeding, maar ook bij bijvoorbeeld kleding wordt tegenwoordig sowieso veel meer waarde gehecht aan de herkomst. Geldt dit ook voor de data die gebruikt worden in je data warehouse?

Waar komen de data in mijn data warehouse eigenlijk vandaan?

Wat is ooit de bron geweest van de data achter dat fraaie grafiekje dat nu ‘Omzet’ is getiteld op mijn dashboard?

Is de data afkomstig van Google Analytics, die de omzet globaal voor mij heeft ingeschat op basis van de inhoud van winkelwagentjes tijdens een bezoek van de webshop? Het is leuk, visueel prettig vormgegeven en lekker snel beschikbaar, maar verre van accuraat. Of is de bron mijn eigen Order Management Systeem? Dat klinkt al een stuk betrouwbaarder.
Voor data is het vaak net zo belangrijk om te weten waar deze vandaan komen als wanneer het er is neergezet. Het is zelfs de vraag of je niet liever geen informatie hebt dan informatie waar je de herkomst niet van kent.

Wettelijke verplichting voor data lineage

Is het niet voor jezelf om de waarde van je data beter in te kunnen schatten, dan is het wel een wettelijke verplichting om te weten waar jouw financiële cijfers of privacygevoelige gegevens hun oorsprong hebben. De vernieuwde regelgeving rond de ‘Algemene Verordening Gegevensbescherming (AVG)’ is hier een goed voorbeeld van. Als een klant verzoekt om verwijdering van zijn gegevens, ben je verplicht dit door de hele keten te doen.

Het is daarom van belang om je data direct bij binnenkomst te labelen met tijdstip en een identificatie van het proces dat verantwoordelijk is voor het binnenhalen van deze data. Labels met tijdstippen worden, samen met andere eigenschappen, gedurende het verwerkende proces bijgehouden in een aparte metadata-tabel. Zo bouw je een volledig pad op van de reis die data heeft afgelegd alvorens deze voor jou zichtbaar wordt op het dashboard.

Bijkomende voordelen:

• Foutief geladen data is eenvoudig te traceren. Op basis van de in de data vastgelegde tags kunnen zo brongegevens die foutief zijn geladen in één keer weer worden verwijderd.
• De impact van aangekondigde wijzigingen in de bron is eenvoudiger te analyseren. Bij een goed ingericht framework is in één oogopslag te zien welke processen, rapporten en dashboards geraakt worden bij een bronwijziging.

Aandachtspunten zijn wel:

• Het taggen van data en vastleggen van afgelegde paden, zoals in de alinea hierna wordt aangestipt, gaat ten koste van de performance van de verwerkende processen. Een hardloper die elke meter broodkruimeltjes neerlegt komt nu eenmaal wat later over de finish dan de loper die in één streep naar de finish kan sprinten.
• Data-lineage zou onderdeel moeten zijn van een grotere data-governance-strategie. Bottom-up starten wordt vooral een IT-feestje terwijl een initiatief puur gestart vanuit een wettelijke verplichting mogelijk blijft hangen in een data-linage as designed. Een goede borging van lineage in de data-govenance door de gehele organisatie is daarom een must.

Is data-lineage makkelijk te realiseren?

In de basis zorgt het labelen van de data voor een prima data-lineage. Het is namelijk best nog eenvoudig op te zetten. Complexere requirements bijvoorbeeld vanuit wetgeving kunnen al snel tot grotere, maar zeker niet onoverkomelijke, uitdagingen leiden:

• Het kan zo zijn dat de bewerkingen op de data die onderweg zijn uitgevoerd worden vastgelegd. Dus welke weg heeft de data genomen in een if-then-else constructie? Of met andere woorden: welke medewerker van boer Erik heeft besloten dat deze licht afwijkende, beetje groene, aardbei in het bakje ‘Klasse B’ terecht is gekomen? En op basis van welke instructie?
• De broncode, de loop van processen of structuur van de data kan in de loop van de tijd gewijzigd zijn. Ook van twee jaar terug wil je nog volledige data-lineage hebben. Een goede integratie met de version-control-software is hier onontbeerlijk.

Dit soort vraagstukken vereisen een uitgebreider ontwerp en metadata-framework rond de data verwerkende processen. Dit kun je custom-made ontwikkelen of ondersteunende software voor inzetten. Bijkomend voordeel is dat deze software vaak ook zorgdraagt voor een visualisatie van de data-flow.

Nieuwsgierig ben ik of jij tegen andere uitdagingen bent gelopen bij het implementeren van een data-lineage-oplossing. Of misschien heb je een goede en gemakkelijke oplossing gevonden om data-lineage te borgen in je organisatie. Deel je ervaringen met ons!

O ja, om in stijl te eindigen, deze blog is geschreven door data engineer Ron Hoes. In Haarlem, juli 2017. Gepubliceerd in augustus 2017 vanuit Den Haag. Gelezen door jou, waar en wanneer?