shuffle 调优之合并map端的输出

Shuffle 情景描述：

每个Executor 有2个 cpu core 4个task。
task是线程执行的。2个core ，4个task的话，就要先并行执行2个task，再跑另外2个task。
第一个stage，每个task，都会给第二个stage的每个task创建一份map端的输出文件
第二个stage，每个task，会到各个节点上面去，拉取第一个stage每个task输出的，属于自己的那一份文件。

问题来了：默认的这种shuffle行为，对性能有什么样的恶劣影响呢？

实际生产环境的条件：
100个节点（每个节点一个executor）：100个executor
每个executor：2个cpucore
总共1000个task：每个executor平均10个task
每个节点，10个task，每个节点会输出多少份map端文件？10* 1000=1万个文件
总共有多少份map端输出文件？
100* 10000 = 100万。
shuffle中的写磁盘的操作，基本上就是shuffle中性能消耗最为严重的部分。

通过上面的分析，一个普通的生产环境的sparkjob的一个shuffle环节，
会写入磁盘100万个文件。
磁盘IO对性能和spark作业执行速度的影响，是极其惊人和吓人的。
基本上，spark作业的性能，都消耗在shuffle中了，
虽然不只是shuffle的map端输出文件这一个部分，
但是这里也是非常大的一个性能消耗点。

开启shufflemap端输出文件合并的机制:
开启配置：

SparkSession.builder().enableHiveSupport().config("spark.shuffle.consolidateFiles","true")

默认情况下，是不开启的，就是会发生如上所述的大量map端输出文件的操作，严重影响性能。

开启的话，怎么样的呢？？？

合并前：

每个executor。2个cpu core。意味着什么？
2个task跑完，再跑另外2个task。
接下来的2个task 会去复用！！把数据写到已有的文件里！！！！

开启合并后：

开启了map端输出文件的合并机制之后：
第一个stage，同时就运行cpucore个task，比如cpucore是2个，并行运行2个task；
每个task都创建下一个stage的task数量个文件；
第一个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同时起来执行，还是做不到复用的。

合并前：

问题来了：默认的这种shuffle行为，对性能有什么样的恶劣影响呢？
实际生产环境的条件：

100个节点（每个节点一个executor）：100个executor

每个executor：2个cpu core

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

每个节点，10个task，每个节点会输出多少份map端文件？10 * 1000=1万个文件 （task per executor * task）

总共有多少份map端输出文件？

100 * 10000 = 100万。（task per executor * task * N）

合并后：

开启了map端输出文件合并机制之后，生产环境上的例子，会有什么样的变化？
实际生产环境的条件：
100个节点（每个节点一个executor）：100个executor

每个executor：2个cpucore

总共1000个task：每个executor平均10个task
每个节点，2个cpucore，有多少份输出文件呢？2* 1000 = 2000个（CPU core * task）
总共100个节点，总共创建多少份输出文件呢？100* 2000 = 20万个文件（CPU core * task * N）
相比较开启合并机制之前的情况，100万个
map端输出文件，在生产环境中，立减5倍！

合并map端输出文件，对咱们的spark的性能有哪些方面的影响呢？

1、maptask写入磁盘文件的IO，减少：100万文件->20万文件
2、第二个stage，原本要拉取第一个stage的task数量份文件，1000个task，第二个stage的每个task，都要拉取1000份文件，走网络传输；

合并以后，100个节点，每个节点2个cpucore，第二个stage的每个task，主要拉取100* 2 = 200个文件即可；
网络传输的性能消耗是不是也大大减少

实际效果

实际在生产环境中，使用了spark.shuffle.consolidateFiles机制以后，实际的性能调优的效果：
对于上述的这种生产环境的配置，性能的提升，还是相当的客观的。spark作业，5个小时->2~3个小时。

大家不要小看这个map端输出文件合并机制。
实际上，在数据量比较大，你自己本身做了前面的性能调优，
executor上去->cpucore上去->并行度（task数量）上去，
shuffle没调优，shuffle就很糟糕了；
大量的map端输出文件的产生。
对性能有比较恶劣的影响。
这个时候，去开启这个机制，可以很有效的提升性能。