spark-shuffle与MapReduce shuffle
MR shuffle
shuffle属于不断被优化和改进的代码库,是MapReduce的“心脏”。
shuffle可以将其定义为:map的输出到reduce的输入(在一些语境中,代表reduce接受map输出的这部分)
1、map端
我们知道map产生的输出是临时写到本地磁盘的,但是他并不是简单的写到本地磁盘中,这个过程更为复杂,如图:
① 分区partition
② 写入环形内存缓冲区
③ 执行溢出写
排序sort—>合并combiner—>生成溢出写文件
④ 归并merge
- 分区Partition
在将map()函数处理后得到的(key,value)对写入到缓冲区之前,需要先进行分区操作,这样就能把map任务处理的结果发送给指定的reducer去执行,从而达到负载均衡,避免数据倾斜 - 写入缓存
频繁的磁盘I/O操作,“中间结果”优先存储到map节点的“环形内存缓冲区”.当写入的数据量(被缓冲的(key,value)对已经被序列化)达到预先设置的阙值(80%)后便会执行一次I/O操作将数据写入到磁盘. - 执行溢写出
缓冲区内容达到阈值,并在每个分区中对其中的键值对按键进行sort排序,具体是将数据按照partition和key两个关键字进行排序,排序结果为缓冲区内的数据按照partition为单位聚集在一起,同一个partition内的数据按照key有序。
(如果客户端自定义了Combiner(相当于map阶段的reduce),则会在分区排序后到溢写出前自动调用combiner,将相同的key的value相加,这样的好处就是减少溢写到磁盘的数据量。这个过程叫“合并”) - 归并merge
一个map task处理的数据很大,就会生成多个spill文件.这时进行归并生成最终的一个已分区且已排序的大文件.Copy阶段分区输出文件通过http的方式提供给reducer)
他会首先使用缓冲的方式写入到内存中,并且处于效率的考虑进行预排序。每个map都有一个缓冲区用于存储任务输出,这个缓冲区的大小默认为100MB,可以通过io.sort.mb属性调整。一旦缓冲的内容达到预设的阀值(通过io.sort.spill.percent,默认是0.8或80%),一个后台进程便把内容溢出(spill)到磁盘。在溢出过程map输出会继续写到缓冲区,如果在此期间被填满,则发生堵塞,直到写磁盘过程完成。这个溢出写的过程会将数据写到mapreduce.cluster.local.dir指定的目录内。在写硬盘之前会根据输出的reduce进行分区(partition),然后对每个分区内容进行排序,如果有combiner函数,则在排序之后执行combiner。每次内存缓冲区达到溢出的阀值,就会新建一个溢出文件(spill file)。最终会有几个溢出文件,这些溢出文件会被合并成一个已分区且已排序的输出文件,io.sort.factor控制一次最多能够合并多少流,默认是10。如果至少有3个溢出文件(这个值由min.num.spills.for.combine属性设置)则就会在输出文件写到磁盘之前在此运行以此combiner。将输出进行压缩可以减少输出及传递到reduce的网络开销,可以设置mapreduce.compress.map.output设置为true,使用mapreduce.map.output.compression.codec指定压缩方法。
2、reduce端
①复制copy
②归并merge
③reduce
- 复制copy
Reduce进程启动一些数据copy线程,使用心跳机制通知它们的application master通过HTTP方式请求MapTask所在的NodeManager以获取(只需拷贝与自己对应的partition中的数据即可)的输出文件。 - 归并merge 和sort
Copy 过来的数据会先放入内存缓冲区中,Map的输出数据已经是有序的,Merge进行一次合并排序,所谓Reduce端的sort过程就是这个合并的过程,采取的排序方法跟map阶段一样,针对键进行排序。
最终Reduce shuffle过程会输出一个整体有序的数据块。
reduce任务需要集群中若干个map的输出作为其输入,但是每个map的完成时间并不一样,所以只要有一个map输出,reduce就开始复制其输出,这就是reduce端的复制阶段。reduce有少量的复制线程,默认是5个,这个值由mapreduce.reduce.parallel.copies属性改变。
那么reduce如何知道从哪台机器获取map输出呢?
map任务完成后,会通知其父tasktracker,tasktracker会通知jobtracker(在MR2中是applicationMaster),从而jobtracker(applicationMaster)知道了tasktracker与map的映射关系,reduce中的一个线程会定期向applicationMaster(或者jobtracker)进行询问,以便获取map输出的位置。
复制完成后,reduce开始进入排序阶段(其实是合并节阶段,因为排序是在map端进行的),这个阶段合并map输出,保持其排好的顺序。这个合并是循环进行的,可以设置合并因子io.sort.factor,默认是10,即每趟合并10个文件,假设总共50个map,总共进行5趟,最终有5个中文文件。之后是reduce阶段,直接把数据输入到reduce函数,而不用将这5个文件合并称一个大文件。reduce函数输出直接写到HDFS上。
配置调优
map端的调优属性:
属性名称 | 类型 | 默认值 | 说明 |
---|---|---|---|
io.sort.mb | int | 100 | map输出所使用的内存缓冲区大小,以MB为单位 |
io.sort.spill.percent | float | 0.80 | 缓冲区预设的阀值,超过这个百分比开始将内容溢到磁盘 |
io.sort.factory | int | 10 | 排序文件时一次最多合并的流数,在reduce端也是用 |
min.num.spills.for.combine | int | 3 | 运行combiner所需要最少溢出文件数 |
mapreduce.compress.map.output | Boolean | false | 压缩map输出 mapreduce.map.output.compression.codec Class Name org.apache.hadoop.io.compress.DefaultCodec 用于map输出的压缩编码器 |
tasktracker.http.threads | int | 40 | 每个tasktracker运行的线程数,用于将map输出到reduce,在YARN不适用 |
这个过程总的来说就是要为shuffle分配更多的内存,但是这时候可能还需要考虑到map函数和reduce函数能够得到足够运行的内。所以一般map函数和reduce函数在编写的时候尽量少占内存。map端可以通过避免多次溢出写磁盘来获得最佳性能,一次是最佳的情况。
reduce端的调优属性
属性名称 | 类型 | 默认值 | 说明 |
---|---|---|---|
mapreduce.reduce.parallel.copies | int | 5 | 用于把map的输出复制到reduce的线程数 |
mapreduce.reduce.copy.backoff | int | 300 | 在声明失败之前,reducer获取一个map输出所花的最大时间,以秒为单位,如果失败,reducer可以在此时间内尝试重传 |
io.sort.factor | int | 10 | 排序合并时的合并因子 |
mapreduce.iob.shuffle.merge.percent | float | 0.66 | map输出缓冲区(上面定义的那个)的阀值使用比例,用于启动合并输出和磁盘溢出写的过程 |
mapreduce.inmem.merge.threshold | int | 1000 | 启动合并输出和磁盘溢出写过程的map的输出的阀值数。0或更小,意味着没有阀值限制 |
mapreduce.iob.reduce.input.buffer.percent | float | 0.0 | 在reduce过程,在内存中保存map输出的空间占整个堆空间的比例。reduce阶段开始时,内存中的map输出不能大于这个值 |
spark shuffle
一.定义
Shuffle的本意是洗牌,目的是为了把牌弄乱。
Spark、Hadoop中的shuffle可不是为了把数据弄乱,而是为了将随机排列的数据转换成具有一定规则的数据.
二.演变
Spark1.1.x addSortShuffle 有排序
Spark1.5 addd unsafe shuffle
spark1.6 hash+sort +unsafe => interagrate
spark2.0 remove hash
三.Hash Shuffle V1
有多少个reduce任务就会产生多少个中间文件(一个task—>所产生的文件数量=== reduce task数量)
Hash Shuffle V1 过程
1:shuffle write阶段
主要就是在一个stage结束计算之后,为了下一个stage可以执行shuffle类的算子(比如reduceByKey,groupByKey),而将每个task处理的数据按key进行“分区”。所谓“分区”,就是对相同的key执行hash算法,从而将相同key都写入同一个磁盘文件中,而每一个磁盘文件都只属于reduce端的stage的一个task。在将数据写入磁盘之前,会先将数据写入内存缓冲中,当内存缓冲填满之后,才会溢写到磁盘文件中去。
2:shuffle read阶段
shuffle read,通常就是一个stage刚开始时要做的事情。此时该stage的每一个task就需要将上一个stage的计算结果中的所有相同key,从各个节点上通过网络都拉取到自己所在的节点上,然后进行key的聚合或连接等操作。由于shuffle write的过程中,task给Reduce端的stage的每个task都创建了一个磁盘文件,因此shuffle read的过程中,每个task只要从上游stage的所有task所在节点上,拉取属于自己的那一个磁盘文件即可。
shuffle read的拉取过程是一边拉取一边进行聚合的。每个shuffle read task都会有一个自己的buffer缓冲,每次都只能拉取与buffer缓冲相同大小的数据,然后通过内存中的一个Map进行聚合等操作。聚合完一批数据后,再拉取下一批数据,并放到buffer缓冲中进行聚合操作。以此类推,直到最后将所有数据到拉取完,并得到最终的结果。
注意:
1).buffer起到的是缓存作用,缓存能够加速写磁盘,提高计算的效率,buffer的默认大小32k。
分区器:根据hash/numRedcue取模决定数据由几个Reduce处理,也决定了写入几个buffer中
block file:磁盘小文件,从图中我们可以知道磁盘小文件的个数计算公式:
block file=M*R
2).M为map task的数量,R为Reduce的数量,一般Reduce的数量等于buffer的数量,都是由分区器决定的
Hash shuffle普通机制的问题
1).Shuffle前在磁盘上会产生海量的小文件,建立通信和拉取数据的次数变多,此时会产生大量耗时低效的 IO 操作 (因為产生过多的小文件)
2).可能导致OOM,大量耗时低效的 IO 操作 ,导致写磁盘时的对象过多,读磁盘时候的对象也过多,这些对象存储在堆内存中,会导致堆内存不足,相应会导致频繁的GC,GC会导致OOM。由于内存中需要保存海量文件操作句柄和临时信息,如果数据处理的规模比较庞大的话,内存不可承受,会出现 OOM 等问题。
四.Hash Shuffle V2( spark.shuffle.consolidateFiles = true)
一个Executor—>所产生的文件数量=== reduce task数量
Hash Shuffle V2 过程:
- 开启consolidate机制之后,在shuffle write过程中,task就不是为下游stage的每个task创建一个磁盘文件了。此时会出现shuffleFileGroup的概念,每个shuffleFileGroup会对应一批磁盘文件,磁盘文件的数量与下游stage的task数量是相同的。一个Executor上有多少个CPU core,就可以并行执行多少个task。而第一批并行执行的每个task都会创建一个shuffleFileGroup,并将数据写入对应的磁盘文件内。
- Executor的CPU core执行完一批task,接着执行下一批task时,下一批task就会复用之前已有的shuffleFileGroup,包括其中的磁盘文件。也就是说,此时task会将数据写入已有的磁盘文件中,而不会写入新的磁盘文件中。因此,consolidate机制允许不同的task复用同一批磁盘文件,这样就可以有效将多个task的磁盘文件进行一定程度上的合并,从而大幅度减少磁盘文件的数量,进而提升shuffle write的性能。
注意:
1).启动HashShuffle的合并机制ConsolidatedShuffle的配置:
spark.shuffle.consolidateFiles=true
2).block file=Core*R
Core为CPU的核数,R为Reduce的数量
Hash shuffle合并机制的问题
如果 Reducer 端的并行任务或者是数据分片过多的话则 Core * Reducer Task 依旧过大,也会产生很多小文件。
五.Sort Shuffle
一个task—>所产生的文件数量===2
Sort Shuffle 过程
该图说明了普通的SortShuffleManager的原理。在该模式下,数据会先写入一个内存数据结构中(默认5M),此时根据不同的shuffle算子,可能选用不同的数据结构。如果是reduceByKey这种聚合类的shuffle算子,那么会选用Map数据结构,一边通过Map进行聚合,一边写入内存;如果是join这种普通的shuffle算子,那么会选用Array数据结构,直接写入内存。接着,每写一条数据进入内存数据结构之后,就会判断一下,是否达到了某个临界阈值。如果达到临界阈值的话,那么就会尝试将内存数据结构中的数据溢写到磁盘,然后清空内存数据结构。
注意:
shuffle中的定时器:定时器会检查内存数据结构的大小,如果内存数据结构空间不够,那么会申请额外的内存,申请的大小满足如下公式:
applyMemory=nowMenory2-oldMemory
**申请的内存=当前的内存情况2-上一次的内嵌情况**
意思就是说内存数据结构的大小的动态变化,如果存储的数据超出内存数据结构的大小,将申请内存数据结构存储的数据*2-内存数据结构的设定值的内存大小空间。申请到了,内存数据结构的大小变大,内存不够,申请不到,则发生溢写
- 排序
在溢写到磁盘文件之前,会先根据key对内存数据结构中已有的数据进行排序。 - 溢写
排序过后,会分批将数据写入磁盘文件。默认的batch数量是10000条,也就是说,排序好的数据,会以每批1万条数据的形式分批写入磁盘文件。写入磁盘文件是通过Java的BufferedOutputStream实现的。BufferedOutputStream是Java的缓冲输出流,首先会将数据缓冲在内存中,当内存缓冲满溢之后再一次写入磁盘文件中,这样可以减少磁盘IO次数,提升性能。 - merge
一个task将所有数据写入内存数据结构的过程中,会发生多次磁盘溢写操作,也就会产生多个临时文件。最后会将之前所有的临时磁盘文件都进行合并,这就是merge过程,此时会将之前所有临时磁盘文件中的数据读取出来,然后依次写入最终的磁盘文件之中。此外,由于一个task就只对应一个磁盘文件,也就意味着该task为Reduce端的stage的task准备的数据都在这一个文件中,因此还会单独写一份索引文件,其中标识了下游各个task的数据在文件中的start offset与end offset。
注意:
- block file= 2M
一个map task会产生一个索引文件和一个数据大文件 - m*r>2m(r>2):SortShuffle会使得磁盘小文件的个数再次的减少
Sort Shuffle–bypass
也可以无排序,按照key做hash节省了性能开销—Sort Shuffle–bypass
一个task—>所产生的文件数量===2
bypass运行机制的触发条件如下:
- shuffle map task数量小于spark.shuffle.sort.bypassMergeThreshold参数的值。
- 不是聚合类的shuffle算子(比如reduceByKey)。
Sort Shuffle–bypass过程:
- 此时task会为每个reduce端的task都创建一个临时磁盘文件,并将数据按key进行hash然后根据key的hash值,将key写入对应的磁盘文件之中。当然,写入磁盘文件时也是先写入内存缓冲,缓冲写满之后再溢写到磁盘文件的。最后,同样会将所有临时磁盘文件都合并成一个磁盘文件,并创建一个单独的索引文件。
- 该过程的磁盘写机制其实跟未经优化的HashShuffleManager是一模一样的,因为都要创建数量惊人的磁盘文件,只是在最后会做一个磁盘文件的合并而已。因此少量的最终磁盘文件,也让该机制相对未经优化的HashShuffleManager来说,shuffle read的性能会更好。
而该机制与普通SortShuffleManager运行机制的不同在于:
第一,磁盘写机制不同;
第二,不会进行排序。也就是说,启用该机制的最大好处在于,shuffle write过程中,不需要进行数据的排序操作,也就节省掉了这部分的性能开销。
shuffle过程中的临时文件写到哪里?
1.在 /tmp 下
2.配置路径
SPARK_LOCAL_DIRS=/hom/lyb/spark_log1,/hom/lyb/spark_log1,
备注:
1、需在每个worker节点上设置,可设置成不一样的值
2、worker节点的磁盘不做raid磁盘列阵
3、可设置以逗号分隔的多个值,提高IO性能。
总结:
- Shuffle 过程本质上都是将 Map 端获得的数据使用分区器进行划分,并将数据发送给对应的 Reducer 的过程。
- shuffle作为处理连接map端和reduce端的枢纽,其shuffle的性能高低直接影响了整个程序的性能和吞吐量。map端的shuffle一般为shuffle的Write阶段,reduce端的shuffle一般为shuffle的read阶段。Hadoop和spark的shuffle在实现上面存在很大的不同,spark的shuffle分为两种实现,分别为HashShuffle和SortShuffle,
HashShuffle又分为普通机制和合并机制,普通机制因为其会产生MR个数的巨量磁盘小文件而产生大量性能低下的Io操作,从而性能较低,因为其巨量的磁盘小文件还可能导致OOM,HashShuffle的合并机制通过重复利用buffer从而将磁盘小文件的数量降低到CoreR个,但是当Reducer 端的并行任务或者是数据分片过多的时候,依然会产生大量的磁盘小文件。 - SortShuffle也分为普通机制和bypass机制,普通机制在内存数据结构(默认为5M)完成排序,会产生2M个磁盘小文件。而当shuffle map task数量小于spark.shuffle.sort.bypassMergeThreshold参数的值。或者算子不是聚合类的shuffle算子(比如reduceByKey)的时候会触发SortShuffle的bypass机制,SortShuffle的bypass机制不会进行排序,极大的提高了其性能
- 在Spark 1.2以前,默认的shuffle计算引擎是HashShuffleManager,因为HashShuffleManager会产生大量的磁盘小文件而性能低下,在Spark 1.2以后的版本中,默认的ShuffleManager改成了SortShuffleManager。SortShuffleManager相较于HashShuffleManager来说,有了一定的改进。主要就在于,每个Task在进行shuffle操作时,虽然也会产生较多的临时磁盘文件,但是最后会将所有的临时文件合并(merge)成一个磁盘文件,因此每个Task就只有一个磁盘文件。在下一个stage的shuffle read task拉取自己的数据时,只要根据索引读取每个磁盘文件中的部分数据即可。