0


hive数据倾斜(超详细)

说到hive的数据倾斜,可能有的小伙伴还不了解什么是数据倾斜,所以咱们这一次就从hive数据倾斜的表现、hive数据倾斜发生的原因、hive数据倾斜的解决方案这三个方面来聊一聊hive的数据倾斜

1、hive数据倾斜的表现

我们都知道hive的底层其实是mr(MapReduce)引擎,hsql其实就是把sql语言转换成mr去运行,这样就大大缩减了咱们去写mr的时间,然而有时候咱们会发现在你运行一个任务的时候,明明所有的map task都完成了,并且99%的reduce task也完成,只剩下一个后者少数几个reduce task一直在执行,等了半天就是不动,其实这种情况一般都是发生了数据倾斜,说白了,hive的数据倾斜本质上就是MapReduce的数据倾斜(感兴趣的小伙伴可以去查看任务监控页面)

** 2、hive数据倾斜的原因**

其实数据倾斜这个问题,在MapReduce编程模型中十分常见,根本原因就是大量相同的key被分配到一个reduce里,造成一个reduce任务累死了,但是其他的reduce任务闲死(和我现在上班一样,,,,)。下面咱们来罗列一下常见的数据倾斜有哪些原因:

一、key分布不均衡

二、业务问题后者业务数据本身的问题,某些数据比较集中

三、建表的时候考虑不周

四、某些sql语句本身就有数据倾斜,例如:

(1)大表join小表:其实小表的key集中,分发到某一个或者几个reduce上的数据远远高于平均值

(2)大表join大表:空值或无意义值:如果缺失的项很多,在做join时这些空值就会非常集中,拖累进度。

(3)group by: group by的时候维度过小,某值的数量过多,处理某值的reduce非常耗时间。

(4)Count distinct:某特殊值过多,处理此特殊值的reduce耗时。

3、Hive数据倾斜解决

【参数调节】 hive.map.aggr = true

Map端部分聚合。

有数据倾斜的时候进行负载均衡,当选项设定为true,生成的查询计划会有两个MRJob。第一个MRJob中,Map的输出结果集合会随机分不到Reduce中,每个Reduce做部分聚合操作,并输出结果,这样处理的结果是相同于Group By Key 有可能被分发到不同的Reduce中,从而达到负载均衡的目的;第二个MRJob再根据预处理的数据结果按照Group By Key分不到Reduce中(这个过程可以保证相同的Group By Key被分布到同一个Reduce中),最后完成最终的聚合操作。

【SQL调整】

1)如何join:关于驱动表的选取,选用join key分布最均匀的表作为驱动表,做好列裁剪和filter操作,以达到两表做join的时候,数据量相对变小的效果。

2)大小表join的时候:使用map join 让小的维度表先进内存,在map端完成reduce。效率很高。

3)大表join大表的时候:把空值的key变成一个字符串加上随机数,把倾斜的数据分到不同的reduce上,由于null值关联不上,处理后不影响最终的结果。

4)count distinct 大量相同特殊值,将这些值为空的情况单独处理,如果是计算count distinct,可以不用处理,直接过滤,在最后结果中加1即可。如果还有其他的计算,需要进行group by,可以先将那些值为空的记录单独处理,再和其他计算结果进行 union。

5)group by 维度过小的时候:采用sum() group by 的方法来替换count(distinct)完成计算。

6)单独处理倾斜key:一般来讲倾斜的key都很少,我们可以将它们抽样出来,对应的行单独存入临时表中,然后打上随机数前缀,最后再进行聚合。或者是先对key做一层hash,先将数据随机打散让它的并行度变大,再汇集。其实办法一样。

标签: hive 大数据 hadoop

本文转载自: https://blog.csdn.net/wind96/article/details/127696043
版权归原作者 满船旧梦压星河 所有, 如有侵权,请联系我们删除。

“hive数据倾斜(超详细)”的评论:

还没有评论