Ga naar de inhoud
R Roesli.
Ga terug
dbt

Een managed dbt job gebruiken in Microsoft Fabric

Een praktische walkthrough voor het maken van een managed dbt job in Fabric, het laden van een seed, het bouwen van geteste Warehouse-modellen en het plannen van het resultaat.

De managed dbt job van Fabric draait dbt Core binnen Fabric. Je bewerkt SQL en YAML in de browser, kiest de adapter, draait dbt-commando’s, inspecteert compiled SQL en lineage, en plant de job zonder een aparte runner te beheren.

Deze walkthrough gebruikt een Fabric Warehouse in blog_fabric_dbt. dbt jobs zijn preview technology en moeten in tenant settings zijn ingeschakeld.

Architectuur

CSV seed
   |
   v
stg_orders
   |
   v
fct_orders
   |
   v
Fabric Warehouse + Power BI

Fabric heeft ook een Lakehouse-adapter, dbt-fabricspark. Die route schrijft Delta-tabellen via Spark. Richt de Warehouse-adapter niet op een Lakehouse SQL analytics endpoint. Dat endpoint is read-only.

1. Bereid de workspace voor

Maak en koppel aan capacity:

blog_fabric_dbt

Maak:

sales_warehouse

Het Warehouse is vóór publicatie succesvol ingericht in de validatieworkspace.

2. Schakel dbt jobs in

Een administrator moet:

  1. OneLake catalog openen;
  2. Govern > Configurations > Tenant settings selecteren; en
  3. dbt jobs (preview) inschakelen voor de organisatie of een security group.

Je hebt Contributor- of hogere workspacetoegang en read/write-toegang tot het Warehouse nodig.

3. Maak de dbt job

In blog_fabric_dbt:

  1. selecteer New item;
  2. kies dbt job;
  3. noem deze sales_dbt_models;
  4. selecteer de connection naar sales_warehouse; en
  5. sla op.

De managed runtime levert de dbt-fabric-adapter voor Warehouse. Fabric beheert de runtime; jij beheert projectbestanden, modellen, tests en runkeuzes.

4. Voeg een seed toe

Maak seeds/raw_orders.csv:

order_id,customer_id,order_date,amount,status
1001,501,2026-09-14,124.90,paid
1002,502,2026-09-15,80.00,paid
1003,503,2026-09-16,210.75,fulfilled
1004,504,2026-09-17,52.10,returned

Draai:

dbt seed

Dit maakt een deterministische brontabel voor de walkthrough.

5. Bouw staging

Maak models/staging/stg_orders.sql:

select
    cast(order_id as bigint) as order_id,
    cast(customer_id as bigint) as customer_id,
    cast(order_date as date) as order_date,
    cast(amount as decimal(18, 2)) as amount,
    lower(trim(status)) as status
from {{ ref('raw_orders') }}

ref() legt de dependency vast en houdt omgevingsspecifieke objectnamen uit het model.

6. Bouw het factmodel

Maak models/marts/fct_orders.sql:

select
    order_id,
    customer_id,
    order_date,
    amount,
    status,
    case when status in ('paid', 'fulfilled') then 1 else 0 end as is_revenue_order,
    case when status in ('paid', 'fulfilled') then amount else 0 end as recognized_revenue
from {{ ref('stg_orders') }}

Maak models/schema.yml:

version: 2

models:
  - name: fct_orders
    description: One row per sales order.
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: customer_id
        tests:
          - not_null
      - name: amount
        tests:
          - not_null

7. Bouw en valideer

Kies dbt build. Dit draait modellen en tests in dependencyvolgorde.

De UI ondersteunt ook:

dbt run
dbt seed
dbt test
dbt compile
dbt snapshot
dbt docs generate

Na de build:

  1. inspecteer Run Results;
  2. bekijk Compiled SQL;
  3. bevestig raw_orders -> stg_orders -> fct_orders in Lineage View; en
  4. bevraag het Warehouse:
select
    count(*) as order_count,
    sum(recognized_revenue) as recognized_revenue
from dbo.fct_orders;

Verwacht resultaat:

order_count = 4
recognized_revenue = 415.65

De geretourneerde order blijft in de facttabel, maar draagt nul recognized revenue bij.

8. Plan de juiste laag

Gebruik de tab Schedule van de dbt job wanneer de transformatie zelfstandig is. Gebruik een Fabric-pipeline wanneer de workflow dit is:

ingest -> dbt build -> validation -> semantic model refresh -> notification

De pipeline hoort te orchestreren. dbt hoort modeldependencies, SQL-transformaties en tests te beheren.

Warehouse of Lakehouse?

TargetAdapterGebruik wanneer
Fabric Warehousedbt-fabricHet team SQL-first werkt en T-SQL-transformaties en relationele serving wil.
Fabric Lakehousedbt-fabricsparkData in Delta moet blijven en Spark SQL de juiste execution engine is.

De adapter is een architectuurbeslissing. Controleer dialect, packages, materializations en commando’s voordat je een project verplaatst.

Beperkingen om rekening mee te houden

Bronnen

Managed dbt jobs zijn nuttig omdat modellen, tests, dependencies en monitoring één Fabric-item delen. De belangrijke ontwerpkeuze blijft het target: Warehouse en Lakehouse zijn verschillende execution paths.


Deel deze post:

Lees verder

Vorige post
Een native Fabric analytics stack met dbt, Airflow, Lakehouse en Direct Lake
Volgende post
Houd Databricks- en Fabric-permissions gelijk met Policy Weaver
Community

Praat mee

Meld je aan met GitHub om een reactie achter te laten.

GitHub

Reacties laden…

Meld je aan met GitHub om te reageren