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端输出文件的产生。
对性能有比较恶劣的影响。
这个时候,去开启这个机制,可以很有效的提升性能。