Spark-Shuffle机制、内存、寻址、调优、源码
一、SparkShuffle概念
reduceByKey会将上一个RDD中的每一个key对应的所有value聚合成一个value,然后生成一个新的RDD,元素类型是<key,value>对的形式,这样每一个key对应一个聚合起来的value
注意:
数据在聚合之前RDD的partition可能存放在不同节点上(RDD是弹性分布数据集)
聚合
– Shuffle Write:上一个stage的每个map task就必须保证将自己处理的当前分区的数据相同的key写入一个分区文件中,可能会写入多个不同的分区文件中。
– Shuffle Read:reduce task就会从上一个stage的所有task所在的机器上寻找属于己的那些分区文件,这样就可以保证每一个key所对应的value都会汇聚到同一个节点上去处理和聚合。
二、SparkShuffle管理类型
1 HashShuffleManager(1.6版本后GG)
a 普通机制
HashShuffleManager-普通机制架构图
在普通机制中,产生小文件数量为:M(map task的个数)*R(reduce task的个数)
拉取数据过程和MR一样
HashShuffleManager-普通机制执行流程
1每一个map task将不同结果写到不同的buffer中,每个buffer的大小为32K。buffer起到数据缓存的作用
2每个buffer文件最后对应一个磁盘小文件
3reduce task来拉取对应的磁盘小文件
隐患–产生磁盘小文件过多
加大Shuffle Write和Shuffle Read读写数据的压力
在JVM堆内存中对象过多会造成频繁的gc,当gc无法解决运行所需要的内存的话,就会OOM
在数据传输过程中会有频繁的网络通信,频繁的网络通信出现通信故障的可能性大大增加,需要DAGScheduler重新连接(4次连接不到当前partition就GG)
b 合并机制
HashShuffleManager-合并机制架构图
产生磁盘小文件的个数:C(core的个数)*R(reduce的个数)
隐患
虽然磁盘小文件相对于普通机制来讲减少了很多,但是依旧存在这个问题
HashShuffleManager的合并模式的核是1,也就容易造成数据等待问题
2 SortShuffleManager(1.2版本提出,2.0+使用)
普通机制常用于需要排序的算子,eg:ReduceBuyKey
bypass机制常用于不需要排序的算子,eg:SortBuyKeyÿ