Data Lineage Tools: een praktische handleiding voor Microsoft Stack teams

Afgelopen dinsdag opende de CFO het Power BI rapport voor de maandelijkse afsluiting. De tabel 'Verkoop per regio' toonde lege data. De data engineer controleerde Power BI Service: dataset refresh succesvol, geen fouten geregistreerd. Azure Data Factory gecontroleerd: pipeline uitgevoerd, 147.000 rijen gekopieerd. Microsoft Fabric gecontroleerd: data correct geïmporteerd.

Drie tools. Drie groene statussen. Eén leeg rapport.

Het werkelijke probleem: een bronanalist had drie dagen eerder een kolom in de SQL Server staging tabel hernoemd. De ADF copy activity liep gewoon door. Het schreef null naar de kolom die 14 downstream rapporten voedde. Zonder een data lineage tool kon de data engineer niet achterhalen welke rapporten van die kolom afhankelijk waren of welke kolom in de brontabel was gewijzigd.

Data lineage tools brengen in kaart hoe data door je pipeline beweegt, van bronsystemen en ingestiejobs via transformatielagen naar de dashboards en rapporten waarop je bedrijf draait. Wanneer een schema wijziging iets downstream verstoort, vertelt lineage je welke rapporten worden beïnvloed en welke upstream job dit heeft veroorzaakt.

Deze handleiding behandelt de vier belangrijkste categorieën data lineage tools, waarvoor ze zijn gebouwd en hoe je er een kiest als je een Microsoft stack gebruikt: Power BI, ADF, Fabric en dbt.

De meeste data lineage tools beginnen op table-level. Ze volgen welke pipeline leest uit tabel A en schrijft naar tabel B, en welke dataset leest uit tabel B om rapport C te produceren. Voor het begrijpen van afhankelijkheidsketens is table-level lineage genoeg om te weten dat 'als brontabel X verandert, rapport Y mogelijk wordt beïnvloed'.

Column-level lineage gaat dieper. Het volgt welke specifieke kolommen van bron naar bestemming stromen, inclusief door elke transformatiestap. Wanneer het rapport van de CFO lege data toont omdat een kolom region_name is hernoemd, vertelt table-level lineage dat het rapport afhankelijk is van de pipeline. Column-level lineage vertelt specifiek dat region_name de visualisatie voedde die is kapotgegaan en dat diezelfde kolom in zes andere rapporten voorkomt.

Het onderscheid is het belangrijkst bij schema drift: de geleidelijke, vaak onaangekondigde wijzigingen in de structuur van brontabellen die voortkomen uit SaaS API updates, operationele databaseschema wijzigingen of beslissingen van upstream teams die niet als breaking errors worden doorgegeven. Table-level lineage detecteert dat een afhankelijkheid bestaat. Column-level lineage detecteert dat het specifieke veld waarvan je transformatie afhankelijk is, is gewijzigd.

Voor Microsoft stack teams die dbt transformaties uitvoeren bovenop Fabric lakehouses helpt column-level lineage ook bij impact analyse vóór een release: hernoem een kolom in een dbt-model en je ziet exact welke Power BI measures en berekende kolommen ernaar verwijzen.

Power BI Service heeft sinds 2021 een lineageweergave. In de werkruimte-weergave zie je een grafiek met gegevensbronnen, dataflows, datasets en rapporten in een afhankelijkheidsketen. Voor een enkele werkruimte met eenvoudige gegevensbronnen dekt dit de basis: rapport A is afhankelijk van dataset B, dataset B is verbonden met een Azure SQL database.

De beperkingen worden zichtbaar zodra je stack de grenzen van tools overschrijdt.

De lineageweergave van Power BI toont geen upstream pipeline geschiedenis. Als de dataset is verbonden met een Fabric lakehouse gevuld door een ADF pipeline, toont de lineageweergave 'Lakehouse' als bron — niet de ADF pipeline run die het heeft gevuld of het dbt-model dat de data heeft gevormd voordat die arriveerde.

Column-level afhankelijkheden zijn ook niet zichtbaar. Je weet dat rapport A dataset B gebruikt. Je weet niet welke specifieke kolommen uit dataset B welke visuals in rapport A aansturen.

Cross-workspace afhankelijkheden zijn eveneens onzichtbaar. In organisaties met development-, test- en productiewerkruimten (of wanneer verschillende teams datasets in aparte werkruimten beheren) toont de native lineageweergave alleen de werkruimte waarin je je momenteel bevindt.

Voor teams met een eenvoudige stack (een paar datasets die rechtstreeks zijn gekoppeld aan Azure SQL of SharePoint) dekt de native weergave de basis. Voor teams waarvan de Power BI rapporten aan het einde staan van een keten met ADF, dbt en Fabric toont de native weergave het laatste stukje van een veel langer traject.

Een typische Microsoft data stack verbindt Azure Data Factory of Fabric Data Pipelines met bronsystemen, verplaatst data naar een Fabric lakehouse of Synapse warehouse, transformeert die met dbt en ontsluit die via Power BI datasets en rapporten. Vier lagen. Vier verschillende API's. Vier onafhankelijke logsystemen.

De hiaten ontstaan op de naadpunten. ADF logt welke tabellen zijn gekopieerd en hoeveel rijen — niet welke kolommen en niet welke downstream dbt-modellen afhankelijk zijn van die output. dbt Cloud registreert welke modellen zijn uitgevoerd en welke tests zijn mislukt, maar de lineage is intern aan het dbt-project: niet verbonden met de ADF pipeline upstream of de Power BI dataset downstream. Power BI Service registreert dataset refreshes en rapportweergaven maar niet wat er is gewijzigd in het Fabric lakehouse dat de dataset leest.

Microsoft Purview dicht een deel van deze hiaten. Het scant ADF, Power BI, Fabric en Azure SQL bronnen om een uniforme catalogus te bouwen met lineage metadata. Voor governance-doeleinden (data-eigendom, classificatie en compliance) is Purview het native Microsoft antwoord.

Waar Purview operationele beperkingen heeft: de scan-gebaseerde architectuur betekent dat lineage metadata wordt bijgewerkt op een geplande scancyclus, niet in realtime. Als een ADF pipeline om 03:00 mislukt en de volgende Purview scan om 06:00 wordt uitgevoerd, weerspiegelt de lineage-grafiek de status van de vorige scan. Voor impact alerting vóór het Power BI refresh venster van 07:00 is Purview's architectuur geschikter voor governance queries dan voor realtime incident detectie.

Zie ook: Wat is een data observabilityplatform?

De markt voor data lineage tools is onderverdeeld in vier categorieën die verschillende use cases bedienen. De juiste keuze hangt meer af van waarvoor je lineage nodig hebt dan van feature-vergelijkingen.

Microsoft Purview: governance lineage

Purview is de juiste keuze wanneer governance, compliance of catalogusbeheer de drijfveer is — niet operationele monitoring. Het integreert native met Azure services, ondersteunt dataclassificatie en gevoeligheidslabels en maakt verbinding met Microsoft Information Protection. Voor teams die aan auditors moeten aantonen welke systemen persoonsgegevens bevatten is Purview daarvoor gebouwd. De lineage functionaliteit werkt goed als referentielaag (een kaart van wat van wat afhankelijk is), geraadpleegd door data stewards en compliance teams — niet door on-call engineers die om 03:00 reageren op een pipeline storing.

Collibra en Alation: enterprise data governance platforms

Beide platforms bouwen lineage als onderdeel van een breder datacatalogus- en governance framework. Ze zijn ontworpen voor grote organisaties met dedicated governance teams, compliance vereisten en de engineering capaciteit om een volledige catalogus te implementeren. Lineage is één feature van velen: data glossarium, kwaliteitsregels, stewardship workflows en beleidsbeheer. Als je organisatie databeheer op grote schaal uitvoert met een specifiek budget en teamcapaciteit daarvoor, kan elk platform volstaan. Als je team van 4–8 data engineers operationeel inzicht nodig heeft in waarom een rapport vanochtend niet werkte, zijn de governance-focus en enterprise prijs meer dan je nodig hebt.

OpenLineage en DataHub: open source opties

OpenLineage is een standaard van de Linux Foundation voor het genereren van lineage events vanuit data pipelines. DataHub is een open source datacatalogus die die events kan verwerken. dbt, Airflow en Spark ondersteunen OpenLineage emitters native. De belangrijkste vereiste is instrumentatie: elke pipeline die lineage events moet genereren heeft een geconfigureerde OpenLineage client nodig. Voor teams die Airflow gebruiken met dedicated platform engineering resources biedt deze aanpak volledige controle over de lineage-grafiek zonder licentiekosten. Voor teams die voornamelijk managed Microsoft services gebruiken (ADF, Fabric Data Pipelines, Power BI) waarbij je de interne werking van de tool niet kunt instrumenteren, vereist de open source aanpak custom connectors die de meeste teams niet willen bouwen en onderhouden.

MetricSign: monitoring-first lineage voor de Microsoft stack

MetricSign bouwt lineage op basis van activiteitslogboeken in plaats van schema scans of code instrumentatie. Het leest het activiteitslogboek van Power BI, de pipeline run API van ADF, de job geschiedenis van Fabric, de run API van dbt Cloud en de job logs van Databricks, en construeert een realtime lineage-grafiek op basis van die operationele events. Het primaire use case is operationeel: wanneer een ADF pipeline mislukt, identificeert MetricSign welke Power BI datasets ervan afhankelijk zijn en stuurt een alert voordat de volgende refresh wordt uitgevoerd. Meer detail in de sectie hieronder.

Drie scenario's dekken de meeste teams die data lineage tools evalueren voor een Microsoft stack.

Scenario 1: je wilt weten waarom een rapport kapotging en wat er nog meer door wordt geraakt

Dit is een operationeel use case. De juiste tool maakt verbinding met je Power BI activiteitslogboek, je ADF pipeline run geschiedenis en je dbt-model runs, en correleert die in één incidentoverzicht. Purview kan deze vraag in principe beantwoorden, maar vereist een voltooide scancyclus om de huidige status te weerspiegelen. Een monitoring-first tool geeft binnen enkele minuten na de pipeline storing antwoord.

Scenario 2: governance en compliance zijn de drijvende kracht

Als je organisatie data assets moet classificeren, lineage moet bijhouden voor wettelijke doeleinden, data stewardship moet toewijzen of een bedrijfsglossarium moet opbouwen, is Purview de eerste optie om te overwegen — zeker als je investeert in het Azure ecosysteem. Voor grotere organisaties met dedicated governance teams voegen Collibra of Alation catalogusdiepte en stewardship workflows toe die Purview niet biedt.

Scenario 3: je team heeft platform engineering resources en wil maximale controle

Als je Airflow gebruikt, een dataplatform team hebt dat infrastructuurcode schrijft en een lineage-grafiek wilt die je volledig zelf beheert, is OpenLineage met DataHub een goede optie. Reken op een budget van meerdere weken voor de instrumentatie per pipeline type dat je lineage events wilt laten genereren, plus doorlopend onderhoud naarmate pipeline frameworks worden bijgewerkt.

Een eerlijke observatie: de meeste datateams op een Microsoft stack (4 tot 10 engineers, Power BI als consumptielaag, geen dedicated platform engineering functie) zijn beter af met Scenario 1. Een governance platform zoals Collibra is ontworpen voor een organisatiecontext waarbij catalogusbeheer een voltijdse functie is.

MetricSign bouwt een live lineage-grafiek door de API's te lezen die je bestaande Microsoft tools al beschikbaar stellen. Het maakt verbinding met Power BI Service voor dataset en rapport afhankelijkheden, met Azure Data Factory voor pipeline run geschiedenis en output tabellen, met Fabric voor job geschiedenis, met dbt Cloud voor model run resultaten en met Databricks voor job logs.

Op basis van die feeds construeert het een grafiek: ADF pipeline X schrijft naar Fabric lakehouse tabel Y, dbt-model Z leest uit tabel Y en schrijft naar semantisch model A, Power BI rapport B leest uit semantisch model A. Wanneer ADF pipeline X om 03:47 mislukt, doorloopt MetricSign de grafiek, identificeert semantisch model A en Power BI rapport B als downstream afhankelijkheden en stuurt een alert voordat de Power BI refresh van 07:00 start.

Dit verschilt van Purview's scan-gebaseerde lineage op één specifiek punt: MetricSign werkt op pipeline run events, niet op metadata snapshots. De lineage-grafiek wordt binnen enkele minuten na voltooiing van een pipeline bijgewerkt. Voor impact analyse vóór een schema wijziging geeft een query op 'welke rapporten zijn afhankelijk van deze dbt-model kolom' een actueel antwoord — niet de status van de laatste scancyclus.

MetricSign is gratis te starten. Het maakt binnen 15 minuten verbinding met Power BI en ADF zonder dat je je bestaande pipelines hoeft aan te passen. Het use case waarvoor het is gebouwd: er gaat iets mis in je Microsoft stack om 03:00 en je moet weten welke rapporten worden geraakt voordat de werkdag om 07:00 begint.