Spark设置自动广播阈值为50M仍广播1.5GB表的原因排查

该问题由Spark SQL优化阶段的表大小估算偏差导致，和你猜测的压缩数据量阈值触发逻辑高度相关，具体原因如下：

• 自动广播的判断逻辑在逻辑计划优化阶段就完成了，这个阶段Spark不会计算实际运行时的解压/序列化后数据大小，只会用预估值和spark.sql.autoBroadcastJoinThreshold的阈值对比，预估值符合条件就会生成广播执行计划。
• 预估值偏差主要来自两个场景：
  1. 若b/c是存储在Hive/数据湖的物理表，观测到的1.5G是内存解压后的实际大小，而Spark优化阶段读取的是元数据里存储的磁盘压缩后文件大小（比如Parquet/ORC高压缩比格式下，磁盘大小可能只有40+M，低于设置的50M阈值），就会误触发自动广播。
  2. 若b/c是临时生成的中间表，Spark 2.3.1本身存在多轮Join下中间结果大小估算的已知bug，会严重低估中间结果的实际大小，触发错误的广播策略。
• 左连接的规则放大了该问题：Spark 2.3.x中左连接的右表只要符合大小阈值就会默认走广播，不会额外校验实际数据量，最终导致1.5G的大表被广播，引发Driver/Executor内存溢出、作业延迟甚至被杀死。

• 临时快速修复：将spark.sql.autoBroadcastJoinThreshold配置为-1，完全关闭自动广播，所有广播操作通过broadcast()函数显式指定，从根源避免误判。
• 保留自动广播的优化方案：定期对用到的物理表执行ANALYZE TABLE <表名> COMPUTE STATISTICS更新元数据统计信息，降低预估值偏差。
• 长期修复：升级Spark版本到2.4及以上，该版本修复了多轮Join的大小估算bug、优化了压缩存储场景下的大小判断逻辑，大幅降低大表误广播的概率。
• 局部修复：在当前Join逻辑中通过hint强制指定要广播的小表，示例如下：

(
    a
    .join(b.hint("broadcast"),'col1','left')
    .join(c.hint("broadcast"),'col2','left')
)

内容的提问来源于stack exchange，提问作者sigh