如何处理hive中的数据倾斜

什么是数据倾斜

hive在shuffle的部分操作时，由于数据key的分化不均，造成有的节点数据很多，而有的节点数据很少。表现在实际应用上：

• 总任务一直看在99%，单个节点一直处于未完成阶段
• 单一reduce记录与平均记录差异过大，甚至3倍以上。
• 总是出现OOM的报错

一句话，“不患多而患不均”。

数据倾斜的原理

当有以下操作时：

数据倾斜的处理方法

join

• 处理null值

  在关联前将两表的关联字段的Null值干掉。

  如果业务需要保留，则单独拿出来计算，或将其替换为一个随机值（保证和新表对应不上）。

  如果不需要，则直接删除null值

• 处理重复值

  如果数据存在重复，且业务运行去重。那首先对数据进行去重处理。或者至少对join的左侧表的key值进行去重

  hive在join时，join左侧表的key值每出现一次重复，那么就要多计算一次。

• 查看join顺序

  确认join左侧为小表，右侧为大表。

  在hive的新版本里，默认开启map join。而mapjoin必须在小表为左侧，且数据极小才可实现。同时小表key值重复概率较小。

• 使用map join

  当join表左侧小表为20000行以下时，可以通过设置map join来加速。

  mapjoin设置后，即将小表直接加载至内存中，将key值hash后与大表的key值hash进行匹配。

  新版本默认开启

• 查看join表的key值分布

  在大表join大表时，不可启用map join，且可能存在key值分布极度不均时。也会出现数据倾斜现象。有两个解决方法。

  1. key值去重后小于20000，首先对A表的key值进行去重后与B表进行map join。然后再将B表作为小表与A表进行mapjoin。

  2. key值去重后大于20000，首先查看key值分布。将大量重复的key值直接取出单独计算再union回去即可。

     此方法的缺点是会有多次IO，且如果重复的key值数量超过20000后也很麻烦

count distinct

count distinct之所以执行缓慢，主要是因为在map阶段不会有combin操作。而是会把所有的数据sql都仍在1个reduce中。

例如：

select count(distcint a) from t1;

可以将其改写为:

select count(1) from (select distinct a from t1) t1;

这样的话，就相当与先通过多个reduce进行去重，然后再放至单个reduce进行计数。

此处的distinct也可以再次优化。比如

select distinct a from t1;

可以优化为：

select a from t1 group by a;

但后者为何更快，还没想明白。待补充

goup by

参数调节

• hive.map.aggr = true

  Map 端就做部分聚合，相当于Combiner，吃部分内存。

• hive.groupby.skewindata=true

  此时会进行负载均衡，查询计划会生成两个MR job。

  第一个map会将输出结果随机分布在不同的reduce中，并做聚合操作。即此时相同的key也可能被分发到不同的reduce里。

  第二个map则会根据预处理的数据结果再根据key分布聚合到reduce中。此处保证每个相同key在同一个reduce中。

其他

可以将倾斜的数据单独处理再union回来