这是我参与「第四届青训营 」笔记创作活动的第7天
Spark 数据倾斜
-
表现
部分任务极慢，任务卡在某个阶段不能结束，任务突然失败
-
原因
数据激增，Key分布不均，建表连接性差；
-
思路
数据预处理，异常值过滤；
数据激增可以单独对这部分数据做两次MR先打散在聚合；
优化代码逻辑，优化sql(每个行动算子都会增加job,每次shuffle都会增加一个阶段)、调参(Hadoop切片、预聚合、合并，hive中MapJoin等)；
-
定位数据倾斜
- 通过web UI或者日志查看task运行情况，定位是哪个stage出现问题；
- 代码中在spark或sparkSQL中出现shuffle语言，那么就可以分出前后两个stage，定位出现问题的stage，优化代码逻辑。
-
方法
- hive中ETL处理数据(在hive中预先将key聚合，spark对预处理的hive表操作) ->提升性能但是在hive ETL中还是会倾斜；
- 过滤掉少数导致倾斜的key(filter/where) -> 适用于倾斜的key少并且对计算本身影响不大的情况;
- 提高shuffle操作的并行度(在执行shuffle算子的时候传入参数设置spark.sql.shuffle.partitions，代表了并行度，默认200)->适用于相同key数据不多情况；
- 两阶段聚合（局部聚合+全局聚合）先将key打上随机数前缀后聚合，然后将前缀去掉全局聚合 -> 适用于聚合类的shuffle操作；
- 将reduce join转为map join(将较小的rdd直接collect拉到内存，然后对其创建广播变量，遍历较大的rdd与变量合并) -> 适用于大表和小表join的情况；
Shuffle
对数据经行打乱重组的过程
产生shuffle的算子：
重分区、ByKey、Join
Shuffle变迁过程
-
HashShuffle
- 优点：不需要排序
- 缺点：打开，创建的文件过多
-
SortShuffle
- 优点：打开的文件少、支持map-side combine
- 缺点：需要排序
-
TungstenSortShuffle
- 优点：更快的排序效率，更高的内存利用效率
- 缺点：不支持map-side combine
Shuffle优化
-
使用broadcast代替join，广播变量
-
使用可以map-side预聚合的算子
-
参数优化
-
AQE：将倾斜的分区打散成小的分区，然后各种进行join
-
如果分区过多有较多随机读，增大MapTask的数据量
