59、Spark性能优化之shuffle性能优化

没有开启consolidation机制的性能低下的原理剖析.png

总结，没有开启consolidation机制的时候，ShuffleWtiter的性能，是比较低的，而且会影响到Shuffle read的性能，而且性能也会比较低
因为Shuffle Map端创建的磁盘文件太多了，导致shuffle writer要耗费大量的性能在磁盘文件的创建，以及磁盘io上，对于shuffle read，也是一样的，每个result task可能都需要通过磁盘io读取多个文件的数据，导致shuffle read 性能也会受到影响
但是，其实最主要的，还是shuffle write，因为要写的磁盘文件太多了
比如每个节点有100个shuffleMapTask，下一个stage，有100个result task，所以每个节点上的磁盘文件数量，就是100 * 100 = 1万个

开启consolidation机制之后对磁盘io性能的提升的原理.png

spark.shuffle.consolidateFiles：是否开启shuffle block file的合并，默认为false
总结，开启了consolidation机制之后，shuffle map端，写磁盘的数量，大大减少
比如节点100个shuffle map task ，10个cpu core，总共1000个result task，那么每个节点的磁盘文件总数，是10 * 1000 = 1万个
此外，result task拉取的时候，磁盘io也变少了，每个result task，只要从每个节点上，拉取cpu core数量的磁盘文件即可
比如，每个节点上，有100个shuffle map task，那么就要从100个文件中fetch，拉取，现在只需要从10个文件中fetch，拉取
map端的bucket缓存，也可以适当提高大小，这样，溢出到磁盘的次数就变少了
spark.shuffle.file.buffer：map task的写磁盘缓存，默认32k
每次只能拉取指定缓存大小的数据量，拉取完聚合处理，然后再次拉取，这个缓存是每个reduce task都有自己的，如果内存够大的话，那么可以适当加大，那么拉取的次数就变少了，spark.reducer.maxSizeInFlight：reduce task的拉取缓存，默认48m
执行reduce task的executor中，有一部分内存用来汇聚各个reduce task 拉取的数据，放入map，进行聚合，spark.shuffle.memoryFraction：用于reduce端聚合的内存比例，默认0.2，超过比例就会溢出到磁盘上
reduce task 拉取数据的时候，可能会遇到map task哪里的executor的jvm正在full gc，此时就会出现正常工作线程停止，那么可能等待一段时间后，full gc还没完成，就导致文件没有拉取到，spark.shuffle.io.maxRetries：拉取失败的最大重试次数，默认3次
很有可能，gc没有调优好，导致每次gc都1分钟，那么拉取的最大时间，默认是3 * 5 = 15s，就会导致频繁的很多文件拉取失败，就会给你报shuffle output file lost，然后，DAGScheduler会重试task和stage，最后甚至可能导致Application挂掉，spark.shuffle.io.retryWait：拉取失败的重试间隔，默认5s

调优参数总结

new SparkConf().set("spark.shuffle.consolidateFiles", "true")

spark.shuffle.consolidateFiles：是否开启shuffle block file的合并，默认为false
spark.reducer.maxSizeInFlight：reduce task的拉取缓存，默认48m
spark.shuffle.file.buffer：map task的写磁盘缓存，默认32k
spark.shuffle.io.maxRetries：拉取失败的最大重试次数，默认3次
spark.shuffle.io.retryWait：拉取失败的重试间隔，默认5s
spark.shuffle.memoryFraction：用于reduce端聚合的内存比例，默认0.2，超过比例就会溢出到磁盘上