PySpark查询性能：when语句与join实现性能差异原因分析

先对齐基础信息：

• 数据集规模：purDf约432.8 MiB，ticDf约9.3 GiB
• 运行环境：Databricks Runtime 10.3（内置Apache Spark 3.2.1、Scala 2.12），4个工作节点，单节点配置为32GB内存 + 4核CPU
• 实测性能：方案1（when/otherwise多层分支做渠道映射+内连）耗时40秒；方案2（拆分小维度表做广播左连+coalesce合并映射结果+内连）耗时22秒

核心差异来自三个层面：

1. 单条记录的CPU计算开销差了一个量级 #

方案1的多层when/otherwise是逐行串行执行的分支判断逻辑，Spark全阶段代码生成（WholeStageCodegen）会把所有分支编译成串行的if-else判断链：每来一条记录，就要按写死的顺序从上到下匹配分支条件，映射规则越多，单条记录需要走的判断步骤越多，还会频繁触发CPU分支预测失败，单条记录的处理周期非常长。而且这个计算完全绑定在9.3GiB大表ticDf的处理task里，直接拉高了单task的计算负载。
方案2用极小维度表做映射时，Spark 3.2会自动识别小表触发BroadcastHashJoin（BHJ）：小维度表会被全量广播到所有executor，加载成内存中的哈希查找表，渠道映射本质是单次哈希查表，时间复杂度O(1)，没有多层分支判断的开销，单条记录的映射耗时比多层when低一个量级都不止。

2. 任务粒度与集群资源利用率差异 #

你在Spark UI看到方案2能跑更多并行任务，本质是两个方案的算子融合逻辑不一样：

• 方案1里的多层分支映射、ticDf预处理、和purDf的内连逻辑，会被全阶段代码生成融合到同一个执行阶段，单task要同时做分支判断、内连哈希表构建/数据匹配，负载很重，task切分粒度粗，受单节点CPU核数限制，同一时间能并行跑的task数量上不去，集群CPU资源跑不满。
• 方案2的两次小维度表左连是广播Join，不会引入额外shuffle，轻量的哈希查表逻辑可以和大表扫描做流水线并行，coalesce只是做非空判断几乎没有开销，整个阶段单task的负载非常均匀，Spark可以把大表切分成更多粒度更细的task，把4个节点总共16个CPU核全部打满，并行度自然高很多。

3. 隐性的长尾task影响 #

方案1的多层if-else逻辑如果存在分支命中不均的情况（比如少数几个saleschannel_id占了80%以上的数据），会出现明显的CPU热点：处理热点数据的task执行速度远慢于其他task，整个阶段的执行时间要等最慢的长尾task跑完才算结束。
方案2的哈希查表逻辑是无状态的，不管渠道id是什么，查表的耗时完全一致，不会出现计算热点导致的长尾task；映射完成后的数据在和purDf做内连shuffle时，数据分布也更均匀，不会因为计算逻辑的问题拖慢整体进度。

验证方法：去Spark UI的SQL页面查看两个方案生成的Codegen代码，方案1能看到一长串串行的if-else分支，方案2的映射部分只有简单的哈希表查找逻辑；同时对比executor的CPU利用率指标，方案1的CPU利用率通常会比方案2低30%左右，就是分支判断开销+task粒度过粗导致的资源浪费。

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