Deklarative dataplattformer

Deklarative dataplattformer handler ikke om mindre kode, men om bedre abstraksjoner. I stedet for å forklare systemet hvordan du skal brygge kaffen, sier du bare “jeg vil ha en kopp kaffe”.

Fra personlig kode til felles retning

I mange organisasjoner er dataplattformen blitt en mosaikk av scripts, notebooks og manuelle rutiner. Hver utvikler har sin egen måte å hente, rense og modellere data på. Det fungerer – helt til det ikke gjør det.

Når tempoet øker og flere team skal samarbeide, blir denne individuelle friheten en bremsekloss: ting gjøres forskjellig, dokumentasjon mangler, og små feil sprer seg fort.

Derfor ser vi nå en bevegelse mot deklarative dataplattformer – systemer som bygger på felles regler og tydelige beskrivelser, heller enn personlig praksis. Kort sagt: vi vil vekk fra tilfeldige notebooks i PySpark, og mot en plattform som forstår intensjonen – ikke bare koden.

En kopp kaffe og to måter å tenke på

Tenk deg at du skal ha en kopp kaffe.

• I den imperative verden sier du nøyaktig hva som skal skje:
  “Kok 2,5 desiliter vann, mal 18 gram bønner, hell vannet sakte over i 25 sekunder, vent i 3 minutter.”

• I den deklarative verden sier du bare:
  “Hent en kopp kaffe.”

Den første metoden gir full kontroll, men krever at du kjenner hvert steg. Den andre overlater detaljene til systemet – baristaen, maskinen eller prosessen – og fokuserer på resultatet.

Deklarative dataplattformer handler om det samme: å beskrive ønsket tilstand, ikke hvert steg som leder dit.

Fra manuell kontroll til intensjonsbasert styring

Dataplattformer har lenge vært bygget på imperative prinsipper: utvikleren beskriver i detalj hvordan data skal flyttes, transformeres og lastes. Det gir kontroll, men også kompleksitet. Pipelines blir skjøre, endringer tar tid, og teknisk gjeld vokser raskt.

En deklarativ dataplattform snus dette på hodet. I stedet for å beskrive hvordan prosessene skal kjøres, beskriver du hva som skal være sant om dataene – og lar plattformen finne ut hvordan det oppnås.

Flere av de største fremskrittene innen programmering og IT-infrastruktur de siste 15 årene bygger på deklarative prinsipper. Vi ser det i språk som SQL og React, i plattformer som Kubernetes og Terraform, og i verktøy som gjør dataflyt mer selvdokumenterende og selvforvaltende.

Dette markerer et skifte som minner om overgangen fra manuell infrastruktur til Infrastructure as Code. Ford, Parsons og Kua beskrev allerede i Building Evolutionary Architectures (2017) ¹ hvordan komplekse systemer må defineres gjennom fitness functions – deklarative beskrivelser av ønsket tilstand. I 2023 viste Papakonstantinou og kolleger ved University of California, San Diego, hvordan det samme prinsippet kan brukes i data engineering. I Making Data Engineering Declarative (CIDR 2023)² beskriver de hvordan pipelines kan defineres ut fra ønskede egenskaper og invariants – fremfor prosedyrer.

Hva betyr det å definere pipelines ut fra «desired invariants»?

Når Papakonstantinou og kolleger² snakker om desired properties and invariants, mener de at vi ikke lenger beskriver stegene som skal kjøres, men egenskapene som alltid skal være sanne om dataene.

Et invariant er en regel som alltid skal gjelde – uansett hvordan dataene oppdateres. For eksempel:

• alle ordrer skal ha en gyldig customer-id
• customer_sales skal alltid representere den nyeste aggregerte ordresummen per kunde

I stedet for å programmere transformasjonene som oppnår dette, beskriver du hva som skal være sant. Plattformen finner selv ut hvordan og når det må oppdateres. Dette flytter fokuset fra prosedyrer til prinsipper – fra hvordan til hva. Resultatet er mer robuste, testbare og selvforvaltende dataplattformer.

Hva betyr “deklarativ” i praksis?

Å jobbe deklarativt handler om å beskrive intensjonen, ikke oppskriften.

I en tradisjonell pipeline sier du:

«Hent data fra A, transformer det på denne måten, og last resultatet til tabell B.»

I en deklarativ modell sier du:

«Tabell B skal representere kundelønnsomhet basert på de siste ordre- og kostnadsdataene.»

I praksis er det riktigere å si at verktøy som dbt beveger seg i deklarativ retning, men ikke er fullt deklarative. dbt beskriver ønsket modellstruktur, mens selve kjøringen fortsatt er sekvensiell. Likevel gjør dbt mye av det vi ønsker: sikrer riktig rekkefølge, idempotens, dokumentasjon og testing.

Og det er viktig: vi trenger ikke å velge. Ofte starter vi deklarativt – for å skape struktur, transparens og gjenbruk – og justerer detaljer imperativt der vi må.

Fra kode til beskrivelser – og litt YAML

Mange moderne plattformer, som dbt, Dagster og Databricks DLT, bruker deklarative DSL-er (domain-specific languages). Her defineres modeller og pipelines gjerne i YAML eller konfigurasjonsfiler. Det gir lesbarhet, versjonering og en felles måte å uttrykke forretningslogikk på.

De fleste løsninger er hybride: en deklarativ kjerne som håndterer struktur og avhengigheter, kombinert med muligheten til å bruke kode der behovet er spesifikt.
Denne kombinasjonen – deklarativ der du kan, imperativ der du må – gir fleksibilitet uten å ofre oversikt.

Praktiske eksempler

1. Datatransformasjon med dbt

dbt viser hvordan deklarative prinsipper kan brukes i praksis. I stedet for å kode hele prosesseringen, definerer du ønsket modell:

SELECT
    c.id AS customer_id,
    SUM(o.amount) AS total_sales
FROM {{ ref('orders') }} o
JOIN {{ ref('customers') }} c ON o.customer_id = c.id
GROUP BY c.id

ref() lar dbt bygge en avhengighetsgraf. Systemet vet selv rekkefølgen, kan kjøre modeller i parallell, og sikre at endringer spres riktig. Samtidig sørger dbt for idempotente kjøringer, predefinerte tester, dokumentasjon og sporbarhet – alt dette er viktige steg mot mer deklarative plattformer.

2. Infrastruktur som kode med Terraform

Terraform beskriver ønsket tilstand som kode – og sørger for at miljøet faktisk er slik.

resource "google_bigquery_dataset" "sales" {
  dataset_id = "sales"
  location   = "EU"
}

Selv om Terraform er et desired state-system, har det ikke en kontinuerlig kontrollsløyfe. Endringer krever et aktivt “apply”-steg, i motsetning til Kubernetes, som kontinuerlig sørger for samsvar mellom faktisk og ønsket tilstand. Begge er likevel deklarative – forskjellen ligger i graden av autonomi.

3. Deklarativ orkestrasjon med Dagster og Hamilton

Tradisjonelle orkestreringsverktøy som Airflow er prosessorienterte – du beskriver når og hvordan ting skal kjøre. Nyere verktøy som Dagster og Hamilton er dataorienterte: de beskriver dataforhold, ikke arbeidsflyt.

@asset
def sales(raw_sales, customers):
    return join_sales_with_customers(raw_sales, customers)

Dagster forstår automatisk at sales avhenger av raw_sales og customers. Dette gjør pipeline mer selvstyrt og robust for endringer.

4. Datakvalitet som deklarative regler

Deklarative prinsipper passer spesielt godt for datakvalitet. I stedet for scripts defineres kvalitetskrav som regler som alltid skal være sanne.

checks for orders:
  - row_count > 0
  - missing_count(order_id) = 0
  - duplicate_count(order_id) = 0

Dette fungerer som invariants for kvalitet: hvis regelen brytes, oppdager systemet det – og stopper pipeline før feil spres.

Abstraksjoner – kjernen i deklarative systemer

Deklarative systemer handler egentlig om abstraksjoner – hvordan vi beskriver og forholder oss til kompleksitet.

En god abstraksjon lar oss “late som” ting er enklere enn de egentlig er:

• Et filsystem lar oss late som en harddisk er mapper og filer.
• SQL lar oss late som vi spør et logisk datasett, ikke et fysisk lagringssystem.

Abstraksjoner er derfor ikke bare teknikk, men et grensesnitt mellom mennesker og systemer.
Det mest givende arbeidet i dataengineering er å designe gode abstraksjoner: strukturer som skjuler kompleksitet, men bevarer mening. Deklarative systemer er nettopp det – et lag av intensjon over et hav av detaljer.

Modell-drevet dataengineering

Bak de praktiske verktøyene ligger en dypere idé: modell-drevet dataengineering (MDDE). Her beskrives dataforhold og transformasjoner som semantiske modeller, og plattformen genererer kode, dokumentasjon og avhengigheter automatisk.

Fordelene er tydelige:

• Konsistens: én semantisk kilde til sannhet

• Automatisering: pipelines og dokumentasjon genereres

• Transparens: logikken kan forstås som relasjoner, ikke scripts

• Tilpasningsevne: endringer i modellen sprer seg automatisk

Et eksempel:

customer_sales = aggregate(orders, by=customer_id, sum=amount)

Plattformen håndterer SQL, avhengigheter og oppdateringer.

Hvorfor dette betyr noe

Deklarative prinsipper løser mange klassiske DataOps-utfordringer.

Papakonstantinou m.fl. (2023)² beskriver dette som et steg mot “the rigor of relational algebra” – dataengineering nærmer seg endelig samme deterministiske presisjon som relasjonsdatabaser opprinnelig hadde.

Oppsummering

Deklarative dataplattformer er fortsatt i utvikling, men retningen er tydelig. De store aktørene – Databricks, Snowflake og Google Cloud – beveger seg mot intent-based prosessering, der brukeren definerer ønsket datatilstand, og systemet realiserer den. Over tid vil dette endre hvordan datateam jobber. Rollene blir mer modellerende, samarbeidet tettere, og plattformene mer selvstyrte.

Vi er på vei fra «data pipelines» til “data guarantees” – fra systemer som utfører instruksjoner, til systemer som håndhever sannheter.

Deklarative dataplattformer handler ikke om mindre kode, men om bedre abstraksjoner — om å beskrive intensjon i stedet for prosess.

Referanser