【数仓】计算管理

  这章主要是计算管理相关的内容。简单来说就是提高计算的效率，包括数据倾斜的处理。关注公众号回复 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 获取《大数据之路》。