hive如何应对数据倾斜

数据倾斜

概念:数据倾斜是指,map /reduce程序执行时,reduce节点大部分执行完毕,但是

有一个或者几个reduce节点运行很慢,导致整个程序的处理时间很长,这是因为某一

个key的条数比其他key多很多(有时是百倍或者千倍之多),这条key所在的reduce

节点所处理的数据量比其他节点就大很多,从而导致某几个节点迟迟运行不完。

执行操作:

1.其中一个表较小,但是key集中,可能会导致分发到一个或几个Reduce上的数据远高于平均值

2.大表与大表关联,但是空值或者0比较多,这些控制都由一个reduce处理,非常慢。

3.group by维度过小,某值的数量过多。处理某值的Reduce非常耗时。

4.count distinct 某特殊值过多,处理此特殊值的Reduce耗时。

原因:

1.key分布不均

2.业务数据本身的特性

3.建表时考虑不周

4.某些语句本身就有数据倾斜

解决方案:

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.如何join?关于驱动表的选取,选用join key分布最均匀的表做为驱动表。做好列裁剪和filter操作,

以达到两表做join的时候数据量相对变小的效果。

3.使用mapjoin让小的维度表先进内存。在map端完成reduce。

4.大表join大表时,把空值的key变成一个字符串加上随机数,把倾斜的数据随机分布到不同的reduce上,

由于null值关联不上,处理后并不影响最终结果。

5.count distinct时,将值为空的情况单独处理,如果是计算count distinct,可以不用处理,直接过滤,

在最后结果中加1。如果还有其它计算,需要进行group by,可以先将值为空的记录单独处理,再和其他

结果进行union。

6.采用sum() group by的方式来替换count(distinct )进行计算。

7.在业务逻辑优化效果不大的情况下,有些时候是可以将倾斜的数据单独拿出来处理,最后union回去。

8.对于控制产生的倾斜问题,解决方案1:为空的数据不参与关联;方案2:随机(rand())赋予空值新的key。

把空值的key变成一个字符串加上随机数,就能把倾斜的数据分到不同的reduce上,解决数据的倾斜问题。

9.不同数据类型关联产生数据倾斜,默认的Hash操作会按int型的id来分配reduce,这样会导致所有的String

类型数据分配到同一个reduce。

10.使用 mapjoin 解决小表(记录数少)关联大表的数据倾斜问题,这个方法使用的频率非常高,但如果小表

很大,大到map join会出现bug或异常,这时就需要特别的处理。

  总之,优化时把握一个规则,单个作业最优不如整体优。

时间: 2024-08-26 06:04:07

hive如何应对数据倾斜的相关文章

hive sql 优化 数据倾斜

此脚本运行速度慢,主要是reduce端数据倾斜导致的,了解到dw.fct_traffic_navpage_path_detl表是用来收集用户点击数据的,那么最终 购物车和下单的点击肯定极少,所以此表ordr_code字段为空和cart_prod_id字段为NULL的数据量极大,如下所示: select ordr_code,count(*) as a from dw.fct_traffic_navpage_path_detl  where ds = '2015-05-10'  group by o

Hive数据倾斜总结

倾斜的原因: 使map的输出数据更均匀的分布到reduce中去,是我们的最终目标.由于Hash算法的局限性,按key Hash会或多或少的造成数据倾斜.大量经验表明数据倾斜的原因是人为的建表疏忽或业务逻辑可以规避的. 解决思路: Hive的执行是分阶段的,map处理数据量的差异取决于上一个stage的reduce输出,所以如何将数据均匀的分配到各个reduce中,就是解决数据倾斜的根本所在 具体办法: 内存优化和I/O优化: 驱动表:使用大表做驱动表,以防止内存溢出:Join最右边的表是驱动表:

Hive数据倾斜

map/reduce程序执行时,reduce节点大部分执行完毕,但是有一个或者几个reduce节点运行很慢,导致整个程序的处理时间很长,这是因为某一个key的条数比其他key多很多(有时是百倍或者千倍之多),这条key所在的reduce节点所处理的数据量比其他节点就大很多,从而导致某几个节点迟迟运行不完,此称之为数据倾斜. 1.万能膏药:hive.groupby.skewindata=true 当选项设定为 true,生成的查询计划会有两个 MR Job. 第一个 MR Job 中,Map 的输

hive大数据倾斜总结

在做Shuffle阶段的优化过程中,遇到了数据倾斜的问题,造成了对一些情况下优化效果不明显.主要是因为在Job完成后的所得到的 Counters是整个Job的总和,优化是基于这些Counters得出的平均值,而由于数据倾斜的原因造成map处理数据量的差异过大,使得这些平均 值能代表的价值降低.Hive的执行是分阶段的,map处理数据量的差异取决于上一个stage的reduce输出,所以如何将数据均匀的分配到各个 reduce中,就是解决数据倾斜的根本所在.规避错误来更好的运行比解决错误更高效.在

Hive语法层面优化之一数据倾斜介绍

数据倾斜:数据分布不均匀,造成数据大量的集中到一点,造成数据热点: 由于数据并不是平均分配的,会导致各个节点上处理的数据量是不均衡的,所以数据倾斜是无法避免的: 造成数据倾斜的最根本原因:key分发不均匀造成的: 常见的数据倾斜的症状 1)  Map阶段快,reduce阶段非常慢: 2)  某些map很快,某些map很慢: 3)  某些reduce很快,某些reduce很慢: 4)  任务进度长时间维持在99%(或100%),查看任务监控页面,发现只有少量(1个或几个)reduce子任务未完成,

Hive语法层面优化之四count(distinct)引起的数据倾斜

当该字段存在大量值为null或空的记录,容易发生数据倾斜: 解决思路: count distinct时,将值为空的情况单独处理,如果是计算count distinct,可以不用处理,直接过滤,在最后结果中加1: 如果还有其他计算,需要进行group by,可以先将值为空的记录单独处理,再和其他计算结果进行union. 案例: select count(distinct end_user_id) as user_num from trackinfo; 调整为: select cast(count(

Hive语法层面优化之五分析执行计划追踪导致数据倾斜的原因

count(distinct key)案例 explain select count(distinct session_id) from trackinfo where ds=' 2013-07-21' ; STAGE DEPENDENCIES: Stage-1 is a root stage Stage-0 is a root stage STAGE PLANS: Stage: Stage-1 Map Reduce Alias -> Map Operator Tree: trackinfo T

HIVE数据倾斜问题

HIVE数据倾斜问题问题状态: 未解决 背景:HDFS对文件进行了压缩,而且不添加索引.主要用HIVE进行开发. 发现的现象:sqoop从Mysql导入数据,根据ID进行平均分割,但是ID分部及其不均匀(我也不知道业务系统怎么搞得).所以导致reduce出来的文件大小严重不均匀,就是所谓的数据倾斜. 导致的问题:写HQL从该表中读取数据,发现整个job很慢.后来我查日志发现,有几个map读取数据非常慢,1G的文件大概需要1个多小时才能读取完毕. 问题分析: 由于hadoop对文件进行了lzo格式

Hive语法层面优化之六数据倾斜常见案例

常见案例一:空值产生的数据倾斜 日志表有一部分的user_id为空或者是0的情况,导致在用user_id进行hash分桶时,会将日志由user_id为0或者为空的数据分到一个reduce上,导致数据倾斜: 如:访户未登录时,日志中的user_id为空,用user_id和用户表的user_id进行关联的时候,会将日志中的user_id为空的数据分到一起,导致了过大的空key造成数据倾斜: 解决办法:随机函数解决数据倾斜 把空值的key变成一个字符串加上随机数(只要不与真正的end_user_id的