Hive调优 | Hive常见数据倾斜及调优技巧

Hive在执行MapReduce任务时经常会碰到数据倾斜的问题，表现为一个或者几个reduce节点运行很慢，延长了整个任务完成的时间，这是由于某些key的条数比其他key多很多，这些Key所在的reduce节点所处理的数据量比其他节点就大很多，从而导致某几个节点迟迟运行不完。

那么经常有哪些情况会产生数据倾斜呢，又该如何解决，这里梳理了几种最常见的数据倾斜场景。

一、小表与大表JOIN
小表与大表Join时容易发生数据倾斜，表现为小表的数据量比较少但key却比较集中，导致分发到某一个或几个reduce上的数据比其他reduce多很多，造成数据倾斜。

优化方法：使用Map Join将小表装入内存，在map端完成join操作，这样就避免了reduce操作。有两种方法可以执行Map Join：

(1) 通过hint指定小表做MapJoin

select  /*+ MAPJOIN(time_dim) */ count(*)  from store_sales join time_dim on ss_sold_time_sk = t_time_sk;

(2) 通过配置参数自动做MapJoin

核心参数：

image.png

二、大表与大表JOIN
大表与大表Join时，当其中一张表的NULL值（或其他值）比较多时，容易导致这些相同值在reduce阶段集中在某一个或几个reduce上，发生数据倾斜问题。

优化方法：

(1) 将NULL值提取出来最后合并，这一部分只有map操作；非NULL值的数据分散到不同reduce上，不会出现某个reduce任务数据加工时间过长的情况，整体效率提升明显。这种方法由于有两次Table Scan会导致map增多。

SELECT a.user_Id,a. username,b.customer_id
FROM user_info a
LEFT JOIN customer_info b
ON a.user_id = b.user_id
where a.user_id IS NOT NULL

UNION ALL

SELECT a.user_Id,a.username,NULL
FROM user_info a
WHERE a.user_id IS NULL
(2) 在Join时直接把NULL值打散成随机值来作为reduce的key值，不会出现某个reduce任务数据加工时间过长的情况，整体效率提升明显。这种方法解释计划只有一次map，效率一般优于第一种方法。

SELECT a.user_id,a.username,b.customer_id
FROM user_info a
LEFT JOIN customer_info b
ON
CASE WHEN
a.user_id IS NULL
THEN
CONCAT ('dp_hive', RAND())
ELSE
a.user_id
END = b.user_id;
三、GROUP BY 操作
Hive做group by查询，当遇到group by字段的某些值特别多的时候，会将相同值拉到同一个reduce任务进行聚合，也容易发生数据倾斜。

优化方法：

(1) 开启Map端聚合

参数设置：

image.png

(2) 有数据倾斜时进行负载均衡

参数设置：

image.png

当设定hive.groupby.skewindata为true时，生成的查询计划会有两个MapReduce任务。在第一个MapReduce 中，map的输出结果集合会随机分布到 reduce 中， 每个 reduce 做部分聚合操作，这样处理之后，相同的 Group By Key 有可能分发到不同的 reduce 中，从而达到负载均衡的目的。在第二个 MapReduce 任务再根据第一步中处理的数据按照Group By Key分布到reduce中，（这一步中相同的key在同一个reduce中），最终生成聚合操作结果。

四、COUNT(DISTINCT) 操作
当在数据量比较大的情况下，由于COUNT DISTINCT操作是用一个reduce任务来完成，这一个reduce需要处理的数据量太大，就会导致整个job很难完成，这也可以归纳为一种数据倾斜。

优化方法：将COUNT DISTINCT使用先GROUP BY再COUNT的方式替换。例如：

select count(id) from (select id from bigtable group by id) a

因此，count distinct的优化本质上也是转成group by操作。