Spark Shuffle运行原理

1.什么是spark shuffle？

Shuffle中文意思就是“洗牌”，在Spark中Shuffle的目的是为了保证每一个key所对应的value都会汇聚到同一个分区上去聚合和处理。

Shuffle 过程本质上都是将 Map 端获得的数据使用分区器进行划分，并将数据发送给对应的 Reducer 的过程。shuffle是连接Map和Reduce之间的桥梁，Map的输出要用到Reduce中必须经过shuffle这个环节，shuffle的性能高低直接影响了整个程序的性能和吞吐量。因为在分布式情况下，reduce task需要跨节点去拉取其它节点上的map task结果。这一过程将会产生网络资源消耗和内存，磁盘IO的消耗。通常shuffle分为两部分：Map阶段的数据准备和Reduce阶段的数据拷贝处理。一般将在map端的Shuffle称之为Shuffle Write，在Reduce端的Shuffle称之为Shuffle Read。

map端的Shuffle简述:

1. input, 根据split输入数据，运行map任务;
2. patition, 每个map task都有一个内存缓冲区，存储着map的输出结果;
3. spill, 当缓冲区快满的时候需要将缓冲区的数据以临时文件的方式存放到磁盘;
4. merge, 当整个map task结束后再对磁盘中这个map task产生的所有临时文件做合并，生成最终的正式输出文件，然后等待reduce task来拉数据。

reduce 端的Shuffle简述:

reduce task在执行之前的工作就是不断地拉取当前job里每个map task的最终结果，然后对从不同地方拉取过来的数据不断地做merge，也最终形成一个文件作为reduce task的输入文件。

1. Copy过程，拉取数据。
2. Merge阶段，合并拉取来的小文件
3. Reducer计算
4. Output输出计算结果

我们可以将Shuffle的过程以数据流的方式呈现：

图形象的描述了MR数据流动的整个过程：

map端，有4个map;Reduce端，有3个reduce。4个map 也就是4个JVM，每个JVM处理一个数据分片(split1~split4)，每个map产生一个map输出文件，但是每个map都为后面的reduce产生了3部分数据(分别用红1、绿2、蓝3标识)，也就是说每个输出的map文件都包含了3部分数据。正如前面第二节所述：mapper运行后，通过Partitioner接口，根据key或value及reduce的数量来决定当前map的输出数据最终应该交由哪个reduce task处理.Reduce端一共有3个reduce，去前面的4个map的输出结果中抓取属于自己的数据。

2.在Spark中，什么情况下会发生shuffle？

1.去重：distinct

2.聚合：reduceByKey，groupBy，groupByKey，aggregateByKey，combineByKey

3.排序：sortByKey，sortBy

4.重分区：coalesce，repartition

5.集合或者表操作：intersection，subtract，subtractByKey，join，leftOuterJoin

3.shuffle运行原理

在Spark的源码中，负责shuffle过程的执行、计算和处理的组件主要就是ShuffleManager。在Spark 1.2以前，默认的shuffle计算引擎是HashShuffleManager。

3.1 spark早期的HashShuffleManager

在Spark 1.2以前，默认的shuffle计算引擎是HashShuffleManager。它的计算模式比较的简单粗暴，详细如下：

• shuffle write阶段

这个阶段将stage中每个task处理的数据根据算子进行“划分”。比如reduceByKey，就是对相同的key执行hash算法，从而将相同都写入同一个磁盘文件中，而每一个磁盘文件都只属于下游stage的一个task。在将数据写入磁盘之前，会先将数据写入内存缓冲中，当内存缓冲填满之后，才会溢写到磁盘文件中去。

• shuffle read阶段

stage的每一个task就需要将上一个stage的计算结果中的所有相同key，从各个节点上通过网络都拉取到自己所在的节点上，然后进行key的聚合或连接等操作。由于shuffle write的过程中，task给下游stage的每个task都创建了一个磁盘文件，因此shuffle read的过程中，每个task只要从上游stage的所有task所在节点上，拉取属于自己的那一个磁盘文件即可。

那么针对这种简单粗暴的HashShuffleManager，有着一个非常严重的弊端：会产生大量的中间磁盘文件，这样大量的磁盘IO操作会很影响性能。磁盘文件的数量由下一个stage的task数量决定，即下一个stage的task有多少个，当前stage的每个task就要创建多少份磁盘文件。比如下一个 stage 总共有 100 个 task，那么当前 stage 的每个 task 都要创建 100 份磁盘文件，如果当前stage有50个 task，那么总共会建立5000个磁盘文件。

3.2优化后的 HashShuffleManager

由于原版的HashShuffleManager，HashShuffleManager后期进行了优化，这里说的优化是指可以设置一个参数，spark.shuffle.consolidateFiles=true。该参数默认值为false，通常来说如果我们使用HashShuffleManager，那么都建议开启这个选项。

开启consolidate机制之后，在shuffle write过程中，task不会为下游stage的每个task创建一个磁盘文件，此时会出现shuffleFileGroup的概念，每个 shuffleFileGroup会对应一批磁盘文件，磁盘文件的数量与下游stage的task数量是相同的。而此时就会根据Executor数，并行执行task。第一批并行执行的每个task都会创建一个shuffleFileGroup，并将数据写入对应的磁盘文件内。

当Executor执行完一批task，接着执行下一批task时，下一批task就会复用之前已有的shuffleFileGroup，将数据写入已有的磁盘文件中，而不会写入新的磁盘文件中。即运行在同一个Executor的task会复用之前的磁盘文件。 这样就可以有效将多个task的磁盘文件进行一定程度上的合并，从而大幅度减少磁盘文件的数量，进而提升shuffle write的性能。

3.3 当前默认的SortShuffleManager

在Spark 1.2以后的版本中，默认的ShuffleManager改成了SortShuffleManager。SortShuffleManager的运行机制主要分成两种，一种是普通运行机制，另一种是bypass运行机制。当shuffle read task的数量小于等于spark.shuffle.sort.bypassMergeThreshold参数的值时（默认为200），就会启用bypass机制。

• 普通运行模式

在普通模式下，数据会先写入一个内存数据结构中，此时根据不同的shuffle算子，可以选用不同的数据结构。如果是由聚合操作的shuffle算子，就是用map的数据结构（边聚合边写入内存），如果是join的算子，就使用array的数据结构（直接写入内存）。等到内存容量到了临界值就准备溢写到磁盘。
  在溢写到磁盘文件之前，会先根据key对内存数据结构中已有的数据进行排序，排序之后，会分批将数据写入磁盘文件，每批次默认1万条数据。
  此时task往磁盘溢写，会产生多个临时文件，最后会将所有的临时文件都进行合并，合并成一个大文件。最终只剩下两个文件，一个是合并之后的数据文件，一个是索引文件，标识了下游各个task的数据在文件中的start offset与end offset。下游的task根据索引文件读取相应的数据文件。需要注意的是，此处所说的两个文件，是指上游一个task生成两个文件，而非所有的task最终只有两个文件。

• bypass运行模式

触发bypass机制的条件：

1. shuffle map task的数量小于spark.shuffle.sort.bypassMergeThreshold参数的值（默认200）
2. 不是聚合类的shuffle算子（比如groupByKey）

我们都知道，排序的时间复杂度最高不能优于O(nlogn)，那么如果将排序的时间复杂度省下，那么shuffle性能将会提升很多。bypass机制与普通SortShuffleManager运行机制的不同在于，bypass机制就是利用了hash的O(1)时间复杂度取代了排序的操作开销，提升了这部分的性能。

task会为每个下游task都创建一个临时磁盘文件，并将数据按key进行hash然后根据key的hash值，将key写入对应的磁盘文件之中。如上，写入磁盘文件时也是先写入内存缓冲，缓冲写满之后再溢写到磁盘文件的。最后，同样会将所有临时磁盘文件都合并成一个磁盘文件，并创建一个单独的索引文件。

spark机制总结：在Spark 1.2以前，默认的shuffle计算引擎是HashShuffleManager，因为HashShuffleManager会产生大量的磁盘小文件而性能低下，在Spark 1.2以后的版本中，默认的ShuffleManager改成了SortShuffleManager。SortShuffleManager相较于HashShuffleManager来说，有了一定的改进。主要就在于，每个Task在进行shuffle操作时，虽然也会产生较多的临时磁盘文件，但是最后会将所有的临时文件合并(merge)成一个磁盘文件，因此每个Task就只有一个磁盘文件。在下一个stage的shuffle read task拉取自己的数据时，只要根据索引读取每个磁盘文件中的部分数据即可。

Spark原理及优化可参考链接:

https://www.cnblogs.com/arachis/p/Spark_Shuffle.html

https://www.cnblogs.com/arachis/p/Spark_Shuffle.html

https://www.dazhuanlan.com/2019/12/07/5dead2acabaef/