当前位置:首页 > 开发 > 开源软件 > 正文

【Hive十一】Hive数据倾斜优化

发表于: 2015-04-08   作者:bit1129   来源:转载   浏览:
摘要: 什么是Hive数据倾斜问题   操作:join,group by,count distinct 现象:任务进度长时间维持在99%(或100%),查看任务监控页面,发现只有少量(1个或几个)reduce子任务未完成;查看未完成的子任务,可以看到本地读写数据量积累非常大,通常超过10GB可以认定为发生数据倾斜。 原因:key分布不均匀 倾斜度衡量:平均记录数超过50w且

什么是Hive数据倾斜问题

 

  • 操作:join,group by,count distinct
  • 现象:任务进度长时间维持在99%(或100%),查看任务监控页面,发现只有少量(1个或几个)reduce子任务未完成;查看未完成的子任务,可以看到本地读写数据量积累非常大,通常超过10GB可以认定为发生数据倾斜。
  • 原因:key分布不均匀
  • 倾斜度衡量:平均记录数超过50w且最大记录数是超过平均记录数的4倍;最长时长比平均时长超过4分钟,且最大时长超过平均时长的2倍



Hive的典型操作时多表关联
查询

SELECT a.* FROM a JOIN b ON (a.id = b.id AND a.department = b.department)

 

1. 判断是否有数据倾斜

通过对表做group by key操作,取Top N,看表中是否有大量相同的Key

 

2.Reducer端数据倾斜

Hive查询底层是基于Hadoop的Map Reduce,如果一个Reducer要处理的数据量远多于其它Reducer要处理的数据量,那么就会产生Reducer端的数据倾斜。那么Reducer要处理的数据量是如何确定的呢?通常数据(KV数值对)Shuffle到某个Reducer是根据Key进行Hash然后对Reducer个数进行取模。那么Reducer端的优化包含三种做法

 

2.1 增加Reducer个数

 

set mapred.reduce.tasks=500;
SELECT a.*,b.name FROM a JOIN b ON (a.id = b.id AND a.department = b.department);

 

2.2 空KEY过滤

 

有时join超时是因为某些key对应的数据太多,而相同key对应的数据都会发送到相同的reducer上,从而导致内存不够。此时我们应该仔细分析这些异常的key,很多情况下,这些key对应的数据是异常数据,我们需要在SQL语句中进行过滤。例如key对应的字段为空。

SELECT table_a.* , b.name
FROM
(
   SELECT *
   FROM a
   WHERE id is not null
)table_a JOIN b ON (table_a.id = b.id AND table_a.department = b.department)

 

2.3 空KEY转换

 

有时虽然某个key为空对应的数据很多,但是相应的数据不是异常数据,必须要包含在join的结果中,此时我们可以表a中key为空的字段赋一个随机的值,使得数据随机均匀地分不到不同的reducer上。例如:

 

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;

 

3 设置set hive.groupby.skewindata=true

这是通用的优化方法,对于group by或distinct设置set hive.groupby.skewindata=true

 

4. 大小表关联,大表和大表关联

 

4.1 大小表关联

将key相对分散,并且数据量小的表放在join的左边,这样可以有效减少内存溢出错误发生的几率;再进一步,可以使用mapjoin让小的维度表(1000条以下的记录条数)先进内存。在map端完成reduce

 

4.2 大表和大表关联

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

 

4.3 大表和不小的表关联

 

使用map join解决数据倾斜的常景下小表关联大表的问题,但如果小表很大,怎么解决。这个使用的频率非常高,但如果小表很大,大到map join会出现bug或异常,这时就需要特别的处理。云瑞和玉玑提供了非常给力的解决方案。以下例子:

select * from log a left outer join members b on a.memberid = b.memberid

 
Members有600w+的记录,把members分发到所有的map上也是个不小的开销,而且map join不支持这么大的小表。如果用普通的join,又会碰到数据倾斜的问题。

解决方法:

select /*+mapjoin(x)*/* from log a left outer join
    ( select  /*+mapjoin(c)*/d.*
      from (select  distinct memberid from log ) c
      join members d
      on c.memberid = d.memberid
    )x on a.memberid = b.memberid

 

先根据log取所有的memberid,然后mapjoin 关联members取今天有日志的members的信息,然后在和log做mapjoin。

假如,log里memberid有上百万个,这就又回到原来map join问题。所幸,每日的会员uv不会太多,有交易的会员不会太多,有点击的会员不会太多,有佣金的会员不会太多等等。所以这个方法能解决很多场景下的数据倾斜问题。







参考:
http://www.dcharm.com/?p=32
http://janefucninax.blog.sohu.com/247717331.html

重点阅读:
http://sznmail.iteye.com/blog/1499789
http://sunyi514.github.io/2013/09/01/%E6%95%B0%E6%8D%AE%E4%BB%93%E5%BA%93%E4%B8%AD%E7%9A%84sql%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96%EF%BC%88hive%E7%AF%87%EF%BC%89/

【Hive十一】Hive数据倾斜优化

  • 0

    开心

    开心

  • 0

    板砖

    板砖

  • 0

    感动

    感动

  • 0

    有用

    有用

  • 0

    疑问

    疑问

  • 0

    难过

    难过

  • 0

    无聊

    无聊

  • 0

    震惊

    震惊

编辑推荐
数据倾斜成因:由于数据分布不均匀,造成数据大量的集中到一点,造成数据热点。具体为某一个reduce
在做Shuffle阶段的优化过程中,遇到了数据倾斜的问题,造成了对一些情况下优化效果不明显。主要是因
概述: 一个Hive查询生成多个map reduec job,一个map reduce job又有map,reduce,spill,Shuffle
4 Hive
主要分为以下几个部分: 用户接口,包括 CLI,Client,WUI。 元数据存储,通常是存储在关系数据库如
5 HIVE
HIVE 为什么要选择Hive 基于Hadoop的大数据的计算/扩展能力 支持SQL like查询语言 统一的元数据管理
6 hive
hive的设计目的就是让精通sql的分析师能够在facebook存放在hdfs的大规模数据集上进行查询。 hive把s
1.当hive执行join内存溢出时,可以修改hive的配置文件hive-site.xml,增大内存,如下: mapred.chil
一 整体架构优化 现在hive的整体框架如下,计算引擎不仅仅支持Map/Reduce,并且还支持Tez、Spark等
1.概述   继续《那些年使用Hive踩过的坑》一文中的剩余部分,本篇博客赘述了在工作中总结Hive的常
  我最近研究了hive的相关技术,有点心得,这里和大家分享下。   首先我们要知道hive到底是做什
版权所有 IT知识库 CopyRight © 2009-2015 IT知识库 IT610.com , All Rights Reserved. 京ICP备09083238号