hive大数据倾斜的原因有哪些

这篇文章主要为大家展示了“hive 大数据倾斜的原因有哪些”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让丸趣 TV 小编带领大家一起研究并学习一下“hive 大数据倾斜的原因有哪些”这篇文章吧。

1 数据倾斜的原因 1.1 操作：

关键词

情形

后果

Join

其中一个表较小，

但是 key 集中

分发到某一个或几个 Reduce 上的数据远高于平均值

大表与大表，但是分桶的判断字段 0 值或空值过多

这些空值都由一个 reduce 处理，灰常慢

group by

group by 维度过小，

某值的数量过多

处理某值的 reduce 灰常耗时

Count Distinct

某特殊值过多

处理此特殊值的 reduce 耗时

1.2 原因：

1)、key 分布不均匀

2)、业务数据本身的特性

3)、建表时考虑不周

4)、某些 SQL 语句本身就有数据倾斜

1.3 表现：

任务进度长时间维持在 99%（或 100%），查看任务监控页面，发现只有少量（1 个或几个）reduce 子任务未完成。因为其处理的数据量和其他 reduce 差异过大。

单一 reduce 的记录数与平均记录数差异过大，通常可能达到 3 倍甚至更多。最长时长远大于平均时长。

2 数据倾斜的解决方案 2.1 参数调节：

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.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 回去。

3 典型的业务场景 3.1 空值产生的数据倾斜

场景：如日志中，常会有信息丢失的问题，比如日志中的 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_idunion allselect * 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 上 , 解决数据倾斜问题。

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

场景：用户表中 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)

3.3 小表不小不大，怎么用 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 不会太多，有交易的会员不会太多，有点击的会员不会太多，有佣金的会员不会太多等等。所以这个方法能解决很多场景下的数据倾斜问题。

以上是“hive 大数据倾斜的原因有哪些”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注丸趣 TV 行业资讯频道！