Automatisér MLOps med datakontrakter i datateams

Forestil dig, at din machine-learning-model er en deli­kat sportsvogn. Motoren - selve algoritmen - er velsmurt, men den kører kun problemfrit, hvis brændstoffet (data) leveres med præcis det oktantal, værkstedet (datateamet) har specificeret. En datakontrakt er den tekniske brændstofspecifikation, som alle leverandører forpligter sig til at overholde.

I praksis er en datakontrakt et schema + et sæt regler, der beskriver:

• Hvilke felter (kolonner/keys) der findes - fx customer_id, signup_timestamp, churned.
• Datatyper og tilladte værdimængder - fx churned ∈ {0, 1}.
• Kvalitetskrav - minimum 99 % fuldstændighed, freshness < 15 min, max 0,5 % outliers.
• Sikkerheds- og compliancekrav - ingen rå CPR-numre, PII skal være hashed eller tokeniseret.

Kontrakten fungerer som en formel aftale mellem data-producenten (kilden) og data-konsumenten (ML-pipeline, analytics, rapporter). Når kontrakten versionstyres i Git og valideres i CI/CD-flowet, kan følgende fordele realiseres:

1. Færre brud i ml-pipelines

Når en kolonne fjernes eller skifter datatype, opdages afvigelsen tidligt. Build- eller deploy-processen stopper automatisk, før en fejl rammer produktion og tvinger modellen til at køre på defekt input.

2. Forudsigelighed i features og labels

Feature-engineering-kode (dbt, Spark, Feast) kan stole på, at signup_timestamp altid er i UTC og at churned altid er binary. Det eliminerer “silent” fejl, hvor modellen degraderer gradvist, fordi distributions­skift sniger sig ind.

3. Automatiseret kvalitetssikring på tværs af lagene

• Datalag: Streaming-validering (Kafka-consumer med JSON-schema) og batch-tests (Great Expectations) afviser records, der bryder kontrakten.
• Featurelag: Feature store håndhæver kontrakten, så uforenelige ændringer (fx strukturændring i en entity) afvises.
• Modellag: Training-pipelines logger kontrakt-hash og metadata; ved inferens sammenlignes realtime payload med træningskontrakt for at detektere training-serving skew.

4. Tæt kobling til forretningens kpi’er

Data­kontrakten binder tekniske egenskaber til konkrete forretningsmål:

• KPI: Øge kundelivstidsværdi (LTV) med 7 %.
  Afledt SLO: Churn -model skal have 0-30 min data-freshness, da forældede events reducerer kampagne-relevansen.
• KPI: Nedbringe manuelt fraud-review med 50 %.
  Afledt SLO: Minimum 99,9 % fuldstændighed i transaction_amount og device_id, ellers stiger false negatives.

Ved at gøre SLO’er machine-readable i kontrakten kan dataplatformen auto­generere Service-Level Objective dashboards og alarmere, når SLA’er er i fare.

5. Styrket governance og risikoreduktion

Datakontrakter sætter automatiske “gelændere” for compliance:

• GDPR & PII: Felter markeres som sensitivity: high. Pipelines nægter at skrive data til uregulerede zoner uden kryptering.
• Datasuverænitet: Kontrakten kan specificere, at europæiske data kun må bo i europe-west3. Overtrædelser fanges som build-fejl.
• Audit-trail: Hver gang en kontrakt ændres, signeres den af data-ejeren, så risk & compliance kan spore beslutningen.

Resultatet?

En self-service dataplatform, hvor teams kan udvikle og udrulle modeller hurtigere, fordi fundamentet for skalerbar MLOps - stabile, dokumenterede og overvågede datastrømme - allerede er sikret gennem data­kontrakter.

I en moderne MLOps‐stack er datakontrakten den røde tråd, der binder alt sammen fra rå datakilder til produktions­serving. Nedenfor får du en referencearkitektur, som du kan kopiere eller tilpasse.

1. Kontrakter som kode

1. Schema + regler i Git
   YAML/JSON beskriver feltnavne, datatyper, forventede distributions­grænser, PII‐tagging osv.
   Eksempel:

   { "field": "customer_age", "type": "int", "constraints": {"min": 18, "max": 120}, "privacy": "PII"}

2. Registrering i Schema Registry (Confluent, Apicurio, Glue) sikrer én sandhed på tværs af microservices, batch‐jobs og modeller.
   Version v1, v2, … gemmes med compatibility mode (backward, forward, full).
3. Automatisk diff & pull-request tests (Great Expectations, Soda-SQL) afviser inkompatible ændringer, før de merges til main.

2. Valideringsgate i ci/cd

• Build-step: Docker-image løber great_expectations checkpoint run mod testdata.
• Schema-evolution-check: GitHub Action kalder Schema Registry API og sikrer semver‐takt.
• Fail-fast princippet: Ved brud blokkeres pipeline; ingen artifacts promoveres.

3. Data­bevægelser: Batch vs. Stream

4. Ml-pipeline & feature store

• TFX/MLflow/DVC: Pipeline-steps læser kontrakterne for at generere FeatureSpecs og automatisk validere input/output.
• Feast: Kontraktfelter mappes direkte til feature store schema; on-write validering stopper anomalier før de når modellen.
• Model promotion: Kun versioner der har passeret kontrakttest i både træning og serving, får stage=production.

5. Runtime-overvågning og alarmering

1. Streaming validator indlejres i consumer service (Java/Go eller Python sidecar). Bryder data kontrakten, stoppes forbrug eller dirty records sendes til quarantine topic.
2. Batch validator kører i slutningen af hvert job og skriver metrikker til Prometheus: data_contract_violations_total.
3. Alarmering: Alertmanager eller Opsgenie sender pager hvis SLO for Freshness < 99 % eller Antal brud > threshold.
4. Incident playbooks: Automatisk rollback til sidste gyldige dataset eller Canary freeze af model‐endpoint.

6. Lineage & governance

Med OpenLineage eller DataHub spores kontraktversionen som metadata på hver transformation. Det giver:

• Impact analysis: Se hvilke dashboards og modeller der rammes af en schemaændring.
• PII-flow: Dokumentér hvor persondata flyttes og hvem der er data­ansvarlig.

7. Fordele ved kontraktstyret drift

• Bagudkompatibilitet: Prod-modeller går aldrig ned pga. skjulte kolonneændringer.
• Versionering: En klar audit trail for både data og modelartefakter.
• Automatisk stop/rollback: Fail-fast i CI/CD og runtime sikrer lavere MTTR og højere tillid til ML-løsningen.

Ved at implementere disse byggesten skaber du en selvlukkende kvalitetscirkel, hvor kontrakter ikke blot dokumenterer krav, men aktivt håndhæver dem - hele vejen fra raw data til real-time predictions.

1. Vælg en kritisk use case
   
   • Start dér hvor datakvalitet gør mest ondt - fx en real-time anbefalings­model eller en finansiel risikomotor.
   • Sikr, at både data-producent (domæne-team) og data-konsument (ML-team) har et fælles forretnings­mål (KPI) og budget til at løse problemer hurtigt.
   • Fastlæg succeskriterier: færre incident-timer, hurtigere time-to-recovery (MTTR) og forbedret model-nøjagtighed.
2. Definér kontraktfelter, kvalitetsregler og SLO’er
   
   • Beskriv hvert felt (customer_id, event_timestamp, avg_basket_size) med type, format og semantik.
   • Tilføj regler: nul-tolerance for null i nøgler, domænekontrol (country IN ('DK','NO','SE')), statistisk drift < 5 %.
   • Formuler målbare SLO’er: Friskhed < 30 sek., fuld­stændighed > 99,5 %, nøjagtighed > 99 %.
   • Gem kontrakten som kode (Avro/Protobuf eller YAML) i samme repo som pipelines.
3. Indfør kontrakttest i PR/CI
   
   • Tilføj automatiske schema- og data­tests i Git-workflows (GitHub Actions, GitLab CI).
   • Bloker merge, hvis ændringen ikke er bagud­kompatibel eller bryder SLO-regler.
   • Generér changelog og versionér kontrakten (v1.2.0) automatisk.
4. Udrul validering i orkestrering og i realtid
   
   • Batch: kald Great Expectations/Soda som første task i Airflow/Prefect DAG’en.
   • Stream: indskyd en validation sidecar i Kafka/Flink-pipelines; drop eller rerout beskeder ved brud.
   • Fejl­rapporter sendes til Slack/Teams og PagerDuty med link til kontrakt og lineage-graf.
5. Etabler observabilitet og incident playbooks
   
   • Eksportér metrikker (freshness lag, failed checks) til Prometheus + Grafana.
   • Definér alarmer med severity-nivauer: advarsel ved trend, kritisk ved brud.
   • Lav playbooks: “Stop pipeline”, “Rollback til forrige kontraktversion”, “Genbehandl backlog”.
6. Mål effekter og lær
   
   • Sammenlign MTTR før/efter; målet er < 30 min. ved databrud.
   • Track antal brud pr. måned; gradvis reduktion demonstrerer ROI.
   • Monitorér model-metrics; kontrakt-drevne data bør give mere stabil prædiktiv performance.

Undgå disse anti-patterns

• Skjulte schemaændringer: kolonner omdøbes i kildetabeller uden PR eller version bump - fører til tavse modelfejl.
• Manglende ejerskab: ingen defineret DRI (Directly Responsible Individual) for kontrakten; eskalation går i stå.
• “One-off” validering: tests kun i staging, ikke i produktion - datadrift opdages for sent.

Samspil med data mesh

Datakontrakter er den tekniske handshake mellem domæne-teams (data-producenter) og platform-teamet. De opfylder Data Mesh-principperne om data as a product og self-serve platform:

• Domæne-teamet ejer kontrakten og budgetterer kvaliteten.
• Platform-teamet leverer self-service tooling (registry, CI-templates, validerings-SDK’er).

Governance-roller & change management

Rul kontrakt-disciplinen ud i faser: pilot → udvalgte domæner → organisation. Hold månedlige schema-review boards og brug interne champions til træning. Successen måles på reduceret støj i on-call rotationen og hurtigere time-to-value for nye ML-features.