Conformed dimensions when two business units define 'customer' differently

If reporting genuinely needs a single conformed 'customer' concept for cross-functional dashboards, define that as a third, explicitly-scoped dimension, like dim_customer_360, built on top of both, rather than overloading either team's native definition.

Check whether AQE is disabled in your Spark conf, skew join handling helped us a lot here.

Model both as distinct dimensions, dim_account and dim_contact, with an explicit bridge or foreign key between them, rather than forcing one team's definition onto the other. 'Customer' meaning two different grains is a real business fact, not a naming inconsistency to paper over.

Any downside to this approach with incremental models?

We saw the same issue, fixing the partition filter dropped runtime 60%.

Building dim_account and dim_contact separately, with a conformed dim_customer_360 for the shared exec dashboard. Keeps both teams' native reporting intact.

Start with the execution plan, numbers beat guesses.

Prefer a staging table plus validation gate before promoting to prod tables.