导航：首页 > 服务器 >

Hive数据倾斜的原因及优化方法

发表于：2026-11-01 作者：千家信息网编辑

千家信息网最后更新 2026年11月01日，这篇文章主要讲解了"Hive数据倾斜的原因及优化方法"，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习"Hive数据倾斜的原因及优化方法"吧！数据倾斜成因：

千家信息网最后更新 2026年11月01日Hive数据倾斜的原因及优化方法

这篇文章主要讲解了"Hive数据倾斜的原因及优化方法"，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习"Hive数据倾斜的原因及优化方法"吧！

数据倾斜成因：由于数据分布不均匀，造成数据大量的集中到一点，造成数据热点。具体为某一个reduce接收到的数据是其他reduce的n倍，导致明显的木桶效应。

症状：

1，对表做select count(1) from tb group by key，看表中是否有大量相同的key。

2，查看监控界面，任务进度长时间维持在99%（或100%），只有少量（1个或几个）reduce子任务未完成或某几个reduce子任务是平均reduce时长的n倍；

上图的其中的一个job的reduce时间远远超出其他reduce时长，表明该reduce处理的数据远超出其他的reduce，可见此次统计发生数据倾斜。

解决方案

参数调优：

1，set hive.groupby.skewindata=true：这个参数的意思是做Reduce操作的时候，拿到的key并不是所有相同值给同一个Reduce，而是随机分发，然后Reduce做聚合，做完之后再做一轮MR，拿前面聚合过的数据再算结果。所以这个参数其实跟Hive.Map.aggr做的是类似的事情，只是拿到Reduce端来做，而且要额外启动一轮Job，所以其实不怎么推荐用，效果不明显。

2，set hive.skewjoin.key=100000：这个是join的键对应的记录条数超过这个值则会进行优化。

3，set mapred.reduce.tasks=500：增加Reducer个数，通常数据(KV数值对）Shuffle到某个Reducer是根据Key进行Hash然后对Reducer个数进行取模。

HQL语句优化：

1，小表join大表：

将小表放在join左边，减少oom的几率；

使用mapjoin，小表数据最好在1000条以内。select /*+mapjoin(a)*/ count(1) from tb_a a left outer join tb_b b on a.uid=b.uid；

2，大表join大表：

把空值的key变成一个字符串加上随机数，把倾斜的数据分到不同的reduce上，由于null值关联不上，处理后并不影响最终结果。

select * from tb_a a left outer join tb_b b on (case when a.userid is null then concact('xxx', rand()) else a.userid end = b.userid);

3，不同数据类型关联产生数据倾斜，在join之前先转换数据类型：

select * from users a left outer join logs b on a.usr_id = cast(b.user_id as string);

4，count distinct优化