Spark缓存后物理计划未变更及isFinalPlan仍为false的原因排查

为什么缓存前后物理计划看起来一致？ #

你看到的explain(mode='simple')输出只是物理计划的逻辑结构预览，它不会体现缓存是否实际生效的执行阶段差异：

• 调用cache()后，Spark会在物理计划中添加InMemoryTableScan节点，但下游依然保留原计划结构——这是因为Spark需要保留完整链路，以便缓存失效（如内存不足被驱逐）时能重新计算。
• 实际执行时，缓存生效的情况下，Spark会直接读取内存中的缓存数据，完全跳过InMemoryTableScan下游的所有计算步骤。但explain的simple模式不会展示这种执行时的路径选择，你可以改用explain(mode='extended')查看更详细的计划，或者通过Spark UI的Jobs页面观察实际执行任务：缓存命中时，只会执行InMemoryTableScan相关任务，不会再跑原计划的计算链。

为什么isFinalPlan始终为false？ #

AdaptiveSparkPlan的isFinalPlan=false表示当前是未经过运行时优化的初始自适应计划模板，而非执行后的最终状态：

• 自适应执行计划的优化（如动态调整分区、处理倾斜join、合并shuffle等）是在任务执行过程中根据运行时数据动态完成的，explain输出的是Spark执行前生成的计划框架，不会反映执行后的最终优化状态。
• 即使调用cache().count()触发执行，再次调用explain时，依然会生成新的初始自适应计划模板，而非复用执行后的最终计划状态。要查看执行后的最终计划，需前往Spark UI的SQL页面，找到对应的查询查看详细执行计划，此时isFinalPlan会显示为true。
• 结合你开启的spark.sql.adaptive.enabled和skewJoin.enabled配置，自适应计划的final状态只有在实际执行完成后才会确定，explain本身无法捕获这个运行时状态变化。

验证缓存是否生效的正确方式 #

• 检查执行时间：缓存后再次执行count()，执行时间应大幅缩短，这是缓存生效最直接的证明。
• 查看Spark UI：在Storage页面可查看DataFrame的缓存状态（存储级别、缓存大小、分区数）；在Jobs页面可看到任务实际执行路径，缓存命中时不会执行原计划的计算步骤。
• 代码验证：调用df.storageLevel，返回结果应与你设置的存储级别一致（如StorageLevel(disk, memory, deserialized, 1 replicas)）。

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