Databricks环境下小型Spark DataFrame执行行列统计异常缓慢问题

• DAG全链路重计算开销：Spark采用惰性计算机制，你看到的590行2列是最终转换结果，但df.count()作为action操作会触发整个DataFrame对应的DAG执行链路从头运行。如果该DataFrame的生成逻辑包含复杂的多表join、大表过滤、自定义UDF运算等重操作，哪怕最终输出数据量极小，也需要跑完前面所有转换步骤才会得到行数统计结果。你可以执行df.explain()查看完整执行计划，确认是否存在预期外的重计算逻辑。
• 无缓存导致重复计算：如果之前没有对该DataFrame执行cache()/persist()操作，每次调用count都会完整重跑一次DAG链路。如果你的场景需要多次查询同一个DataFrame的属性，建议首次计算后主动缓存数据。
• 数据源访问或元数据开销过大：若DataFrame的数据源是对象存储（S3/OSS等）、HDFS上的大量小文件，哪怕最终只有几百行数据，Spark也需要先遍历所有源文件的元数据、拉取所有符合条件的源文件内容，元数据遍历、网络请求、大量空分区调度的开销会远大于数据本身的处理开销。另外如果数据源侧存在访问限流、网络抖动，也会导致执行耗时拉长。
• Spark配置不合理导致调度开销冗余：如果Spark任务的默认分区数设置过大，哪怕数据只有几百行也会生成成百上千个空分区，大量时间会浪费在任务调度、空任务执行的overhead上。另外也可能存在集群资源被其他租户抢占、当前任务分配到的实际可用资源不足的情况，可以通过Spark UI查看各阶段的资源分配和耗时分布。
• 自定义逻辑隐含性能问题：如果DataFrame生成链路中用到了Python UDF、自定义扩展函数，可能存在函数初始化、序列化反序列化开销过高，甚至UDF内部存在低效逻辑、隐性死循环的问题。

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