Hive调优(语法与参数层面优化)

标签: hive 语法 参数 | 发表时间:2015-05-04 19:09 | 作者:scgaliguodong123_
出处:http://blog.csdn.net

一、简介
作为企业Hadoop应用的核心产品,Hive承载着FaceBook、淘宝等大佬 95%以上的离线统计,很多企业里的离线统计甚至全由Hive完成,如我所在的电商。Hive在企业云计算平台发挥的作用和影响愈来愈大,如何优化提速已经显得至关重要。

好的架构胜过任何优化,好的Hql同样会效率大增,修改Hive参数,有时也能起到很好的效果。

有了瓶颈才需要优化
1、Hadoop的主要性能瓶颈是IO负载,降IO负载是优化的重头戏。
2、对中间结果的压缩
3、合理设置分区,静态分区和动态分区

二、Hive Sql语法层面和Properties参数层面优化

优化方法
合并小文件
避免数据倾斜,解决数据倾斜
减少job数据(合并job,大job的拆分…)

优化手段
2.1 合理控制Map和Reduce数
(一)map数
1、Map数过大
Map阶段输出文件太小,产生大量小文件(下一个阶段就需要进行小文件合并,或者到reduce阶段就会浪费很多reduce数)。
初始化和创建map的开销很大。

2、Map数过小
文件处理或查询并发度小,Job执行空间过长。
大量作业时,容易堵塞集群。

通常情况下,作业会通过input文件产生一个或者多个map数
主要的决定因素有:input文件数,input文件大小。
举例
a)假设input目录下有1个文件a,大小为800M,那么hadoop会将该文件a分隔成7个块(6个128M的块和1个32M的块,Block是128M),从而产生7个map数。

b)假设input目录下有3个文件a,b,c,大小分别为30M,60M,130M,
那么hadoop会分隔成4个块(30M,60M,128M,2M),从而产生4个map数。

拆分是根据大文件来分的,而map数是根据文件数来生成的。

解决方法:
两种方式控制Map数:即减少map数和增加map数
1、减少map数可以通过合并小文件来实现,这点是对文件源。

2、增加map数的可以通过控制上一个job的reduce数来控制(一个sql中join多个表会分解为多个mapreduce)

Map对应参数和默认值:

set hive.merge.mapfiles = true;#在Map-only的任务结束时合并小文件,map阶段Hive自动对小文件合并。

  hive> set hive.merge.mapfiles;
hive.merge.mapfiles=true(默认)

set hive.merge.mapredfiles = true;#默认false, true时在MapReduce的任务结束时合并小文件

set hive.merge.per.task = 256*1000*1000;#合并文件的大小

set mapred.max.split.size = 256000000;#每个Map最大分割大小(hadoop)

set mapred.min.split.size.per.node = l00000000; #一个节点上split的最小值

set hive.input.format =org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;#执行Map前进行小文件合并

在开启了 org.apache.hadoop.hive.ql.io.CombineHiveInputFormat后,一个datanode节点上多个小文件会进行合并,合并文件数大小由 mapred.max.split.size 限制的大小决定。
mapred.min.split.size.per.node 决定了 多个datanode上的文件 是否需要合并。

Hive中设置map数:参数 mapred.map.tasks
set mapred.map.tasks=100; (并不是每次都是有效的,要看大小是否合理)

set的作用域是session级

案例环境如下:

  hive.merge.mapredfiles=true (默认是false,可以在hive-site.xml里配置)
hive.merge.mapfiles=true
hive.merge.per.task=256000000
mapred.map.tasks=2(默认值)

因为合并小文件默认为true,而dfs.block.size与hive.merge.per.task的搭配使得合并后的绝大部分文件都在256MB左右。

Case1:
现在我们假设有3个300MB大小的文件,整个JOB**会有**6个map.其牛3个map分别处理256M的数据,还有3个map分别处理44M的数据。

那么 木桶效应就来了,整个Job的map阶段的执行时间,不是看最短的1个map的执行时间,而是看最长的1个map的执行时间。虽然有3个map分别只处理44MB的数据,可以很快跑完,但它们还是要等待另外3个处理256MB的map。显然,处理256MB的3个map拖了整个JOB的后腿。

Case2:
如果我们把mapred.map.tasks设置成6,再来看一下变化:
goalsize=min(900M/6,256M)=150M
整个JOB同样会分配6个Map来处理,每个map处理150MB,非常均匀,谁都不会拖后腿,最合理地分配了资源,执行时间大约为case1的59%(150/256)。

(二)reduce数
1、Reduce数过大
生成了很多个小文件(最终输出文件由reduce决定,一个reduce一个文件),那么如果这些小文件作为下一个Job输入,则也会出现小文件过多需要进行合并(耗费资源)的问题。
启动和初始化reduce也会消耗大量的时间和资源,有多少个reduce就会有多少个输出文件。

2、Reduce数过小
每个文件很大,执行耗时。
可能出现数据领斜。

reduce个数的决定
默认下,Hive分配reduce数基于以下参数:
参数1: hive.exec.reducers.bytes.per.reducer(默认是1G)
参数2: hive.exec.reducers.max(最大reduce数,默认为999)

计算reduce数的公式:
N=min(参数2,总输入数据量/参数1),
即默认一个reduce处理1G数据量

什么情况下只有一个reduce?
很多时候你会发现任务中不管数据量多大,不管你有没有设置调reduce个数的参数,任务中一直都只有一个reduce任务(会产生数据倾斜)。

原因:
1、数据量小于hive.exec.reducers.bytes.per.reducer参数值(有时,通常情况下设置reduce个数会起作用)
2、没有group by的汇总
3、用了order by

解决:
设置reduce数
参数mapred.reduce.tasks 默认是1
set mapred.reduce.tasks=10
set的作用域是session级

设置reduce数有时对我们优化非常有帮助。
当某个job的结果被后边job**多次引用**时,设置该参数,以便增大访问的map数。Reuduce数决定中间结果或落地文件数,文件大小和Block大小无关。

2.2 解决数据倾斜
(一) 什么是数据领斜?
hadoop框架的特性决定最怕数据倾斜。
由于数据分布不均匀,造成数据大量的集中到一点,造成数据热点。

症状:
map阶段快,reduce阶段非常慢;
某些map很快,某些map很慢;
某些reduce很快,某些reduce奇慢。

如下情况:
A、数据在节点上分布不均匀(无法避免)。
B、join 时 on 关键词中个别值量很大(如null值)
C、count(distinct),数据量大的情况下,容易数据倾斜,
因为count(distinct)是按group by字段分组,按distinct字段排序。(有时无法避免)

(二)数据倾斜的解决方案
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、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、应用场景
(一)空值产生的数据倾斜
场景:
如日志中,常会有信息丢失的问题,比如日志中的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_id
union all
select * 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上,解决数据倾斜问题。

(二)不同数据类型关联产生数据倾斜
场景:用户表中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);

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

作者:scgaliguodong123_ 发表于2015/5/4 11:09:30 原文链接
阅读:4 评论:0 查看评论

相关 [hive 语法 参数] 推荐:

Hive调优(语法与参数层面优化)

- - CSDN博客推荐文章
作为企业Hadoop应用的核心产品,Hive承载着FaceBook、淘宝等大佬 95%以上的离线统计,很多企业里的离线统计甚至全由Hive完成,如我所在的电商. Hive在企业云计算平台发挥的作用和影响愈来愈大,如何优化提速已经显得至关重要. 好的架构胜过任何优化,好的Hql同样会效率大增,修改Hive参数,有时也能起到很好的效果.

hive参数hive.mapred.mode分析

- - CSDN博客云计算推荐文章
Hive配置中有个参数hive.mapred.mode,分为nonstrict,strict,默认是nonstrict. 如果设置为strict,会对三种情况的语句在compile环节做过滤:. 这种情况由于没有指定reduce join key,所以只会启用一个reducer,数据量大时会造成性能瓶颈.

Hive基本语法使用

- - 企业架构 - ITeye博客
1 创建表以及表的关联查询. 3 复杂数据类型的使用 . 一、 创建表以及表的关联查询. 2)创建本地数据文件 student.txt 和ticket.txt,并加载到hive的数据表中.  student.txt文件. ticket.txt文件,加载到数据库中每一行多的数据会被忽略掉,少得数据会变成null.

Hadoop Hive sql语法详解5--HiveQL与SQL区别

- - SQL - 编程语言 - ITeye博客
1.hive内联支持什么格式. 3.hive中empty是否为null. 4.hive是否支持插入现有表或则分区中. 5.hive是否支持INSERT INTO 表 values(). 1、Hive不支持等值连接 . •SQL中对两表内联可以写成:. •分号是SQL语句结束标记,在HiveQL中也是,但是在HiveQL中,对分号的识别没有那么智慧,例如:.

hive调优

- - 互联网 - ITeye博客
一、    控制hive任务中的map数: . 1.    通常情况下,作业会通过input的目录产生一个或者多个map任务. 主要的决定因素有: input的文件总个数,input的文件大小,集群设置的文件块大小(目前为128M, 可在hive中通过set dfs.block.size;命令查看到,该参数不能自定义修改);.

hive 优化 tips

- - CSDN博客推荐文章
一、     Hive join优化. 也可以显示声明进行map join:特别适用于小表join大表的时候,SELECT /*+ MAPJOIN(b) */ a.key, a.value FROM a join b on a.key = b.key. 2.     注意带表分区的join, 如:.

Hive中的join

- - CSDN博客云计算推荐文章
select a.* from a join b on a.id = b.id select a.* from a join b on (a.id = b.id and a.department = b.department). 在使用join写查询的时候有一个原则:应该将条目少的表或者子查询放在join操作符的左边.

hive优化(2)

- - 开源软件 - ITeye博客
Hive是将符合SQL语法的字符串解析生成可以在Hadoop上执行的MapReduce的工具. 使用Hive尽量按照分布式计算的一些特点来设计sql,和传统关系型数据库有区别,. 所以需要去掉原有关系型数据库下开发的一些固有思维. 1:尽量尽早地过滤数据,减少每个阶段的数据量,对于分区表要加分区,同时只选择需要使用到的字段.

hive优化

- - 开源软件 - ITeye博客
hive.optimize.cp=true:列裁剪. hive.optimize.prunner:分区裁剪. hive.limit.optimize.enable=true:优化LIMIT n语句. hive.limit.optimize.limit.file=10:最大文件数.   1.job的输入数据大小必须小于参数:hive.exec.mode.local.auto.inputbytes.max(默认128MB).

Hive优化

- - 互联网 - ITeye博客
     使用Hive有一段时间了,目前发现需要进行优化的较多出现在出现join、distinct的情况下,而且一般都是reduce过程较慢.      Reduce过程比较慢的现象又可以分为两类:. 情形一:map已经达到100%,而reduce阶段一直是99%,属于数据倾斜. 情形二:使用了count(distinct)或者group by的操作,现象是reduce有进度但是进度缓慢,31%-32%-34%...一个附带的提示是使用reduce个数很可能是1.