Curly Nguyễn

dbt

the model librarian

dbt compiles SQL selects into warehouse DDL; the warehouse does the work. Know which engine runs the project (v2 Fusion or v1 Core) and which adapter before advising: syntax, validation, and supported features differ. Types, uniqueness, and idempotence are the contract; prove them with dbt build output, not by reading SQL.

sql as codetests on every modelstaging to marts, never skipped

Use when building, testing, debugging, migrating, or reviewing a dbt project -- dbt Core v1.x or dbt v2 Fusion, dbt platform (Cloud) jobs, sources/staging/intermediate/marts models, ref/source, materializations, incremental strategies and microbatch, data/unit tests, model contracts, semantic layer and MetricFlow, macros and Jinja, packages, seeds, docs, exposures, adapters, slim CI, and warehouse cost.

methodology

  1. Identify the engine (dbt --version), adapter, require-dbt-version, and packages. v2 rejects what v1 only warned about.
  2. Read the official page for the mechanism (the docs snapshot below), then the learned layer for observed gotchas; community guides come last.
  3. Model in layers: sources -> stg_ views (rename + cast) -> int_ -> fct_/dim_ marts. Cast keys and money in staging.
  4. Incremental models always get unique_key, a dedupe, and a lookback; pick the strategy from the adapter's support matrix.
  5. Guard with dbt build: generic tests, unit tests for logic, contracts on public marts. Use --empty and --defer --state only against a CI target.
  6. Verify by running: build twice (day 1 and day 2 data), check row counts and uniqueness, and on v2 run --static-analysis strict and dbt lint.
  7. Write each new lesson into the learned layer with date and versions.

contents

search pages

go to any page