hive 数据倾斜

hive上执行脚本，数据一直跑不出，询问dba说可能是数据倾斜的问题，需要优化脚本（之前脚本可以正常执行），最后发现join表的重复数据过多造成的。网上看了下倾斜，简单总结下。
一、 概念

• 由于数据分布不均，造成大量数据集中到一点，造成数据热点。

二、现象

1. 绝大多数task执行的很快，但是个别task执行很慢。eg：一共10个task，9个几分钟就执行完了，剩余的一个跑了一个多小时还没有结束
2. 之前可以正常执行的spark作业，某天突然爆出内存溢出

三、hadoop框架特性

1. 不怕数据量大,怕数据倾斜
2. jobs数比较多的作业运行效率相对较低，例如子查询较多
3. sum、count、max、min等聚合函数，通常不会有数据倾斜问题

四、容易出现数据倾斜的情况（join、group by、count distinct）

4. group by不和聚合函数搭配使用的时候
5. count(distinct)，在数据量大的情况下，容易倾斜。
6. count(distinct)是按groupby字段分组，按distinct字段排序 小标关联超大表join，即join的值数据量过多
7. 异常数据过多，导致数据倾斜

五、场景

1、在日志中，常会有信息丢失的问题，比如日志中的 user_id，如果取其中的 user_id 和用户表中的 user_id
相关联，就会碰到数据倾斜的问题。

解决：

select * from log a left outer join user b on
case when a.user_id is null then concat('hive', trunc(dbms_random.value(0,10))) else a.user_id end 
= b.user_id

将对应的空值的key变成一个字符串和一个随机数，把造成数据倾斜的数据分到不同的reduce上面，解决倾斜的问题。因为如果user_id为空，会被替代成字符串加随机数，和b.user_id匹配不上，不会影响最终结果。

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

用户表中 user_id 字段为 int，log 表中 user_id 为既有 string 也有 int 的类型， 当按照两个表的 user_id 进行 join 操作的时候，默认的 hash 操作会按照 int 类型的 id 进 行分配，这样就会导致所有的 string 类型的 id 就被分到同一个 reducer 当中

解决：

select * from user a left outer join log b on b.user_id = cast(a.user_id as string)

3、 大小表关联查询产生数据倾斜

使用map join解决小表关联大表造成的数据倾斜问题。
例如a是小表，b是大表：

select /* +mapjoin(a) */ a.id aid, name, age from a join b on a.id = b.id;

每个MapTask载入了大表的一个数据块做处理，载入小表的所有数据做处理，省去了ReduceTask，提高效率。
hive参数设置自动开启map join：

set hive.auto.convert.join=true; //设置 MapJoin 优化自动开启
set hive.mapjoin.smalltable.filesize=25000000 //设置小表不超过多大时开启 mapjoin 优化