Waarom data kwaliteit in Fabric je pipeline-ontwerp bepaalt

In veel teams ontstaat datakwaliteit pas als probleem wanneer dashboards ineens “niet kloppen”. Dan ga je zoeken naar de oorzaak, terwijl je eigenlijk eerder in de keten had willen ingrijpen. In Microsoft Fabric is dat juist goed te doen, omdat je ingestion en processing dicht bij elkaar organiseert in dezelfde omgeving. Daardoor kun je data kwaliteit bewaken in Microsoft Fabric op het moment dat data binnenkomt en voordat het downstream schade aanricht.

Een praktische manier om dit te organiseren is de medallion-aanpak: Bronze is je landingzone, Silver is je opgeschoonde en gevalideerde laag, Gold is je model- en reportinglaag. In Bronze test je vooral of de data technisch klopt, zoals aanwezigheid van verplichte velden en basisformaten. In Silver doe je businessvalidatie, zoals referentiële checks tussen feiten en dimensies. Dit sluit aan bij hoe Fabric-patronen vaak worden beschreven in community en praktijkvoorbeelden.

De grootste winst haal je door vooraf te bepalen wat er moet gebeuren bij een mislukte check. Soms wil je hard falen en de pipeline stoppen, soms wil je door maar wel quarantainen, en soms wil je alleen loggen en monitoren. Als je dat consistent maakt, krijgt je team voorspelbaarheid en vertrouwen in de data. En dat vertrouwen is precies wat je nodig hebt om analytics en adoptie te versnellen.

Basispatroon: checks als first-class stap in pipeline en notebook

De kern is een herhaalbaar patroon dat je overal toepast: je voert checks uit, je schrijft resultaten weg, en je koppelt daar een actie aan. In Fabric betekent dit meestal dat een notebook de checks uitvoert en een Delta-tabel bijwerkt met een kwaliteitslog. Dat past goed bij het Lakehouse-model waarin Delta het standaardformat is.

Je kunt die notebooks vervolgens orchestreren vanuit een Fabric Data Pipeline, zodat je dezelfde checkset draait bij elke run. Een pipeline is vooral sterk in volgorde, herhaalbaarheid en “wat nu”-logica, terwijl een notebook sterk is in expressieve validaties met SQL of PySpark. Dataflow Gen2 heeft ook validatie, maar dat is vooral gericht op het kunnen bepalen van schema’s en het voorkomen van kapotte queries, niet op business data quality.

In de praktijk werkt een minimalistische set tabellen het best: een quality_log tabel, een optionele quarantine tabel, en je normale bronze/silver tabellen. De quality_log bevat per run welke check is uitgevoerd, op welke tabel, met welke drempel, en wat de uitkomst was. Daardoor kun je later trendmatig zien of je data langzaam verslechtert, zonder dat je meteen een nieuw platform introduceert. Dit is precies de “zonder extra tooling” aanpak die veel teams zoeken.

Voorbeeld: simpele quality_log structuur (conceptueel, geen tooling nodig)
Kolommen die vrijwel altijd werken: run_id, dataset, check_name, check_type, severity, metric_value, threshold, status, checked_at, details.

Rij-validaties in Fabric zonder extra tooling

Rij-validaties gaan over de kwaliteit van individuele records: is een veld gevuld, voldoet het aan een patroon, is een sleutel uniek, klopt een datumrange. Dit soort checks is ideaal om dicht bij ingestion te doen, omdat je fouten dan nog kunt scheiden voordat ze zich verspreiden. In Fabric doe je dit vaak in een notebook op je Bronze of vroege Silver tabellen, afhankelijk van hoe schoon je brondata is.

Een praktisch uitgangspunt is dat je per dataset een kleine set “must-have” regels definieert. Denk aan not-null op businesskritische velden, geldige waarden voor statuscodes, en uniqueness voor natuurlijke sleutels of surrogate keys. Je hoeft daar geen framework voor te gebruiken: een paar Spark SQL queries die counts en afwijkingen meten zijn vaak genoeg. Het doel is niet perfectie, maar voorspelbaarheid en zichtbaarheid.

De toepassing wordt krachtig zodra je het standaardiseert: elke rij-validatie levert een metric op, bijvoorbeeld “aantal nulls in CustomerId” of “aantal dubbele OrderIds”. Die metric schrijf je naar je quality_log en je bepaalt een drempel, bijvoorbeeld nul voor uniqueness en not-null. Als de status “fail” is, kun je besluiten te stoppen of de afwijkende records naar quarantine te schrijven voor herstel door de bron of het datateam.

Voorbeeldqueries (Spark SQL, te draaien in Fabric

-- Not-null check
SELECT COUNT(*) AS null_count
FROM silver_orders
WHERE customer_id IS NULL;

-- Uniqueness check
SELECT COUNT(*) AS duplicate_keys
FROM (
SELECT order_id
FROM silver_orders
GROUP BY order_id
HAVING COUNT(*) > 1
) d;

-- Pattern check (simpel voorbeeld e-mail)
SELECT COUNT(*) AS invalid_emails
FROM silver_customers
WHERE email IS NOT NULL AND email NOT RLIKE '^[^@]+@[^@]+\\.[^@]+$';

Volumechecks en drift-detectie die je wél volhoudt

Volumechecks zijn je early-warning systeem: ineens veel minder rijen dan normaal betekent vaak dat een bron faalt, een filter is veranderd, of een load incompleet is. Iets meer rijen dan normaal kan juist duiden op duplicatie, een herverwerking of een join-explosie. In plaats van dit “op gevoel” te controleren, maak je het een vaste check met drempels en logging.

De verdieping zit in drift: je vergelijkt niet alleen met nul, maar met een historisch patroon. Een simpele variant is vergelijken met de vorige run, of met een gemiddelde van de laatste N runs per dataset. Dit is goed te implementeren met je eigen quality_log, omdat je daar per run de row_count bewaart. Je hebt dan geen monitoringtool nodig om toch trending en anomalieën te zien.

De toepassing is dat je volumechecks koppelt aan severity. Een kleine afwijking kan een warning zijn die je wel logt maar de pipeline laat doorgaan. Een grote afwijking kan een hard fail zijn, zeker bij financiële of operationele rapportages. Als je dit consequent doet, wordt “data kwaliteit bewaken in Microsoft Fabric” een routine, niet een incidentproces.

Voorbeeld: row count + drift (conceptueel in SQL)

-- Row count van huidige run
SELECT COUNT(*) AS row_count
FROM bronze_orders;

-- Simpele drift t.o.v. vorige run (op basis van quality_log)
-- (uitwerking hangt af van jouw log-schema, maar het principe is hetzelfde)

Referentiële integriteit controleren zonder foreign keys

Veel teams verwachten dat referentiële integriteit “in de database” wordt afgedwongen met foreign keys. In een Lakehouse-wereld werkt dat anders: Delta Lake biedt ACID op tabelniveau, maar geen klassieke multi-table foreign keys die automatisch afdwingen dat elke fact een bestaande dimension-key heeft. Daarom bouw je referentiële integriteit in Fabric meestal als expliciete check.

De verdieping is dat je deze checks het liefst in Silver doet, omdat je dan al opgeschoonde dimensies en facts hebt. De check zelf is eenvoudig: zoek fact-records waarvan de dimension-key niet bestaat in de dimension tabel. Je kunt dit uitvoeren als left anti join en het aantal “orphans” loggen, plus eventueel de records quarantainen. Dit past ook bij het idee dat Silver de plek is voor businessvalidatie.

De toepassing is dat je per belangrijk domein een set integriteitsregels definieert, bijvoorbeeld Orders moeten een bestaande Customer hebben, en Sales moeten aan een bestaande Product hangen. Als de orphan-count boven nul komt, kun je gericht handelen: dimension-load eerst repareren, mapping uitbreiden, of brondata corrigeren. Zo voorkom je dat je Gold-modellen later workarounds nodig hebben die de semantiek vervuilen.

Voorbeeldquery: orphan facts detecteren (Spark SQL)

SELECT COUNT(*) AS orphan_orders
FROM silver_orders o
LEFT ANTI JOIN silver_customers c
ON o.customer_id = c.customer_id;

Samenvatting

Microsoft Fabric leent zich goed voor ingebouwde data quality checks omdat je orchestration, compute en opslag in één platform samenbrengt. Door checks als eerste klas bouwblok te behandelen, creëer je een consistente manier om fouten te detecteren, te registreren en af te handelen. Rij-validaties, volumechecks en referentiële integriteitscontroles dekken samen het grootste deel van de praktische problemen die BI- en data teams dagelijks tegenkomen. Met een simpele quality_log en optionele quarantine tabel houd je het lichtgewicht én schaalbaar.