dbt laten implementeren

dbt is een tool voor de T in ELT: hij transformeert data die al in je warehouse of lakehouse staat. Je schrijft een model als SQL-select of als Python-dataframe, en dbt maakt er een view of tabel van en regelt de DDL.

Modellen verwijzen naar elkaar met ref(), zodat dbt de volgorde en de lineage kent. Tests en documentatie staan naast de code. Inladen uit bronsystemen doet dbt niet. Het is een bouwsteen van je data fundament.

dbt Core is de opdrachtregelversie die je zelf installeert en draait. dbt Cloud is het gehoste product, dat dbt Labs nu het dbt platform noemt. Dat voegt een IDE in de browser, een planner voor jobs, CI per pull request, gehoste documentatie en meldingen toe. Catalog en de Semantic Layer zitten alleen in bepaalde abonnementen.

De engine kent nu twee generaties. dbt v1 is de Python-versie, nog onderhouden en Apache 2.0. dbt v2 draait op een nieuwe engine in Rust en is de standaardinstallatie; dbt OSS is daarvan de Apache 2.0-uitgave.

dbt Labs adviseert drie lagen. Staging maakt per brontabel één schoon model, met de prefix stg_. Intermediate combineert en rekent voor een specifiek doel. Marts leveren de entiteiten waar de organisatie over praat, zoals klanten en orders. Zo verschuift de data van de vorm van de bron naar de taal van het bedrijf.

Begin met views; maak tabellen van wat Power BI leest. Incrementele modellen, die alleen nieuwe rijen verwerken, gebruik je pas als runs te traag worden.

Data tests controleren de data na het bouwen: is een sleutel uniek, ontbreekt er niets, verwijst elke order naar een bestaande klant. Unit tests controleren je SQL-logica op een klein, vast voorbeeld vóór het bouwen; dbt Labs raadt aan die alleen in ontwikkeling en CI te draaien.

Voor modellen waar andere teams op bouwen, leg je een contract vast met kolomnamen en datatypes; klopt de uitkomst niet, dan bouwt het model niet. Welke regels je bewaakt, lees je bij datakwaliteit verbeteren.

Op Databricks gebruik je de adapter dbt-databricks en draai je het project als dbt-taak in Lakeflow Jobs, op een SQL warehouse. De identiteit waaronder de job draait, heeft in Unity Catalog rechten nodig op de catalogus, het schema en de tabellen die de modellen lezen en schrijven. Databricks raadt aan de adapterversie vast te zetten. Zie Databricks implementatie.

In Fabric is er een dbt job in Data Factory, nog in preview, die dbt Core draait op een warehouse of lakehouse. Zie Microsoft Fabric implementatie.

Met een snapshot. dbt legt dan elke wijziging vast als nieuwe rij, met de kolommen dbt_valid_from en dbt_valid_to: een slowly changing dimension van type 2. De voorkeur gaat naar een updated_at-kolom; ontbreekt die, dan vergelijkt dbt de kolommen die je opgeeft.

Komt de bron te laat binnen, dan meldt source freshness dat met een waarschuwing of een fout. Let op: dbt build draait die controle niet mee, je zet hem als eigen stap in de job.

Vaak op het één-op-één overzetten van oude views: dan staat dezelfde wirwar in dbt, alleen in Git. Ook zonder eigenaar per mart groeit het project uit tot een woud van modellen die niemand durft weg te halen.

Andere valkuilen zijn incrementele modellen te vroeg, geen CI-check zodat fouten pas in productie opvallen, en tests die altijd waarschuwen en daarom genegeerd worden. Het laden van de bronnen hoort bij data engineering; het onderhoud daarna kan bij ons via beheer en doorontwikkeling.

Als je een paar rapporten maakt uit één systeem en de logica in één Power BI-model past. Dan voegt dbt een laag toe die iemand moet onderhouden. Ook als het meeste werk streaming of zware verwerking in Spark is, hoort dat in pipelines; dbt past bij de modellen daarna.

En als niemand in het team SQL wil schrijven of reviewen, levert een dbt-project weinig op. Past een lichtere oplossing, dan zeggen we dat. Wil je eerst aanbieders vergelijken, bekijk dan ons overzicht van dataplatformbureaus.