Data bliver først værdifulde, når de kan flyttes, styres og anvendes sikkert; derfor designer, bygger og driver en dataingeniør de datapipelines, dataplatforme og styringsmekanismer, som gør data brugbare, sikre og pålidelige i en organisation.
I Danmark er rollen blevet mere konkret end den brede fortælling om “big data” antyder. Efterspørgslen kommer især fra organisationer, der moderniserer ældre datavarehuse, flytter analyseplatforme til cloud, indfører lakehouse-arkitekturer eller skal dokumentere datakontrol bedre på grund af GDPR og NIS2. Det gælder i offentlig digitalisering, pharma, energi, finans og større virksomheder med komplekse rapporteringskrav.
Det betyder også, at dataingeniørens arbejde sjældent begynder med avancerede modeller. Det begynder med adgang til de rigtige kilder, stabil ingestion, transformationer der kan gentages, data lineage, kvalitetskontroller og klare aftaler om, hvem der må bruge hvilke data. Rollen er teknisk, men den ligger tæt på forretningens behov, fordi en pipeline uden ejerskab, datakvalitet og driftsoverblik hurtigt bliver en ny flaskehals.
Sidst opdateret: januar 2026. Internationale artikler, som LinkedIns Emerging Jobs Report omtalt af CNBC, viser den tidlige globale vækst i rollen, men danske karrierebeslutninger bør især vurderes ud fra lokale stillingsopslag, branchekrav og teknologistakke.
Hvad dataingeniøren faktisk laver
En dataingeniør bygger forbindelsen mellem datakilder og de mennesker eller systemer, der skal bruge data. Kilderne kan være ERP-systemer, IoT-målinger, fagsystemer, SaaS-platforme, filer, databaser eller streaming-events. Arbejdet består i at hente data ind, rense og strukturere dem, gemme dem rigtigt og gøre dem tilgængelige for rapportering, analyse, maskinlæring eller operationelle applikationer.
I praksis er rollen tæt forbundet med arkitektur og drift. En god pipeline skal ikke blot virke på udviklerens maskine. Den skal kunne genkøres, overvåges, versioneres, fejlfindes og forklares, når en rapport viser noget uventet mandag morgen. Derfor efterspørger arbejdsgivere ofte erfaring med SQL, Python, Spark eller PySpark, datamodellering, orkestrering, cloud storage, CI/CD og infrastruktur som kode.
I mange danske organisationer er Azure en dominerende platform, ofte kombineret med Databricks til lakehouse- og Spark-baserede workloads. Samtidig er mange miljøer hybride, hvor data stadig ligger i lokale databaser, filshares eller ældre datavarehuse, mens analyse- og AI-initiativer flyttes til cloud. Det stiller særlige krav til netværk, identitet, kryptering, privat adgang, dataflytning og omkostningsstyring, fordi datapipelines kan blive dyre, hvis compute, storage og refresh-frekvens ikke designes med omtanke.
Dataingeniør, data scientist og analytics engineer er ikke samme rolle
En hyppig fejl i jobopslag og karriereplanlægning er at blande dataingeniør, data scientist og analytics engineer sammen. Rollerne overlapper, men de løser forskellige problemer. Dataingeniøren skaber datagrundlaget. Data scientisten bygger statistiske eller maskinlæringsbaserede modeller på grundlaget. Analytics engineeren arbejder typisk tættere på BI-laget og omdanner rå eller semi-forædlede data til modeller, metrics og semantiske lag, som analytikere og beslutningstagere kan bruge.
I mindre teams kan én person dække dele af alle tre roller. Det er almindeligt i danske virksomheder, hvor datateams vokser gradvist frem fra BI, økonomi, IT-drift eller analysefunktioner. Hybride profiler bliver derfor mere synlige: en dataingeniør med analytics engineering-kompetencer, eller en dataingeniør der også forstår MLOps nok til at sætte feature pipelines, modeldata og driftsovervågning op.
For den enkelte betyder det, at karrierevalget bør tage udgangspunkt i den type problemer, vedkommende vil løse. Den, der trives med systemdesign, drift, skalerbarhed og dataflow, vil ofte passe godt til data engineering. Den, der helst arbejder med hypoteser, eksperimenter og modelperformance, bør undersøge data science. Den, der gerne vil bygge forretningsnære datamodeller, metrics og BI-fundament, kan finde et stærkt spor i analytics engineering.
Det danske marked: platforme, regulering og domæneforståelse
Danske arbejdsgivere efterspørger sjældent “data engineering” i abstrakt form. De søger personer, der kan få en konkret platform til at fungere i en bestemt reguleret eller forretningskritisk kontekst. I finans handler det ofte om sporbarhed, rapportering og adgangskontrol. I pharma fylder validering, kvalitet og dokumentation meget. I energi kan datavolumen, tidsserier og IoT-lignende mønstre være centrale. I det offentlige spiller fagsystemer, udbudsrealiteter, datasikkerhed og dansk domænesprog ofte en stor rolle.
Det er også her, GDPR og NIS2 ændrer rollen. En moderne dataingeniør skal kunne tale om dataklassifikation, lineage, retention, adgangsstyring og teknisk dokumentation uden at sende alle spørgsmål videre til compliance. Digitaliseringsstyrelsens danske NIS2-vejledning peger på behovet for styring, risikohåndtering og sikkerhedsforanstaltninger; for dataprofessionelle bliver det oversat til kontroller, logging, adskillelse af miljøer, robust identitetshåndtering og dokumenteret ejerskab af datasæt.
Fra et praktisk perspektiv bliver cost management også en del af faget. Cloud gør det let at skalere databehandling, men også let at betale for gentagne batchkørsler, brede Spark-clustre, unødvendig dataduplikering og dårligt partitionerede datasæt. Den dataingeniør, der kan koble teknisk design med FinOps-tankegang, står stærkere end den, der kun kan få en pipeline til at køre én gang.
Løn og efterspørgsel bør vurderes lokalt
Den oprindelige bølge af data engineering-opmærksomhed kom i høj grad fra amerikanske jobrapporter og lønartikler. De kan være nyttige som trendsignal, men de bør ikke bruges som dansk lønbenchmark. Amerikanske lønniveauer, aktiepakker og sundhedsfordele kan ikke oversættes direkte til danske ansættelsesvilkår.
I Danmark bør løn vurderes ud fra kilder som Jobindex, Danmarks Statistik, fagforeningers lønstatistikker og aktuelle stillingsopslag. Tallene varierer betydeligt efter branche, ansvar, platformserfaring, anciennitet, konsulentrolle kontra fastansættelse og geografisk placering. En juniorprofil med stærk SQL og et par solide pipelines vil ikke blive vurderet som en senior data platform engineer med ansvar for governance, sikkerhed, drift og arkitektur.
Et mere realistisk signal end én gennemsnitsløn er kombinationen af stillingsopslag og kravprofil. Når opslag efterspørger Azure, Databricks, Spark, SQL, Python, data governance, Terraform eller Bicep, CI/CD og erfaring med drift, er det et tegn på, at organisationen leder efter produktionskapacitet frem for ren analyse. Det er her projekterfaring ofte vejer tungere end en lang række teoretiske certifikater.
Certificeringer der giver mening, og dem der bør sættes i perspektiv
Certificeringer kan give struktur og et fælles sprog, især for personer der kommer fra BI, softwareudvikling, drift eller dataanalyse. De bør dog vælges efter den platform og rolle, man faktisk sigter mod. Microsoft Certified: Azure Data Engineer Associate med eksamen DP-203 er relevant, når arbejdsgiverens stack er Azure, fordi den validerer arbejde med dataopbevaring, behandling, sikkerhed og integration på Azure. Databricks-certificeringer er mere oplagte, når lakehouse-pipelines på Databricks er kernen i jobbet.
En praktisk progression for mange danske kandidater er at bruge DP-900 som valgfrit fundament, hvis cloud-data er nyt, og derefter arbejde mod DP-203, når målet er produktionspipelines på Azure. DP-100 giver først mening, når personen reelt skal arbejde med machine learning-løsninger, mens AI-102 hører til, når ansvaret omfatter AI-applikationer i Azure. I den sammenhæng bør ældre eller snævre kursuskoder som DP-3014 og DP-3011 ikke forveksles med den bredere Azure Data Engineer Associate-certificering, og MS-721 er ikke en data engineering-certificering.
Readynez kan være relevant, når en kandidat har valgt retning og har brug for struktureret forberedelse til DP-203 eller et beslægtet Azure-spor, men certificeringen bør ikke stå alene. En lille portefølje med PySpark, SQL, datakvalitetstjek, CI/CD og infrastruktur som kode vil i mange interviews sige mere om arbejdsevne end flere certifikater uden produktionserfaring.
En realistisk vej til første produktionspipeline på 60 til 90 dage
Den hurtigste vej ind i data engineering er sjældent at starte med et stort platformsskifte. Det er mere effektivt at vælge ét prioriteret use case og bygge en small-batch pipeline, som har en tydelig datakilde, en defineret modtager og målbare krav til friskhed, kvalitet og omkostning. Det kan eksempelvis være en daglig indlæsning fra et fagsystem til et lakehouse, hvor data valideres, partitioneres og gøres tilgængelige for Power BI eller en analytikergruppe.
En god læringssti begynder med SQL, datamodellering og Python, fortsætter med Spark eller PySpark og kobler derefter cloud storage, identitet, orkestrering og deployment på. Undervejs bør den lærende dokumentere beslutninger: hvorfor data lander i bestemte lag, hvilke felter der er personfølsomme, hvordan fejl håndteres, og hvilke SLO’er der gælder for datafriskhed. Den form for dokumentation er ikke pynt; den viser, at kandidaten forstår drift og governance.
Typiske fejl er at fokusere på modelcertificeringer, før datagrundlaget er stabilt, at undervurdere streaming- eller near-real-time behov, og at ignorere skemaevolution i datasøer. Når kildesystemer ændrer feltnavne, datatyper eller forretningslogik, skal pipeline-designet kunne opdage og håndtere det. Data contracts mellem kildeejer og datateam kan virke formelle i starten, men de reducerer brud og misforståelser senere.
Et stærkt 60 til 90 dages projekt behøver ikke være stort. Det bør derimod være færdigt nok til at vise end-to-end-forståelse: ingestion, transformation, test, sikkerhed, deployment, overvågning og omkostningsbevidsthed. Hvis projektet ligger i GitHub med README, arkitekturbeskrivelse, SQL/PySpark-kode og Bicep eller Terraform, giver det en ansættende leder et langt bedre billede end et CV med uklare kursusnavne.
Hvad ledere bør kigge efter ved ansættelse
En god dataingeniøransættelse handler ikke kun om at matche værktøjsnavne. Kandidaten bør kunne forklare, hvordan data bevæger sig fra kilde til forbrug, hvor fejl typisk opstår, hvordan datakvalitet måles, og hvordan adgang styres. Derudover bør vedkommende kunne diskutere kompromiser mellem batch og streaming, mellem central platform og domæneejet data, og mellem hurtig levering og langsigtet vedligeholdelse.
I danske teams er kommunikation ofte undervurderet. Dataingeniøren skal kunne tale med systemejere, BI-udviklere, compliance, sikkerhed, arkitekter og forretningen. Sprog- og domæneforståelse på dansk kan være afgørende i offentlige eller stærkt regulerede miljøer, hvor datadefinitioner, lovkrav og arbejdsgange ikke kan afklares alene gennem teknisk dokumentation.
Derfor bør tekniske interviews ikke kun teste syntaks. De bør undersøge, hvordan kandidaten tænker om lineage, datakvalitet, rettigheder, omkostninger og drift efter første release. En kandidat, der kan beskrive en mislykket pipeline og forklare, hvordan den blev stabiliseret, kan være mere værdifuld end en kandidat, der kun kan gengive eksamensmål.
Næste skridt for danske dataingeniører
2024 var ikke magisk i sig selv, men det markerede et tidspunkt, hvor data engineering blev en mere moden og nødvendig disciplin i danske organisationer. I 2026 er retningen endnu tydeligere: virksomheder har brug for dataprofessionelle, der kan kombinere platformserfaring med governance, sikkerhed, dokumentation og forretningsforståelse.
Den mest effektive næste handling er at vælge én teknologistak, bygge én fungerende pipeline og bruge certificeringer til at lukke konkrete huller i forståelsen. Læsere, der vil afklare et Azure-baseret læringsspor, kan kontakte Readynez for at få hjælp til at vælge et relevant næste skridt uden at overinvestere i irrelevante certifikater.
