hive优化

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：最大文件数

 

1. 本地模式(小任务)：
需要满足以下条件：
　　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.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内存大小

 

2. 并发执行：
hive.exec.parallel=true ，hive.exec.parallel参数控制在同一个sql中的不同的job是否可以同时运行,默认为false.同一个sql中的几个子查询对应的mapreduce job是可以并行执行的，这种情况下如果系统资源充足设置此参数为true可以加快执行速度。
hive.exec.parallel.thread.number=8，控制对于同一个sql来说同时可以运行的job的最大值,该参数默认为8.此时最大可以同时运行8个job.

 

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

 

4.动态分区：
hive.exec.dynamic.partition.mode=strict：该模式下必须指定一个静态分区，strict是避免全分区字段是动态的，必须有至少一个分区字段是指定有值的
hive.exec.max.dynamic.partitions=1000，一个DML操作可以创建的最大动态分区数
hive.exec.max.dynamic.partitions.pernode=100：在每一个mapper/reducer节点允许创建的最大分区数，还有人解释说是：each mapper or reducer可以创建的最大动态分区数。
DATANODE：dfs.datanode.max.xceivers=8192：允许DATANODE打开多少个文件

 

5.推测执行：
mapred.map.tasks.speculative.execution=true
mapred.reduce.tasks.speculative.execution=true
hive.mapred.reduce.tasks.speculative.execution=true;

所谓的推测执行，就是当所有task都开始运行之后，Job Tracker会统计所有任务的平均进度，如果某个task所在的task node机器配置比较低或者CPU load很高（原因很多），导致任务执行比总体任务的平均执行要慢，此时Job Tracker会启动一个新的任务（duplicate task），然后原有任务和新任务哪个先执行完就把另外一个kill掉，这也是我们经常在Job Tracker页面看到任务执行成功，但是总有些任务被kill，就是这个原因。

 

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

 

7. hive.exec.rowoffset：是否提供行偏移量的虚拟列，默认是false不提供，Hive有两个虚拟列:一个是INPUT__FILE__NAME,表示输入文件的路径，另外一个是BLOCK__OFFSET__INSIDE__FILE，表示记录在文件中的块偏移量，这对排查出现不符合预期或者null结果的查询是很有帮助的

 

8. 分组
两个聚集函数不能有不同的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中会做部分聚集操作，效率更高但需要更多的内存，0.13版本中默认是true。
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中），最后完成最终的聚合操作。

 

11.Multi-Group-By Inserts：
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;

好像这个就没有用，必须是group by对应的key是完全一样的才只会产生一个mr，否则就是多个单独的mr。hive default-site.xml中对于参数hive.multigroupby.singlemr的解释是Whether to optimize multi group by query to generate single M/R job plan. If the multi group by query has common group by keys, it will be optimized to generate single M/R job.

 

12.排序
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使用相同的列时。

 

13.合并小文件
hive.merg.mapfiles=true：合并map输出，用来控制是否merge MAP-ONLY型Job的文件输出
hive.merge.mapredfiles=false：合并reduce输出，用来控制merge MAP-REDUCE型Job的文件输出
hive.merge.size.per.task=256*1000*1000：合并文件的大小
hive.mergejob.maponly=true：如果支持CombineHiveInputFormat则生成只有Map的任务执行merge。这个参数是用来控制是以MAP-ONLY的形式来进行merge（这里有个前提条件就是需要Hadoop支持CombineInputFormat，0.20之前的即使设置了这个参数true也不会生效）或者以MAP-REDUCE的形式来进行merge.
hive.merge.smallfiles.avgsize=16000000：文件的平均大小小于该值时，会启动一个MR任务执行merge。

 

14.map/reduce数目
减少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（几百万记录）的数据，效率肯定会好很多。

reduce数目设置：
　参数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数目。

 

15.使用索引：
hive.optimize.index.filter：自动使用索引
hive.optimize.index.groupby：使用聚合索引优化GROUP BY操作