Hive优化学习(join ,group by,in)

[color=red][b]一、join优化 [/b][/color]
Join查找操作的基本原则：应该将条目少的表/子查询放在 Join 操作符的左边。原因是在 Join 操作的 Reduce 阶段，位于 Join 操作符左边的表的内容会被加载进内存，将条目少的表放在左边，可以有效减少发生内存溢出错误的几率。
Join查找操作中如果存在多个join，且所有参与join的表中其参与join的key都相同，则会将所有的join合并到一个mapred程序中。
案例：

SELECT a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key1)

在一个mapred程序中执行join ;

SELECT a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key2)

在两个mapred程序中执行join ,Map join的关键在于join操作中的某个表的数据量很小，案例：

SELECT /*+ MAPJOIN(b) */ a.key, a.value FROM a join b on a.key = b.key 

Mapjoin 的限制是无法执行a FULL/RIGHT OUTER JOIN b，和map join相关的hive参数：

hive.join.emit.interval 
hive.mapjoin.size.key  
hive.mapjoin.cache.numrows 

由于join操作是在where操作之前执行，所以当你在执行join时，where条件并不能起到减少join数据的作用；
案例：

 SELECT a.val, b.val FROM a LEFT OUTER JOIN b ON (a.key=b.key) 
WHERE a.ds='2009-07-07' AND b.ds='2009-07-07' 

最好修改为：

SELECT a.val, b.val FROM a LEFT OUTER JOIN b 
ON (a.key=b.key AND b.ds='2009-07-07' AND a.ds='2009-07-07') 

在join操作的每一个mapred程序中，hive都会把出现在join语句中相对靠后的表的数据stream化，相对靠前的变的数据缓存在内存中。当然，也可以手动指定stream化的表：SELECT /*+ STREAMTABLE(a) */ a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key1)

[color=red][b]二、group by 优化 [/b][/color]
Map端聚合，首先在map端进行初步聚合，最后在reduce端得出最终结果，相关参数：

hive.map.aggr = true是否在 Map 端进行聚合，默认为 True 
hive.groupby.mapaggr.checkinterval = 100000在 Map 端进行聚合操作的条目数目 

数据倾斜聚合优化，设置参数hive.groupby.skewindata = true，当选项设定为 true，生成的查询计划会有两个 MR Job。[color=red][b]第一个 MR Job 中，Map 的输出结果集合会随机分布到 Reduce 中，每个 Reduce 做部分聚合操作，并输出结果，这样处理的结果是相同的 Group By Key 有可能被分发到不同的 Reduce 中，从而达到负载均衡的目的；[/b][/color][b][color=blue]第二个 MR Job 再根据预处理的数据结果按照 Group By Key 分布到 Reduce 中（这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce 中），最后完成最终的聚合操作。 [/color][/b]

[color=red][b]三、合并小文件 [/b][/color]
文件数目过多，会给 HDFS 带来压力，并且会影响处理效率，可以通过合并 Map 和 Reduce 的结果文件来消除这样的影响：

hive.merge.mapfiles = true是否和并 Map 输出文件，默认为 True 
hive.merge.mapredfiles = false是否合并 Reduce 输出文件，默认为 False 
hive.merge.size.per.task = 256*1000*1000合并文件的大小 

[color=red][b]四、Hive实现(not) in [/b][/color]
通过left outer join进行查询,（假设B表中包含另外的一个字段 key1

select a.key from a left outer join b on a.key=b.key where b.key1 is null 

通过left semi join 实现 in
SELECT a.key, a.val FROM a LEFT SEMI JOIN b on (a.key = b.key)
[color=blue][b]Left semi join 的限制：join条件中右边的表只能出现在join条件中。 [/b][/color]

[color=red][b]五、排序优化 [/b][/color]
Order by 实现全局排序，一个reduce实现，效率低
Sort by 实现部分有序，单个reduce输出的结果是有序的，效率高，通常和DISTRIBUTE BY关键字一起使用（DISTRIBUTE BY关键字 可以指定map 到 reduce端的分发key）
CLUSTER BY col1 等价于DISTRIBUTE BY col1 SORT BY col1

[color=red][b]六、使用分区 [/b][/color]
Hive中的每个分区都对应hdfs上的一个目录，[b]分区列也不是表中的一个实际的字段，而是一个或者多个伪列，在表的数据文件中实际上并不保存分区列的信息与数据。[/b]Partition关键字中排在前面的为主分区（只有一个），后面的为副分区
静态分区：静态分区在加载数据和使用时都需要在sql语句中指定
案例：(stat_date='20120625',province='hunan')
动态分区：使用动态分区需要设置hive.exec.dynamic.partition参数值为true，默认值为false，在默认情况下，hive会假设主分区时静态分区，副分区使用动态分区；如果想都使用动态分区，需要设置set hive.exec.dynamic.partition.mode=nostrick，默认为strick
案例：(stat_date='20120625',province)

[color=red][b]七、Distinct 使用[/b][/color]
Hive支持在group by时对同一列进行多次distinct操作，却不支持在同一个语句中对多个列进行distinct操作。

[color=red][b]八、Hql使用自定义的mapred脚本 [/b][/color]
注意事项：在使用自定义的mapred脚本时，关键字MAP REDUCE 是语句SELECT TRANSFORM ( ... )的语法转换，并不意味着使用MAP关键字时会强制产生一个新的map过程，使用REDUCE关键字时会产生一个red过程。
自定义的mapred脚本可以是hql语句完成更为复杂的功能，但是性能比hql语句差了一些，应该尽量避免使用，如有可能，使用UDTF函数来替换自定义的mapred脚本

[color=red][b]九、UDTF [/b][/color]
UDTF将单一输入行转化为多个输出行，并且在使用UDTF时，select语句中不能包含其他的列，UDTF不支持嵌套，也不支持group by 、sort by等语句。如果想避免上述限制，需要使用lateral view语法，案例：

select a.timestamp, get_json_object(a.appevents, '$.eventid'), get_json_object(a.appenvets, '$.eventname') from log a; 
select a.timestamp, b.* 
from log a lateral view json_tuple(a.appevent, 'eventid', 'eventname') b as f1, f2; 

其中，get_json_object为UDF函数，json_tuple为UDTF函数。
UDTF函数在某些应用场景下可以大大提高hql语句的性能，如需要多次解析json或者xml数据的应用场景。
[color=red][b]十、聚合函数count和sum [/b][/color]
Count和sum函数可能是在hql语句中使用的最为频繁的两个聚合函数了，但是在hive中count函数在计算distinct value时支持加入条件过滤。

hive.optimize.cp=true：列裁剪
hive.optimize.prunner：分区裁剪
hive.limit.optimize.enable=true：优化LIMIT n语句
hive.limit.row.max.size=1000000：
hive.limit.optimize.limit.file=10：最大文件数

[color=red][b]1. 本地模式(小任务)：[/b][/color]
需要满足以下条件：
1.job的输入数据大小必须小于参数：hive.exec.mode.local.auto.inputbytes.max(默认128MB)
2.job的map数必须小于参数：hive.exec.mode.local.auto.tasks.max(默认4)
3.job的reduce数必须为0或者1
-----------------------------------Hive配置优化----------------------------------
hive.exec.mode.local.auto.inputbytes.max=134217728
hive.exec.mode.local.auto.tasks.max=4
hive.exec.mode.local.auto=true
hive.mapred.local.mem：本地模式启动的JVM内存大小

[color=red][b]2. 并发执行：[/b][/color]
hive.exec.parallel=true ，默认为false
hive.exec.parallel.thread.number=8

[color=red][b]3.Strict Mode：[/b][/color]
hive.mapred.mode=true，严格模式不允许执行以下查询：
分区表上没有指定了分区
没有limit限制的order by语句
笛卡尔积：JOIN时没有ON语句

[color=red][b]4.动态分区：[/b][/color]
hive.exec.dynamic.partition.mode=strict：该模式下必须指定一个静态分区
hive.exec.max.dynamic.partitions=1000
hive.exec.max.dynamic.partitions.pernode=100：在每一个mapper/reducer节点允许创建的最大分区数
DATANODE：dfs.datanode.max.xceivers=8192：允许DATANODE打开多少个文件

[color=red][b]5.推测执行：[/b][/color]
mapred.map.tasks.speculative.execution=true
mapred.reduce.tasks.speculative.execution=true
hive.mapred.reduce.tasks.speculative.execution=true;

6.Single MapReduce MultiGROUP BY
hive.multigroupby.singlemar=true：当多个GROUP BY语句有相同的分组列，则会优化为一个MR任务

7. hive.exec.rowoffset：是否提供虚拟列

[color=red][b]8. 分组[/b][/color]
两个聚集函数不能有不同的DISTINCT列，以下表达式是错误的：
INSERT OVERWRITE TABLE pv_gender_agg SELECT pv_users.gender, count(DISTINCT pv_users.userid), count(DISTINCT pv_users.ip) FROM pv_users GROUP BY pv_users.gender;
SELECT语句中只能有GROUP BY的列或者聚集函数。

9.
hive.map.aggr=true;在map中会做部分聚集操作，效率更高但需要更多的内存。
hive.groupby.mapaggr.checkinterval：在Map端进行聚合操作的条目数目

10.
hive.groupby.skewindata=true：数据倾斜时负载均衡，当选项设定为true，生成的查询计划会有两个MRJob。第一个MRJob 中，
Map的输出结果集合会随机分布到Reduce中，每个Reduce做部分聚合操作，并输出结果，这样处理的结果是相同的GroupBy Key
有可能被分发到不同的Reduce中，从而达到负载均衡的目的；第二个MRJob再根据预处理的数据结果按照GroupBy Key分布到
Reduce中（这个过程可以保证相同的GroupBy Key被分布到同一个Reduce中），最后完成最终的聚合操作。

[color=red][b]11.Multi-Group-By Inserts：[/b][/color]
FROM test
INSERT OVERWRITE TABLE count1
SELECT count(DISTINCT test.dqcode)
GROUP BY test.zipcode
INSERT OVERWRITE TABLE count2
SELECT count(DISTINCT test.dqcode)
GROUP BY test.sfcode;

[color=red][b]12.排序[/b][/color]
ORDER BY colName ASC/DESC
hive.mapred.mode=strict时需要跟limit子句
hive.mapred.mode=nonstrict时使用单个reduce完成排序
SORT BY colName ASC/DESC ：每个reduce内排序
DISTRIBUTE BY(子查询情况下使用 )：控制特定行应该到哪个reducer，并不保证reduce内数据的顺序
CLUSTER BY ：当SORT BY 、DISTRIBUTE BY使用相同的列时。

[color=red][b]13.合并小文件[/b][/color]
hive.merg.mapfiles=true：合并map输出
hive.merge.mapredfiles=false：合并reduce输出
hive.merge.size.per.task=256*1000*1000：合并文件的大小
hive.mergejob.maponly=true：如果支持CombineHiveInputFormat则生成只有Map的任务执行merge
hive.merge.smallfiles.avgsize=16000000：文件的平均大小小于该值时，会启动一个MR任务执行merge。

[color=red][b]14.map/reduce数目[/b][/color]
减少map数目：
　　

set mapred.max.split.size
　　set mapred.min.split.size
　　set mapred.min.split.size.per.node
　　set mapred.min.split.size.per.rack
　　set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat

增加map数目：
当input的文件都很大，任务逻辑复杂，map执行非常慢的时候，可以考虑增加Map数，来使得每个map处理的数据量减少，从而提高任务的执行效率。
假设有这样一个任务：
　　select data_desc, count(1), count(distinct id),sum(case when …),sum(case when ...),sum(…) from a group by data_desc
如果表a只有一个文件，大小为120M，但包含几千万的记录，如果用1个map去完成这个任务，肯定是比较耗时的，这种情况下，我们要考虑将这一个文件合理的拆分成多个，这样就可以用多个map任务去完成。
　　set mapred.reduce.tasks=10;
　　create table a_1 as select * from a distribute by rand(123);
这样会将a表的记录，随机的分散到包含10个文件的a_1表中，再用a_1代替上面sql中的a表，则会用10个map任务去完成。每个map任务处理大于12M（几百万记录）的数据，效率肯定会好很多。

[color=red][b]reduce数目设置：[/b][/color]
　参数1：hive.exec.reducers.bytes.per.reducer=1G：每个reduce任务处理的数据量
　参数2：hive.exec.reducers.max=999(0.95*TaskTracker数)：每个任务最大的reduce数目
　reducer数=min(参数2,总输入数据量/参数1)
　set mapred.reduce.tasks：每个任务默认的reduce数目。典型为0.99*reduce槽数，hive将其设置为-1，自动确定reduce数目。



[color=red][b]15.使用索引：[/b][/color]
hive.optimize.index.filter：自动使用索引
hive.optimize.index.groupby：使用聚合索引优化GROUP BY操作

转自：[url]http://qingyuan-jishu.iteye.com/blog/2071114[/url]