Datakontrakter

Tenk deg at du skal lage en rapport. Du leter deg frem i noen databaser, men så finner du fire forskjellige tabeller som alle heter customers. Hvilken skal du bruke? Er den egentlig oppdatert? Og i hvilken grad kan du stole på dataen?

Når data er spredt, dårlig dokumentert, og med uklar eierskap, bruker vi unødvendig mye tid på å lete etter-, undersøke- og validere data som er produsert av andre.

Her kommer datakontrakter inn i bildet.

Datakontrakter er en av grunnsteinene for organisasjoner som ønsker å bli datadrevne. De skaper felles forventninger mellom produsenter og konsumenter av data. De bryter ned datasiloer, gjør det enklere å dele og forstå data, og gjør det tryggere å bruke data.
‍

Hva er en datakontrakt?

En datakontrakt er et sett med definisjoner og regler om hvordan et datasett skal være bygget opp. Det fungerer som en avtale mellom dem som endrer et datasett, og dem som konsumerer det.

Målet med en datakontrakt er å avklare forventninger mellom konsument og produsent. Det gjør at konsumentene kan forstå datasettet bedre, og samtidig stole på at datasettet er- og forblir slik de forventer at det skal være.

I tillegg finnes det mange verktøy og systemer som kan bruke datakontrakter til å utføre automatisk validering. Det gjør det mulig å oppdage avvik tidlig og sikre at datasettet faktisk følger kontrakten.

En datakontrakt kan inneholde:
‍

• Skjemaet til datasettet: hvilke felter og kolonner finnes, hvilke datatyper er de hvilke felt er påkrevd.
  ‍
• Hva dataen betyr: Hva er meningen bak feltene, og hvor kommer de fra.
  ‍
• Valideringsregler på datasettet: Påkrevde relasjoner til andre datasett, forventet snittverdi på kolonner, minimum- og maksimumverdi på kolonner og andre valideringsregler.
  ‍
• Versjonen til datakontrakten
  ‍
• Governance og SLAer: forventet oppdateringsfrekvens på datasettet, informasjon om sensitiviteten på dataen, governance krav

Hvordan ser en datakontrakt ut?
‍

Det finnes ikke én dominerende standard innenfor datakontrakter. Det er likevel noen aktører som skiller seg ut og er verdt å se på.

• DBT model schemas - brukt i datateam som jobber med analyse og transformasjon i DBT.
  ‍
• Databricks Unity Catalog - For aktører som er tett knyttet til Databricks
  ‍
• Open Data Contract Standard, som er laget og open-sourcet av Paypal
  ‍

La oss se på et eksempel på en datakontrakt basert på Open Data Contract Standard. Her defineres kontrakten i en tekstfil (YAML-format), og den sier noe om hvilke kolonner som finnes i et datasett, hva de betyr, og hvilke regler som gjelder for innholdet.
‍

Med denne kontrakten blir det enklere for de som bruker datasettet hva hver kolonne betyr, hvilke verdier man kan forvente, og hvilke regler som gjelder. Samtidig kan programvare automatisk sjekke at dataene følger reglene.
‍

Andre nyttige ting i en datakontrakt
‍

I tillegg til å beskrive selve datastrukturen, kan en datakontrakt også inneholde praktisk informasjon og metainformasjon om datasettet. Eksempler på slik informasjon kan være:
‍

• Oppdateringsfrekvens: Hvor ofte datasettet blir oppdatert (for eksempel hver time, daglig, månedlig).
  ‍
• End of support: Når datasettet ikke lenger blir vedlikeholdt eller støttet.
  ‍
• Fysisk lokasjon: Hvor datasettet er lagret (for eksempel region i Azure eller land).
  ‍
• Datakvalitet og roller: Forventet kvalitet på dataene og hvem som har ansvar for den.
  ‍
• Prisinformasjon: Eventuelle kostnader knyttet til bruk, lagring eller konsum av datasettet.
  ‍
• Governance-informasjon: Regler og krav datasettet må følge, for eksempel om det inneholder personopplysninger (PII), følger GDPR, og hvem som er ansvarlig for datasettet.
  ‍

Under ser du et eksempel på hvordan noen av disse punktene kan spesifiseres i en datakontrakt, ved hjelp av Open Data Contract Standard:
‍

Ved å ha med denne typen informasjon blir det enklere for konsumentene å ta i bruk datasettet på riktig måte og kan fjerne usikkerhet rundt eierskap og sikkerhetskrav.
‍

Automatisk validering av datasettet
‍

For å være sikker på at et datasett følger datakontrakten er det hensiktsmessig å ha automatiske sjekker på plass. Dette kan gjøres på flere måter:
‍

• Implisitt skjema-validering i verktøy eller filformat. Noen filformater, som Parquet og Avro, passer på at skjemaet stemmer. Det samme gjør mange databaser, for eksempel PostgreSQL, som validerer skjemaet automatisk, og feiler oppdateringen av tabellen dersom de ikke oppfyller skjemaet. Dette gjelder kun skjemavalidering, og vil ikke sjekke mer komplekse sjekker som oppdateringsfrekvens, eller antall rader i datasettet.
  ‍
• Validering in-motion. Her sjekkes dataene før de blir en del av datasettet, og datasettet vil dermed alltid oppfylle kontrakten. Likevel er dette begrenset til å omfatte enkle sjekker på rad-nivå, og mer sammensatte valideringer som går på hele tabellen vil ikke være mulig.
  ‍
• Validering at rest. Da valideres hele datasettet etter at det har blitt oppdatert, for å være sikker på at alt er som det skal. Dersom sjekken er gyldig kan transaksjonen rulles tilbake, eller de feilaktige radene kan filtreres ut.
  ‍

Det finnes mange gode verktøy for datavalidering:
‍

• Data Contract Manager
  
  https://github.com/datacontract-manager/datacontract-manager-ce?ref=dma-dp
  Et verktøy som brukes til å validere datakontrakter basert på Open Data Contract Standard.
  
  
• Innebygd validering i DBT
  
  DBT har støtte for validering og testing av data direkte i modellen, basert på DBT model schemas.
  
  
• Great Expectations
  
  Et pythonrammeverk som lar deg definere og sjekke datakvalitet gjennom såkalte "expectations" (forventninger) på datasett.
  
  

Hvordan deles datakontraktene?

Som regel har hvert datasett en dataeier. Det er dataeieren som har ansvaret for at datakontrakten er tilgjengelig, oppdatert og at den er riktig. Det er vanlig å plassere datakontrakter i de samme repositoriene som koden for å definere datasettene. Noen ganger samler organisasjonen alle datakontraktene i en felles datakatalog, så det blir lett å få oversikt.

‍