spark--shuffle

在之前的博客里,我对于hadoop和spark的相关基础进行了一定的讲解,大致的运行流程已经基本清晰,就像一辆极品的跑车,大致的框架已经出来了,剩下的是优化的操作,就像兰博基尼和拖拉机的区别,都是4个轮子发动机驱动,但是,我想大家应该都喜欢兰博基尼不喜欢拖拉机吧,尤其是男生,好车发动机的轰鸣声,听着都会热血沸腾吧!那么,spark的研发在出期的时候因为当时条件的限制,数据量不会那么大,已有的硬件处理水平完全能够满足,但是,随着时代的发展,就有人发现,现有的车的配置已经完全不能满足自己对于速度的追求,太慢了,可是,硬件的水平完全不能够满足数据的增长速度,这该怎么办呢?计算机界的各路大神汇集,商量了一下说:这样不大行啊,妖魔鬼怪太多了,消除不过来怎么办,没法短时间内提升咱的人数,没办法,只能提升我们自己的能力了,在自己身上下手,于是,这群大神在spark的配置上进行了一系列的优化,比如RDD的shuffle过程进行调优、将数据进行持久化处理并提出了多种不同的持久化级别、在资源以及任务调度方面进行相应的改善,

今天主要说的是shuffle的操作:大家都知道,hadoop中在进行mapreduce的时候会进行一个重新洗牌的过程也就是shuffle,其中包括hashshuffle和sortshuffle两种不同的shuffle形式,

首先来说hashshuffle,maptask将计算结果由分区起的策略决定分别存储到哪一个buffer内存中,然后将文件写入到磁盘中,提高与磁盘之间小文件的读写速率,,然后reducetask去磁盘中将数据拉取到reduce memory中进行存储,然后进行相应的计算,但是产生的问题就是当磁盘小文件过多的是时候会产生大量 的磁盘io和网络传输,造成shuffle过程是很浪费时间的,而且非常容易产生OOM,影响application的执行速度,那么hashshuffle是怎么解决的呢?大神们想到一个办法,当maptask将数据写到buffer之后其他maptask会复用内存中的数据,减少了磁盘小文件,相应产生的问题也就得到了减弱或处理

其次就是shuffle中的sortshuffle,maptask会将数据结果写入到内存(默认5M,当写满之后会自动申请内存,若系统内存不足就会产生溢写,但是会产生大量的磁盘小文件)中,至于是map或者array是根据每一个业务自身的不同进行决定的,然后在数据写入到内存之后,会自动的对数据进行一个排序,然后传入到内存缓冲区中,当maptask计算完毕以后,会将所有的磁盘小文件进行合并,合并成一个大的磁盘文件和一个索引文件(引导我们读懂磁盘中的文件,就像是书本的目录一样,可以清晰地了解一本书的每一个部分),然后task去磁盘中读取文件进行处理,但是在拉取数据之前会先解析索引文件,然后再拉取数据进行处理。大家可能也发现了,在这两种不同的shuffle过程中,有一个很大的不同就是sortshuffle中会对磁盘小文件进行一个排序,那这个排序是必要的吗?肯定不是的,比如在wordcount中,是没有必要进行这种操作的,浪费时间,所以,sortshuffle有一个bypass机制,会将数据直接写到内存中,那这个机制是怎么开启的呢?虽然是自动的,但是他也是有一个临界值的,在官方网站的定义里有这样一个配置信息:spark.shuffle.sort.bypassMergeThreshold,默认值200,当我们的maptask的值小于我们设定的值得时候就可以自动启动bypass机制

这就是shuffle的两种不同的运行机制以及他的优化,其实简单点来说,他就是通过一些方法减少磁盘小文件,相当于减少了网络和磁盘IO,节约了时间和效率,也就提高了spark的性能,就相当于我们的超级跑车追求起步和加速一样,省掉多余的步骤,直接一键启动,百公里加速就要几秒钟,就完整的能够体现出来汽车的高效性。

就像各大汽车生产商之间的竞争一样,每一个都想要自己的跑车能够跑出来最好的状态和速度,所以,只是单纯的修改几个参数是不够的,而剩下的也就是后面要说的性能/资源调优以及持久化,这两种方法都对spark的运行起到了很大的优化作用。

如果更好地见解或者我的理解有问题欢迎进行交流

交流QQ群:859121793

微信公众号:刚哥人工智能1000集

 

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页