如果不合并map端输出文件的话,会怎么样?
前置条件:
每个executor有2个cpu core。4个task。

task是线程执行的。
所以先并行跑2个task,再跑剩下2个task
图解如下:

第一个stage,每个task,都会给第二个stage的每个task创建一份map端的输出文件

第二个stage,每个task,会到各个节点上面去,拉取第一个stage每个task输出的,属于自己的那一份文件。

shuffle中的写磁盘的操作,基本上就是shuffle中性能消耗最为严重的部分。

通过上面的分析,一个普通的生产环境的spark job的一个shuffle环节,会写入磁盘100万个文件。

磁盘IO对性能和spark作业执行速度的影响,是极其惊人和吓人的。

基本上,spark作业的性能,都消耗在shuffle中了,虽然不只是shuffle的map端输出文件这一个部分,但是这里也是非常大的一个性能消耗点。
问题来了:默认的这种shuffle行为,对性能有什么样的恶劣影响呢?

实际生产环境的条件:
100个节点(每个节点一个executor):100个executor
每个executor:2个cpu core
总共1000个task:每个executor平均10个task

每个节点,10个task,每个节点会输出多少份map端文件?10 * 1000=1万个文件

总共有多少份map端输出文件?100 * 10000 = 100万。
new SparkConf().set(“spark.shuffle.consolidateFiles”, “true”)

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

new SparkConf().set(“spark.shuffle.consolidateFiles”, “true”)

开启shuffle map端输出文件合并的机制;默认情况下,是不开启的,就是会发生如上所述的大量map端输出文件的操作,严重影响性能。
开启了map端输出文件的合并机制之后:

第一个stage,同时就运行cpu core个task,比如cpu
core是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同时起来执行,还是做不到复用的。
开启了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倍!

欢迎关注,更多福利


友情链接
ioDraw流程图
API参考文档
OK工具箱
云服务器优惠
阿里云优惠券
腾讯云优惠券
华为云优惠券
站点信息
问题反馈
邮箱:ixiaoyang8@qq.com
QQ群:637538335
关注微信