Datakwaliteit en monitoring

Groene jobs en foute cijfers

Een job kan elke nacht slagen en toch foute data opleveren. Een bron stuurt de helft van de rijen, een valutakolom krijgt een andere betekenis, een join gaat dupliceren. De scheduler ziet succes en de CFO ziet een omzetcijfer dat een vijfde afwijkt. Datakwaliteitswerk dicht die kloof: het controleert de data, niet alleen de job.

In deze les scheiden we vijf soorten controles, plaatsen we elke controle in de laag waar ze hoort en richten we eigenaarschap en alerts in. Datacatalogustooling en masterdatamanagement behandelen we niet.

Vijf soorten controles

Zet de controle waar de fout het goedkoopst te begrijpen is. Een foute waarde is zichtbaar op één rij, dus controleer per record in silver. Een ontbrekende levering is alleen over tijd zichtbaar, dus bewaak hem op de tabel. Een afwijking van de bron is alleen zichtbaar tegen een extern getal, dus vergelijk in de job.

Controles per record: expectations

Expectations ken je uit les 3. Ze toetsen elk record aan een SQL-voorwaarde en waarschuwen, gooien weg of laten falen. Voor kwaliteitswerk tellen twee gewoonten.

• Tel wat je weggooit. Expectation-metrics voor waarschuwen en weggooien worden vastgelegd. Zet het percentage weggegooide rijen op een dashboard. Een stijging van 0,1 naar 8 procent vertelt je dat een bron veranderde voor een gebruiker het doet.
• Promoveer regels in de tijd. Begin nieuwe regels als waarschuwing, bekijk de overtredingstellingen en promoveer dan naar weggooien of laten falen met akkoord van de dataeigenaar.

Controles op tabelniveau: data quality monitoring

Databricks biedt data quality monitoring voor assets in Unity Catalog. De documentatie beschrijft twee mogelijkheden.

Anomaliedetectie bewaakt met één klik alle tabellen in een schema. Het geeft voorrang aan belangrijke tabellen, slaat tabellen met weinig impact over en analyseert historische patronen om de versheid en volledigheid van elke tabel te beoordelen. Versheid meet hoe recent een tabel is bijgewerkt: een model per tabel voorspelt de volgende commit en een ongewoon late commit markeert de tabel als verouderd. Volledigheid vergelijkt de rijen van de afgelopen 24 uur met een voorspeld bereik en markeert de tabel als onvolledig als het aantal onder de ondergrens komt.

Data profiling geeft samenvattende statistieken voor een tabel en volgt hoe de datadistributie in de tijd verandert. De documentatie zegt dat het eerder Lakehouse Monitoring heette en dat het ook ML-modellen en inference-tabellen kan bewaken.

Account- en metastore-beheerders kunnen de gezondheid van de datakwaliteit bekijken, zoals het percentage gezonde tabellen, in Governance Hub. De documentatie noemt dat monitoring de bewaakte tabellen niet wijzigt en geen extra belasting geeft aan de jobs die ze vullen. Het draait op serverless compute en wordt gefactureerd als serverless DBU's onder het billingproduct DATA_QUALITY_MONITORING, waarbij de uitgaven afhangen van het aantal en de grootte van bewaakte tabellen en hoe vaak ze worden beoordeeld.

De pagina vermeldt niet of deze mogelijkheden algemeen beschikbaar, in preview of in bèta zijn, dus controleer de releasenotes voor de status in jouw regio voor je een klantafspraak erop bouwt. Anomaliedetectie voor een schema aanzetten is hoe dan ook een stap met weinig risico, omdat het alleen metadata en historie leest.

Reconciliatie: de controle die de grote fouten vindt

Geldigheidscontroles en anomaliedetectie kennen het juiste totaal niet. Alleen een extern getal doet dat. In elke domeinpipeline voegen we een reconciliatietaak toe die een of twee controlecijfers vergelijkt, bijvoorbeeld:

-- Vergelijk het vandaag geladen aantal rijen met het controlecijfer dat de leverancier stuurde.
-- control.supplier_totals is een kleine tabel die de ingestie vult uit het controlebestand van de leverancier.
SELECT
  s.delivery_date,
  s.expected_rows,
  COUNT(o.order_id)                          AS loaded_rows,
  COUNT(o.order_id) - s.expected_rows        AS difference
FROM   dev_sales.control.supplier_totals s
LEFT JOIN dev_sales.silver.orders o
       ON DATE(o.order_ts) = s.delivery_date
GROUP  BY s.delivery_date, s.expected_rows
HAVING COUNT(o.order_id) <> s.expected_rows;

Geeft de query rijen terug, dan faalt de taak en stopt de publicatie stroomafwaarts (les 4). De taak is simpel en vangt de fout die het meeste kost.

Datacontracten

Een datacontract legt vast wat een producent belooft en een afnemer kan vertrouwen: schema, betekenis van velden, versheid, toegestane waarden en wie je belt. Het maakt van kwaliteit een afspraak in plaats van een hoop. Ons artikel over datacontracten afdwingen voor je publiceert laat zien hoe wij het contract in de pipeline controleren, zodat een brekende wijziging wordt gevangen voor afnemers hem zien.

Een contract is zo goed als zijn handhaving. Zet elke belofte in een expectation, een monitor of een reconciliatie en houd het contract naast de code in dezelfde repository.

Eigenaarschap en alerts

Elke dataset heeft een benoemde eigenaarsgroep nodig. Een controle zonder eigenaar faalt eeuwig in stilte.

• Stuur alerts naar de eigenaar. Een kwaliteitsalert voor de silvertabel van sales gaat naar het salesdatateam, niet naar een gedeelde inbox.
• Alarmeer op een korte lijst. Mislukte expectations van het type fail, een verouderde of onvolledige tabel, een mislukte reconciliatie, een weggooipercentage boven de limiet. Meer alerts betekent meer genegeerde alerts.
• Schrijf de reactie op. Zeg per alert wat de eigenaar eerst doet. Onze runbookgewoonte uit de agentcursus geldt ook hier: één actie per regel.
• Sluit de lus. Elk incident eindigt met een nieuwe controle die het had gevangen.

Lineage helpt de impact vinden

Faalt een controle, dan moet je weten wie erdoor geraakt wordt. Unity Catalog legt lineage automatisch vast voor queries die op Databricks draaien, tot op kolomniveau, en stelt hem beschikbaar in de systeemtabellen system.access.table_lineage en system.access.column_lineage. Wij gebruiken die om afnemers te vertellen welke dashboards stroomafwaarts van een mislukte tabel staan. Les 5 van de governancecursus behandelt lineage uitgebreider.

Veelgemaakte fouten

• Alertmoeheid. Tientallen controles die dezelfde persoon oproepen.
• Stille verwijderingen. Rijen verdwijnen en niemand telt ze.
• Alleen geldigheid controleren. Je mist ontbrekende data.
• Geen controlecijfers. Je ziet het verschil niet tussen een rustige dag en een kapotte bron.
• De data repareren en niet de controle. Het volgende incident is hetzelfde.

Samenvatting

Gebruik expectations per record, tabelmonitoring voor versheid en volledigheid en reconciliatie voor de totalen. Schrijf contracten, wijs eigenaren aan, alarmeer op een korte lijst en voeg na elk incident een controle toe.

Volgende les: kosten en computekeuzes, waar dezelfde discipline de rekening ontmoet.