本篇文章为Spark shuffle调优系列第一篇，主要分享Spark Shuffle调优之合并map端输出文件。
默认的shuffle过程如下图所示：
其中第一个stage中的每个task都会给第二个stage的每个task创建一份map端的输出文件;
第二个stage中每个task会到各个节点上面去拉取第一个stage中每个task输出的，属于自己的那一份文件。
问题来了：默认的这种shuffle行为，对性能有什么样的恶劣影响呢？
假设实际生产环境的条件如下：
100个节点（每个节点一个executor）：100个executor
每个executor：2个 cpu core
总共1000个task：每个executor平均10个task
每个节点中包含10个task，每个节点会输出10 * 1000=1万 份map端文件
总共有多少份map端输出文件？100 * 10000 = 100万。
通过上面的分析，一个普通的生产环境的spark job的一个shuffle环节，会写入磁盘100万个文件。
shuffle中的写磁盘的操作，基本上就是shuffle中性能消耗最为严重的部分。
磁盘IO对性能和spark作业执行速度的影响，是极其惊人和吓人的。基本上，spark作业的性能，都消耗在shuffle中了，虽然不只是shuffle的map端输出文件这一个部分，但是这里也是非常大的一个性能消耗点。
开启了map端输出文件的合并机制后：
上图中每个节点有4个task，并且有2个cpu core, 下一个stage简单起见设置在两个task。
开启了map端输出文件的合并机制之后：
第一个stage同时运行2个task；每个task都创建下一个stage的task数量个文件（2个)；
第一个stage并行运行的2个task执行完以后就会执行另外两个task，另外2个task不会再重新创建输出文件而是复用之前的task创建的map端输出文件，将数据写入上一批task的输出文件中。
第二个stage中的task在拉取数据的时候，就不会去拉取上一个stage每一个task为自己创建的那份输出文件了；而是拉取少量的输出文件，每个输出文件中，可能包含了多个task给自己的map端输出。
注意一下（map端输出文件合并）：
只有并行执行的task会去创建新的输出文件；下一批并行执行的task，就会去复用之前已有的输出文件；
但是有一个例外，比如2个task并行在执行，但是此时又启动要执行2个task；那么这个时候的话，就无法去复用刚才的2个task创建的输出文件了；而是还是只能去创建新的输出文件。
要实现输出文件的合并的效果，必须是一批task先执行，然后下一批task再执行，才能复用之前的输出文件；负责多批task同时起来执行，还是做不到复用的。
开启了map端输出文件合并机制之后，生产环境上的例子，会有什么样的变化？
实际生产环境的条件：
100个节点（每个节点一个executor）：100个executor
每个executor：2个cpu core
总共1000个task：每个executor平均10个task·
每个节点，2个cpu core，有多少份输出文件呢？2 * 1000 = 2000个
总共100个节点，总共创建多少份输出文件呢？100 * 2000 = 20万个文件
相比较开启合并机制之前的情况，100万个
map端输出文件，在生产环境中，立减5倍！
合并map端输出文件，对咱们的spark的性能有哪些方面的影响呢？
1、map task写入磁盘文件的IO降低 100万文件 -> 20万文件。
2、优化前第二个stage的每一个需要从第一个stage拉取1000份文件；合并以后,100个节点(每个节点2个cpu core)情况下，第二个stage的每个task只需要拉取100 * 2 = 200个文件即可；网络传输的性能消耗大大降低。
在实际在生产环境中，使用了spark.shuffle.consolidateFiles机制以后，实际的性能调优的效果：对于上述的这种生产环境的配置，性能的提升是相当客观的，spark作业执行耗时可以降低50%左右。
map端输出文件合并机制虽然看起来不起眼，但是实际上在数据量比较大且已经做了资源上的调优(executor增大->cpu core增大->并行度（task数量）增大) 基础上却没有做shuffle的调优，shuffle的性能就会很差，大量的map端输出文件的产生对性能有比较恶劣的影响。
这个时候，去开启合并map端输出文件，可以很有效的提升性能。
往期精选▼
Flink中Checkpoint和Savepoint 的 3 个不同点
3种Flink State Backend | 你该用哪个？
扫码关注我们
