Skip to content

dbt Mesh review

This is the deepest mesh content in the workshop - an access-control audit followed by a full design exercise for extending the mesh boundary deliberately.

Exercise

Step 1 - Re-read the promise

  • Step complete

Open mediapulse_base/models/marts/ads/_marts__ads__models.yml. dim_campaigns's description explicitly states it's meant to be joined by marts in both mediapulse_base and mediapulse_analytics.

Step 2 - Check whether the config backs that up

  • Step complete

Open mediapulse_base/dbt_project.yml. dim_campaigns sits in the default marts access tier - only the streaming folder is overridden to public. Confirm: as configured today, could mediapulse_analytics actually ref('mediapulse_base', 'dim_campaigns') if it wanted to?

Step 3 - Fix the mismatch

  • Step complete

dim_campaigns shares its ads folder with fct_ad_impressions, which has no documented need to be public - so a folder-level override isn't the right tool here. Add a model-level access override to dim_campaigns only, in mediapulse_base/models/marts/ads/_marts__ads__models.yml, so its actual configuration matches what its description already promises. Then run dbt parse in mediapulse_base to confirm the project still parses cleanly.

Hint: Where access gets configured

Access can be set as a project-level default per folder in dbt_project.yml, or overridden per model via a config block in that model's YAML (this moved to the config: key as of dbt 1.10). You want the second one here. See Model access for both patterns.

Step 4 - Weigh the tradeoff before you commit

  • Step complete

Making dim_campaigns public isn't free. Write down what you'd be signing up for - what stability guarantee does a public model imply, and what would break in mediapulse_analytics (now or later) if mediapulse_base changed dim_campaigns's shape after making it public?

Deliverable: The actual access config change you made to dim_campaigns in step 3, confirmation it parses cleanly, plus the tradeoff you identified in step 4.

Extension

The hardest task in the workshop's mesh content: design, end to end, a genuinely new cross-project connection.

Step 1 - Define the target model, and stub it out

  • Step complete

Design a new model that joins mediapulse_base's dim_campaigns with mediapulse_analytics's CRM dim_advertisers, giving a single advertiser-level view spanning campaign spend and account/contract data. Decide which project should own this new model, and why. Then create a real stub file for it in that project (e.g. mediapulse_analytics/models/marts/crm/<your_model_name>.sql) with the correct ref()/cross-project ref() calls wired up in a CTE or two, and a comment describing what the final select would produce - it doesn't need to compile successfully yet.

Step 2 - Work out what has to change upstream

  • Step complete

Based on your fix in the main exercise, what access-level changes are now required for this new model to actually compile? Does anything in the CRM domain need to change access too, given the new model may itself need to be consumed elsewhere?

Step 3 - Apply model governance, not just access

  • Step complete

A newly-public model that other teams will build on deserves more than an access flag. Design what you'd want in place before treating it as stable: a model contract on its key columns, a decision on whether/when you'd need model versions if its shape changes later, and a group assignment reflecting who owns it.

Hint: Governance is a set of tools, not one setting

Access, groups, contracts, and versions are four separate but related governance mechanisms - a model can have any combination of them. Review how they compose in About model governance.

Step 4 - Name what you're NOT solving

  • Step complete

Even with access, groups, and a contract in place, what real operational problem would still be unsolved by this design (for example: who gets notified if the upstream model's data quality changes; how CI would need to work across two projects for this one joined model)? You don't need to solve it - just name it precisely.

Deliverable: The stub model file from step 1, a short design document covering the new model's ownership, the access changes required, the governance mechanisms you'd apply and why, and the one open problem you identified in step 4.

Done?

You've fixed a real access bug this mesh shipped with and designed a genuinely new cross-project model end to end, including naming the operational problem that governance config alone doesn't solve.

Now head to Advanced Testing for the deepest testing content in the workshop.