11shuffle调优之合并map端输出文件

前置条件

每个executor有2个CPU core,4个task。task是线程执行的，所以先并行跑2个task，再跑剩下的2个task。

问题分析：默认的shuffle行为，对性能有什么样的影响？

实际生产环境的条件：

100个节点，每个节点一个executor，那么有100个executor，每个executor2个CPU core，总共1000个task，每个executor平均10个task

那么每个节点10个task，每个节点会输出多少份map端文件？

答：10（一个executor的task数量）*1000（task并行度）=1万个文件

总共有多少份map端输出：100*1万=100万

shufflemap 的影响

shuffl中的写磁盘操作，基本是shuffle中性能消耗最严重的部分，通过上面的分析，一个普通的生产环境的job一个shuffle环节，就会写入磁盘100万个文件，磁盘io对性能和spark的执行速度的影响，是特别惊人的。基本上spark作业的性能，都消耗在shuffle上，

开启shuffle map端文件输出合并机制

开启shufflemap输出文件的合并机制，默认情况下，是不开启的，就会发生上面分析的那样，严重影响性能，

开启方式：

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

开启map端输出文件合并机制之后：

第一个stage同时运行CPU core 个task，比如CPU core是2个，并行运行2个task，每个task都创建下一个stage的task数量个文件（2个）；

第一个stage并行运行的2个task执行完之后，就会执行另外两个task，另外两个task不会再重新创建数据文件，而是复用之前task创建的map端输出文件，将数据写入上一批task的输出文件中。

第二个stage的task在拉去数据的时候，就不会去拉去上一个stage每一个task为自己创建的那份输出文件，而是拉去少量的输出文件，每个输出文件中可能包含多个task给自己的map端输出。

说明map端输出文件合并：

只有并行执行的task会去创建新的输出文件，下一批并行执行的task，就会复用之前已经有的输出文件，特殊情况，比如2个task并行执行，但是此时又启动要执行2个task，那么这个时候就无法复用之前task创建的输出文件了，而是去创建新的输出文件。要实现输出文件合并的效果，必须是一批task先执行，然后下一批task再执行，才能复用之前的输出文件，如果多批task同时起来执行，还是做不到复用。

效果：

100个节点，每个节点一个executor：100个executor

每个executor：2个CPU core

总共1000个task：每个executor平均10个task

每个节点2个CPU core，有多少分输出文件呢？2*1000=2000个

总共100个节点，一共创建多个文件？100*2000=20万个文件

比以前的情况100万少了80万

合并map端输出文件对性能的影响

1.map task写入磁盘文件的IO减少

2.第二个stage的每个task由原来要拉去第一个stage的task数量份文件1000个，减少到200个，网络传输消耗降低。