Nederlands
Het is belangrijk om te weten welke data waar wordt gebruikt om de impact van veranderende processen en definities in te schatten. Of om bepaalde bronnen te laten evolueren zonder de daaropvolgende apps die hun data gebruiken te breken.
Je kunt twee hoofdmethoden identificeren in data lineage: het vooraf ontwerpen van de dataflows enerzijds en het ontdekken van de data lineage uit bestaande dataflows anderzijds. Eerst gaan we in op deze twee methoden, dan bespreken we drie tools die je data lineage discovery automatiseren en tenslotte leggen we op een zeer hands-on manier uit hoe je data lineage visualiseert in ArangoDB graph database.
Wanneer je begint met het bouwen van een analytics omgeving heb je waarschijnlijk een plan hoe je verschillende bronnen integreert en welke data nodig is om de KPI's te berekenen die je wilt opvolgen. Dit plan zal een ontwerp van de dataflows bevatten. Het stelt je in staat om het werk dat nodig is om de pipelines te bouwen in te schatten. Het plan wordt ergens opgeschreven en dient als leidende documentatie.
Er zijn verschillende uitdagingen om mee om te gaan wanneer je van plan bent een data pipeline te ontwerpen:
• Je hebt mogelijk een veelheid aan developers in meerdere landen die verschillende talen spreken en andere voorkeuren hebben als het gaat om het documenteren van dit type informatie.
• Er kunnen verschillende types analytische applicaties zijn die het moeilijk maken om slechts één methode te gebruiken om je dataflow te documenteren, omdat de logica die ze volgen zo veel van elkaar verschilt.
• Zodra je begint met bouwen ontdek je misschien dat er andere bronnen nodig zijn, of dat de data niet kan worden geïntegreerd zoals je had gepland.
• Soms moet je waarschijnlijk een kritiek strategisch project heel snel afmaken, waarbij je concessies doet aan de documentatie en technische schuld opbouwt.
Enzovoort. Er zijn talloze redenen waarom je vooraf documentatie niet op peil zal zijn.
Daarom heb je een sterk data governance team nodig om ervoor te zorgen dat de documentatie compleet is, up-to-date, consistent over de verschillende projecten en om een speciaal oogje te houden op persoonlijke data die binnen de scope valt van data privacy regelgeving. Dit kan worden gedaan in data catalogs en data dictionaries — indien nodig in een spreadsheet.
Zodra de projecten zijn voltooid, wil je misschien dubbelchecken of alles is geïmplementeerd zoals beschreven, maar dit is een enorme klus. Ook het up-to-date houden van de documentatie is geen kleine prestatie. Dan kan een data lineage discovery van pas komen. Tools zoals Collibra, Manta en Octopai stellen je in staat om te linken naar de verschillende bronnen waar data wordt getransformeerd.
• Collibra belooft lineage automatisch te extraheren en te onderhouden van bronsystemen, SQL dialects, ETL tools en BI tools met hun native lineage harvesters. Dit zou 95% van de tijd besparen die normaal wordt besteed aan het handmatig documenteren en onderhouden van lineage.
• Manta spreekt over data pipeline observability om de hele omgeving in kaart te brengen om te bepalen welke data wordt opgeslagen en waar. Ze voeren instant en accurate impact analyses uit om software testing te versnellen, te zien hoe geplande veranderingen andere delen van de omgeving zullen beïnvloeden, en samenwerking tussen data users te versnellen.
• De use cases die Octopia opsomt omvatten het voorspellen van de impact van een procesverandering, het analyseren van de impact van een kapot proces, het ontdekken van parallelle processen die dezelfde taken uitvoeren en high-level visualisatie van dataflow.
De beloftes en use cases van deze tools met betrekking tot data lineage zijn allemaal vrij vergelijkbaar. Collibra en Octopai combineren data lineage met een data catalog en Collibra ook met data privacy functionaliteit terwijl Manta alleen data lineage dekt. Tool selectie is vaak meer een kunst dan een wetenschap en we zullen dit hier niet verder in detail behandelen.
Om een gevoel te krijgen voor waar de complexiteiten liggen in dit type oefening heb ik geprobeerd de data lineage van een vrij groot Qlik Sense project te visualiseren in een graph database. Waarom een graph database? Wanneer we alle objecten opsommen die relevant zijn voor data lineage zijn er grotendeels slechts twee: de objecten, en de relatie tussen de objecten.
In graph database termen zijn dit de documents en de edges. Een derde die ook belangrijk is en een functie is van de relatie, is het soort combinaties en transformaties die kunnen plaatsvinden tussen het ene document en het andere.
Voordat we verder in detail gaan zetten we enkele grenzen aan de scope van onze oefening: het werk van het verzamelen en organiseren van de informatie over onze data werd handmatig gedaan. We hebben geen SQL parser tot onze beschikking om het Qlik Sense load script te lezen of om de metadata te extraheren uit de proprietary Qlik QVD databestanden die in dit project worden gebruikt.
Voor nu hebben we ervoor gekozen om ons te beperken tot het niveau van de verschillende tabellen in het datamodel, en niet naar het niveau van de velden te gaan. Het zijn de velden die worden gebruikt in het uiteindelijke dashboard om de measures te berekenen die de KPI's vormen. Natuurlijk zou het de volgende stap moeten zijn om te zien wat voor soort aggregaties, combinaties en functies worden toegepast op veldniveau. Maar omdat we het hebben over meer dan 500 velden en het handmatig werk is om ze te verzamelen en te organiseren, zijn we er nog niet aan toegekomen.
We zullen in meer detail uitleggen hoe we dit technisch hebben gedaan, maar om een eerste smaak van de resultaten te krijgen, hier kun je zien hoe de graph eruitziet wanneer we de documents en edges in de database laden:
Zoals je kunt zien, is dit niet erg informatief en je moet echt weten waar je naar kijkt om er iets van te kunnen maken. Daarom heb ik ervoor gekozen om slechts één van de facts te gebruiken voor de documentatie hieronder.
Hoe ben ik concreet en pragmatisch te werk gegaan bij deze taak? Allereerst installeerde ik de community edition van open source graph database ArangoDB op een Ubuntu 20.04 server in de Hetzner cloud.
Vervolgens somde ik alle documents en edges op in verschillende collections in Excel. Ik gebruik verschillende collections om later een kleur per collection te kunnen gebruiken om de graph leesbaarder te maken. In het voorbeeld hierboven wordt slechts één collection gebruikt. Een nadeel van het gebruik van verschillende collections is dat je verschillende upload bestanden nodig hebt per collection en per edge die de collections verbindt.
Nu kunnen we beginnen met het definiëren van de graph door de verschillende collections en edge definities toe te voegen. Je kunt ook afzonderlijk de vertices uploaden, waarbij je de richting van een relatie tussen documents aangeeft. We hebben dit toegevoegd aan onze edge definitie.
Dan kan ik deze graph visualiseren, maar ik moet eerst een paar van de standaardinstellingen aanpassen om er zeker van te zijn dat alle nodes worden weergegeven. Voor deze graph veranderde ik de search depth naar 10 en de limit naar 10.000. Als ik dit doe, ziet de graph er nogal grillig uit en wordt bepaald door het gewicht dat de verschillende nodes krijgen gebaseerd op het aantal verbindingen dat ze hebben.
Je kunt ook gewichten definiëren op de edges. Dit stelt je in staat om ArangoDB te gebruiken om de kortste paden te berekenen, bijvoorbeeld voor een travelling salesman optimalisatieprobleem. Als ik denk hoe ik dit type gebruik zou kunnen vertalen naar onze context zou ik de reload tijd van het transformeren van het ene document naar het andere op de edges kunnen toevoegen en de bestandsgroottes op de documents.
Om de graph visueel aantrekkelijker te maken en te gebruiken als communicatietool heb ik handmatig de nodes gesleept en gedropt. Dit is iets wat de meer geavanceerde tools automatisch doen. Voor zover ik weet kun je de layout van de graph op deze manier niet opslaan, dus zorg ervoor dat je een screenshot maakt zodra je klaar bent.
Data lineage is een zeer krachtige methode om grip te krijgen op je data pipelines. In sommige industrieën is dit onmisbaar om compliant te zijn met regelgeving. Er zijn een paar zeer goede tools op de markt om dit op een meer geautomatiseerde manier te behandelen, maar ze komen met een prijs. Als je niet wilt investeren in tooling, zorg er dan voor dat je een proces hebt om je data te besturen en gemoedsrust hebt dat alles onder controle is. Dit zal je ook in staat stellen om use cases aan je data omgeving toe te voegen op een efficiëntere manier en meer uitgebreide self service data analyse voor je eindgebruikers te ondersteunen.
Ik speelde al een tijdje met het idee om een graph database te gebruiken voor data lineage en eindelijk door het te bouwen leerde ik hoe dit op een pragmatische en snelle manier te doen. Zelfs als de concepten eigenlijk heel eenvoudig zijn, begreep ik de kracht van een graph database niet echt voordat ik het zelf probeerde. Je kunt de documentatie lezen maar als je het niet probeert en ermee speelt zul je er nooit echt de kneep van krijgen. Een nadeel van deze manier van werken is nog steeds het enorme handmatige werk dat gaat in het verzamelen en organiseren van de relevante informatie.
Volgende stappen zullen zijn om de andere functionaliteiten van de database beter te leren kennen, zoals queries, views, services en schema's, en om erachter te komen of de meer geavanceerde features zoals kortste paden kunnen worden toegepast in de context van data lineage. Ik hoop dat je deze content leuk vond, en als dat zo is, volg me dan op LinkedIn.
Het allerbeste en veel succes op je data journey!
