考察点
广播 join 是生产调优里收益最高的一招，也是坑最多的一招。面试官想听：广播的完整生命周期（谁收集、怎么分发、hash 表建在哪）；阈值参数到底量的是什么（很多人答不上「是物理大小不是行数」）；以及几个经典翻车场景——统计信息失真导致该广播没广播、表没剪枝就超阈值、driver 收集时 OOM。追问常往强制广播的写法、AQE 动态广播、广播变量内存占用怎么估算方向走。
参考答案
原理：三个阶段的完整链路
Broadcast Hash Join 把小表（build side）完整复制到每个 executor，大表（probe side）原地扫描。拆开看三个阶段：
1. 收集（driver 端）
Catalyst 决定广播后，build side 数据先 collect 到 driver。这里用的是一种「分块收集」：build side 的每个分区把数据写到 driver 的一个本地块管理器，汇总成一个完整的字节数组。driver 内存必须装得下这份数据——spark.driver.maxResultSize（默认 1g）之外的另一个隐含约束是 driver 堆本身。
2. 分发（TorrentBroadcast）
直接用 HTTP 从 driver 向几千个 executor 推数据会把 driver 网卡打爆，所以 Spark 用 BitTorrent 思路的 TorrentBroadcast：driver 把广播数据切成块（默认 4MB 一块，由 spark.broadcast.blockSize 控制），存进自己的 BlockManager；executor 先随机从 driver 或其他已拿到块的 executor 拉块，拿到块的 executor 自己变成新的分发源。指数扩散，driver 只承担初始几跳的流量。这就是「广播不会压垮 driver 网络」的原因——但要分清，压 driver 内存的是第一阶段收集，跟分发无关。
3. 探测（executor 端）
每个 executor 拿到完整小表后，在内存里建 hash 表（实际是 Tungsten 的 UnsafeHashedRelation，二进制布局、堆外内存）。大表侧的 task 流式读取本分区数据，逐条算 join key 的 hash 去表里探测。大表全程不 shuffle、不排序，这是全部收益的来源——一次原本要全量网络重分布 + 排序的 SMJ，退化成一次顺序扫描。
阈值的语义与调优
spark.sql.autoBroadcastJoinThreshold，默认 10MB，量的是表一侧的物理大小估算，注意三点：
- 它不是行数，是 Catalyst 依据表的统计信息（sizeInBytes）估算的字节数。统计信息从哪来：表做过 ANALYZE TABLE 就有准确值；没有的话 Spark 用逻辑计划的默认估算，对 DataFrame 读文件的场景经常估不准。
- 估算的是 join 前过滤、列裁剪之后 的大小。如果 SQL 里对小表有 where 过滤，过滤后的估算大小低于阈值照样会广播——所以「小表 200MB 能不能广播」的答案可能是「加过滤后能」。
- 设为 -1 可彻底关闭自动广播（某些超大集群为了确定性会这么做）。
生产上调到 100MB~500MB 是常规操作，但要算一笔账：广播数据在每个 executor 上都会建一份 hash 表，executor 上 task 并发度越高，这份内存对 execution 区域的挤压越明显。200MB 的小表广播到 50 个 executor，集群层面就是 10GB 的常驻内存。
几个经典翻车场景
1. 该广播的没广播。 表没 ANALYZE 过，Catalyst 估算偏大，走了 SMJ。现象是 join 莫名其妙慢一个量级，explain 一看是 SortMergeJoin。解法：ANALYZE TABLE t COMPUTE STATISTICS，或 hint 强制：/*+ BROADCAST(t) */。
2. 不该广播的广播了。 反过来的情况：统计失真估算偏小，200MB 的表被当成 5MB 广播，executor 建 hash 表时 OOM。解法同样是刷新统计或 hint 禁广播 /*+ NO_BROADCAST(t) */。
3. driver 收集 OOM。 小表真实大小 2GB，driver 堆只给了 2GB，collect 阶段直接挂。广播阈值不是安全绳，driver 内存要跟着调。
4. 广播超时。 大广播 + 网络抖动，spark.sql.broadcastTimeout（默认 300s）内没发完，整个 query 失败。大广播下把它调大。
5. 误以为广播等于零代价。 广播本身是一次全表物化 + 分发，如果小表其实有 500MB 且 join 选择性很差（大部分数据探测不匹配），广播的固定成本可能比 SMJ 的 shuffle 还亏。
排查与确认
判断一个 join 是否走了广播，三个地方看：explain 物理计划里的 BroadcastHashJoin + BroadcastExchange 节点；Spark UI SQL tab 里 BroadcastExchange 的耗时和广播大小指标；以及 executor 日志里 TorrentBroadcast 的拉取记录。发现 BroadcastExchange 耗时占比异常高，通常是广播太大或 executor 数太多。
可能的追问
- RDD API 怎么做广播 join？ 手动
sc.broadcast(smallData.collectAsMap())，然后大表 map 里查这个 map。没有自动阈值判断，大小合不合适全靠自己掂量；collectAsMap 同样会压 driver。 - AQE 能动态把 SMJ 切成 BHJ 吗？ 能。AQE 在 shuffle 完成后拿到真实分区统计，发现一侧实际数据量低于广播阈值时，会把物理计划里的 SortMergeJoin 改写成 BroadcastHashJoin。这是 Spark 3.x 里「统计不准」问题的自动兜底。
- 广播变量和广播 join 是一回事吗？ 底层机制相同（TorrentBroadcast），使用方式不同：广播变量是用户 API（sc.broadcast），生命周期由用户控制；广播 join 是 Catalyst 自动生成的执行策略。广播 join 的 build side 用完即释放，不需要用户 unpersist。