Data freshness (data-SLA)

Wat is data freshness?

Data freshness zegt hoe goed je data de werkelijkheid van nu weergeeft. Een tabel is vers wanneer wat erin staat overeenkomt met wat er op dit moment echt gebeurt in je webshop, je boekhouding of je magazijn. Ze is stale, verouderd, wanneer de wereld al is opgeschoven en de data nog op de vorige stand blijft hangen.

Het gaat niet over of de cijfers kloppen, maar over hoe recent ze zijn. Een verkoopcijfer kan perfect juist zijn en tegelijk twaalf uur oud. Daarin verschilt het van datakwaliteit: kwaliteit kijkt of een waarde correct is, freshness of ze recent genoeg is. Een tabel kan vers zijn en toch fouten bevatten, of foutloos zijn en toch dagen achterlopen.

Je kan freshness vergelijken met de datum op een pak melk. Melk van gisteren is niet plots slecht, maar je wil weten hoe oud ze is voor je ze meeneemt. Bij data is de vraag dezelfde: van wanneer dateert dit cijfer, en is dat vers genoeg voor wat ik er nu mee doe?

Waarom data freshness ertoe doet

Verouderde data ziet er even betrouwbaar uit als verse data. Net daarom is het gevaarlijk: het dashboard laadt, de cijfers staan er, en niemand ziet dat ze een dag stilstaan.

Neem een voorraadrapport dat een halve dag achterloopt. Volgens het rapport liggen er nog tweehonderd stuks, in het magazijn zijn er nog twintig. De inkoper bestelt niets bij, en twee dagen later staat het artikel op nul terwijl de bestellingen blijven binnenkomen. De data was niet fout, ze was te oud. Hetzelfde gebeurt met een omzetdashboard dat sinds gisteren niet meer ververst is: de beslissing die je er vanmiddag op neemt, voelt onderbouwd maar rust op een foto van gisteren.

In beide gevallen liep de datapijplijn wellicht gewoon groen. Een run kan slagen en toch niets nieuws laden, omdat de bron niets aanleverde of een stap stilviel. Freshness meten vangt net die stille stilstand op.

Hoe meet je data freshness?

Freshness meet je als een vertraging tussen twee momenten: wanneer iets gebeurde bij de bron, en wanneer het beschikbaar is in je warehouse of rapport. Hoe groter dat gat, hoe staler de data.

De eenvoudigste meting kijkt naar de jongste timestamp in een tabel en vergelijkt die met nu. Staat de recentste rij op 08:00 en is het 14:00, dan is je data zes uur oud. Dat is exact wat de source freshness-check van dbt doet: hij neemt de hoogste laadtijd in een tabel, trekt die af van het huidige tijdstip, en meldt hoe oud de data is.

Twee soorten vertraging wil je apart in het oog houden: de aanvoervertraging, hoelang het duurt voor een gebeurtenis in de bron effectief in je warehouse landt, en de ouderdom van de jongste rij, hoe recent het nieuwste record is dat er al in staat. Die tweede meting toont of de laatste run wel echt iets binnenhaalde, en voor de meeste KMO-rapportering vangt ze het gros van de problemen op.

Data-SLA en staleness-alerts

Een data-SLA is een afspraak over hoe vers je data moet zijn. "De verkoopdata is nooit ouder dan een uur" is een data-SLA. Zonder zo'n afspraak blijft freshness een gevoel, met de afspraak wordt het meetbaar: je kan objectief zeggen of de data binnen de grens zit of niet.

Op die afspraak zet je een staleness-alert. Zodra een tabel langer dan afgesproken niet ververst is, stuurt een controle een melding naar wie er iets mee doet. dbt werkt hiervoor met twee drempels per bron: een waarschuwing na zoveel tijd, en een echte fout na een langere periode. Zo krijg je een zachte tik voor het menens wordt.

Een vuistregel uit de praktijk: controleer minstens dubbel zo vaak als je strengste afspraak. Moet de data nooit ouder zijn dan een uur, check dan om het halfuur. Anders merk je een stilstand pas wanneer je al ruim over de grens zit.

Hoe hangt het samen met observability, refresh en CDC?

Freshness is een van de vijf pijlers van data observability, naast volume, schema, distributie en lineage. Observability-tools bewaken het automatisch: ze leren het normale ritme van een tabel en slaan alarm zodra een verse update uitblijft.

De verversfrequentie bepaalt de ondergrens van je freshness. Een semantisch model in Power BI dat je met een geplande refresh bijwerkt, kan nooit verser zijn dan de tijd tussen twee refreshes. Met Power BI Pro plan je tot acht refreshes per dag, met een Premium- of Fabric-capaciteit tot achtenveertig. Wil je verser, dan moet je vaker verversen of van patroon veranderen.

Voor grote tabellen helpt incremental refresh: door enkel de recente partities opnieuw te laden blijft een refresh kort genoeg om vaker te draaien. Wil je nog dichter bij realtime, dan verschuift de aanpak naar Change Data Capture, dat elke wijziging in de bron bijna meteen doorstuurt en de aanvoervertraging van uren naar seconden brengt.

Een simpele freshness-check opzetten

Je hebt geen dure tool nodig om te beginnen. Een bruikbare eerste check op een KMO-warehouse ziet er zo uit:

1. Kies de tabellen die er echt toe doen. De tabellen waar rapporten en beslissingen op draaien, niet elke tabel in je warehouse. Begin klein.

2. Vind per tabel een betrouwbare tijdkolom. Een laaddatum of een gebeurtenisdatum die bij elke rij correct wordt ingevuld. Zonder zo'n kolom kan je de ouderdom niet meten.

3. Bepaal de grens. Spreek per tabel af hoe oud de data maximaal mag zijn. Voor een dagelijkse boekhoudimport is dat misschien zesendertig uur, voor een webshopvoorraad eerder een uur.

4. Draai de check en stuur een melding. Een klein script of een geplande query vergelijkt de jongste datum met nu. Zit het verschil boven de grens, dan gaat er een mail of een Teams-bericht naar de verantwoordelijke.

Die vier stappen vangen het gros van de stille stilstanden op, lang voor een collega of klant merkt dat de cijfers niet meer kloppen.