spark的shuffle

spark的shuffle的过程是怎样从一个个partition中聚合在一起的

reduceByKey会将一个RDD中的每一个key对应的所有value聚合成一个value，然后生成一个新的RDD，元素类型是<key,value>对的形式，这样每一个key对应一个聚合起来的value

Shuffle write: 上一个stage的每一个map task就必须保证自己处理的当前分区的数据相同的key写到一个分区

文件中，也可能写到多个不同的文件中

Shuffle read: reduce task就会从上一个stage的所有task所在机器徐州数据自己的那些分区文件，

这样就保证每一个key所对应的value都会聚集在同一个节点上去处理和聚会

 

spark又两种shuffle管理类型

HashShuffleManager和SortShuffleManager，在Spark1.2之前，是使用的HashShuffleManager

在spark 1.2之后 引入了SortShuffleManager，在2.0版本中已经将HashShuffleManager丢弃了

 

HashShuffleManager:

  1）.普通机制： M（map task的个数）*R(reduce task的个数)

  2).优化机制： C（core的个数）*R(reduce的个数)

 

SortShuffleManager:

   1).普通机子：2*M

   2). bypass机制,没有排序:2*M

Shuffle的问题有：

    1.小文件过多，耗时低效的IO操作

    2.OOM，读写文件以及缓存过多

 1.每一个Map task会将结果写入到不同的buffer中，每个buffer的大小为32k

buffer起到数据缓存的作用

2.每个buffer文件最后对应一个磁盘小文件

3.reduce task来拉去对应的磁盘小文件

以上的总结：

   1.map task的计算结果会根据分区器(默认hashPartitioner) 来决定写入那个一个磁盘小文件中去，Reducetask

会去Map端拉去相应的磁盘小文件

   2.磁盘小文件的个数：M（Map task的个数）*R（reduce task的个数）

  存在的问题：

        产生的磁盘小文件过多会导致一下的问题:

            1.在shuffle write过程中会残生很多的写磁盘小文件的对象

            2.在shuffle read过程中会产生很多读磁盘小文件的对象

            3.在JVM 堆内存中对象过多，造成频繁的gc，gc如果处理不过来会导致OOM

            4.数据传输会有频繁地网络通信，频繁的网络通信出现通信故障的可能性大大曽加，

              一旦网络通信出现了故障，会导致shuffle file cannot find ，会导致TaskScheduler重试

合并机制:

         hashShuffleManager原理：

          

SortShuffle运行原理

SortShuffle运行机制主要分为两种:

  普通运行机制

  bypass运行机制

  区别:

   普遍运行机制:

  

 

 

 

 

 

执行流程：

       1.map task的计算结果会写入到一个内存数据结构里面，内容默认5M

       2.在shuffle的时候会有一个定时器，不定期的屈估算这个内存结构的大小，当内存数据超过5M，那么

         就回去申请内存，如果申请不成功，就会进行益写磁盘

      3.在溢写之前内存结构中的数据会进行排序分区，然后开始溢写磁盘，以batch的形式去写，一个batch就是

      1万条数据，map task执行完成后，会将这些磁盘小文件合并成一个大的磁盘文件，同时生成一个

        索引文件

       4. reduce task 去map端拉去数据的时候，首先解析索引文件，根据索引文件再去拉去对应的数据

       产生磁盘小文件的个数：2*M(map task的个数)

 

byPass 运行机制

 bypass运行机制的触发条件如下：

    1.shuffle reduce task数量小于spark.shuffle.sort.bypassMergeThreshold的参数值(默认是200)

    2.参数的磁盘小文件为：2*M（map task的个数）

  文章转载于：https://zhuanlan.zhihu.com/p/70331869