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

69次阅读
没有评论

这篇文章主要为大家展示了“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 行业资讯频道!