Skip to content

dbt Project Structure

Loosely based on how dbt structures projects.

Models

models/
├── dims/          Dim* models, built on staging or intermediate
├── facts/         Fact* models, reference keys to dimensions only
├── intermediate/  heavy business transformation, organised by the Dim/Fact it builds
├── marts/         business entities, organised like Looker
│   ├── accounting/ acquisition/ crm/ finance/ operation/ product/
└── stage/         one folder per source, light transformation, no joins
    ├── backend/ (event/base, batch)
    ├── zendesk/ braze/ dbo/
  • Facts that do not follow the convention carry the Legacy tag so they are reworked later, and are not mistaken for missed ones
  • If stage needs joins, the plain stage model moves to base/ and stage/ holds the join

Requirements for every new model

  • A .yml file with a top-level description (mandatory)
  • Tests where appropriate, and column descriptions where possible (optional)
  • Reused column descriptions go in .md docs blocks

Sources

One file per source system in models/sources/, named [source_system].yml, e.g. funnel.yml, zendesk.yml, backend_app.yml.

  • backend_app.yml covers rebtel_stage_elt, rebtel_stage_dbo and events_dump
  • stitch.yml is a loader, not an originating system
  • Always set description (explains the flow differences between sources) and loader (how each source is loaded)