hadoop和spark中的shuffle操作是一本很好的读物。一些引语：
spark中的每个map任务为每个reducer写出一个shuffle文件（操作系统磁盘缓冲区）–这对应于spark中的一个逻辑块。这些文件不是中介文件，因为spark不会将它们合并到更大的分区文件中。由于spark中的调度开销要小得多，Map器（m）和还原器（r）的数量远远高于hadoop。因此，将m*r文件传送到相应的减速器可能会导致显著的开销。
hadoop和spark之间的一个主要区别是在reducer方面——spark需要所有经过洗牌的数据才能放入相应reducer任务的内存中（我们看到hadoop有一个选项可以将数据溢出到磁盘）。
从目前的讨论来看，hadoop shuffle确实比spark的shuffle优化得多。然而，情况确实如此，研究人员已经进行了重大的优化，以激发w.r.t.的洗牌操作。两种可能的方法是1。通过合并中间文件来模拟hadoop行为2。创建更大的随机文件3。使用列压缩将瓶颈转移到cpu。
在优化spark中的洗牌性能时，可以得出类似的结论：
通过识别特定于spark的shuffle阶段瓶颈，我们探索了几种方法来减轻与这些瓶颈相关的操作系统开销。其中最富有成效的是shuffle文件整合，这是一个简单的解决方案，使总体作业完成时间提高了2倍。
所以你看，hadoop/yarn并不能直接与spark相比，特别是在shuffle和reduce方面。spark需要特定的优化技术，与hadoop不同。你的情况到底需要什么很难猜测。但我的印象是，你只是轻描淡写的问题表面和简单地调整数量的减速器在Spark不会解决问题。