Datakontrakter: Sånn passer Norges Bank på dataene sine
– En av fordelene med datakontrakter er at de gir alle parter, utviklere og forretningsbrukere, et felles språk, skriver Vilde Almestad i Norges Bank.
Som utviklere skriver vi kode, definerer API-kontrakter, og setter opp tester som sikrer at systemet vårt gjør akkurat det vi forventer.
Hvis et felt i et API endrer navn eller datatype, får vi umiddelbar feedback – kompilatoren klager, testene feiler, CI/CD-pipelinen stopper, og vi fikser feilen lenge før den når produksjon.
Men ta det samme prinsippet og overfør det til data:
- Tenk deg at du håndterer hundrevis av datastrømmer i stedet for API-er, fra ulike team, med data som flyter mellom systemer du ikke eier.
- Så endrer et annet team semantikken i et felt fra “created_at” til “processed_at”, uten å si ifra.
- Du kan selvfølgelig prøve å rydde opp — skrive nye tester, vaske data og koordinere endringer mellom team. Men det vil raskt vokse til et vedlikeholdsmareritt. Det skalerer ikke når datamengden, antall systemer og behovet for kontinuerlig analyse øker.
Da står man igjen med et grunnleggende spørsmål: Hvem har egentlig ansvaret for at dataen er riktig?
Antageligvis alle som produserer eller bruker dataen. Og for å forventningsstyre alle involverte, så er det hensiktsmessig å lage en avtale mellom disse partene.
I vårt prosjekt tar vi tak i nettopp dette problemet – ved å innføre datakontrakter:
På samme måte som API-kontrakter definerer hvordan systemer snakker sammen, definerer datakontrakter eksplisitte forventninger til dataene våre. De setter eksplisitte forventninger til struktur (schema), eierskap, oppdateringsfrekvens og datakvalitet – og lar oss validere brudd automatisk.
Med hjelp av open-source verktøyet Data Contract CLI definerer vi forventningene til hvert datasett. Det gir oss en oversikt og mulighet til å reagere når data ikke lenger oppfører seg som forventet.
Hva er egentlig Data Contracts?
En datakontrakt er et maskinlesbart dokument – for eksempel skrevet i YAML – som beskriver forventningene til et datasett.
Det er en slags avtale mellom produsenten og konsument av data:
name: customer_silver
version: 1.0.0
owner: [email protected]
models:
customer_silver:
fields:
customer_id:
description: Identifikator til en kunde som har konto hos et foretak.
type: string
primaryKey: true
required: true
email:
description: Eposten til en kunde som har konto hos et foretak.
type: string
required: false
_meta_updated_at:
description: meta data for når tabellen ble sist oppdatert.
type: timestamp
required: true
servicelevels:
freshness:
threshold: 24h
timestamp_field: _meta_updated_at
quality:
type: SodaCL
specification:
checks for customer_silver:
- freshness(_meta_updated_at) < 1d3h
Denne kontrakten sier at dataene ikke skal være eldre enn ett døgn, at customer_id alltid må ha en verdi, og at email må være av typen string.
Når kontrakten valideres, sammenlignes faktisk data med det som har blitt definert. Avvik blir automatisk rapportert, slik at vi kan se når og hvor ting begynner å skli ut. Slik synliggjør vi feilene som gjør det lettere for oss mennesker å følge opp, tolke og handle.
Ferskhet
Når jeg snakker om «ferskhet», mener jeg hvor lenge siden et datasett sist ble oppdatert. Dette måles automatisk på tvers av lag ved hjelp av tidsstempler.
Hvis et datasett overstiger sin definerte maksalder, vil utviklerne få varsel.
Det betyr ikke nødvendigvis at alt er feil - kanskje leverandøren har en god grunn til å ikke levere data, men vi er klar over feilen og kan reagere.
Slik får både utviklerne og forretningsbrukerne en oversikt over hva vi faktisk får og ikke får.
Skjemavalidering
En annen vanlig kilde til problemer er når et felt endrer struktur, eller at det kommer data med rader som inneholder feil i seg.
Plutselig har customer_id blitt en integer i stedet for string, eller at en kolonne email plutselig bare inneholder tall.
På den måten får utviklerne en varsling dersom data avviker fra den definerte strukturen på dataen.
Det betyr ikke at vi låser alt fast. Målet er ikke rigide systemer, men varsling og bevissthet når noe endres.
Et felles språk for data
En av fordelene med datakontrakter er at de gir alle parter, utviklere og forretningsbrukere et felles språk.
- For utviklerne er kontrakten et praktisk verktøy for automatisk validering.
- For forretningsbrukere og andre konsumenter er det et levende dokument som forteller hvilke data som finnes, hva de betyr, hvem som eier dem og hvor ofte de oppdateres.
Forståelse av data vil bli ekstra viktig i en hverdag der kunstig intelligens tar stadig en større plass i hverdagen. Når alle kan lese av det samme dokumentet, blir det færre misforståelser og tydeligere forventninger. Dette bygger tillit ikke bare til tallene, men til hele prosessen bak.
Til syvende og sist handler dette ikke om å lage et perfekt system, men om å forstå virkeligheten bak tallene bedre.
Data vil alltid være i bevegelse, og med datakontrakter får vi et verktøy som hjelper oss å følge med.
