HIVE—数据倾斜

数据倾斜：任务进度长时间维持在99%（或100%），查看任务监控页面，发现只有少量（1个或几个）reduce子任务未完成。因为其处理的数据量和其他reduce差异过大。单一reduce的记录数与平均记录数差异过大，通常可能达到3倍甚至更多。 最长时长远大于平均时长。

解决数据倾斜，归根结底是使map的输出数据更均匀的分布到reduce中去。

一、原因

1、join

（1）其中一个表较小，但是key集中。分发到某一个或几个Reduce上的数据远高于平均值

（2）大表与大表，但是分桶的判断字段0值或空值过多。这些空值都由一个reduce处理，非常慢

2、group by

group by 维度过小，某值的数量过多。导致处理某值的reduce非常耗时

3、count（distinct）

某特殊值过多，处理此特殊值的reduce耗时

二、解决方案

1、参数调节

hive.map.aggr=true
Map 端部分聚合，相当于Combiner

hive.groupby.skewindata=true
由于group by 引起数据倾斜的时候进行负载均衡。当选项设定为 true，生成的查询计划会有两个 MR Job。第一个 MR Job 中，Map 的输出结果集合会随机分布到 Reduce 中，每个 Reduce 做部分聚合操作，并输出结果，这样处理的结果是相同的 Group By Key 有可能被分发到不同的 Reduce 中，从而达到负载均衡的目的；第二个 MR Job 再根据预处理的数据结果按照 Group By Key 分布到 Reduce 中（这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce 中），最后完成最终的聚合操作。

set hive.optimize.skewjoin=true;
如果是join 过程出现倾斜，应该设置为true

2、sql调节

（1）空值产生的数据倾斜

场景：如日志中的user_id有些为空（很多），如果取其中的 user_id 和 用户表中的user_id 关联，会碰到数据倾斜的问题。

解决方案1：user_id为空的不参与关联

select * from log a
  join users b
  on a.user_id is not null
  and a.user_id = b.user_id
union all
select * from log a
  where a.user_id is null;

解决方案2：赋与空值新的key值（随机数）

select *from log a
left outer join users b
on case when a.user_id is null then concat(‘hive’,rand() ) else a.user_id end = b.user_id;

结论：方法2比方法1效率更好，不但io少了，而且作业数也少了。解决方法1中 log读取两次，jobs是2。解决方法2 job数是1 。这个优化适合无效 id (比如 -99 , ’’, null 等) 产生的倾斜问题。把空值的 key 变成一个字符串加上随机数，就能把倾斜的数据分到不同的reduce上 ,解决数据倾斜问题。

（2）不同数据类型关联产生数据倾斜

场景：用户表中user_id字段为int，log表中user_id字段既有string类型也有int类型。当按照user_id进行两个表的Join操作时，默认的Hash操作会按int型的id来进行分配，这样会导致所有string类型id的记录都分配到一个Reducer中。

解决方案：把数字类型转换成字符串类型

select * from users a
  left outer join logs b
  on a.usr_id = cast(b.user_id as string)

（3）mapjoin

MAPJION会把小表全部读入内存中，在map阶段直接拿另外一个表的数据和内存中表数据做匹配，由于在map阶段进行了join操作，省去了reduce运行，效率也会高很多。这样就不会由于数据倾斜导致某个reduce上落数据太多而失败。

适用条件：关联操作中有一张表非常小（<1000行）

              需要做不等值join操作（a.x < b.y 或者 a.x like b.y等）

例1：关联操作中有一张表非常小

select f.a, f.b from A t join B f  on ( f.a=t.a and f.ftime=20110802)  
该语句中B表有30亿行记录，A表只有100行记录，而且B表中数据倾斜特别严重，有一个key上有15亿行记录，在运行过程中特别的慢，而且在reduece的过程中遇有内存不够而报错。

改进：
select /*+ mapjoin(A)*/ f.a, f.b from A t join B f  on ( f.a=t.a and f.ftime=20110802) 

例2：需要做不等值join操作

select A.a, A.b from A join B where A.a>B.a
将不等条件写在where中，那么mapreduce过程中会进行笛卡尔积，运行效率特别低。

改进：
select /*+ mapjoin(A)*/  A.a, A.b from A join B where A.a>B.a

例3：小表不小不大

select * from log a
  left outer join users b
  on a.user_id = b.user_id;
users 表有 600w+ 的记录，把 users 分发到所有的 map 上也是个不小的开销，而且 map join 不支持这么大的小表。如果用普通的 join，又会碰到数据倾斜的问题。

解决方案：
select /*+mapjoin(x)*/* from log a
  left outer join (
    select  /*+mapjoin(c)*/d.*
      from ( select distinct user_id from log ) c
      join users d
      on c.user_id = d.user_id
    ) x
  on a.user_id = b.user_id;