Hive作业优化总结

标签: hive 作业 优化 | 发表时间:2015-05-23 18:52 | 作者:lixuguang
出处:http://www.iteye.com

目录

Hive作业优化总结... 1

一、Hadoop 计算框架的特性... 1

二、优化常用的手段... 2

三、优化案例... 2

1、Join原则... 2

2、笛卡尔积... 2

3、控制Map数... 3

4、设置合理reducer个数... 3

5、合并MapReduce操作... 4

6 、LEFT SEMI  JOIN.. 4

7、Hive注意事项... 4

 

 

 

 

一、Hadoop 计算框架的特性

1、什么是数据倾斜?

•由于数据分布不均匀,造成数据大量的集中到一点,造成数据热点。

 

2、Hadoop框架的特性

•不怕数据大,怕数据倾斜。

•jobs数比较多的作业运行效率相对比较低,如子查询比较多。

•sum,count,max,min等聚集函数,不会有数据倾斜问题

3、容易数据倾斜情况

·group by

·count(distinct ),在数据量大的情况下,容易数据倾斜,因为count(distinct)是按group by 字段分组,按distinct字段排序。

·小表关联超大表

 

•    数据倾斜的时候进行负载均衡

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 中),最后完成最终的聚合操作。

 

二、优化常用的手段

•解决数据倾斜问题

•减少job数(合并MapReduce,用Multi-group by)

•设置合理的map reduce的task数,能有效提升性能。

•数据量较大的情况下,慎用count(distinct)。

•对小文件进行合并,针对文件数据源。

 

三、优化案例

1、Join原则

将条目少的表/子查询放在 Join的左边。 原因是在 Join 操作的 Reduce 阶段,位于 Join左边的表的内容会被加载进内存,将条目少的表放在左边,可以有效减少发生内存溢出的几率。

 

当一个小表关联一个超大表时,容易发生数据倾斜,可以用MapJoin把小表全部加载到内存在map端进行join,避免reducer处理。

         如:SELECT /*+ MAPJOIN(user) */  l.session_id, u.username from user u join page_views l on (u. id=l.user_id) ;

 

2、笛卡尔积

         当Hive设定为严格模式(hive.mapred.mode=strict)时,不允许在HQL语句中出现笛卡尔积。

         当无法躲避笛卡尔积时,采用MapJoin,会在Map端完成Join操作,将Join操作的一个或多个表完全读入内存。

MapJoin的用法是在查询/子查询的SELECT关键字后面添加/*+ MAPJOIN(tablelist) */提示优化器转化为MapJoin 。

其中tablelist可以是一个表,或以逗号连接的表的列表。tablelist中的表将会读入内存,应该将小表写在这里

3、控制Map数

同时可执行的map数是有限的。

•通常情况下,作业会通过input的目录产生一个或者多个map任务

•主要的决定因素有: input的文件总个数,input的文件大小。

 

•举例

    a) 假设input目录下有1个文件a,大小为780M,那么hadoop会将该文件a分隔成7个块(block为128M,6个128m的块和1个12m的块),从而产生7个map数

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

 

 

两种方式控制Map 数:即减少map 数和增加map

减少map数可以通过合并小文件来实现,这点是对文件数据源来讲。

增加map数的可以通过控制上一个job的reduer数来控制,见5.

 

4、设置合理reducer个数

•reducer个数的设定极大影响执行效率

•不指定reducer个数的情况下,Hive分配reducer个数基于以下:

    参数1:hive.exec.reducers.bytes.per.reducer(默认为1G)

    参数2 :hive.exec.reducers.max(默认为999)

•计算reducer数的公式

•N=min(参数2,总输入数据量/参数1)

set mapred.reduce.tasks=13;

 

•reduce个数并不是越多越好

同map一样,启动和初始化reduce也会消耗时间和资源;有多少个reduce,就会有多少个输出文件。

 

Reducer数过多:

生成了很多个小文件,那么如果这些小文件作为下一个任务的输入,则也会出现小文件过多的问题。

 

Reducer过少:

         影响执行效率。

 

•什么情况下只有一个reduce

    很多时候你会发现任务中不管数据量多大,不管你有没有设置调整reduce个数的参数,任务中一直都只有一个reduce任务;

1、  除了数据量小于hive.exec.reducers.bytes.per.reducer参数值的情况外

2、没有group by的汇总

3、用了Order by。

 

 

5、 合并 MapReduce 操作

• Multi-group by:当从同一个源表进行多次查询时用。

 

•Multi-group by是Hive的一个非常好的特性,它使得Hive中利用中间结果变得非常方便

•FROM log

•  insert overwrite table test1 select log.id group by log.id

•  insert overwrite table test2 select log.name group by log.name

• 上述查询语句使用了Multi-group by特性连续group by了2次数据,使用不同的group by key。这一特性可以减少一次MapReduce操作。

 

 

 

6 、LEFT SEMI  JOIN

是 IN/EXISTS 子查询的一种更高效的实现。

Hive 当前没有实现 IN/EXISTS 子查询,所以你可以用 LEFT SEMI JOIN 重写你的子查询语句。LEFT SEMI JOIN 的限制是, JOIN 子句中右边的表只能在 ON 子句中设置过滤条件,在 WHERE 子句、SELECT 子句或其他地方过滤都不行。

  SELECT a.key, a.value

  FROM a

  WHERE a.key in

   (SELECT b.key

    FROM B);

可以被重写为:

   SELECT a.key, a.val

   FROM a LEFT SEMI JOIN b on (a.key = b.key)

 

7、Hive注意事项

只支持INSERT/LOAD操作,无UPDATE和DELTE

0.10之前版本没有索引

不支持HAVING操作。

不支持where子句中的子查询

Join只支持等值关联

Not用法

关系数据库:

… where username not like(in) ..

 

Hive

… where not username like(in)..

 

Hive中string类型没有长度限制



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [hive 作业 优化] 推荐:

Hive作业优化总结

- - 开源软件 - ITeye博客
一、Hadoop 计算框架的特性. 4、设置合理reducer个数. 5、合并MapReduce操作. 一、Hadoop 计算框架的特性. •由于数据分布不均匀,造成数据大量的集中到一点,造成数据热点. 2、Hadoop框架的特性. •不怕数据大,怕数据倾斜. •jobs数比较多的作业运行效率相对比较低,如子查询比较多.

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优化(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.

hive优化

- - 互联网 - ITeye博客
1:尽量尽早地过滤数据,减少每个阶段的数据量,对于分区表要加分区,同时只选择需要使用到的字段. 2:尽量原子化操作,尽量避免一个SQL包含复杂逻辑. 可以使用中间表来完成复杂的逻辑. 3:单个SQL所起的JOB个数尽量控制在5个以下. 4:慎重使用mapjoin,一般行数小于2000行,大小小于1M(扩容后可以适当放大)的表才能使用,小表要注意放在join的左边(目前TCL里面很多都小表放在join的右边).

Hive优化总结

- - 淘剑笑的博客
优化时,把hive sql 当做map reduce 程序来读,会有意想不到的惊喜. 理解hadoop 的核心能力,是hive 优化的根本. 这是这一年来,项目组所有成员宝贵的经验总结. 长期观察hadoop处理数据的过程,有几个显著的特征 :. 1.不怕数据多,就怕数据倾斜. 2.对jobs数比较多的作业运行效率相对比较低,比如即使有几百行的表,如果多次关联多次汇总,产生十几个jobs,没半小时是跑不完的.

HIVE 优化浅谈

- - IT瘾-dev
作者:邓力,entobit技术总监,八年大数据从业经历,由一代HADOOP入坑,深耕云计算应用领域,由从事亚马逊EMR和阿里云EMR应用开发逐步转入大数据架构领域,对大数据生态及框架应用有深刻理解. 随着商务/运营同学执行的HQL越来越多,整体HIVE执行效率变低,本文从HIVE切入,分析HQL面临的问题和待优化部分,结合其他大数据框架来解决实际问题.

Hive Join 优化 翻译

- - 数据库 - ITeye博客
翻译自  https://cwiki.apache.org/confluence/display/Hive/LanguageManual+JoinOptimization#LanguageManualJoinOptimization-AutoConversiontoSMBMapJoin. Join Optimization ----Join 调优.

hive优化要点总结

- - CSDN博客云计算推荐文章
1、让服务器尽可能的多做事情,榨干服务器资源,以最高系统吞吐量为目标. 再好的硬件没有充分利用起来,都是白扯淡. (1)  启动一次job尽可能的多做事情,一个job能完成的事情,不要两个job来做.  通常来说前面的任务启动可以稍带一起做的事情就一起做了,以便后续的多个任务重用,与此紧密相连的是模型设计,好的模型特别重要..