--- title: "Inkrementelle tabeller i dbt: Tre feller du sannsynligvis har gått i" url: "https://www.bekk.christmas/post/2025/18/inkrementelle-tabeller-tre-feller-du-sannsynligvis-har-gatt-i" authors: ["August Dahl"] published: "2025-12-18" updated: "2026-01-29T13:09:34Z" language: "nb-NO" type: "article" tags: ["Data og analyse"] --- # Inkrementelle tabeller i dbt: Tre feller du sannsynligvis har gått i Setter du materialized=incremental og håper på det beste? Her er tre feller de fleste går i med inkrementelle tabeller i dbt. ## Kort fortalt Inkrementelle tabeller i dbt blir først riktige og effektive når både strategien og filtreringen matcher hvordan data faktisk endrer seg. Artikkelen viser tre vanlige feller: å tro at materialisering alene gjør jobben, å velge feil inkrementell strategi som append, og å bruke faste tidsvinduer i stedet for å ta utgangspunkt i hva mål-tabellen allerede inneholder. Du sitter igjen med en forståelse av hvordan dbt kompilere og kjører inkrementelle modeller, og hvorfor {{ this }} og is_incremental() er sentrale for robust lasting. - **Passer for:** Data engineers og analytikere som jobber med dbt - **Fint å kunne fra før:** Grunnleggende dbt- og SQL-kunnskap _Generert med KI_ Inkrementelle tabeller er et av de viktigste verktøyene vi har for å bygge skalerbare datamodeller. I stedet for å laste og prosessere hele datasettet på nytt hver gang, oppdaterer vi bare det som faktisk har endret seg siden forrige kjøring. Det gir raskere kjøretider, lavere kostnader i datavarehuset og modeller som tåler økende datamengder over tid. ## **Der inkrementell last ofte går galt** Inkrementell last i dbt virker enkelt i teorien, men går ofte galt i praksis. Mange modeller ser inkrementelle ut, men gjør enten full last hver gang, produserer duplikater eller blir unødvendig dyre å kjøre. Årsaken er sjelden dbt i seg selv. Den ligger nesten alltid i hvordan inkrementell logikk er implementert. La oss starte med tre feller som går igjen i de fleste dbt-prosjekter. ### **Felle 1: Inkrementell materialisering uten inkrementell logikk** Den vanligste misforståelsen er å tro at materialiseringen alene gjør modellen inkrementell. ```sql {{ config(materialized='incremental') }} select * from {{ ref('stg_timeforing') }} ``` Her er det ingenting som forteller dbt hvilke rader som er nye eller oppdatert. Resultatet er at hele tabellen lastes på nytt hver gang. Modellen er teknisk sett inkrementell, men kjøres i praksis som en full last hver gang. Inkrementell last forutsetter eksplisitt filtrering i SQL-en, vanligvis styrt av `is_incremental()` som evalueres _før_ spørringen kjøres i datavarehuset: ```sql ... from {{ ref('stg_timeforing') }} {% if is_incremental() %} where {% endif %} ``` ### **Felle 2: Feil inkrementell strategi** Dette er en mer **subtil** feil: modellen kjører uten problemer, men dataene blir gradvis feil over tid. Mange velger `append` fordi det er enkelt og raskt, uten å vurdere om dataene faktisk er immutable. ```sql {{ config( materialized='incremental', incremental_strategy='append' ) }} ``` `append` legger kun til nye rader. Eksisterende rader oppdateres aldri. Hvis kilden endrer historiske data, for eksempel ved å korrigere timeføring bakover i tid, vil dbt legge inn nye rader i stedet for å oppdatere de gamle. Over tid fører dette til både inkonsistente data og duplikater i tabellen – uten at dbt gir noen advarsel. Med mindre dataene er immutable, bør `append` unngås til fordel for strategier som `merge` (oppdaterer eksisterende rader) eller `delete+insert` (erstatter rader ved å slette og sette inn på nytt). ### **Felle 3: Inkrementell filtrering med faste tidsvinduer** En veldig vanlig tilnærming er å gjøre inkrementell filtrering med et fast tidsintervall, typisk “siste 7 dager”. Det ser fornuftig ut, men det er egentlig en antakelse om at alle relevante endringer alltid ligger innenfor vinduet. ```sql {% if is_incremental() %} where sist_oppdatert >= dateadd(day, -7, current_date) {% endif %} ``` I disse tilfellene skjer nesten alltid én av to ting: 1. Enten prosesserer du for mye: hver kjøring leser og skriver om igjen et helt vindu, selv om svært få rader faktisk har endret seg. Det blir dyrt og tregt i datavarehuset uten at du får bedre datakvalitet. 2\. ... eller så prosesserer du for lite: når data kommer forsinket, kan rader utenfor vinduet fortsatt være “nye” for mål-tabellen. Da filtreres de bort, og blir aldri lastet inn uten en eksplisitt backfill-mekanisme. En mer robust tilnærming er å la inkrementell filtrering ta utgangspunkt i hva mål-tabellen faktisk inneholder. Her refererer `{{ this }}` til mål-tabellen som modellen skriver til i datavarehuset: ```sql {% if is_incremental() %} where sist_oppdatert > (select max(sist_oppdatert) from {{ this }}) {% endif %} ``` Fellene over ser forskjellige ut, men har én ting til felles: de oppstår når man forventer at dbt skal forstå mer enn det den faktisk gjør. For å unngå dem, må man forstå hvordan dbt behandler inkrementelle modeller i praksis. ## **Hvordan dbt faktisk kjører inkrementelle modeller** Når du setter `materialized='incremental'`, tar dbt ansvar for **hvordan** data skrives til mål-tabellen. Den tar ikke ansvar for **hvilke** rader som er nye. Det avgjør du i SQL-en. Det starter alltid med konfigurasjonen: ```sql {{ config( materialized='incremental', unique_key=['ansatt_id', 'dato'], incremental_strategy='merge' ) }} ``` Denne konfigurasjonen sier to viktige ting: - `unique_key` definerer hvordan rader matches - `incremental_strategy` bestemmer _hva som skjer når en rad allerede finnes_ ### **Første kjøring: alltid full last** På første kjøring finnes ikke mål-tabellen. Da ignoreres all inkrementell logikk, og dbt kjører en full last: ```sql select ansatt_id, dato, timer, sist_oppdatert from {{ ref('stg_timeforing') }} ``` Datavarehuset ender opp med en spørring noe tilsvarende dette: ```sql create or replace table fct_timeforing as ( select ... ); ``` ### **Senere kjøringer: strategi + filtrering** Først når tabellen finnes, blir modellen faktisk inkrementell. Da evalueres `is_incremental()` under kompilering, og dbt inkluderer `WHERE`-logikken før SQL-en sendes til datavarehuset. Med denne filtreringen: ```sql {% if is_incremental() %} where sist_oppdatert > (select max(sist_oppdatert) from {{ this }}) {% endif %} ``` og denne strategien: ```sql incremental_strategy='merge' ``` vil dbt generere et `MERGE`-statement i datavarehuset som: - matcher rader basert på `unique_key` - oppdaterer eksisterende rader - legger inn nye rader Forenklet ser det slik ut: ```sql merge into fct_timeforing T using (select * from ...) S on T.ansatt_id = S.ansatt_id and T.dato = S.dato when matched then update set ... when not matched then insert ... ``` Ved å sammenligne mot det modellen faktisk inneholder (`{{ this }}`), blir inkrementell last forutsigbar, repeterbar og robust – også når kjøringer feiler, data kommer sent eller historiske rader endres. Derfor er inkrementell last robust først når filtreringen tar utgangspunkt i **modellens faktiske tilstand**, ikke i antakelser om når data burde ha kommet eller hvor stort et tidsvindu bør være. ### **Oppsummert under panseret** - dbt avgjør **hvordan** data skrives (via config) - SQL-en avgjør **hvilke** rader som behandles - Datavarehuset gjør selve jobben (`MERGE`, `INSERT`, osv.) Robust inkrementell last krever at: 1. strategien støtter hvordan data faktisk endres 2. filtreringen tar utgangspunkt i hva modellen allerede har lastet Når begge deler stemmer, blir inkrementelle tabeller både riktige og forutsigbare – også når data er forsinket eller kjøringer feiler.