Spark Shuffle调优之调节map端内存缓冲与reduce端内存占比 Spark Shuffle调优之调节map端内存缓冲与reduce端内存占比
调优原理
默认情况下shuffle的map task输出到磁盘文件的时候，统一都会先写入每个task自己关联的一个内存缓冲区。这个缓冲区大小，默认是32kb。
每一次当内存缓冲区满溢之后才会进行spill操作(溢写操作)溢写到磁盘文件中去。
reduce端task拉取到数据之后会用hashmap这种数据格式来对各个key对应的values进行汇聚。针对每个key对应的values执行我们自定义的聚合函数的代码，比如_ + _（把所有values累加起来）。
reduce task在进行汇聚、聚合等操作的时候使用的就是自己对应的executor的内存，默认executor内存中划分给reduce task进行聚合的比例，是0.2。
问题来了，因为默认比例是0.2，理论上很有可能会出现拉取过来的数据很多导致在内存中放不下，内存无法放下的数据，都被spill（溢写）到磁盘文件中去了。
原理说完之后，来看一下默认情况下不调优会出现什么样的问题
默认配置下map端内存缓冲是每个task，32kb。
默认配置下reduce端聚合内存比例，是0.2，也就是20%。
如果map端的task处理的数据量比较大而配置的内存缓冲大小是固定的可能会出现什么样的情况？
每个task处理320kb时总共会向磁盘溢写320 / 32 = 10次。
每个task处理32000kb时总共会向磁盘溢写32000 / 32 = 1000次。
在map task处理的数据量比较大的情况下，而你的task的内存缓冲默认是比较小的（32kb）。可能会造成多次的map端往磁盘文件的spill溢写操作，发生大量的磁盘IO，从而降低性能。
reduce端聚合内存占比默认是0.2。如果数据量比较大，reduce task拉取过来的数据很多，那么就会频繁发生reduce端聚合内存不够用，频繁发生spill操作溢写到磁盘上去。而且最致命的是，磁盘上溢写的数据量越大后面在进行聚合操作的时候很可能会多次读取磁盘中的数据进行聚合。
默认不调优，在数据量比较大的情况下，可能频繁地发生reduce端的磁盘文件的读写。
这两个点之所以放在一起说是因为他们俩是有关联的。数据量变大，map端肯定会出点问题；reduce端肯定也会出点问题；出的问题是一样的：都是磁盘IO频繁，影响性能。
调优方案
调优主要涉及如下两个参数：
- 调节map task内存缓冲：
spark.shuffle.file.buffer
- 调节reduce端聚合内存占比：
spark.shuffle.memoryFraction
在实际生产环境中，我们在什么时候来调节两个参数？
看Spark UI，如果采用的是standalone模式，可以通过SparkUI查看每个stage的详情，有哪些executor，task ？每个task的shuffle write和shuffle read的量，shuffle的磁盘和内存，读写的数据量；如果是用的yarn模式来提交，可以从yarn的界面进去，点击对应的application，进入Spark UI，查看详情。
如果发现shuffle 磁盘的write和read很大。这个时候，就意味着最好调节一些shuffle的参数。进行调优。首先当然是考虑开启map端输出文件合并机制。
调节原则：
spark.shuffle.file.buffer参数的值每次扩大一倍，然后看看效果（如扩大到64->128...)
spark.shuffle.memoryFraction参数的值每次提高0.1，看看效果。
上面两个参数不能调节的太大，太大了以后过犹不及，因为内存资源是有限的，你这里调节的太大了，其他环节的内存使用就会有问题了。
调节了以后效果如何？
map task内存缓冲变大了，减少spill到磁盘文件的次数；reduce端聚合内存变大了，减少spill到磁盘的次数，而且减少了后面聚合读取磁盘文件的数量。
原文: https://mp.weixin.qq.com/s/PnHR31k57QEwHVblLBKOGw
总结
其他条件不变 改变这两个条件
spark.shuffle.file.buffer (64-> 128 -> 256 ) 默认 32
spark.shuffle.memoryFraction (0.1 -> 0.2 -> 0.3) 默认 0.2
原理就是, 减少溢写磁盘 , 减少IO.