Kort svar: AI vil ikke erstatte dataingeniører fullstendig; den vil automatisere repeterende arbeid som SQL-utkasting, pipeline-stillas, tester og dokumentasjon. Hvis rollen din for det meste er arbeid med lavt eierskap og saksbehandling, er den mer utsatt. Hvis du eier pålitelighet, definisjoner, styring og hendelsesrespons, gjør AI deg hovedsakelig raskere.
Viktige konklusjoner:
Eierskap : Prioriter ansvarlighet for resultater, ikke bare å produsere kode raskt.
Kvalitet : Bygg tester, observerbarhet og kontrakter slik at pipelines forblir pålitelige.
Styring : Hold personvern, tilgangskontroll, oppbevaring og revisjonsspor menneskeeid.
Motstand mot misbruk : Behandle AI-utdata som utkast; gjennomgå dem for å unngå selvsikre feil.
Rolleskifte : Bruk mindre tid på å skrive standardtekster og mer tid på å designe slitesterke systemer.

Hvis du har brukt mer enn fem minutter rundt datateam, har du hørt refrenget – noen ganger hvisket, noen ganger slengt utover i et møte som en plottwist: Vil AI erstatte dataingeniører?
Og … jeg skjønner det. AI kan generere SQL, bygge pipelines, forklare stakkspor, utarbeide dbt-modeller, til og med foreslå lagerskjemaer med urovekkende selvtillit. GitHub Copilot for SQL Om dbt-modeller GitHub Copilot
Det føles som å se en gaffeltruck lære å sjonglere. Imponerende, litt alarmerende, og du er ikke helt sikker på hva det betyr for jobben din 😅
Men sannheten er mindre ryddig enn overskriften. AI forandrer datateknikk fullstendig. Den automatiserer de kjedelige, repeterbare delene. Den fremskynder «jeg vet hva jeg vil, men kan ikke huske syntaksen»-øyeblikkene. Den avler også helt nye typer kaos.
Så la oss legge det opp ordentlig, uten håndbølget optimisme eller doom-scrolling-panikk.
Artikler du kanskje vil lese etter denne:
🔗 Vil AI erstatte radiologer?
Hvordan bildebehandling med kunstig intelligens endrer arbeidsflyt, nøyaktighet og fremtidige roller.
🔗 Vil AI erstatte regnskapsførere?
Se hvilke regnskapsoppgaver AI automatiserer og hva som forblir menneskelig.
🔗 Vil AI erstatte investeringsbankfolk?
Forstå AIs innvirkning på avtaler, research og kunderelasjoner.
🔗 Vil AI erstatte forsikringsagenter?
Lær hvordan AI forvandler underwriting, salg og kundesupport.
Hvorfor spørsmålet «AI erstatter dataingeniører» stadig dukker opp igjen 😬
Frykten kommer fra et veldig spesifikt sted: datateknikk har mye repeterbart arbeid .
-
Skriving og refaktorering av SQL
-
Bygge inntaksskript
-
Tilordne felt fra ett skjema til et annet
-
Lage tester og grunnleggende dokumentasjon
-
Feilsøking av pipeline-feil som er ... liksom forutsigbare
AI er uvanlig god på repeterbare mønstre. Og en del av datateknikk er nettopp det – mønstre stablet på mønstre. GitHub Copilot-kodeforslag
Verktøyøkosystemet «skjuler» allerede kompleksiteten:
-
Administrerte ELT-kontakter Fivetran-dokumentasjon
-
Serverløs databehandling AWS Lambda (serverløs databehandling)
-
Lageroppsett med ett klikk
-
Dokumentasjon for automatisk skalering av orkestrering av
-
Deklarative transformasjonsrammeverk Hva er dbt?
Så når AI dukker opp, kan det føles som den siste brikken. Hvis stakken allerede er abstrahert, og AI kan skrive limkoden … hva er igjen? 🤷
Men her er det folk hopper over: datateknikk handler ikke hovedsakelig om å skrive . Skriving er den enkle delen. Den vanskelige delen er å få en dunkel, politisk, skiftende forretningsvirkelighet til å oppføre seg som et pålitelig system.
Og AI sliter fortsatt med det uklarheten. Folk sliter også – de improviserer bare bedre.
Hva dataingeniører faktisk gjør hele dagen (den lite glamorøse sannheten) 🧱
La oss være ærlige – stillingstittelen «Dataingeniør» høres ut som om du bygger rakettmotorer av ren matematikk. I praksis bygger du tillit .
En typisk dag går mindre ut på å «finne opp nye algoritmer» og mer på å:
-
Forhandling med oppstrømsteam om datadefinisjoner (smertefullt, men nødvendig)
-
Undersøke hvorfor en måleenhet endret seg (og om den er reell)
-
Håndtering av skjemaavvik og overraskelser knyttet til «noen la til en kolonne ved midnatt»
-
Sikre at rørledninger er idempotente, utvinnbare og observerbare
-
Lage beskyttelsesrekkverk slik at nedstrømsanalytikere ikke ved et uhell bygger tulldashboards
-
Administrer kostnader slik at lageret ditt ikke blir til et pengebål 🔥
-
Sikring av tilgang, revisjon, samsvar, oppbevaringsregler GDPR-prinsipper (Europakommisjonen) Lagringsbegrensning (ICO)
-
Å bygge dataprodukter som folk faktisk kan bruke uten å sende deg en direktemelding, 20 spørsmål
En stor del av jobben er sosial og operativ:
-
«Hvem eier dette bordet?»
-
«Er denne definisjonen fortsatt gyldig?»
-
«Hvorfor eksporterer CRM-systemet duplikater?»
-
«Kan vi formidle denne målingen til ledere uten å bli flaue?» 😭
AI kan hjelpe med deler av dette, ja visst. Men å erstatte det helt er ... en utfordring.
Hva gjør en dataingeniørrolle til en sterk versjon? ✅
Denne delen er viktig fordi det vanligvis antas at dataingeniører hovedsakelig er «rørledningsbyggere». Det er som å anta at kokker hovedsakelig «hakker grønnsaker». Det er en del av jobben, men det er ikke jobben.
En sterk versjon av en dataingeniør betyr vanligvis at de kan gjøre det meste av dette:
-
Design for endring
. Data endres. Team endres. Verktøy endres. En god ingeniør bygger systemer som ikke kollapser hver gang virkeligheten nyser 🤧 -
Definer kontrakter og forventninger
Hva betyr «kunde»? Hva betyr «aktiv»? Hva skjer når en rad ankommer for sent? Kontrakter forhindrer kaos mer enn fancy kode gjør. Open Data Contract Standard (ODCS) ODCS (GitHub) -
Bygg observerbarhet inn i alt.
Ikke bare «kjørte det», men «kjørte det riktig». Ferskhet, volumavvik, nulleksplosjoner, fordelingsskift. Dataobserverbarhet (Dynatrace) Hva er dataobserverbarhet? -
Gjør avveininger som en voksen:
Hastighet vs. korrekthet, kostnad vs. latens, fleksibilitet vs. enkelhet. Det finnes ingen perfekt pipeline, bare pipelines du kan leve med. -
Oversett forretningsbehov til holdbare systemer.
Folk ber om målinger, men det de trenger er et dataprodukt. AI kan utarbeide koden, men den kan ikke magisk vite hva som er forretningsminene. -
Hold data hemmelig.
Den største komplimenten for en dataplattform er at ingen snakker om den. Hendelsesløse data er gode data. Som rørleggerarbeid. Du legger bare merke til det når det svikter 🚽
Hvis du gjør disse tingene, begynner spørsmålet «Vil AI erstatte dataingeniører?» å høres … litt rart ut. AI kan erstatte oppgaver , ikke eierskap .
Der AI allerede hjelper dataingeniører (og det er virkelig flott) 🤖✨
AI er ikke bare markedsføring. Brukt riktig er det en legitim kraftmultiplikator.
1) Raskere SQL- og transformasjonsarbeid
-
Utarbeide komplekse sammenføyninger
-
Å skrive vindusfunksjoner du helst ikke vil tenke på
-
Å gjøre logikk fra vanlig språk om til spørreskjeletter
-
Refaktorering av stygge spørringer til lesbare CTE-er GitHub Copilot for SQL
Dette er enormt fordi det reduserer effekten av «blanke ark». Du må fortsatt validere, men du starter på 70 % i stedet for 0 %.
2) Feilsøking og brødsmuler for rotårsak
AI er grei på:
-
Forklaring av feilmeldinger
-
Forslag til hvor man skal lete
-
Anbefaler trinn av typen «sjekk skjemaavvik» GitHub Copilot
Det er som å ha en utrettelig junioringeniør som aldri sover og noen ganger lyver selvsikkert 😅
3) Dokumentasjon og berikelse av datakataloger
Automatisk generert:
-
Kolonnebeskrivelser
-
Modellsammendrag
-
Avstamningsforklaringer
-
«Hva brukes denne tabellen til?» utarbeider DBT-dokumentasjon
Det er ikke perfekt, men det bryter forbannelsen med udokumenterte rørledninger.
4) Test stillas og kontroller
AI kan foreslå:
-
Grunnleggende nulltester
-
Unikhetskontroller
-
Ideer om referanseintegritet
-
«Denne metrikken skal aldri avta»-stilpåstander dbt-datatester Store forventninger: Forventninger
Igjen – du bestemmer fortsatt hva som betyr noe, men det fremskynder rutinedelene.
5) Kode for «lim» i rørledningen
Konfigurasjonsmaler, YAML-stillas, orkestrerings-DAG-utkast. De tingene er repetitive, og AI spiser repetitivt til frokost 🥣 Apache Airflow DAG-er
Der AI fortsatt sliter (og dette er kjernen i det) 🧠🧩
Dette er den delen som betyr mest, fordi den svarer på erstatningsspørsmålet med ekte tekstur.
1) Tvetydighet og skiftende definisjoner
Forretningslogikk er sjelden skarp. Folk ombestemmer seg midt i en setning. «Aktiv bruker» blir til «aktiv betalende bruker» blir til «aktiv betalende bruker uten refusjoner, unntatt noen ganger» ... du vet hvordan det er.
AI kan ikke eie den tvetydigheten. Den kan bare gjette.
2) Ansvarlighet og risiko
Når en pipeline går i stykker og lederdashbordet viser tull, må noen:
-
triage
-
kommunisere effekt
-
fikse det
-
forhindre gjentakelse
-
skriv obduksjonen
-
avgjøre om bedriften fortsatt kan stole på forrige ukes tall
AI kan hjelpe, men den kan ikke være ansvarlig på en meningsfull måte. Organisasjoner drives ikke av vibrasjoner – de drives av ansvar.
3) Systemtenkning
Dataplattformer er økosystemer: inntak, lagring, transformasjoner, orkestrering, styring, kostnadskontroll, tjenestenivåavtaler. En endring på ett lag gir ringvirkninger. Apache Airflow-konsepter
AI kan foreslå lokale optimaliseringer som skaper global smerte. Det er som å fikse en knirkende dør ved å fjerne døren 😬
4) Sikkerhet, personvern, samsvar
Det er her erstatningsfantasier dør.
-
Tilgangskontroller
-
Radnivåsikkerhet Snowflake-retningslinjer for radtilgang BigQuery-radnivåsikkerhet
-
Håndtering av personlig identifiserende informasjon (PII) i NIST Privacy Framework
-
Oppbevaringsregler Lagringsbegrensning (ICO) EU-veiledning om oppbevaring
-
Revisjonsspor NIST SP 800-92 (logghåndtering) CIS Control 8 (håndtering av revisjonslogg)
-
Begrensninger for dataoppbevaring
AI kan utarbeide retningslinjer, men å implementere dem på en sikker måte er ekte ingeniørkunst.
5) De «ukjente ukjente»
Datahendelser er ofte uforutsigbare:
-
Et leverandør-API endrer semantikk i stillhet
-
En antagelse om tidssone endres
-
En tilbakefylling dupliserer en partisjon
-
En mekanisme for nye forsøk forårsaker dobbeltskriving
-
En ny produktfunksjon introduserer nye hendelsesmønstre
AI er svakere når situasjonen ikke er et kjent mønster.
Sammenligningstabell: hva reduserer hva, i praksis 🧾🤔
Nedenfor er et praktisk perspektiv. Ikke «verktøy som erstatter mennesker», men verktøy og tilnærminger som krymper visse oppgaver.
| Verktøy / tilnærming | Publikum | Prisstemning | Hvorfor det fungerer |
|---|---|---|---|
| AI-kode-copiloter (SQL + Python-hjelpere) GitHub Copilot | Ingeniører som skriver mye kode | Gratis-aktig til betalt | God på stillasering, refaktorering, syntaks ... noen ganger selvtilfreds på en veldig spesifikk måte |
| Administrerte ELT-kontakter Fivetran | Teamene er lei av å bygge inntak | Abonnement-y | Fjerner smerten ved tilpasset inntak, men bryter ned på morsomme nye måter |
| Dataobservasjonsplattformer Dataobservabilitet (Dynatrace) | Alle som eier tjenestenivåavtaler | Mellomstor til bedrift | Oppdager avvik tidlig – som røykvarslere for rørledninger 🔔 |
| Transformasjonsrammeverk (deklarativ modellering) dbt | Analyse + DE-hybrider | Vanligvis verktøy + beregning | Gjør logikken modulær og testbar, mindre spaghetti |
| Datakataloger + semantiske lag dbt semantisk lag | Organisasjoner med forvirring rundt metrikk | Avhenger av, i praksis | Definerer «sannhet» én gang – reduserer endeløse debatter om metriske data |
| Orkestrering med maler Apache Airflow | Plattformbevisste lag | Åpen + driftskostnad | Standardiserer arbeidsflyter; færre snøfnugg-DAG-er |
| AI-assistert dokumentasjon DBT-dokumentgenerering | Lag som hater å skrive dokumenter | Billig til moderat | Lager «gode nok» dokumenter slik at kunnskapen ikke forsvinner |
| Automatiserte styringspolicyer NIST Privacy Framework | Regulerte miljøer | Enterprise-y | Bidrar til å håndheve regler – men trenger fortsatt mennesker til å utforme reglene |
Legg merke til hva som mangler: en rad som sier «trykk på knappen for å fjerne dataingeniører». Ja ... den raden finnes ikke 🙃
Så ... vil AI erstatte dataingeniører, eller bare endre rollen? 🛠️
Her er det ikke-dramatiske svaret: AI vil erstatte deler av arbeidsflyten, ikke yrket.
Men det vil omkonfigurere rollen. Og hvis du ignorerer det, vil du føle presset.
Hva som endres:
-
Mindre tid på å skrive standardtekster
-
Mindre tid på å søke i dokumenter
-
Mer tid til gjennomgang, validering og design
-
Mer tid til å definere kontrakter og kvalitetsforventninger Open Data Contract Standard (ODCS)
-
Mer tid til samarbeid med produkt, sikkerhet og finans
Dette er det subtile skiftet: datateknikk handler mindre om å «bygge pipelines» og mer om å «bygge et pålitelig dataproduktsystem»
Og i en stille vri, det er mer verdifullt, ikke mindre.
I tillegg – og jeg kommer til å si dette selv om det høres dramatisk ut – øker AI antallet personer som kan produsere dataartefakter , noe som øker behovet for noen som kan holde hele greia i orden. Mer output betyr mer potensiell forvirring. GitHub Copilot
Det er som å gi alle en elektrisk drill. Flott! Nå må noen håndheve regelen om «ikke bor i vannrøret» 🪠
Den nye ferdighetsstakken som forblir verdifull (selv med AI overalt) 🧠⚙️
Hvis du ønsker en praktisk «fremtidssikker» sjekkliste, ser den slik ut:
Tankegang innen systemdesign
-
Datamodellering som overlever endringer
-
Avveininger mellom batch og strømming
-
Tenkning om latens, kostnad og pålitelighet
Datakvalitetsteknikk
-
Kontrakter, valideringer, avviksdeteksjon Open Data Contract Standard (ODCS) Dataobservabilitet (Dynatrace)
-
SLA-er, SLO-er, vaner for hendelseshåndtering
-
Rotårsaksanalyse med disiplin (ikke vibrasjoner)
Styring og tillitsarkitektur
-
Tilgangsmønstre
-
Reviderbarhet NIST SP 800-92 (logghåndtering)
-
Personvern gjennom design NISTs personvernrammeverk
-
EU-veiledning om oppbevaring av datalivssyklus
Plattformtenkning
-
Gjenbrukbare maler, gylne stier
-
Standardiserte mønstre for inntak, transformasjoner og testing av Fivetran dbt-datatester
-
Selvbetjent verktøy som ikke smelter ned
Kommunikasjon (ja, virkelig)
-
Å skrive tydelige dokumenter
-
Justering av definisjoner
-
Å si «nei» høflig, men bestemt
-
Forklarer avveininger uten å høres ut som en robot 🤖
Hvis du kan gjøre dette, blir spørsmålet «Vil AI erstatte dataingeniører?» mindre truende. AI blir ditt eksoskjelett, ikke din erstatning.
Realistiske scenarier der noen dataingeniørroller krymper 📉
Ok, en kjapp realitetssjekk, for det er ikke bare solskinn og emoji-konfetti 🎉
Noen roller er mer utsatt:
-
Rene inntaksroller der alt er standardkoblinger Fivetran-koblinger
-
Team som stort sett utfører repeterende rapporteringsprosesser med minimale nyanser innen domenet
-
Organisasjoner der datateknikk blir behandlet som «SQL-aper» (strengt, men sant)
-
Stillinger med lavt eierskap der jobben bare er billetter og kopiering og liming
AI pluss administrerte verktøy kan redusere disse behovene.
Men selv der ser erstatning vanligvis slik ut:
-
Færre personer gjør det samme repeterende arbeidet
-
Mer vekt på plattformeierskap og pålitelighet
-
Et skifte mot «én person kan støtte flere rørledninger»
Så ja – antall ansatte kan endre seg. Roller utvikler seg. Titler skifter. Den delen er reell.
Likevel holder versjonen av rollen med høyt eierskap og høy tillit seg.
Avsluttende oppsummering 🧾✅
Vil AI erstatte dataingeniører? Ikke på den rene, helhetlige måten folk forestiller seg.
AI vil:
-
automatisere repeterende oppgaver
-
akselerer koding, feilsøking og dokumentasjon GitHub Copilot for SQL dbt-dokumentasjon
-
redusere kostnadene ved å produsere rørledninger
Men datateknikk handler fundamentalt om:
-
ansvarlighet
-
systemdesign
-
tillit, kvalitet og styring Open Data Contract Standard (ODCS) NIST Privacy Framework
-
oversette dyster forretningsvirkelighet til pålitelige dataprodukter
AI kan hjelpe med det ... men den «eier» det ikke.
Hvis du er dataingeniør, er overgangen enkel (ikke lett, men enkel):
ta ansvar for eierskap, kvalitet, plattformtenkning og kommunikasjon. La AI håndtere standardløsningene mens du håndterer de delene som betyr noe.
Og ja - noen ganger betyr det å være den voksne i rommet. Ikke glamorøs. Men stille og kraftfull 😄
Vil AI erstatte dataingeniører?
Den vil erstatte noen oppgaver, omstokke karrierestigen og gjøre de beste dataingeniørene enda mer verdifulle. Det er den virkelige historien.
Vanlige spørsmål
Vil AI erstatte dataingeniører fullstendig?
I de fleste organisasjoner er det mer sannsynlig at AI overtar spesifikke oppgaver enn å viske ut rollen fullstendig. Det kan akselerere SQL-utkast, pipeline-stillas, førstegangsgodkjenninger av dokumentasjon og grunnleggende testoppretting. Men datateknikk innebærer også eierskap og ansvarlighet, pluss det lite glamorøse arbeidet med å få rotete forretningsvirkelighet til å oppføre seg som et pålitelig system. Disse delene trenger fortsatt mennesker for å bestemme hva som er «riktig» og for å ta ansvar når ting går i stykker.
Hvilke deler av datateknikk automatiserer AI allerede?
AI fungerer best på repeterbart arbeid: utarbeidelse og refaktorering av SQL, generering av DBT-modellskjeletter, forklaring av vanlige feil og produksjon av dokumentasjonsoversikter. Den kan også stillase tester som null- eller unikhetskontroller og generere mal-"lim"-kode for orkestreringsverktøy. Seieren er momentum – du begynner nærmere en fungerende løsning – men du må fortsatt validere korrektheten og sørge for at den passer til miljøet ditt.
Hvis AI kan skrive SQL og pipelines, hva er da igjen for dataingeniører?
Mye: definere datakontrakter, håndtere skjemaavvik og sørge for at pipelines er idempotente, observerbare og gjenopprettbare. Dataingeniører bruker tid på å undersøke endringer i metrikkdata, bygge rekkverk for nedstrømsbrukere og håndtere avveininger mellom kostnader og pålitelighet. Jobben handler ofte om å bygge tillit og holde dataplattformen «stille», som betyr stabil nok til at ingen trenger å tenke på den daglig.
Hvordan endrer AI det daglige arbeidet til en dataingeniør?
Det reduserer vanligvis standard- og «oppslagstid», slik at du bruker mindre tid på å skrive og mer tid på å gjennomgå, validere og designe. Dette skiftet dytter rollen mot å definere forventninger, kvalitetsstandarder og gjenbrukbare mønstre i stedet for å kode alt for hånd. I praksis vil du sannsynligvis gjøre mer partnerskapsarbeid med produkt, sikkerhet og finans – fordi det tekniske resultatet blir enklere å lage, men vanskeligere å styre.
Hvorfor sliter AI med tvetydige forretningsdefinisjoner som «aktiv bruker»?
Fordi forretningslogikk ikke er statisk eller presis – den endres midt i prosjektet og varierer fra interessent til interessent. AI kan utarbeide en tolkning, men den kan ikke ta ansvar for avgjørelsen når definisjoner utvikler seg eller konflikter dukker opp. Datateknikk krever ofte forhandlinger, dokumentasjon av antagelser og omdanning av uklare krav til varige kontrakter. Dette arbeidet med «menneskelig justering» er en sentral grunn til at rollen ikke forsvinner selv om verktøyene forbedres.
Kan AI håndtere datastyring, personvern og samsvar på en sikker måte?
AI kan bidra til å utarbeide retningslinjer eller foreslå tilnærminger, men sikker implementering krever fortsatt reell ingeniørkunst og nøye tilsyn. Styring innebærer tilgangskontroller, håndtering av personopplysninger, oppbevaringsregler, revisjonsspor og noen ganger begrensninger i bostedsforhold. Dette er høyrisikoområder der «nesten riktig» ikke er akseptabelt. Mennesker må utforme reglene, verifisere håndheving og forbli ansvarlige for samsvarsresultater.
Hvilke ferdigheter forblir verdifulle for dataingeniører etter hvert som AI forbedres?
Ferdigheter som gjør systemer robuste: systemdesigntenkning, datakvalitetsteknikk og plattformorientert standardisering. Kontrakter, observerbarhet, vaner for hendelsesrespons og disiplinert rotårsaksanalyse blir enda viktigere når flere mennesker raskt kan generere dataartefakter. Kommunikasjon blir også en differensierende faktor – å samkjøre definisjoner, skrive tydelige dokumenter og forklare avveininger uten dramatikk er en stor del av å holde data troverdige.
Hvilke datatekniske roller er mest utsatt for AI og administrerte verktøy?
Roller som fokuserer snevert på repeterende inntak eller standard rapporteringsrørledninger er mer utsatt, spesielt når administrerte ELT-koblinger dekker de fleste kilder. Arbeid med lavt eierskap og saksbehandling kan krympe fordi AI og abstraksjon reduserer innsatsen per rørledning. Men dette ser vanligvis ut som færre personer som gjør repeterende oppgaver, ikke «ingen dataingeniører». Roller med høyt eierskap sentrert rundt pålitelighet, kvalitet og tillit forblir holdbare.
Hvordan bør jeg bruke verktøy som GitHub Copilot eller dbt med AI uten å skape kaos?
Behandle AI-utdata som et utkast, ikke en beslutning. Bruk det til å generere spørreskjeletter, forbedre lesbarheten eller bygge opp DBT-tester og dokumenter, og valider deretter mot reelle data og kanttilfeller. Kombiner det med sterke konvensjoner: kontrakter, navnestandarder, observerbarhetskontroller og gjennomgangspraksis. Målet er raskere levering uten å ofre pålitelighet, kostnadskontroll eller styring.
Referanser
-
Europakommisjonen - Forklaring av databeskyttelse: GDPR-prinsipper - commission.europa.eu
-
Informasjonskommisjonærens kontor (ICO) – Lagringsbegrensning – ico.org.uk
-
Europakommisjonen – Hvor lenge kan data lagres, og er det nødvendig å oppdatere dem? – commission.europa.eu
-
Nasjonalt institutt for standarder og teknologi (NIST) – personvernrammeverk – nist.gov
-
NISTs ressurssenter for datasikkerhet (CSRC) – SP 800-92: Veiledning for håndtering av datasikkerhetslogger – csrc.nist.gov
-
Senter for Internettsikkerhet (CIS) – Administrasjon av revisjonslogger (CIS-kontroller) – cisecurity.org
-
Snowflake-dokumentasjon – Retningslinjer for radtilgang – docs.snowflake.com
-
Google Cloud-dokumentasjon – BigQuery-sikkerhet på radnivå – docs.cloud.google.com
-
BITOL – Standard for åpne datakontrakter (ODCS) v3.1.0 – bitol-io.github.io
-
BITOL (GitHub) – Standard for åpne datakontrakter – github.com
-
Apache Airflow – Dokumentasjon (stabil) – airflow.apache.org
-
Apache Airflow - DAG-er (kjernekonsepter) - airflow.apache.org
-
dbt Labs-dokumentasjon - Hva er dbt? - docs.getdbt.com
-
dbt Labs-dokumentasjon - Om dbt-modeller - docs.getdbt.com
-
dbt Labs-dokumentasjon - Dokumentasjon - docs.getdbt.com
-
dbt Labs-dokumentasjon - Datatester - docs.getdbt.com
-
dbt Labs-dokumentasjon - dbt semantisk lag - docs.getdbt.com
-
Fivetran-dokumentasjon - Komme i gang - fivetran.com
-
Fivetran - Kontakter - fivetran.com
-
AWS-dokumentasjon – AWS Lambda-utviklerveiledning – docs.aws.amazon.com
-
GitHub – GitHub Copilot – github.com
-
GitHub-dokumentasjon – Få kodeforslag i IDE-en din med GitHub Copilot – docs.github.com
-
Microsoft Learn – GitHub Copilot for SQL (VS Code-utvidelse) – learn.microsoft.com
-
Dynatrace-dokumentasjon - Dataobservabilitet - docs.dynatrace.com
-
DataGalaxy – Hva er dataobserverbarhet? – datagalaxy.com
-
Dokumentasjon om store forventninger - Oversikt over forventninger - docs.greatexpectations.io