我正在尝试在Spark数据集中进行简单的计数和分组。 但是，每次阶段之一卡住时（200/201 1正在运行）。 我重试了从1000到6000的几个分区。每次我停留在一个在状态栏中显示（1000/1001 1 running）或（6000/6001 1 running）的阶段中。
请帮助我了解这1个额外任务是从哪里产生的。
spark-submit选项如下：
--conf spark.dynamicAllocation.enabled=false --conf spark.kryoserializer.buffer.max=2000m --conf spark.shuffle.service.enabled=true --conf spark.yarn.executor.memoryOverhead=4000 --conf spark.default.parallelism=3000 --conf spark.sql.autoBroadcastJoinThreshold=-1 --conf spark.sql.shuffle.partitions=6000 --conf spark.driver.memory=30g --conf spark.yarn.maxAppAttempts=1 --conf spark.driver.cores=6 --num-executors 80 --executor-cores 5 --executor-memory 40g
答案 0 :(得分：0)
火花混洗分区的数量巨大。 Spark将每个随机分区的文件写入磁盘。如果您拥有大量的分区以及随机排序的分区，则可能会花费大量时间。您可以尝试减少默认的并行性和混洗分区。
答案 1 :(得分：0)
很难看到特定的火花代码和输入格式，但是我首先要研究的是输入数据中的数据偏斜。
如果一项任务持续花费更长的时间来完成，可能是因为它比其他任务大得多。如果您要分组的数据中的一个键比其他键显示的频率更高，那么在重新组合期间就会发生这种情况，因为它们最终都将位于同一重新组合的分区中。
话虽这么说，如果您实际上只是在做df.groupBy("key").count，那么Spark不需要重新排列值，而只是每个键的中间和。这就是为什么查看您的特定代码会有所帮助。
另一个要考虑的因素是，您的输入格式和数据将定义初始分区的数量，而不是火花并行性设置。例如，如果您有10个gzip压缩的文本文件，则将只能有10个输入分区。听起来，您所看到的陷入困境的阶段是随着设置更改而改变任务计数，因此，我认为这不是第一阶段。