我正在使用PySpark查询一个大型（2万亿条记录）的parquet文件，该文件由两列（month和day）进行分区。
如果我运行一个简单的查询：
SELECT month, day, count(*) FROM mytable
WHERE month >= 201801 and month< 202301 -- two years data
GROUP BY month, day
ORDER BY month, day查询在5分钟或更短的时间内执行。2性能非常好！
如果删除where条件，将得到整个数据湖信息（4年）。执行此查询将花费1.5小时。
我猜想可能与在worker节点中查询的大量数据有关，从而导致GC或shuffle，但这只是一种猜测
如何调试上述情况？
我的理解是Spark应该足够聪明来计算每个分区（因为是分布式环境），并且需要大约5 * 2（两年），没有那么大的不同
Edit 1：从SparkUI添加信息
我将显示两次运行的屏幕截图，4年数据为1.7小时，3年数据为7.5分钟。首先，始终显示4年数据
概述x1c 0d1x
工作页面
第一次
阶段1 -重型阶段
x1c4d 1x指令集
第二阶段
指令集
查询语句
指令集
指令集
编辑2 -新发现-调度程序延迟在繁重的任务中，我发现了调度程序延迟
如果是这样的话，方法是什么？
多谢了！
1条答案
按热度按时间zlwx9yxi1#
我已经发现了问题所在。
通过增加驱动程序的内存和内核（并不真正重要），问题得到了解决。
如何得出这个结论
首先，我知道我的数据不是很扭曲（正如@samkart和@Leonid Vasilev所指出的）。
其次，所有的指标都非常相似，没有太大的数字差异，所以，它必须是什么。
第三，也是最后一个，我打开Stage Event行，发现了一个非常有趣的问题，请参见edit 2。
在进一步调查我的日程表为什么这么晚之后，我确实没有找到真正的原因，但这句话给了我一个提示，问题出在驱动程序
调度程序延迟（蓝色）是等待所花费的时间。执行程序在等待一些东西-通常是等待控制和协调作业的驱动程序。
来源：enter link description here
在那篇文章中，作者还提到了一些非常重要的东西，我想补充一下
看到那些红色和蓝色了吗？这是一个肯定的信号，表明有什么事情发生了。我们真正想看到的是大量的绿色--花在工作上的时间比例--我指的是真正的工作--Spark做数字运算的部分。
TDLR：
最大的问题来自调度程序延迟，与驱动程序密切相关。增加内存（和vCPU）可解决此问题。