Spark技术内幕：Shuffle的性能调优

通过上面的架构和源码实现的分析，不难得出Shuffle是Spark Core比较复杂的模块的结论。它也是非常影响性能的操作之一。因此，在这里整理了会影响Shuffle性能的各项配置。尽管大部分的配置项在前文已经解释过它的含义，由于这些参数的确是非常重要，这里算是做一个详细的总结。

1.1.1  spark.shuffle.manager

前文也多次提到过，Spark1.2.0官方支持两种方式的Shuffle，即Hash Based Shuffle和Sort Based Shuffle。其中在Spark 1.0之前仅支持Hash Based Shuffle。Spark 1.1的时候引入了Sort Based Shuffle。Spark 1.2的默认Shuffle机制从Hash变成了Sort。如果需要Hash Based Shuffle，可以将spark.shuffle.manager设置成“hash”即可。

如果对性能有比较苛刻的要求，那么就要理解这两种不同的Shuffle机制的原理，结合具体的应用场景进行选择。

Hash Based Shuffle，就是将数据根据Hash的结果，将各个Reducer partition的数据写到单独的文件中去，写数据时不会有排序的操作。这个问题就是如果Reducer的partition比较多的时候，会产生大量的磁盘文件。这会带来两个问题：

1)       同时打开的文件比较多，那么大量的文件句柄和写操作分配的临时内存会非常大，对于内存的使用和GC带来很多的压力。尤其是在Sparkon YARN的模式下，Executor分配的内存普遍比较小的时候，这个问题会更严重。

2)       从整体来看，这些文件带来大量的随机读，读性能可能会遇到瓶颈。

更加细节的讨论可以参见7.1节和7.6.6（尝试去解决写的文件太多的问题）。

 

Sort Based Shuffle会根据实际情况对数据采用不同的方式进行Sort。这个排序可能仅仅是按照Reducer的partition进行排序，保证同一个Shuffle Map Task的对应于不同的Reducer的partition的数据都可以写到同一个数据文件，通过一个Offset来标记不同的Reducer partition的分界。因此一个Shuffle Map Task仅仅会生成一个数据文件（还有一个index索引文件）