Data observability

Wat is data observability?

Data observability is het continu bewaken van de gezondheid van je data: zijn de tabellen ververst, zijn de rij-aantallen normaal, kloppen de schema's nog, vallen de waarden binnen normaal, en welke dashboards en modellen bouwen erop? De term komt van Barr Moses bij Monte Carlo (2019). De inspiratie zit in DevOps: zoals Datadog of New Relic je applicaties bewaken, bewaakt data observability je data.

Een dashboard staat al maanden op stale data en niemand merkt het tot een klant het opmerkt. Een upstream API verandert haar schema in stilte en je sales-rapport draait plots op halve cijfers. Klassieke pipelines bewaken of de jobs draaien, niet of de data klopt. Data observability vult dat gat.

De vijf pijlers

Het Monte Carlo-framework dat de markt grotendeels heeft overgenomen, ordent observability rond vijf signalen:

1. Freshness
   Hoe recent is de data? Een tabel die elk uur ververst zou moeten worden, maar al achttien uur stilstaat, is een incident.

2. Volume
   Hoeveel rijen kwamen erbij? Een dagelijkse import van pakweg 10.000 transacties die plots 200 oplevert, of net 500.000, vraagt onderzoek.

3. Schema
   Veranderden kolomnamen, types of nullability? Eén stille kolomhernoeming bij de bron breekt downstream tien dashboards.

4. Distributie
   Liggen de waarden binnen normaal? Een sprong in NULL-percentage, of een numerieke kolom waar opeens negatieve waarden in zitten, is een rode vlag.

5. Lineage
   Welke bronnen voeden welk rapport? Bij een incident wil je in seconden weten welke modellen en dashboards mee getroffen zijn. Hier overlapt observability met klassieke data lineage.

Niet elke tool dekt alle vijf even hard. Sommige (Monte Carlo, Bigeye, Anomalo) leggen de klemtoon op anomaliedetectie, andere (Atlan, OpenLineage) op de lineage-kant.

Hoe verschilt het van data testen en pipeline-monitoring?

Het grote verschil met klassieke data tests (zoals dbt-tests) is wat je vooraf kent. Een dbt-test is een regel die je vooraf opschrijft: "kolom customer_id mag nooit NULL zijn", "order_total moet positief zijn". Dat zijn known unknowns: dingen waarvan je weet dat ze fout kunnen gaan, dus check je ze.

Observability gaat over unknown unknowns. Anomalieën die je niet had voorzien: een gemiddelde orderwaarde die plots dertig procent stijgt zonder duidelijke reden, een tabel die fragiel begint te worden zonder dat iemand er een test op had geschreven. Een statistisch model bouwt baselines uit historische scans en zet alerts wanneer een verse meting daar significant van afwijkt.

Het verschil met klassieke pipeline-monitoring (Airflow logs, run-statussen, Fabric pipeline-monitoring) is even fundamenteel. Die tools melden of een job liep. Observability meldt of de data die hij produceerde klopt. Een job kan groen draaien terwijl hij stille onzin oplevert; observability ziet dat.

Geen van de drie vervangt de andere. Tests vangen voorspelbare fouten goedkoop op, observability vangt de rest, pipeline-monitoring waakt over de orchestratie.

Twee voorbeelden uit de praktijk

Het stille dashboard
Een marketingteam gebruikt een Looker-dashboard met campagne-prestaties van de laatste dertig dagen. Een upstream Airflow-DAG faalt in stilte op de incrementele load. De pipeline-status blijft groen omdat de fallback op de oude tabel valt. Drie maanden lang werkt iedereen met data die langzaam veroudert. Een freshness-monitor op die tabel had het de eerste ochtend opgepikt.

De schema-explosie
Een bronsysteem voegt een nieuw type event toe aan zijn JSON-payload. De ingest-pipeline parseert braaf alles en plots verveelvoudigt het rij-aantal van een tabel. De analyses die er bovenop draaien rapporteren overschatte conversies. Een volume-monitor en een schema-monitor zien beiden het incident, vaak voor de business-kant het merkt.

De alert-flow die observability-tools meestal hanteren is kort: een anomalie wordt gedetecteerd, een notificatie gaat naar Slack of e-mail van de owner, de tool toont meteen welke downstream-modellen en dashboards in de data lineage hangen, en triage gebeurt op basis van die context.

Waar moet je op letten bij data observability?

Alert fatigue
Drempels te scherp en je verdrinkt in meldingen, te losjes en je mist incidents. De eerste weken na implementatie zijn altijd luidruchtig. Plan tijd in om gevoeligheid bij te stellen op basis van wat echt impact had.

Baselines hebben historie nodig
Statistische detectie werkt op patronen uit het verleden. Op een verse tabel of een verse pipeline heb je weken nodig voor de baselines betrouwbaar zijn. Tot dan: meer false positives.

Een alert zonder owner sterft
Notificaties die in een Slack-kanaal vallen waar niemand verantwoordelijk is, worden weggeklikt. Spreek per dataset of per belangrijke tabel een owner af, laat alerts naar die persoon gaan, hou een logboek van afgehandelde incidents.

Observability vervangt geen tests of contracts
Schrijf nog steeds expliciete tests op de regels die je kent (PK uniek, FK aanwezig, business-rules), en leg een data contract vast met je upstream-bronnen. Observability vult dat aan zonder het te vervangen.

Het prijsmodel kan verrassen
Sommige tools rekenen per gemonitorde tabel of per kolom. Op een brede catalogus van duizenden tabellen loopt dat snel op. Bekijk het prijsmodel voor je elke tabel onder monitoring zet, of selecteer alleen de tabellen die echt in productie gaan.