Spark总结整理(六)：Spark Core 性能优化之Shuffle调优

Spark性能优化主要分为：

1. 开发调优
2. 资源调优
3. 数据倾斜调优
4. shuffle调优

大多数Spark作业的性能主要就是消耗在了shuffle环节，因为该环节包含了大量的磁盘IO、序列化、网络数据传输等操作

因此，如果要让作业的性能更上一层楼，就有必要对shuffle过程进行调优

影响一个Spark作业性能的因素，主要还是代码开发、资源参数以及数据倾斜，shuffle调优只能在整个Spark的性能调优中占到一小部分而已，不要舍本逐末

本篇罗列shuffle调优的注意事项

1. shuffle的定义

Spark的运行主要分为2部分：

1. 驱动程序，其核心是SparkContext

2. Worker节点上Task，它是运行实际任务的

程序运行的时候，Driver 会分配 Task 到 Executor，Driver 跟 Executor 进行网络传输

Task 要从 Driver 抓取其他上游的 Task 的数据结果，在这个过程中就不断的产生网络结果

Shuffle描述着数据从map task输出到reduce task输入的这段过程

2. ShuffleManager发展概述

在Spark的源码中，负责 shuffle 过程的执行、计算和处理的组件主要就是 ShuffleManager，也即 Shuffle 管理器

在 Spark 1.2 以前，默认的 Shuffle 计算引擎是 HashShuffleManager，而 HashShuffleManager 有着一个非常严重的弊端，就是会产生大量的中间磁盘文件，进而由大量的 磁盘IO 操作影响了性能。

因此在 Spark 1.2 以后的版本中，默认的 ShuffleManager 改成了 SortShuffleManager，SortShuffleManager 相较于 HashShuffleManager 来说，有了一定的改进

改进主要在于，每个 Task 在进行 Shuffle 操作时，虽然也会产生较多的临时磁盘文件，但是最后会将所有的临时文件*合并（merge）*成一个磁盘文件

因此每个 Task 就只有一个磁盘文件，在下一个 stage 的 shuffle read task 拉取自己的数据时，只要根据索引读取每个磁盘文件中的部分数据即可

3. HashShuffleManager 的运行原理

3.1 未经优化的HashShuffleManager

和 MapReduce 类似，Spark 的 Shuffle 也分为 Map 端的 Shuffle Write 和 Reduce 端的 Shuffle Read

3.1.1 Shuffle Write

在一个 Stage 结束计算之后，为了下一个 Stage 可以执行 Shuffle 类的算子（比如reduceByKey），而将每个 Task 处理的数据按key进行“分类”

所谓“分类”，就是对相同的 key 执行hash算法，从而将相同 key 都写入同一个磁盘文件中，而每一个磁盘文件都只属于下游 Stage 的一个 Task

在将数据写入磁盘之前，会先将数据写入内存缓冲中，当内存缓冲填满之后，才会溢写到磁盘文件中去

此时，文件数量 = 当前Stage的总Task数 * 下游Stage的总Task数

上图中，需要创建的磁盘文件数为：4 * 3 = 12

3.1.2 Shuffle Read

Stage 的每一个 Task 就需要将上一个 Stage 的计算结果中的所有相同key，从各个节点上通过网络都拉取到自己所在的节点上，然后进行 key 的聚合或连接等操作

由于 Shuffle Write 的过程中，Task 给下游 Stage 的每个 Task 都创建了一个磁盘文件，因此 Shuffle Read 的过程中，每个task只要从上游 Stage 的所有 Task 所在节点上，拉取属于自己的那一个磁盘文件即可

Shuffle Read 的拉取过程是一边拉取一边进行聚合的

每个 Shuffle Read Task 都会有一个自己的 Buffer 缓冲，每次都只能拉取与 Buffer 缓冲相同大小的数据，然后通过内存中的一个Map进行聚合等操作

聚合完一批数据后，再拉取下一批数据，并放到 Buffer 缓冲中进行聚合操作

以此类推，直到最后将所有数据到拉取完，并得到最终的结果

3.2 优化后的HashShuffleManager

这里说的优化，是指我们可以设置一个参数，spark.shuffle.consolidateFiles

该参数默认值为false，将其设置为true即可开启优化机制，通常来说，如果我们使用HashShuffleManager，那么都建议开启这个选项

开启 consolidate机制 之后，根据 bucketId 把要分到同一个下游 Reduce Task 的结果写入到一个文件中

此时，文件数量 = 当前Stage的总 Executor 数 * 下游Stage的总Task数

上图中，需要创建的磁盘文件数为：2 * 3 = 6

4. SortShuffleManager运行原理

SortShuffleManager 的运行机制主要分成两种，一种是普通运行机制，另一种是 bypass 运行机制

4.1 普通运行机制

在该模式下，数据会先写入一个内存数据结构中，此时根据不同的shuffle算子，可能选用不同的数据结构

如果是 reduceByKey这种聚合类的 Shuffle 算子，那么会选用 Map数据结构，一边通过 Map 进行聚合，一边写入内存；如果是 join 这种普通的 Shuffle 算子，那么会选用 Array 数据结构，直接写入内存

接着，每写一条数据进入内存数据结构之后，就会判断一下，是否达到了某个临界阈值

如果达到临界阈值的话，会先根据key对内存数据结构中已有的数据进行排序，再尝试将内存数据结构中的数据溢写到磁盘，然后清空内存数据结构

一个task将所有数据写入内存数据结构的过程中，会发生多次磁盘溢写操作，也就会产生多个临时文件，最后会将之前所有的临时磁盘文件都进行合并，这就是 merge 过程

此外，由于一个 Task 就只对应一个磁盘文件，也就意味着该 Task 为下游 Stage 的 Task 准备的数据都在这一个文件中，因此还会单独写一份索引文件，其中标识了下游各个 Task 的数据在文件中的 start offset 与 end offset

4.2 bypass运行机制

上图说明了 bypass SortShuffleManager 的原理，bypass 运行机制的触发条件如下：

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

此时task会为每个下游task都创建一个临时磁盘文件，并将数据按key进行hash然后根据key的hash值，将key写入对应的磁盘文件之中

当然，写入磁盘文件时也是先写入内存缓冲，缓冲写满之后再溢写到磁盘文件的

最后，同样会将所有临时磁盘文件都合并成一个磁盘文件，并创建一个单独的索引文件。

该过程的磁盘写机制其实跟未经优化的HashShuffleManager是一模一样的，因为都要创建数量惊人的磁盘文件，只是在最后会做一个磁盘文件的合并而已

因此少量的最终磁盘文件，也让该机制相对未经优化的HashShuffleManager来说，shuffle read的性能会更好

bypass运行机制 与普通 SortShuffleManager 运行机制的不同在于不会进行排序，也就是说，启用bypass运行机制的最大好处在于，shuffle write过程中，不需要进行数据的排序操作，也就节省掉了这部分的性能开销

5. shuffle相关参数调优

以下是Shffule过程中的一些主要参数，这里详细讲解了各个参数的功能、默认值以及基于实践经验给出的调优建议

注意：Spark各个版本的参数默认值可能会有不同，可参考：http://spark.apache.org/docs/2加粗样式.4.4/configuration.html

5.1 spark.shuffle.file.buffer

默认值：32k

参数说明：设置 shuffle write task 的B ufferedOutputStream 的 buffer 缓冲大小（将数据写到磁盘文件之前，会先写入buffer缓冲中，待缓冲写满之后，才会溢写到磁盘）

调优建议：如果作业可用的内存资源较为充足的话，可以适当增加这个参数的大小（比如64k），以减少 shuffle write 过程中溢写磁盘文件的次数，从而减少磁盘IO次数，进而提升性能

5.2 spark.reducer.maxSizeInFlight

默认值：48m

参数说明：设置 shuffle read task 的 buffer 缓冲大小，而这个 buffer 缓冲决定了每次能够拉取多少数据

调优建议：如果作业可用的内存资源较为充足的话，可以适当增加这个参数的大小（比如96m），从而减少拉取数据的次数，也就可以减少网络传输的次数，进而提升性能

5.3 spark.shuffle.io.maxRetries

默认值：3

参数说明：shuffle read task 从 shuffle write task 所在节点拉取属于自己的数据时，如果因为网络异常导致拉取失败，是会自动进行重试的。该参数就代表了可以重试的最大次数。如果在指定次数之内拉取还是没有成功，就可能会导致作业执行失败

调优建议：对于那些包含了特别耗时的shuffle操作的作业，建议增加重试最大次数（比如60次），以避免由于JVM的full gc或者网络不稳定等因素导致的数据拉取失败

5.4 spark.shuffle.io.retryWait

默认值：5s

参数说明：具体解释同上，该参数代表了每次重试拉取数据的等待间隔，默认是5s

调优建议：建议加大间隔时长（比如60s），以增加shuffle操作的稳定性

5.5 spark.shuffle.manager（2.0.0后废弃）

在 Spark 2.0 之后remove了 HashShuffle，开始只使用 on-heap 或 off-heap 的 sort-based shuffle

默认值：sort

参数说明：该参数用于设置 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

5.6 spark.shuffle.consolidateFiles（1.6.0后废弃）

默认值：false

参数说明：如果使用HashShuffleManager，该参数有效。如果设置为true，那么就会开启consolidate机制，会大幅度合并shuffle write的输出文件，对于shuffle read task数量特别多的情况下，这种方法可以极大地减少磁盘IO开销，提升性能。

调优建议：如果的确不需要SortShuffleManager的排序机制，那么除了使用bypass机制，还可以尝试将spark.shffle.manager参数手动指定为hash，使用HashShuffleManager，同时开启consolidate机制

5.7 spark.shuffle.memoryFraction（1.6.0后废弃）

在 Spark 1.6.0 之后，使用了统一内存管理方式，此参数不再生效

默认值：0.2

参数说明：该参数代表了Executor内存中，分配给shuffle read task进行聚合操作的内存比例，默认是20%

调优建议：如果内存充足，而且很少使用持久化操作，建议调高这个比例，给 shuffle read 的聚合操作更多内存，以避免由于内存不足导致聚合过程中频繁读写磁盘

5.8 spark.memory.fraction 和 spark.memory.storageFraction

在 Spark 1.6.0 之后，使用了统一内存管理方式，execution内存和storage内存支持合并配置

spark.memory.fraction：“execution内存 + storage内存” 占 Executor 总内存比例，默认值 0.6

spark.memory.storageFraction：storage内存 默认 占Executor总内存比例，默认值 0.5

调优建议：同6.7，如果内存充足，而且很少使用持久化操作，建议调高 execution内存 比例

5.9 spark.shuffle.sort.bypassMergeThreshold

默认值：200

参数说明：当 ShuffleManager 为 SortShuffleManager 时，如果shuffle read task的数量小于这个阈值（默认是200），则 shuffle write 过程中不会进行排序操作，而是直接按照未经优化的HashShuffleManager的方式去写数据，但是最后会将每个task产生的所有临时磁盘文件都合并成一个文件，并会创建单独的索引文件

调优建议：当你使用 SortShuffleManager 时，如果的确不需要排序操作，那么建议将这个参数调大一些，大于shuffle read task 的数量。那么此时就会自动启用bypass机制，map-side就不会进行排序了，减少了排序的性能开销。但是这种方式下，依然会产生大量的磁盘文件，因此 shuffle write 性能有待提高

参考：https://www.cnblogs.com/qingyunzong/p/8954552.html