Spark 里 Broadcast Join 和 Shuffle Join 有什么区别？怎么选？

一句话：Shuffle Join 是「两边都按键搬家再对齐」；Broadcast Join 是「小表复印一份送到每个 Executor，大表原地关联」。能广播就别让大表 Shuffle；不能塞进内存就老老实实 Shuffle，别硬广播把 Driver 打爆。

Shuffle Join（常见是 Sort-Merge Join）：两张表都按 join key 做 Shuffle，相同 key 落到同一分区，再排序合并。代价是网络、磁盘溢写、Stage 切分。适合两边都大，或者小表其实已经超过广播阈值。

Broadcast Hash Join：Driver 把小表 collect 成哈希表，广播到每个 Executor；大表每个 partition 本地 probe，大表不 Shuffle。省的是大表那一次全量交换。Spark SQL 里小表低于 spark.sql.autoBroadcastJoinThreshold（默认常见 10MB）会自动广播，也可以 /*+ BROADCAST(d) */ 强制。

我面试会按「谁搬家」讲选型：
1. 事实表很大、维度很小（城市码表、配置、活动名单）：Broadcast。这是数仓里最常见的星型关联。
2. 两边都是大事实、或维表已经上 GB：Shuffle / SMJ。硬广播会把 Driver 和每个 Executor 的堆打满。
3. 一边中等、统计过期：别死盯阈值。AQE（spark.sql.adaptive.enabled）可以在运行中看真实大小，把本来的 SMJ 改成 Broadcast，或把倾斜分区拆开。
4. join key 倾斜：广播解决不了「一个 key 占 80%」——大表那个分区本地哈希还是爆。要先打散/加盐，或让 AQE 拆倾斜分区；空字符串、unknown 当 key 等于人为制造一个超热 key。

落地长这样：

-- 维表明确很小：强制广播，避免统计不准走了 SMJ
SELECT /*+ BROADCAST(d) */
  f.order_id, f.gmv, d.city_name
FROM fct_order f
JOIN dim_city d
  ON f.city_id = d.city_id;

-- 两边都大：不要 BROADCAST，让优化器走 SMJ
SELECT /*+ SHUFFLE_MERGE(a, b) */
  a.user_id, b.sku_id
FROM fct_click a
JOIN fct_order b
  ON a.user_id = b.user_id
 AND a.dt = b.dt;

口述收尾：先说「小表复印、大表不搬家」；再主动报阈值、Driver 内存和倾斜。面试官要的是你会看计划，不是会背 hint 单词。