dbt

Solution

Staging is 1:1 with a source: rename, type, light clean. Marts are the business grain a dashboard or feature job can trust. Logic piled into staging is how projects rot. If two marts need the same join, that is an intermediate — not a copy-paste.

Solution

Slim CI: state:modified+ with --defer against production artifacts. Full dbt build in CI on a 400-model project is a junior tell. Also isolate CI schemas, never write to prod from a PR.

Solution

source() is the raw relation you do not own; ref() is a model in the project DAG. Breaking a source contract is a producer problem. Breaking a ref is your DAG. Tests on sources catch upstream silence; tests on marts catch your grain. Mixing them hides who pages whom.

Solution

merge when you have a unique key and late-arriving updates. delete+insert (or insert_overwrite) for partition-sized days you can safely replace. insert_overwrite needs a reliable partition column. “incremental” without a unique key or a partition is just append — and append is how you get duplicates.

Solution

Select the key, count(*), min/max loaded_at grouped by the key having count > 1. Decide: source duplicate, fan-out join, or a timezone that split one order into two days. Do not --full-refresh and hope. Fix the grain, then re-run the test.

Solution

dbt snapshots are a convenient Type-2 of a source when you do not control the producer. A first-class Type-2 dim you own (valid_from / valid_to, is_current) is better when facts must join “as of event time.” Do not snapshot every table “for lineage.”

Solution

Unit tests catch macro/SQL mistakes on fixtures. Warehouse unique/not_null catch grain on real data. You need both; fixtures will not invent yesterday’s duplicate key.

Solution

The CTE is inlined into every downstream compile. Materialize it as a view/table or split it. Ephemeral is for tiny reusable logic.

Solution

The warehouse role dbt uses must be able to GRANT. Configure grants on the model so BI is not broken every rebuild. “We click in the UI” does not survive CI.

Solution

One metric definition, many consumers. Four definitions of revenue is how finance pages you. dbt metrics or your metrics tool — pick one owner.

Solution

Either the SLA is a lie (widen it) or freshness should fail the DAG. Yellow forever trains people to ignore red. Pair with an owner in the source YAML.

Solution

Filter on a watermark minus lookback, merge on the unique key, and unique/not_null tests. max(updated_at) alone misses late deletes. Say the lookback in hours.

Solution

So a model change can warn the dashboard owner in CI, and so lineage is not a screenshot. If BI is not in git, exposures are how dbt still sees consumers.

Solution

Pin versions, read changelogs, run slim CI on the package bump in a branch. “Latest” on main is how Friday night breaks. Vendored macros you do not understand are worse than a package.

Solution

No semantic owner. Freeze both, diff grain and filters with finance, pick a survivor, deprecate the other with a failing test if it is still queried. Renaming in place without a sunset is how Slack fills with “which revenue.”

Solution

A changed macro/project YAML, a source that always looks new, and defer pointing at the wrong prod manifest. Then check whether you selected the whole tag by accident.