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;