Hive数据倾斜

哪些操做须要注意数据倾斜？

产生数据倾斜的缘由有哪些？

1)key分布不均匀
2)业务数据自己的特性
3)建表时考虑不周
4)某些SQL语句自己就有数据倾斜

发生数据倾斜的表现？

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

数据倾斜的解决方案有哪些？

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

2 SQL语句调节 如何Join：

关于驱动表的选取，选用join key分布最均匀的表做为驱动表
作好列裁剪和filter操做，以达到两表作join的时候，数据量相对变小的效果。
复制代码

大小表Join：

使用map join让小的维度表（1000条如下的记录条数） 先进内存。在map端完成reduce.
复制代码

大表Join大表：

把空值的key变成一个字符串加上随机数，把倾斜的数据分到不一样的reduce上，因为null值关联不上，处理后并不影响最终结果。
复制代码

count distinct大量相同特殊值

count distinct时，将值为空的状况单独处理，若是是计算count distinct，能够不用处理，直接过滤，在最后结果中加1。若是还有其余计算，须要进行group by，能够先将值为空的记录单独处理，再和其余计算结果进行union。
复制代码

group by维度太小：

采用sum() group by的方式来替换count(distinct)完成计算。
复制代码

特殊状况特殊处理：

在业务逻辑优化效果的不大状况下，有些时候是能够将倾斜的数据单独拿出来处理。最后union回去。
复制代码

典型的发生数据倾斜的场景有哪些？

一、空值产生的数据倾斜 场景：如日志中，常会有信息丢失的问题，好比日志中的 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上 ,解决数据倾斜问题。

二、不一样数据类型关联产生数据倾斜
场景：用户表中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)
复制代码

三、小表不小不大，怎么用 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不会太多，有交易的会员不会太多，有点击的会员不会太多，有佣金的会员不会太多等等。因此这个方法能解决不少场景下的数据倾斜问题。
四、总结

使map的输出数据更均匀的分布到reduce中去，是咱们的最终目标。因为Hash算法的局限性，按key Hash会或多或少的形成数据倾斜。大量经验代表数据倾斜的缘由是人为的建表疏忽或业务逻辑能够规避的。在此给出较为通用的步骤：

1）采样log表，哪些user_id比较倾斜，获得一个结果表tmp1。因为对计算框架来讲，全部的数据过来，他都是不知道数据分布状况的，因此采样是并不可少的。

2）数据的分布符合社会学统计规则，贫富不均。倾斜的key不会太多，就像一个社会的富人很少，奇特的人很少同样。因此tmp1记录数会不多。把tmp1和users作map join生成tmp2,把tmp2读到distribute file cache。这是一个map过程。

3）map读入users和log，假如记录来自log,则检查user_id是否在tmp2里，若是是，输出到本地文件a,不然生成。