Versneld naar dbt.
Projectstructuur, gelaagde models, SQL-stijl, tests, CI/CD, documentatie. De afspraken die bepalen of een dbt-project overzichtelijk blijft bij model nummer 800. Wij maakten die keuzes al in tientallen rollouts, zodat jij ze niet opnieuw hoeft te maken.
VOOR WE BEGINNEN
Klinkt dit bekend?
Wat teams die al met dbt werken, of het overwegen, ons vertellen nog voor er werk begint. Elk ervan heeft een uitweg, en de rest van deze pagina is hoe we er geraken.
Hoe we het aanpakken
Een mappenstructuur per auteur of per team, prefixen die iedereen anders gebruikt, intermediate models die ongemerkt gold tables geworden zijn. Zonder afspraken over lagen en naamgeving wordt lineage giswerk.
Hoe we het aanpakken
yml-bestanden in een aparte map, beschrijvingen die één keer geschreven en nooit meer bijgewerkt zijn, onduidelijk eigenaarschap, exposures die nergens gedefinieerd zijn. Documentatie die los van de code staat, vertrouwt na een tijd niemand nog. En dan leest ook niemand ze nog.
Hoe we het aanpakken
Not-null- en unique-tests zonder strategie verspreid over het project, singular tests voor dingen die generic zouden moeten zijn, geen freshness blocks op de sources die ertoe doen, een CI die groen blijft bij kapotte logica. Een testsuite zonder structuur geeft je een vals gevoel van veiligheid.
Hoe we het aanpakken
Ad-hoc {{ config() }}-overrides bovenaan elk bestand, materialisaties die per model beslist worden, Jinja-logica die van staging naar intermediate gekopieerd is. De oplossing: defaults op projectniveau in dbt_project.yml, en macro's voor de patronen die terugkomen.
Onze keuzes, zwart op wit.
Zes patronen die we op elk dbt-project toepassen. Opgeschreven, zodat je ze kan lezen nog voor je met ons praat.
Elke laag heeft één doel. Bronze, silver, ADS, gold.
Staging models heten stg_<source>_<entity>, één per brontabel, en doen niets meer dan casten en hernoemen. Intermediate per businessdomein, niet per team. ADS als het geharmoniseerde contract voor entiteiten die over bronnen heen gaan. Gold blijft dun en business-ready, met namen die gebruikers meteen snappen. Selecties als dbt build --select intermediate.finance+ worden dan kinderspel.
Defaults in dbt_project.yml. Niet in elk model.
Materialisaties, incremental strategies en quotingregels leg je vast op project- en mapniveau. Losse {{ config() }}-overrides verspreid over de bestanden maken het gedrag onvoorspelbaar. Met instellingen per pad ziet een reviewer hoe een model zich gedraagt, gewoon door te kijken waar het staat.
Eerst config, één afsluitende CTE, geen SELECT *.
{{ config() }} bovenaan, dan CTE's in een duidelijke volgorde (sources, transformaties, eindselectie), en op het einde één afsluitende CTE die het model teruggeeft. Expliciete kolommen, aliassen in lowercase snake_case, keywords in hoofdletters. Diffs blijven voorspelbaar, lineage-audits blijven haalbaar.
Zwaar op sources en gold. Licht op intermediate.
not_null en unique op elk staging model en op elke gold fact of dimensie. Relationship tests en contracts waar downstream metrics van afhangen. Intermediate models die ephemeral blijven, hebben geen eigen tests nodig: staging ervoor en gold erna dekken ze af.
dbt build, niet dbt run plus dbt test.
Één commando dat tegelijk materialiseert en test, zodat een kapot model nooit bij een downstream dependency raakt. De CI stopt meteen als een test faalt, en kritieke sources krijgen freshness blocks met warn/error-drempels (warn na 18u, error na 26u). Geen groene build, geen deploy.
Documentatie leeft naast de models. Of ze leeft niet.
_models.yml en _sources.yml staan in dezelfde map als de models die ze beschrijven. doc()-referenties zodat elke beschrijving maar op één plek staat, een eigenaar op elk model, exposures gekoppeld aan Power BI-rapporten en notebooks. De CI faalt op models zonder documentatie. Aparte documentatiebestanden raken altijd achterop.
Hoe we een dbt-project opleveren
Vier stappen. Elke keer dezelfde. De keuzes in elke stap hebben we tientallen keren gemaakt, niet gelezen op een documentatiepagina.
Verankeren
Één bron, één mart, één stakeholder die erom geeft. We leveren één bruikbaar model end to end op voor we aan de rest van het project komen. Naamgeving, lagen en tests liggen vast met dat eerste model.
Gelaagd opbouwen
Staging per bron, intermediate per domein, ADS als integratiecontract, gold dun en gebruiksvriendelijk. dbt_project.yml draagt de defaults, zodat elk nieuw model de patronen automatisch overneemt.
Bouwen met overtuiging
Volle testdekking op sources en gold, documentatie naast de models, dbt build in de CI, freshness op de sources die ertoe doen, dbt Power User als standaard IDE-setup, SQLFluff in pre-commit. De knopen zijn al doorgehakt.
Overdragen
Geplande builds, een eigenaar op elk model, exposures die verwijzen naar de dashboards die ze gebruiken. Je team bouwt de volgende mart zonder ons, en het project blijft overzichtelijk, ook bij model nummer 800.
Bespaar jezelf de tachtig beslissingen waar elk dbt-project opnieuw over discussieert.
Voor dbt heb je geen wizard nodig. Wat je nodig hebt, zijn de standpunten van iemand anders over de beslissingen die elk project telkens opnieuw neemt. Neem over wat werkt, fork de rest, of laat het ons voor je implementeren.
- Gelaagde projectstructuur (staging, intermediate, ADS, gold) met naamgevingsregels
- SQL-stijlgids en de patronen die in dbt_project.yml thuishoren
- Teststrategie: waar je zwaar test, waar je het licht houdt
- CI-gates, freshness-drempels, afspraken over eigenaarschap en exposures
Gaat goed samen met
dbt is de transformatielaag. Het platform eronder is een aparte beslissing, en over allebei hebben we een mening.
ONZE AANPAK →dbt op Databricks
Databricks SQL Warehouses als dbt-adapter, Unity Catalog als governance-laag, Asset Bundles om het project uit te rollen. Ook op de platformlaag brengen we dezelfde standpunten mee.
ONZE AANPAK →dbt op Fabric
Fabric heeft nu native dbt jobs. We zetten die in voor teams die al op Fabric-capaciteit gestandaardiseerd hebben en SQL-first transformaties willen bovenop het lakehouse.
Ons dbt-werk valt onder Data & analytics, binnen Bouwen.
Strategie beslist of dbt de juiste keuze is voor de transformatielaag. Wij bouwen het. Experts houden het draaiende nadat we het overgedragen hebben.
Strategie
Van zakelijke vragen naar een richting voor data, AI en software die je organisatie kan volgen.
Bekijken →Bouwen
Data en analytics, AI en software op maat. Gebouwd met adoptie en eigenaarschap vanaf dag één.
Bekijken →Experts
Specialisten die meedenken als teamgenoten. Ze houden je motor draaiend en je team scherp.
Bekijken →Overweeg je dbt? Praat eerst met ons.
Een gesprek van een halfuur. We zeggen je of het de juiste keuze is voor jouw situatie, en hoe je een project opzet dat overzichtelijk blijft naarmate het groeit.
Plan een dbt-gesprek