Hulpmiddelen voor datakwaliteitsmonitoring: wat ze detecteren, wat ze missen en hoe je er een kiest.

Een tool voor datakwaliteitsmonitoring voert volgens een schema controles uit op je gegevens, geeft een foutmelding als er een regel wordt overtreden en stuurt een waarschuwing. De controles zien er als volgt uit:

• customer_id mag nooit null zijn
• order_total moet tussen 0 en 1.000.000 liggen
• country_code moet een van de volgende zijn: {NL, DE, FR, BE, ...}
• Het aantal rijen dat vandaag is verwerkt, moet binnen 20% van het aantal van gisteren liggen
• email moet uniek zijn binnen de actieve klantenset

Als je bekend bent met unit tests voor code, is het mentale model hetzelfde. Je schrijft verwachtingen op. De tool voert ze uit. Je krijgt een melding als de werkelijkheid er niet aan voldoet.

Dit is echt nuttig en verrassend weinig gebruikt. Volgens een BARC-onderzoek uit 2023 heeft slechts 38% van de organisaties systematische datakwaliteitsmonitoring geïmplementeerd, ondanks dat 92% aangeeft dat datakwaliteit een topprioriteit is.

Uit onderzoek van Forrester blijkt dat slechte data een gemiddelde onderneming $15 miljoen per jaar kost, waarbij meting en monitoring de meest voorkomende tekortkoming vormen in herstelprogramma's. (Forrester, 2024)

De eerste 30 tot 50 nuttige controles kunnen doorgaans binnen een dag worden uitgevoerd. De verbetering in incident detectie is direct merkbaar.

Drie families van tools voor datakwaliteitsmonitoring domineren de markt, en ze beantwoorden elk iets andere vragen.

Voor de meeste teams is het juiste antwoord de tool die het beste aansluit op de bestaande stack en de minste wrijving veroorzaakt. dbt-native als je al met dbt werkt. Een framework als je engineers hebt en met complexe bronnen werkt. Een observatie platform als je naast DataQuery ook behoefte hebt aan herkomst en actualiteit.

De verkeerde aanpak is kiezen voor de tool met de langste expectation library en vervolgens nooit tijd hebben om de expectations te schrijven.

Elke tool voor datakwaliteitsmonitoring detecteert, per definitie, de fouten waarvoor je een regel hebt opgesteld. Dat is de kracht en tegelijkertijd de beperking.

De fouten die erdoorheen glippen:

1. De onbekende onbekenden Je regels dekken wat je eerder al eens fout hebt zien gaan. Ze missen de fouten die voor het eerst voorkomen. Een nieuw upstream-systeem gaat op maandag live en begint een kolom te genereren met 80% lege strings in plaats van null-waarden. De null-controle slaagt. De dashboards zijn dinsdag onjuist.

2. Volume en actualiteit De meeste regelengines behandelen elke rij onafhankelijk. Ze detecteren niet automatisch dat de batch van vandaag vier uur te laat is binnengekomen of 60% minder rijen bevat dan gisteren. Je kunt dit benaderen met rijtellingen door vensters te vergelijken, maar dit is een onbetrouwbare methode.

3. Schemaverschuiving Een kolom wordt upstream hernoemd. De regel verwijst naar de oude naam. De tool rapporteert nul gecontroleerde rijen, wat vaak stilzwijgend wordt behandeld als nul overtredingen. Dit is een van de meest voorkomende manieren waarop een kwaliteitsmonitoringsysteem vals vertrouwen wekt.

4. Problemen tussen tabellen en tools Een referentiële controle tussen twee tabellen in hetzelfde datawarehouse is eenvoudig. Het detecteren dat een Power BI dashboard gegevens van gisteren weergeeft omdat een ADF-pipeline drie lagen stroomopwaarts is mislukt, vereist lineage, geen regels.

Een brancheonderzoek van Wakefield Research / Monte Carlo uit 2024 meldde gemiddeld 70 data-incidenten per 1.000 tabellen per jaar, waarvan de meeste niet werden gedetecteerd door vooraf gedefinieerde regels voor datakwaliteit. (Monte Carlo, 2024)

De praktische conclusie: op regels gebaseerde tools dekken de bekende helft. Voor de rest hebt je observability-tools nodig, of je moet accepteren dat de onbekende fouten je zakelijke gebruikers zullen blijven bereiken.

Deze twee termen worden vaak door elkaar gehaald, terwijl dat niet de bedoeling is. Het onderscheid is cruciaal voor de keuze van de tool die je als eerste moet aanschaffen.

Een praktische vuistregel: als je nog geen enkele datakwaliteitsregel hebt geschreven, begin dan met een tool voor kwaliteitsmonitoring. De voordelen zijn enorm en de kosten laag. Als je honderden regels hebt en er nog steeds incidenten bij je zakelijke gebruikers binnenkomen, dan heb je de limiet bereikt van wat regels kunnen doen. Dat is het moment waarop observability van pas komt.

De meeste evaluaties richten zich op de verkeerde dingen. Dit is wat er echt toe doet als je eenmaal een paar tools in productie hebt gebruikt.

Waar de regels staan. SQL-native tools bewaren regels dicht bij de data, in versiebeheer en controleerbaar via pull requests. Frameworktools slaan verwachtingen vaak op in YAML- of JSON-bestanden, gescheiden van de datalaag. Hoe dichter de regels bij de transformaties staan, hoe gemakkelijker ze te onderhouden zijn – en hoe groter de kans dat ze worden bijgewerkt wanneer de data verandert.

Hoe gemakkelijk is het om de scope te bepalen. Kun je een controle richten op één kolom, één tabel of 50 tabellen die aan een patroon voldoen? Tools die je dwingen om elke controle expliciet te schrijven, schalen niet verder dan een paar honderd controles. Tools waarmee je één keer kunt aangeven dat "elke stagingtabel niet-null primaire sleutels moet hebben" dekken duizenden controles.

Kosten van valse positieven. Een tool die bij elke weekenddaling in het aantal rijen een foutmelding geeft, zal je team binnen een week leren om het kanaal te negeren. Zoek naar tools met ingebouwde baseline-bewustzijn (rollende vensters, dag-van-de-week-patronen) of anomaliedrempels.

Integratie met je alert-routering. Een controle die in het niets verdwijnt, is verspilde moeite. De tool moet integreren met je incidentworkflow: PagerDuty, Slack met eigenaarstags of je data-observability platform.

Prestatie-impact. Sommige tools voeren elke controle uit als een aparte query. Bij een tabel met een miljard rijen is dat snel duur. SQL-native tools die controles samenvoegen tot één query per tabel zijn meestal goedkoper op grote schaal.

Een IDC InfoBrief meldt dat data-engineers tot 30% van hun tijd besteden aan incident triage en het achterhalen van de hoofdoorzaak. (IDC, 2023) De juiste tool voor datakwaliteitsmonitoring vermindert het triviale deel van die tijd. De verkeerde tool verhoogt het.

Patronen die we bij verschillende teams steeds weer zien terugkomen.

Fout 1: Te snel te veel regels schrijven. Een team importeert 1.000 dbt-tests op dag één en krijgt 1.000 waarschuwingen op dag twee. Begin met de 20 meest gecontroleerde datasets. Voeg regels toe totdat je een zinvolle dekking hebt. Weersta de verleiding om systematisch elke kolom te testen.

Fout 2: Controles met nul rijen behandelen als nul overtredingen. Een regel die wordt uitgevoerd op een hernoemde of verwijderde kolom zal nul rijen retourneren. De meeste tools zullen nul fouten rapporteren, wat misleidend is. Configureer de tool om lege resultaatsets als verdacht te markeren, niet als veilig.

Fout 3: Vergeten regels bij te werken wanneer de data verandert. Regels zijn code. Code veroudert. Bouw het bijwerken van regels in dezelfde PR-workflow in als modelwijzigingen.

Fout 4: Stoppen bij kwaliteit. Kwaliteitsmonitoring is noodzakelijk. Het is niet voldoende. Zodra je een goede dekking van de regels hebt, is het volgende knelpunt alles wat kwaliteitsmonitoring niet kan zien: actualiteit, herkomst, volume, de onbekenden. Dat is hét moment om een tool voor data-observability toe te voegen, en dat is geen moment te vroeg.

MetricSign is niet primair een tool voor het bewaken van de datakwaliteit. Het is een tool voor data-observability die kwaliteitscontroles als een van de mogelijkheden biedt, naast actualiteit, volume, schema-afwijkingen en data lineage tussen verschillende tools.

Als je helemaal vanaf nul begint, brengen dbt-tests of Soda je waarschijnlijk sneller verder met puur op regels gebaseerde datakwaliteit, vooral in een Snowflake-omgeving. MetricSign is de juiste aanvulling zodra je regeldekking hebt en de fouten die zakelijke gebruikers nog steeds bereiken, onbekend zijn: verouderde Power BI updates, afwijkingen in de ADF-pipeline, schemawijzigingen stroomopwaarts van je dbt-modellen, anomalieën waarvoor je geen regel hebt geschreven.

We zijn ontworpen om naast je bestaande tool voor datakwaliteitsmonitoring te draaien, niet om deze te vervangen.