【Spark-core学习之八】 SparkShuffle & Spark内存管理
环境
虚拟机:VMware 10
Linux版本:CentOS-6.5-x86_64
客户端:Xshell4
FTP:Xftp4
jdk1.8
scala-2.10.4(依赖jdk1.8)
spark-1.6html
1、SparkShuffle
1. SparkShuffle概念
reduceByKey会将上一个RDD中的每个key对应的全部value聚合成一个value,而后生成一个新的RDD,元素类型是<key,value>对的形式,这样每个key对应一个聚合起来的value。问题:聚合以前,每个key对应的value不必定都是在一个partition中,也不太可能在同一个节点上,由于RDD是分布式的弹性的数据集,RDD的partition极有可能分布在各个节点上。shell
如何聚合?两个过程:
–Shuffle Write:上一个stage的每一个map task就必须保证将本身处理的当前分区的数据相同的key写入一个分区文件中,不一样的key写入多个不一样的分区文件中。缓存
–Shuffle Read:reduce task就会从上一个stage的全部task所在的机器上寻找属于己的那些分区文件,这样就能够保证每个key所对应的value都会汇聚到同一个节点上去处理和聚合。网络
Spark中有两种Shuffle类型,HashShuffle和SortShuffle,Spark1.2以前是HashShuffle默认的分区器是HashPartitioner,Spark1.2引入SortShuffle默认的分区器是RangePartitioner。数据结构
2. HashShuffle
1)普通机制
1.1)普通机制示意图
1.2)执行流程
a) 每个map task将不一样结果写到不一样的buffer中,每一个buffer的大小为32K。buffer起到数据缓存的做用。
b) 每一个buffer文件最后对应一个磁盘小文件。
c) reduce task来拉取对应的磁盘小文件。架构
1.3)总结
①map task的计算结果会根据分区器(默认是hashPartitioner)来决定写入到哪个磁盘小文件中去。ReduceTask会去Map端拉取相应的磁盘小文件。
②产生的磁盘小文件的个数:M(map task的个数)*R(reduce task的个数)分布式
1.4)存在的问题
产生的磁盘小文件过多,会致使如下问题:
a) 在Shuffle Write过程当中会产生不少写磁盘小文件的对象。
b) 在Shuffle Read过程当中会产生不少读取磁盘小文件的对象。
c) 在JVM堆内存中对象过多会形成频繁的gc,gc还没法解决运行所须要的内存 的话,就会OOM。
d)在数据传输过程当中会有频繁的网络通讯,频繁的网络通讯出现通讯故障的可能性大大增长,一旦网络通讯出现了故障会致使shuffle file cannot find 因为这个错误致使的task失败,TaskScheduler不负责重试,由DAGScheduler负责重试Stage。ide
2)合并机制(优化)
2.1)合并机制示意图
2.2)总结:产生磁盘小文件的个数:C(core的个数)*R(reduce的个数)性能
三、SortShuffle
1)普通机制
1.1)普通机制示意图
1.2)执行流程
a)map task 的计算结果会写入到一个内存数据结构里面,内存数据结构默认是5M
b)在shuffle的时候会有一个定时器,不按期的去估算这个内存结构的大小,当内存结构中的数据超过5M时,好比如今内存结构中的数据为5.01M,那么他会申请5.01*2-5=5.02M内存给内存数据结构。
c)若是申请成功不会进行溢写,若是申请不成功,这时候会发生溢写磁盘。
d)在溢写以前内存结构中的数据会进行排序分区
e)而后开始溢写磁盘,写磁盘是以batch的形式去写,一个batch是1万条数据,
f)map task执行完成后,会将这些磁盘小文件合并成一个大的磁盘文件,同时生成一个索引文件。
g)reduce task去map端拉取数据的时候,首先解析索引文件,根据索引文件再去拉取对应的数据。学习
1.3)总结
产生磁盘小文件的个数:2*M(map task的个数)
2)bypass机制(适用于不须要排序的场景)
2.1)bypass机制示意图
2.2)总结
①bypass运行机制的触发条件以下:
shuffle reduce task的数量小于spark.shuffle.sort.bypassMergeThreshold的参数值。这个值默认是200。
②产生的磁盘小文件为:2*M(map task的个数)
四、Shuffle文件寻址
1)MapOutputTracker
MapOutputTracker是Spark架构中的一个模块,是一个主从架构。管理磁盘小文件的地址。
MapOutputTrackerMaster是主对象,存在于Driver中。MapOutputTrackerWorker是从对象,存在于Excutor中。
2)BlockManager
BlockManager块管理者,是Spark架构中的一个模块,也是一个主从架构。
BlockManagerMaster,主对象,存在于Driver中。BlockManagerMaster会在集群中有用到广播变量和缓存数据或者删除缓存数据的时候,通知BlockManagerSlave传输或者删除数据。
BlockManagerWorker,从对象,存在于Excutor中。
BlockManagerWorker会与BlockManagerWorker之间通讯。
不管在Driver端的BlockManager仍是在Excutor端的BlockManager都含有四个对象:
①DiskStore:负责磁盘的管理。
②MemoryStore:负责内存的管理。
③ConnectionManager:负责链接其余的BlockManagerWorker。
④BlockTransferService:负责数据的传输。
3)Shuffle文件寻址图
4)Shuffle文件寻址流程
a)当map task执行完成后,会将task的执行状况和磁盘小文件的地址封装到MpStatus对象中,经过MapOutputTrackerWorker对象向Driver中的MapOutputTrackerMaster汇报。
b)在全部的map task执行完毕后,Driver中就掌握了全部的磁盘小文件的地址。
c)在reduce task执行以前,会经过Excutor中MapOutPutTrackerWorker向Driver端的MapOutputTrackerMaster获取磁盘小文件的地址。
d) 获取到磁盘小文件的地址后,会经过BlockManager中的ConnectionManager链接数据所在节点上的ConnectionManager,而后经过BlockTransferService进行数据的传输。
e)BlockTransferService默认启动5个task去节点拉取数据。默认状况下,5个task拉取数据量不能超过48M。
2、Shuffle调优
一、SparkShuffle调优配置项如何使用?
1)在代码中,不推荐使用硬编码。
new SparkConf().set(“spark.shuffle.file.buffer”,”64”)
2)在提交spark任务的时候,推荐使用。
spark-submit --conf spark.shuffle.file.buffer=64 –conf ….
3)在conf下的spark-default.conf配置文件中,不推荐,由于是写死后全部应用程序都要用。
二、调优参数
(1)spark.shuffle.file.buffer 默认值:32k 参数说明:该参数用于设置shuffle write task的BufferedOutputStream的buffer缓冲大小。将数据写到磁盘文件以前,会先写入buffer缓冲中,待缓冲写满以后,才会溢写到磁盘。 调优建议:若是做业可用的内存资源较为充足的话,能够适当增长这个参数的大小(好比64k),从而减小shuffle write过程当中溢写磁盘文件的次数,也就能够减小磁盘IO次数,进而提高性能。在实践中发现,合理调节该参数,性能会有1%~5%的提高。 (2)spark.reducer.maxSizeInFlight 默认值:48m 参数说明:该参数用于设置shuffle read task的buffer缓冲大小,而这个buffer缓冲决定了每次可以拉取多少数据。 调优建议:若是做业可用的内存资源较为充足的话,能够适当增长这个参数的大小(好比96m),从而减小拉取数据的次数,也就能够减小网络传输的次数,进而提高性能。在实践中发现,合理调节该参数,性能会有1%~5%的提高。 (3)spark.shuffle.io.maxRetries 默认值:3 参数说明:shuffle read task从shuffle write task所在节点拉取属于本身的数据时,若是由于网络异常致使拉取失败,是会自动进行重试的。该参数就表明了能够重试的最大次数。若是在指定次数以内拉取仍是没有成功,就可能会致使做业执行失败。 调优建议:对于那些包含了特别耗时的shuffle操做的做业,建议增长重试最大次数(好比60次),以免因为JVM的fullgc或者网络不稳定等因素致使的数据拉取失败。在实践中发现,对于针对超大数据量(数十亿~上百亿)的shuffle过程,调节该参数能够大幅度提高稳定性。 shuffle file not find taskScheduler不负责重试task,由DAGScheduler负责重试stage (4)spark.shuffle.io.retryWait 默认值:5s 参数说明:具体解释同上,该参数表明了每次重试拉取数据的等待间隔,默认是5s。 调优建议:建议加大间隔时长(好比60s),以增长shuffle操做的稳定性。 (5)spark.shuffle.memoryFraction 默认值:0.2 参数说明:该参数表明了Executor内存中,分配给shuffle read task进行聚合操做的内存比例,默认是20%。 调优建议:若是内存充足,并且不多使用持久化操做,建议调高这个比例,给shuffle read的聚合操做更多内存,以免因为内存不足致使聚合过程当中频繁读写磁盘。在实践中发现,合理调节该参数能够将性能提高10%左右。 (6)spark.shuffle.manager 默认值:sort|hash 参数说明:该参数用于设置ShuffleManager的类型。Spark 1.5之后,有三个可选项:hash、sort和tungsten-sort。HashShuffleManager是Spark 1.2之前的默认选项,可是Spark 1.2以及以后的版本默认都是SortShuffleManager了。tungsten-sort与sort相似,可是使用了tungsten计划中的堆外内存管理机制,内存使用效率更高。 调优建议:因为SortShuffleManager默认会对数据进行排序,所以若是你的业务逻辑中须要该排序机制的话,则使用默认的SortShuffleManager就能够;而若是你的业务逻辑不须要对数据进行排序,那么建议参考后面的几个参数调优,经过bypass机制或优化的HashShuffleManager来避免排序操做,同时提供较好的磁盘读写性能。这里要注意的是,tungsten-sort要慎用,由于以前发现了一些相应的bug。 (7)spark.shuffle.sort.bypassMergeThreshold----针对SortShuffle 默认值:200 参数说明:当ShuffleManager为SortShuffleManager时,若是shuffle read task的数量小于这个阈值(默认是200),则shuffle write过程当中不会进行排序操做,而是直接按照未经优化的HashShuffleManager的方式去写数据,可是最后会将每一个task产生的全部临时磁盘文件都合并成一个文件,并会建立单独的索引文件。 调优建议:当你使用SortShuffleManager时,若是的确不须要排序操做,那么建议将这个参数调大一些,大于shuffle read task的数量。那么此时就会自动启用bypass机制,map-side就不会进行排序了,减小了排序的性能开销。可是这种方式下,依然会产生大量的磁盘文件,所以shuffle write性能有待提升。 (8)spark.shuffle.consolidateFiles----针对HashShuffle 默认值:false 参数说明:若是使用HashShuffleManager,该参数有效。若是设置为true,那么就会开启consolidate机制,会大幅度合并shuffle write的输出文件,对于shuffle read task数量特别多的状况下,这种方法能够极大地减小磁盘IO开销,提高性能。 调优建议:若是的确不须要SortShuffleManager的排序机制,那么除了使用bypass机制,还能够尝试将spark.shffle.manager参数手动指定为hash,使用HashShuffleManager,同时开启consolidate机制。在实践中尝试过,发现其性能比开启了bypass机制的SortShuffleManager要高出10%~30%。
3、Spark内存管理
Spark执行应用程序时,Spark集群会启动Driver和Executor两种JVM进程,Driver负责建立SparkContext上下文,提交任务,task的分发等。Executor负责task的计算任务,并将结果返回给Driver。同时须要为须要持久化的RDD提供储存。Driver端的内存管理比较简单,这里所说的Spark内存管理针对Executor端的内存管理。
Spark内存管理分为静态内存管理和统一内存管理,Spark1.6以前使用的是静态内存管理,Spark1.6以后引入了统一内存管理。
一、静态内存管理
(1)静态内存管理中存储内存、执行内存和其余内存的大小在Spark应用程序运行期间均为固定的,但用户能够应用程序启动前进行配置。Spark1.6以上版本默认使用的是统一内存管理,能够经过参数spark.memory.useLegacyMode设置为true(默认为false)使用静态内存管理。
(2)静态内存管理分布图
二、统一内存管理
(1)统一内存管理与静态内存管理的区别在于储存内存和执行内存共享同一块空间,能够互相借用对方的空间。
(2)统一内存管理分布图
三、reduce 中OOM如何处理?
1) 减小每次拉取的数据量
2) 提升shuffle聚合的内存比例
3) 提升Excutor的总内存
参考: