Vol04-数据倾斜

典型的业务场景

1. 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 thenconcat(‘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上 ,解决数据倾斜问题。

1. 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)

1. 3.      小表不小不大，怎么用map join 解决倾斜问题

使用 map join 解决小表(记录数少)关联大表的数据倾斜问题，这个方法使用的频率非常高，但如果小表很大，大到map join会出现bug或异常，这时就需要特别的处理。 以下例子:

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;

假如，log里user_id有上百万个，这就又回到原来map join问题。

所幸，每日的会员uv不会太多，有交易的会员不会太多，有点击的会员不会太多，有佣金的会员不会太多等等。所以这个方法能解决很多场景下的数据倾斜问题。