dbt-projektstruktur: Mappar, modeller och tests som skalar

Jag har tagit över dbt-projekt som vuxit från fem modeller till femhundra utan att någon stannat upp och bestämt hur det skulle hänga ihop. Resultatet är alltid detsamma: en platt mapp full av filer med namn som "final_v2_real" och tester som ingen vågar köra. Den här texten handlar om hur jag lägger upp ett dbt-projekt så att det fortfarande går att förstå när teamet har dubblats och datakällorna har tiodubblats.

Tre lager räcker längre än du tror

Jag delar alltid in modellerna i tre lager: staging, intermediate och marts. Staging speglar källan en till en, med lätt städning som omdöpta kolumner och rätt datatyper. Intermediate är där jag bygger återanvändbara byggstenar som flera marts behöver. Marts är de färdiga tabellerna som BI-verktyget och affärsanvändarna faktiskt frågar mot.

Poängen med uppdelningen är inte att den ser fin ut. Den gör att jag kan resonera om var en förändring hör hemma. När en källa byter kolumnnamn rör jag bara staging. När en affärsdefinition ändras rör jag marts. Intermediate fångar logik som annars hade kopierats in på tio ställen.

Mappar som matchar lagren

Under models/ lägger jag en mapp per lager, och under staging en undermapp per källsystem. Det låter trivialt, men den disciplinen är vad som håller projektet läsbart efter ett år.

• models/staging/<kalla>/ med en modell per källtabell och en _sources.yml som deklarerar källan.
• models/intermediate/ för mellanliggande logik, namngivet med prefixet int_.
• models/marts/<doman>/ uppdelat på affärsdomän, till exempel finance, sales och product.

Namngivningen följer samma logik: stg_, int_ och fct_ eller dim_ för faktum respektive dimensioner i marts. När en kollega ser en modell vid namn fct_orders vet hen direkt vad det är och var den ligger.

Om du står inför att lägga om ett befintligt projekt eller bygga en helt ny dataplattform hjälper jag gärna till. Jag erbjuder konkret rådgivning kring vår tjänst för dataplattform där just modellstruktur ofta är första steget.

Tester är inte valfria

Jag lägger generiska tester direkt i yml-filerna: unique och not_null på nycklar, accepted_values på statuskolumner och relationships mellan faktum och dimensioner. De fångar de fel som annars dyker upp först när en chef undrar varför intäkten ser konstig ut.

Utöver det skriver jag singulära tester för affärsregler som inte fångas av de generiska. Ett exempel är att summan av raderna i en orderrad alltid ska matcha ordertotalen. Sådana tester är billiga att skriva och dyra att sakna.

Sources och freshness

Jag deklarerar alltid källor explicit och sätter freshness-regler på dem som ska vara aktuella. Då larmar dbt när en källa inte har uppdaterats inom rätt fönster, i stället för att felet sprider sig tyst genom hela pipelinen. Det är en av de billigaste försäkringarna ett dataprojekt kan ha.

Seeds, snapshots och referensdata

Utöver modellerna finns det två verktyg i dbt som jag ser många glömma men som löser vanliga problem elegant. Seeds är små statiska tabeller som lever som csv-filer i projektet, perfekta för referensdata som landskoder eller en mappning av gamla kategorinamn till nya. Att lägga dem i versionshanteringen gör att alla kör mot samma uppslagstabell i stället för en kopia som driftar. Snapshots löser något svårare: att fånga hur en rad såg ut över tid när källan bara visar det aktuella tillståndet. Om en kund byter segment och du vill kunna analysera historiken behöver du en snapshot som registrerar förändringen när den sker. Båda är enkla att sätta upp men sparar mycket huvudvärk, och jag inkluderar dem tidigt så att teamet vänjer sig vid att de finns.

CI som kör bara det som ändrats

När projektet växer blir det ohållbart att köra om allt vid varje förändring. Jag sätter därför upp en CI-pipeline som bara bygger och testar de modeller som faktiskt påverkats av en ändring, plus det som ligger nedströms. dbt har inbyggt stöd för att jämföra mot ett tidigare tillstånd och välja ut just de modellerna, vilket gör att en liten ändring ger snabb återkoppling i stället för en halvtimmes väntan. Det här är skillnaden mellan att teamet vågar göra många små förändringar och att de drar sig för att röra något alls. Snabb feedback är inte en lyx, det är vad som håller utvecklingstempot uppe när antalet modeller blir stort. Jag brukar koppla samma pipeline till en granskningsmiljö där en kollega kan se effekten av en ändring innan den slås ihop, vilket gör kodgranskningen meningsfull även för transformationer.

Hur jag inför detta utan stora omtag

Jag försöker aldrig städa allt på en gång. I stället inför jag strukturen för nya modeller direkt och flyttar gamla i takt med att de ändå behöver röras. Inom ett par kvartal har den nya strukturen tagit över utan att något stannat upp. Vill du se konkreta exempel på hur det gått för andra finns flera berättelser i vår casebook.

Relaterat

• MLflow vs Weights & Biases: Experiment-tracking för ML-team i Sverige
• BigQuery-dataplattform från noll: Referensarkitektur 2026
• ETL vs ELT vs Reverse ETL: Modern data stack för svenska bolag

Vill du ta det vidare?

En sund projektstruktur är grunden för allt annat du bygger ovanpå. Om du vill ha hjälp att lägga grunden rätt, eller städa upp ett projekt som vuxit ifrån sig, hör av dig via kontaktsidan så tittar vi på din situation tillsammans.