Spark的shuffle优化、join优化、数据倾斜优化

Spark的shuffle优化

shuffle定义及哪些操作产生shuffle

spark中的shuffle操作功能：将分布在集群中多个节点上的同一个key，拉取到同一个节点上，进行聚合或join操作，类似洗牌的操作。
RDD的特性是不可变的带分区的记录集合，Spark提供了Transformation和Action两种操作RDD的方式。
Transformation是生成新的RDD，包括map, flatMap, filter, union, sample, join, groupByKey, cogroup, ReduceByKey, cros, sortByKey, mapValues等；Action只是返回一个结果，包括collect，reduce，count，save，lookupKey等
Spark所有的算子操作中是否使用shuffle过程要看计算后对应多少分区：
• 若一个操作执行过程中，结果RDD的每个分区只依赖上一个RDD的同一个分区，即属于窄依赖，如map、filter、union等操作，这种情况是不需要进行shuffle的，同时还可以按照pipeline的方式，把一个分区上的多个操作放在同一个Task中进行；
• 若结果RDD的每个分区需要依赖上一个RDD的全部分区，即属于宽依赖，如repartition相关操作（repartition，coalesce）、 * ByKey操作（groupByKey，ReduceByKey，combineByKey、aggregateByKey等）、join相关操作（cogroup，join）、distinct操作，这种依赖是需要进行shuffle操作的。

shuffle操作过程

shuffle过程分为shuffle write和shuffle read两部分
• shuffle write：分区数由上一stage的最后的RDD分区数控制，shuffle write过程主要是将计算的中间结果按某种规则临时放到各个executor所在的本地磁盘上（当前stage结束之后或者是数据量很大时候，每个task处理的数据按key进行分类，数据大于5M时候，数据先写入内存缓冲区，缓冲区满（大于32M），溢写spill到磁盘文件，最终相同key被写入同一个磁盘文件）
- spark.shuffle.file.buffer : 默认32M，shuffle Write阶段写文件时的buffer大小，若内存资源比较充足，可适当将其值调大一些（如64M），减少executor的IO读写次数，提高shuffle性能

• shuffle read：从上游stage的所有task节点上拉取属于自己的磁盘文件，每个read task会有自己的buffer缓冲，每次只能拉取与buffer缓冲相同大小的数据，然后聚合，聚合完一批后拉取下一批，边拉取边聚合。分区数由Spark提供的一些参数控制，如果这个参数值设置的很小，同时shuffle read的数据量很大，会导致一个task需要处理的数据非常大，容易发生JVM crash，从而导致shuffle数据失败，同时executor也丢失了，就会看到Failed to connect to host 的错误(即executor lost)。
shuffle过程中，各个节点会通过shuffle write过程将相同key都会先写入本地磁盘文件中，然后其他节点的shuffle read过程通过网络传输拉取各个节点上的磁盘文件中的相同key。这其中大量数据交换涉及到的网络传输和文件读写操作是shuffle操作十分耗时的根本原因。
- spark.shuffle.io.maxRetries ：默认3次，Shuffle Read阶段取数据的重试次数，若shuffle处理的数据量很大，可适当将该参数调大。

spark的shuffle类型

参数spark.shuffle.manager用于设置ShuffleManager的类型。Spark1.5以后，该参数有三个可选项：hash、sort和tungsten-sort。
HashShuffleManager是Spark1.2以前的默认值，
Spark1.2之后的默认值都是SortShuffleManager。
tungsten-sort与sort类似，但是使用了tungsten计划中的堆外内存管理机制，内存使用效率更高。
**建议：**由于SortShuffleManager默认会对数据进行排序，因此如果业务需求中需要排序的话，使用默认的SortShuffleManager就可以；但如果不需要排序，可以通过bypass机制或设置HashShuffleManager避免排序，同时也能提供较好的磁盘读写性能。

shuffle的Writer选择条件

BypassMergeSortShuffleWriter
1 .不能map端预聚合
2 . 分区数据 <= 200
UnsafeShuffleWriter
1. 支持序列化定位 KRYO序列化方式
2. 不能map端预聚合
3. 分区数 , 小于等于 16777216
SortShuffleWriter
其他情况

如何开启bypass机制

bypass机制通过参数spark.shuffle.sort.bypassMergeThreshold设置，默认值是200，表示当ShuffleManager是SortShuffleManager时，若shuffle read task的数量小于这个阈值（默认200）时，则shuffle write过程中不会进行排序操作，而是直接按照未经优化的HashShuffleManager的方式写数据，但最后会将每个task产生的所有临时磁盘文件合并成一个文件，并创建索引文件。
这里给出的调优建议是：当使用SortShuffleManager时，如果的确不需要排序，可以将这个参数值调大一些，大于shuffle read task的数量。那么此时就会自动开启bypass机制，map-side就不会进行排序了，减少排序的性能开销，提升shuffle操作效率。但这种方式并没有减少shuffle write过程产生的磁盘文件数量，所以写的性能没有改变。

HashShuffleManager优化建议

如果使用HashShuffleManager，可以设置spark.shuffle.consolidateFiles参数。该参数默认为false，只有当使用HashShuffleManager且该参数设置为True时，才会开启consolidate机制，大幅度合并shuffle write过程产生的输出文件，对于shuffle read task 数量特别多的情况下，可以极大地减少磁盘IO开销，提升shuffle性能。consolidate性能比开启bypass机制的SortShuffleManager高出10% ~ 30%。

处理shuffle类操作的注意事项：

• 减少shuffle数据量：在shuffle前过滤掉不必要的数据，只选取需要的字段处理
• 针对SparkSQL和DataFrame的join、group by等操作：可以通过spark.sql.shuffle.partitions控制分区数，默认设置为200，可根据shuffle的量以及计算的复杂度提高这个值，如2000等
• RDD的join、group by、reduceByKey等操作：通过spark.default.parallelism控制shuffle read与reduce处理的分区数，默认为运行任务的core总数，官方建议为设置成运行任务的core的2~3倍
• 提高executor的内存：即spark.executor.memory的值
• 分析数据验证是否存在数据倾斜的问题：如空值如何处理，异常数据（某个key对应的数据量特别大）时是否可以单独处理，可以考虑自定义数据分区规则

Spark的join优化

Spark所有的操作中，join操作是最复杂、代价最大的操作，也是大部分业务场景的性能瓶颈所在。
如果是大表join小表的情况，则可以将小表声明为broadcast变量，使用map操作快速实现join功能，但又不必执行Spark core中的join操作。
如果是两个大表join，则必须依赖Spark Core中的join操作了。Spark RDD Join的过程如下：
spark的join过程中最核心的函数是cogroup方法，这个方法中会判断join的两个RDD所使用的partitioner是否一样，如果分区相同，即存在OneToOneDependency依赖，不用进行hash分区，可直接join；如果要关联的RDD和当前RDD的分区不一致时，就要对RDD进行重新hash分区，分到正确的分区中，即存在ShuffleDependency，需要先进行shuffle操作再join。因此提升join效率的一个思路就是使得两个RDD具有相同的partitioners。
所以针对Spark RDD的join操作的优化建议是：
• 如果需要join的其中一个RDD比较小，可以直接将其存入内存，使用broadcast hash join
• 在对两个RDD进行join操作之前，使其使用同一个partitioners，避免join操作的shuffle过程
• 如果两个RDD其一存在重复的key也会导致join操作性能变低，因此最好先进行key值的去重处理

数据倾斜优化

存在数据倾斜时，仍然会有性能问题。主要体现在绝大多数task执行得都非常快，个别task执行很慢，拖慢整个任务的执行进程，甚至可能因为某个task处理的数据量过大而爆出OOM错误。

分析数据分布

如果是Spark SQL中的group by、join语句导致的数据倾斜，可以使用SQL分析执行SQL中的表的key分布情况；
如果是Spark RDD执行shuffle算子导致的数据倾斜，可以在Spark作业中加入分析Key分布的代码，使用countByKey()统计各个key对应的记录数。

数据倾斜的解决方案

（1）如果发现导致倾斜的key就几个，而且对计算本身的影响不大，可以考虑过滤掉少数导致倾斜的key。
（2）设置参数spark.sql.shuffle.partitions，提高shuffle操作的并行度，增加shuffle read task的数量，降低每个task处理的数据量
（3）针对RDD执行reduceByKey等聚合类算子或是在Spark SQL中使用group by语句时，可以考虑两阶段聚合方案，即局部聚合+全局聚合。
第一阶段局部聚合，先给每个key打上一个随机数，接着对打上随机数的数据执行reduceByKey等聚合操作，然后将各个key的前缀去掉。第二阶段全局聚合即正常的聚合操作。
（4）针对两个数据量都比较大的RDD/hive表进行join的情况，如果其中一个RDD/hive表的少数key对应的数据量过大，另一个比较均匀时，可以先分析数据，将数据量过大的几个key统计并拆分出来形成一个单独的RDD，得到的两个RDD/hive表分别和另一个RDD/hive表做join，其中key对应数据量较大的那个要进行key值随机数打散处理，另一个无数据倾斜的RDD/hive表要1对n膨胀扩容n倍，确保随机化后key值仍然有效。
（5）针对join操作的RDD中有大量的key导致数据倾斜，对有数据倾斜的整个RDD的key值做随机打散处理，对另一个正常的RDD进行1对n膨胀扩容，每条数据都依次打上0~n的前缀。处理完后再执行join操作

Spark的常见参数的设置

1. –driver-memory 4g : driver内存大小，一般没有广播变量(broadcast)时，设置4g足够，如果有广播变量，视情况而定，可设置6G，8G，12G等均可

2. –executor-memory 4g : 每个executor的内存，正常情况下是4g足够，但有时处理大批量数据时容易内存不足，再多申请一点，如6g

3. –num-executors 15 : 总共申请的executor数目，普通任务十几个或者几十个足够了，若是处理海量数据，如百G上，T的数据时可以申请多一些，100，200等

4. –executor-cores 2 : 每个executor内的核数，即每个executor中的任务task数目，此处设置为2，即2个task共享上面设置的6g内存，每个map或reduce任务的并行度是executor数目executor中的任务数，yarn集群中一般有资源申请上限，如，executor-memorynum-executors < 400G 等，所以调试参数时要注意这一点

5. —-spark.default.parallelism 200 ：Spark作业的默认为500-1000个比较合适,如果不设置，spark会根据底层HDFS的block数量设置task的数量，这样会导致并行度偏少，资源利用不充分。该参数设为num-executors * executor-cores的2~3倍比较合适。

6. – spark.storage.memoryFraction 0.6 : 设置RDD持久化数据在Executor内存中能占的最大比例。默认值是0.6

7. —-spark.shuffle.memoryFraction 0.2 ：设置shuffle过程中一个task拉取到上个stage的task的输出后，进行聚合操作时能够使用的Executor内存的比例，默认是0.2，如果shuffle聚合时使用的内存超出了这个20%的限制，多余数据会被溢写到磁盘文件中去，降低shuffle性能

8. —-spark.yarn.executor.memoryOverhead 1g ：executor执行的时候，用的内存可能会超过executor-memory，所以会为executor额外预留一部分内存，spark.yarn.executor.memoryOverhead即代表这部分内存