Zonder lineage begint elk onderzoek helemaal opnieuw.
Je Power BI dashboard geeft onjuiste cijfers weer. Waar begin je? Zonder metadata over lineage is het antwoord: overal.
Dataherkomst is een van de kernfunctionaliteiten die volwaardige data-observability platformen onderscheidt van monitoring met één tool. Het is de verbindende schakel tussen een hoofdoorzaak in ADF en een symptoom in Power BI.
Je controleert de refreshgeschiedenis van de dataset in Power BI Service. De refresh is succesvol voltooid om 06:04. Je bekijkt de ADF-pipeline runen. De pipeline is geslaagd. Je voert een query rechtstreeks uit op de stagingdatabase. De gegevens lijken aanwezig. Je controleert de dbt Cloud-taak die vóór ADF wordt uitgevoerd. Deze is geslaagd met twee waarschuwingen. Je leest de waarschuwingen. Een ervan gaat over een model dat een foutieve berekening heeft uitgevoerd omdat een brontabel onverwachte null-waarden bevatte.
Vijftig minuten later heb je het probleem gevonden. Nu moet je uitzoeken welke andere datasets afhankelijk zijn van hetzelfde dbt-model. Dat betekent nog eens dertig minuten handmatig controleren van de databronconfiguraties in alle Power BI werkruimten.
Het onderzoek was niet moeilijk. Het duurde lang, omdat je een keten moest doorlopen die weliswaar in je infrastructuur bestaat, maar nergens gedocumenteerd is waar je een query kunt uitvoeren. Lineage maakt die keten expliciet.
De volledige keten: vijf lagen tussen een bronsysteem en een rapport.
Een typische bedrijfsdataketen doorloopt vijf verschillende lagen voordat een rij gegevens een Power BI visualisatie bereikt.
Bronsystemen bevatten de originele gegevens: SQL Server databases, SAP-exports, REST API's, Dataverse-tabellen. Deze systemen schrijven gegevens volgens hun eigen schema, onafhankelijk van alles wat verderop in de keten gebeurt.
Orchestratiepipelines (ADF, Fabric Pipelines) verplaatsen gegevens tussen de lagen: van bron naar staging, van staging naar datawarehouse, van datawarehouse naar semantisch model. Ze bepalen wanneer gegevens worden verplaatst en handhaven het volume en de timing van elke load.
Transformatielagen (dbt-modellen, Synapse Analytics-views, Databricks-taken) herschikken ruwe gegevens naar de vorm die analytische query's nodig hebben. Fouten in deze lagen leiden vaak tot technisch succesvolle loads met semantisch onjuiste resultaten.
Het Power BI semantisch model bevindt zich bovenop de getransformeerde gegevens. Het definieert de bedrijfslogica: berekende kolommen, metingen, beveiliging op rijniveau. Het wordt vernieuwd op basis van de uitvoer van de transformatielaag.
Rapporten en dashboards lezen gegevens uit het semantisch model en presenteren deze aan zakelijke gebruikers. Een storing in een van de voorgaande lagen komt uiteindelijk hier aan het licht, maar om die terug te sporen moet je het exacte pad kennen.
Afstammingsgegevens worden samengesteld uit meerdere bronnen, niet opgevraagd uit één enkele bron.
Er bestaat geen enkele API die een complete lineage-grafiek voor een moderne datastack retourneert. Lineage wordt samengesteld uit meerdere metadata-bronnen en vereist het samenvoegen ervan.
ADF-pipeline runslogboeken laten zien naar welke tabellen een pipeline heeft geschreven en wanneer. De eigenschap 'Activity Output' van elke copy activity bevat gelezen en geschreven rijen — hier bevinden zich gegevens voor volumevalidatie naast lineage-signalen.
dbt-manifesten (het gecompileerde manifest.json-artefact dat door elke dbt-uitvoering wordt geproduceerd) bevatten de volledige DAG van modelafhankelijkheden. Elk knooppunt registreert zijn upstream-bronnen en downstream-afhankelijkheden. Het parsen van een dbt-manifest geeft je automatisch de lineage van de transformatielaag, zonder handmatige documentatie.
Power BI datasource-metadata (beschikbaar via de REST API) laat zien uit welke databasetabellen of -weergaven elke dataset leest. Door de verbindingsreeksen van de datasource te matchen met de doeltabellen in je pipeline-logboeken en dbt-manifest wordt de link tussen de transformatielaag en de semantische laag gesloten.
De resulterende grafiek is niet perfect. Niet elke verbinding wordt volledig nauwkeurig vastgelegd — het matchen van verbindingsreeksen is probabilistisch wanneer omgevingen verschillende naamgevingsconventies gebruiken. Maar een afstammingsgrafiek met 80% dekking elimineert het grootste deel van het handmatige onderzoek.
Met lineageonderzoek duurt hetzelfde onderzoek tien minuten.
Hetzelfde scenario — onjuiste cijfers in een Power BI dashboard — opgelost met beschikbare lineage-metadata.
Je opent het incident in je monitoringtool. De melding bevat de naam van de betreffende dataset en een link naar de upstream-keten. De keten laat zien: het dbt-model daily_sales → de ADF-pipeline orders_staging → de SQL Server tabel orders_source. De dbt-modeluitvoering van vanochtend geeft een waarschuwing: het model compute_margins is mislukt vanwege onverwachte null-waarden in order_line_items.
Je controleert welke andere Power BI datasets gegevens lezen uit daily_sales. Lineage toont er drie: Verkoopoverzicht, Omzet per regio en Maandelijkse werkelijke cijfers. Alle drie zijn vernieuwd na de dbt-fout en leveren momenteel gegevens die de betreffende berekening uitsluiten.
Het duurde tien minuten om het volledige plaatje — hoofdoorzaak, getroffen datasets, omvang van de impact — in kaart te brengen. De oplossing is apart, maar het onderzoek is afgerond.
Stroomopwaartse en stroomafwaartse doorkruising dienen verschillende doelen.
Lineage werkt in beide richtingen, en elke richting is nuttig voor een andere fase van een incident.
Upstream traversal (analyse van de hoofdoorzaak) begint bij een defect rapport of dataset en gaat terug naar de bron. Wanneer een rapport onjuiste cijfers weergeeft, beantwoordt upstream traversal de volgende vragen: welke pipeline heeft deze data geproduceerd? Welk dbt-model heeft deze getransformeerd? Welk bronsysteem heeft de onderliggende records geschreven? Dit is de richting die je volgt tijdens het onderzoek.
Downstream traversal (impactanalyse) begint bij een bekende fout en gaat vooruit naar de eindgebruikers. Wanneer je ontdekt dat een dbt-model is mislukt, beantwoordt downstream traversal de volgende vragen: welke ADF-pipelines zijn afhankelijk van de output van dit model? Welke Power BI datasets zijn vernieuwd vanuit die pipelines? Welke rapporten leveren momenteel de getroffen data? Dit is de richting die je volgt om te bepalen wie je moet informeren en hoe urgent.
Bij de meeste incidenten is beide nodig. Stroomopwaarts om de oorzaak te vinden; stroomafwaarts om de omvang vast te stellen voordat je iets aanraakt.