Databricks Runtime升级后ETL性能异常下降问题咨询

1. 不同DBR版本性能差异的可能原因 #

• Spark内核迭代影响：DBR 13.3基于Spark 3.3，14.3/15.4对应Spark 3.4/3.5，新版本可能调整了执行计划优化逻辑、算子实现，部分特定场景下出现性能退化（比如特定join/shuffle逻辑的改动）。
• Unity Catalog集成适配问题：刚部署UC后，新版本DBR对UC元数据的访问、权限校验逻辑可能更严格或存在兼容性bug，导致表读写时额外开销增加。
• Delta Lake版本变化：DBR升级会同步升级Delta Lake版本，新版本可能修改了读写默认配置（比如文件合并策略、日志校验逻辑），对小文件或特定表结构的场景产生影响。
• 缓存机制调整：新版本可能优化了缓存的存储、清理策略，比如默认内存占比调整、缓存失效条件变更，导致原本依赖缓存的作业无法复用缓存。
• 实例资源调度逻辑变化：即使切换到Standard_D8ads_v5，新版本DBR对实例CPU、内存、磁盘的调度逻辑可能不同，未充分利用Delta缓存或实例资源。
• 新版本已知bug：部分DBR版本可能存在特定场景下的性能bug，比如某些算子的并行度异常、shuffle效率下降，这类问题通常会在后续小版本修复。

2. 惰性求值与DataFrame物化机制的有效性排查 #

df.cache() + df.count()的物化机制本身在新版本DBR中并未失效，但需排查以下可能导致重复计算的场景：

• DataFrame引用是否正确：如果后续代码中对df进行了转换（如df.filter(...)生成新的DataFrame），新的DataFrame未复用原缓存，会触发重新计算。
• 缓存状态未生效：可通过print(df.is_cached)验证缓存是否成功，或查看Spark UI的Storage标签确认缓存的DataFrame是否存在、数据量是否匹配。
• 缓存被提前清理：新版本DBR的缓存清理策略可能更激进，若集群内存不足，缓存的DataFrame可能被提前释放，导致后续计算重新执行。
• UC表元数据变更：如果df来自UC中的Delta表，若表元数据（如分区、schema）发生变化，会触发缓存失效，强制重新读取数据。

3. coalesce(1)耗时过长的原因分析 #

coalesce(1)本身会将所有数据集中到单个节点，操作耗时取决于数据源的大小，但如果出现10分钟的异常耗时，大概率是缓存未被复用，需排查：

• 缓存的DataFrame是否被正确引用：确认coalesce(1)是直接调用在已缓存的df上，而非后续转换生成的未缓存DataFrame。
• 查看Spark UI执行计划：在Jobs标签中查看coalesce对应的job，检查上游是否有全量计算的算子（如scan、join），若有则说明缓存未生效。
• UC表访问的额外开销：UC下读取Delta表时，可能存在元数据校验、权限检查的额外步骤，导致即使缓存了DataFrame，仍需重新执行部分逻辑。
• Spark配置影响：新版本DBR默认开启的自适应执行计划（Adaptive Query Execution）可能调整coalesce的执行逻辑，比如强制重新计算上游数据以优化分区，可尝试临时关闭spark.sql.adaptive.enabled验证。

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