常见数据倾斜及解决方法

1.group by导致数据倾斜

• 设置hive.map.aggr：默认为true，在map端做聚合，推荐使用

• 设置hive.groupby.skewindata：reduce操作的时候，相同key值并不是都给同一个reduce，而是随机分发到各个reduece做聚合。这个参数其实跟hive.map.aggr做的类似，只是在reduce端做，要额外启动一轮job，不推荐使用

• 优化sql语句

有个tt表，数据量很大，假如字段a代表的性别，那么只有2个值，对a进行group by操作，所有聚合运行将会落在两个节点上。优化方法，先group by a b，b需要一个比较分散的值，比如班级或者年级，得到一个较小规模的中间结果数据，再对中间结果group by a。

改写前

select a, count(distinct b) as c from tt group by a;

改写后 

select a, count(*) as c from (select a, b from tt group by a, b) group by a;

2.join操作导致数据倾斜

select * from logs a join users b on a.user_id = b.user_id;

日志表有大量未登陆用户的数据，即user_id为0，reduce时候，某个节将会其他节点多出大量数据，形成单点压力。

• 设置hive.optimize.skewjoin和hive.skewjoin.key参数 

其原理把这种user_id为0的特殊值先不在reduce端计算掉，而是先写入hdfs，然后启动一轮map join专门做这个特殊值的计算，期望能提高计算这部分值的处理速度。hive.skewjoin.key设置值比如是1万，那么超过1万条记录的值就是特殊值。

• 优化sql，特殊值分开处理

user_id=0的单独做join，这样user_id=0转化成map join，user_id!=0是没有数据倾斜的普通join。

select
    *
from (select * from logs where user_id = 0) a
join (select * from users where user_id = 0) b on a.user_id = b.user_id

union all

select * from logs a join users b on a.user_id <> 0 and a.user_id = b.user_id;

• 优化sql，特殊值赋予新key

select * from logs a
left outer join users b
on
    case
        when a.user_id is null
        then concat('prefix_', rand())
        else a.user_id
    end = b.user_id;

• 优化sql，关联key随机打散

select a.*,b.*
from (select *, cast(rand() * 10 as int) as r_id from logs) a
join (select *, r_id from items lateral view explode(range_list(1, 10)) rl as r_id) b
on a.item_id = b.item_id and a.r_id = b.r_id

对行为表的每条记录生成一个1-10的随机整数，对于item属性表，每个item生成10条记录，随机key分别也是1-10，这样就能保证行为表关联上属性表。其中range_list(1,10)代表用udf实现的一个返回1-10整数序列的方法。这个做法是一个解决join倾斜比较根本性的通用思路，就是如何用随机数将key进行分散。 

3.不同类型关联导致数据倾斜

用户表中user_id字段为int，logs表中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)

4.利用map join解决数据倾斜问题

• 大小表关联

 select * from users as a join logs b  on a.user_id = b.user_id

如果users表只有100行数据，logs表有1亿条数据且数据倾斜特别严重，reduce过程中同样会遇到数据倾斜问题。

利用map join，会把小表全部读入内存中，在map阶段直接拿另外一个表的数据和内存中表数据做匹配，由于在map是进行了join操作，省去了reduce运行的效率也会高很多。

select /*+ mapjoin(a)*/ from users as a join logs b  on a.user_id = b.user_id

• where条件中存在不等式造成的笛卡尔积

map join还有一个优势，能够进行不等连接的join操作，如果将不等条件写在where中，那么mapreduce过程中会进行笛卡尔积，运行效率特别低，如果使用map join操作，在map的过程中就完成了不等值的join操作，效率会高很多。

select /*+ mapjoin(a)*/ from A join B where A.a>B.a

•  小表不大大表不小

select * from log a left outer join users b on a.user_id = b.user_id;

users 表有 600w+ 的记录，把 users 分发到所有的 map 上也是个不小的开销，而且 map join 不支持这么大的小表。如果用普通的 join，又会碰到数据倾斜的问题。

log里user_id有上百万个，但每日的会员uv不会太多，有交易的会员不会太多，有点击的会员不会太多，有佣金的会员不会太多等等，可以利用这一特性，通过map join进行优化

select
    /*+mapjoin(x)*/
    *
from
    logs a
left outer join
    (
        select
            /*+mapjoin(c)*/
            d.*
        from
            (
                select distinct user_id from logs
            )
            c
        join users d
        on
            c.user_id = d.user_id
    )
    x on a.user_id = b.user_id; 

 

参考

https://blog.csdn.net/anshuai_aw1/article/details/84033160

https://www.cnblogs.com/qiuhong10/p/7698277.html