这章主要是计算管理相关的内容。简单来说就是提高计算的效率,包括数据倾斜的处理。关注公众号回复 802 获取 pdf。
1.系统优化
1.1 重新排序 Join
Join 的性能关系到整个 SQL 的性能。重新排序 Join 是 将 Join 所有不同输入进行全排序,找到代价最小的排序。
1.2 自动 MapJoin
自动评估是否采用 MapJoin。
2.任务优化
2.1 Map 倾斜
由于读入文件大小不均匀,导致某些 Map Instance 读取的数据特别多,某些 Map Instance 读取的数据特别少,造成 Mpa 端长尾。可能的原因:
- 上游表大小不均匀,小文件特别多。
- 解决:合并小文件。
- Map 端做聚合时,某些 Map Instance 读取文件的某个值特别多。
- 使用 distribute by rand() 打乱数据分布,使数据分布均匀。
2.2 Join 倾斜
Join Key 相同的数据会发到一个 Instance 上处理。如果某个 Key 的数据量大,则会导致该 Instance 执行时间较长。比如双十一期间,大型店铺的 PV 远超其他店铺的 PV。用浏览日志和卖家维表关联时,会按照卖家 ID 进行分发,导致某些大卖家所在的 Instance 处理的数据量远超其他 Instance。处理:
- Join 的某路输入比较小,可采用 MapJoin,避免分发引起长尾效应;
- Join 的每路输入都很大,长尾由空值造成,可将空值处理成随机值避免聚集;
- Join 的每路输入都很大,长尾由热点值造成,可取出热点 key,对热点值和非热点值分别进行处理,再合并数据。
2.3 Reduce 倾斜
Reduce 端负责 Count、Sum、Avg 等聚合操作。Reduce 端长尾的主要原因是 key 分别不均匀。具体如下:
- 对同一个表按照维度对不同的列进行 Count Distinct 操作,造成 Map 端数据膨胀,使得下游的 Join 和 Reduce 出现链路上的长尾。
- Map 端直接做聚合时出现 key 值分布不均匀,造成 Reduce 端长尾。
- 处理:对热点 key 单独处理,再 Union All 合并。
- 动态分区数过多时造成小文件过多,引起 Reduce 端长尾。
- 处理:符和不同条件的数据放到不同分区,避免多次 Insert Overwrite 写入表中。对动态分区额外引入一级 Reduce Task。
- 多个 Distinct 同时出现在一段 SQL 代码中时,数据会被分发多次,造成数据膨胀 N 倍,长尾现象放大 N 倍。
对于 count distinct 操作,可以先分别进行查询,在原表上 Group by。目前 Reduce 端数据倾斜很多是由 Count Distinct 问题引起的,需要重视。
欢迎关注。每天分享大数据开发技术和面经。回复 802 获取《大数据之路》。