数据倾斜学习总结

数据倾斜只会发生在shuffle过程中。
这里给大家罗列一些常用的并且可能会触发shuffle操作的算子：distinct、groupByKey、reduceByKey、aggregateByKey、join、cogroup、repartition等。
出现数据倾斜时，可能就是你的代码中使用了这些算子中的某一个所导致的。



解决数据倾斜的常用手段
1.使用Hive ETL预先处理数据
        在hive中预先将数据处理成数据分布均匀的数据等待spark读取数据，此时spark读取的数据就是分布均匀的
        局限:spark读取数据来源与hive
        缺点:治标不治本，数据本身的不均匀还是无法解决，依旧需要在hive中处理分布不均匀的数据
2.过滤少数导致倾斜的key
        若发生数据倾斜时，99%的key只有几条或几十条数据，而1%的key有几百万条数据，而且去除掉99%的数据对结果无大的影响，可以选择过滤掉那部分的数据
        方法:rdd.sample(false,0.1).countByKey()取出数据量最多的key过滤即可
        局限:场景不多，大部分的数据倾斜不是几个key导致的
3.提高shuffle的并行度( 首选 )
        使用spark.sql.shuffle.partitions 参数设置shuffle的并行度，默认为200，一般数据较多，设置为1000，提高shuffle并行度
        缺点:无法根本解决数据倾斜问题，比如极端情况，一个key有几百万条数据，其他key依然之后几十条数据，那个几百万条的数据还是只会分配到一个task中处理，数据倾斜依旧存在
        方法:--conf spark.sql.shuffle.partitions=1000
4.聚合类的操作分两次聚合(局部聚合+全局聚合)
        第一次做 聚合操作 前给每个key都加上一个10以内的随机数，然后把key的随机数去掉做第二次聚合操作(有点像M/R中Map端的contain操作)
        有点:对聚合类的shuffle操作导致的数据倾斜，可以大幅缓解数据倾斜问题，提升spark的性能
        缺点:仅仅适用于聚合类的shuffle操作(egg:reduceByKey)，使用范围较窄。不适用join类的shuffle操作
5.shuffle调优:
        Spark 1.2之前使用的是HashShuffleManager调优机制
                开启HashShuffleManager优化机制
                设置spark.shuffle.consolidateFiles参数值为true(多分task在同一个executor上只有一份下一个stage需要的文件数)
        Spark 1.2之后改为使用SortShuffleManager调优机制
                spark.shuffle.sort.bypassMergeThreshold 默认200
                shuffle read task > 200  普通运行机制
                        meory-->sort-->meory--(溢出)->输出文件--(merge)->最终文件-->交给下一个stage处理
                shuffle read task < 200  bypass运行机制
                        相对普通运行机制没有sort操作

以下copy了一些数据倾斜的参数列表及说明
1.spark.shuffle.file.buffer
        默认值：32k
        参数说明：该参数用于设置shuffle write task的BufferedOutputStream的buffer缓冲大小。
                          将数据写到磁盘文件之前，会先写入buffer缓冲中，待缓冲写满之后，才会溢写到磁盘。
        调优建议：如果作业可用的内存资源较为充足的话，可以适当增加这个参数的大小（比如64k），从而减少shuffle write过程中溢写磁盘文件的次数，也就可以减少磁盘IO次数，进而提升性能。
                          在实践中发现，合理调节该参数，性能会有1%~5%的提升。

2.spark.reducer.maxSizeInFlight
        默认值：48m
        参数说明：该参数用于设置shuffle read task的buffer缓冲大小，而这个buffer缓冲决定了每次能够拉取多少数据。
        调优建议：如果作业可用的内存资源较为充足的话，可以适当增加这个参数的大小（比如96m），从而减少拉取数据的次数，也就可以减少网络传输的次数，进而提升性能。
                          在实践中发现，合理调节该参数，性能会有1%~5%的提升。

3.spark.shuffle.io.maxRetries
        默认值：3
        参数说明：shuffle read task从shuffle write task所在节点拉取属于自己的数据时，如果因为网络异常导致拉取失败，是会自动进行重试的。
                          该参数就代表了可以重试的最大次数。如果在指定次数之内拉取还是没有成功，就可能会导致作业执行失败。
        调优建议：对于那些包含了特别耗时的shuffle操作的作业，建议增加重试最大次数（比如60次），以避免由于JVM的full gc或者网络不稳定等因素导致的数据拉取失败。
                          在实践中发现，对于针对超大数据量（数十亿~上百亿）的shuffle过程，调节该参数可以大幅度提升稳定性。

4.spark.shuffle.io.retryWait
        默认值：5s
        参数说明：具体解释同上，该参数代表了每次重试拉取数据的等待间隔，默认是5s。
        调优建议：建议加大间隔时长（比如60s），以增加shuffle操作的稳定性。

5.spark.shuffle.memoryFraction
        默认值：0.2
        参数说明：该参数代表了Executor内存中，分配给shuffle read task进行聚合操作的内存比例，默认是20%。
        调优建议：在资源参数调优中讲解过这个参数。如果内存充足，而且很少使用持久化操作，建议调高这个比例，给shuffle read的聚合操作更多内存，以避免由于内存不足导致聚合过程中频繁读写磁盘。
                          在实践中发现，合理调节该参数可以将性能提升10%左右。

6.spark.shuffle.manager
        默认值：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。

7.spark.shuffle.sort.bypassMergeThreshold
        默认值：200
        参数说明：当ShuffleManager为SortShuffleManager时，如果shuffle read task的数量小于这个阈值（默认是200），则shuffle write过程中不会进行排序操作，
                          而是直接按照未经优化的HashShuffleManager的方式去写数据，但是最后会将每个task产生的所有临时磁盘文件都合并成一个文件，并会创建单独的索引文件。
        调优建议：当你使用SortShuffleManager时，如果的确不需要排序操作，那么建议将这个参数调大一些，大于shuffle read task的数量。
                          那么此时就会自动启用bypass机制，map-side就不会进行排序了，减少了排序的性能开销。但是这种方式下，依然会产生大量的磁盘文件，因此shuffle write性能有待提高。

8.spark.shuffle.consolidateFiles
        默认值：false
        参数说明：如果使用HashShuffleManager，该参数有效。如果设置为true，那么就会开启consolidate机制，会大幅度合并shuffle write的输出文件，
                          对于shuffle read task数量特别多的情况下，这种方法可以极大地减少磁盘IO开销，提升性能。
        调优建议：如果的确不需要SortShuffleManager的排序机制，那么除了使用bypass机制，还可以尝试将spark.shffle.manager参数手动指定为hash，使用HashShuffleManager，
                          同时开启consolidate机制。在实践中尝试过，发现其性能比开启了bypass机制的SortShuffleManager要高出10%~30%。


若有不对，请各大网友纠正，谢谢

强！感谢分享~~~

谢谢分享

总结的很全面啊！