一、hive参数优化
hive通过将查询划分成一个或多个MapReduce任务达到并行处理的目的。每个任务都可能具有多个mapper和reducer任务，其中至少有一些是可以并行执行的。确定最佳的mapper个数和reducer个数取决于多个变量，例如输入的数据量大小以及对这些数据执行的操作类型等。保持平衡性是很有必要的，对于Spark/Hadoop这样的大数据系统来讲，数据量大并不可怕,可怕的是数据倾斜，每个节点处理的运算不均衡。如果有太多的mapper或reducer任务，就会导致启动阶段、调度和运行job过程中产生过多的开销；而如果设置的数量太少，那就有可能没充分利用好集群内在并行性。
千万不要以为一条hive sql语句只会产生一个application哦！！！
不多bb，上硬货：
1、Hive.fetch.task.conversion 默认为minimal，修改为more
fetch task 为执行hive时，不用执行MapReduce，如select * from emp； 修改当前会话： set hive.fetch.task.conversion=more; 执行SELECT id, money FROM m limit 10; 不走mr |
2、并行执行
当一个sql中有多个job时候，且这多个job之间没有依赖，则可以让顺序执行变为并行执行（一般为用到union all ）
|
3、jvm 重用
JVM重用对hive的性能具有非常大的 影响，特别是对于很难避免小文件的场景或者task特别多的场景，这类场景大多数执行时间都很短。jvm的启动过程可能会造成相当大的开销，尤其是执行的job包含有成千上万个task任务的情况。
set mapred.job.reuse.jvm.num.tasks=10; |
JVM的一个缺点是，开启JVM重用将会一直占用使用到的task插槽，以便进行重用，直到任务完成后才能释放。如果某个“不平衡“的job中有几个 reduce task 执行的时间要比其他reduce task消耗的时间多得多的话，那么保留的插槽就会一直空闲着却无法被其他的job使用，直到所有的task都结束了才会释放。
4、设置reduce的数目
reduce个数的设定极大影响任务执行效率，不指定reduce个数的情况下，Hive会猜测确定一个reduce个数，基于以下两个设定： hive.exec.reducers.bytes.per.reducer（每个reduce任务处理的数据量，在Hive 0.14.0版本之前默认值是1G(1,000,000,000)；而从Hive 0.14.0开始，默认值变成了256M(256,000,000) ） hive.exec.reducers.max（每个任务最大的reduce数，在Hive 0.14.0版本之前默认值是999；而从Hive 0.14.0开始，默认值变成了1009 ） 计算reducer数的公式很简单N=min(参数2，总输入数据量/参数1) 即，如果reduce的输入（map的输出）总大小不超过1G,那么只会有一个reduce任务；
调整reduce个数方法一： 调整hive.exec.reducers.bytes.per.reducer参数的值；
set hive.exec.reducers.bytes.per.reducer=500000000; （500M） |
调整reduce个数方法二；
set mapred.reduce.tasks = number |
reduce个数并不是越多越好； 同map一样，启动和初始化reduce也会消耗时间和资源； 另外，有多少个reduce,就会有多少个输出文件，如果生成了很多个小文件，那么如果这些小文件作为下一个任务的输入，则也会出现小文件过多的问题
5、推测执行
什么是推测执行？
所谓的推测执行，就是当所有task都开始运行之后，Job Tracker会统计所有任务的平均进度，如果某个task所在的task node机器配置比较低或者CPU load很高（原因很多），导致任务执行比总体任务的平均执行要慢，此时Job Tracker会启动一个新的任务（duplicate task），原有任务和新任务哪个先执行完就把另外一个kill掉
怎么配置推测执行参数？
推测执行需要设置Job的两个参数：
mapred.map.tasks.speculative.execution mapred.reduce.tasks.speculative.execution |
两个参数的默认值均为true.
6、数据倾斜
表现：任务进度长时间维持在99%（或100%），查看任务监控页面，发现只有少量（1个或几个）reduce子任务未完成。因为其处理的数据量和其他reduce差异过大。
原因：某个reduce的数据输入量远远大于其他reduce数据的输入量
1)、key分布不均匀
2)、业务数据本身的特性
3)、建表时考虑不周
4)、某些SQL语句本身就有数据倾斜
解决方案：
(1)参数调节
set hive.map.aggr=true set hive.groupby.skewindata=true |
(2) 熟悉数据的分布，优化sql的逻辑，找出数据倾斜的原因。
7、合并小文件
小文件的产生有三个地方，map输入，map输出，reduce输出。
小文件过多也会影响hive的分析效率：设置map输入的小文件合并
set mapred.max.split.size=256000000; //一个节点上split的至少的大小(这个值决定了多个DataNode上的文件是否需要合并) set mapred.min.split.size.per.node=100000000; //一个交换机下split的至少的大小(这个值决定了多个交换机上的文件是否需要合并) set mapred.min.split.size.per.rack=100000000; //执行Map前进行小文件合并 set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat; |
设置map输出和reduce输出进行合并的相关参数：
//设置map端输出进行合并，默认为true set hive.merge.mapfiles = true //设置reduce端输出进行合并，默认为false set hive.merge.mapredfiles = true //设置合并文件的大小 set hive.merge.size.per.task = 256*1000*1000 //当输出文件的平均大小小于该值时，启动一个独立的MapReduce任务进行文件merge。 set hive.merge.smallfiles.avgsize=16000000 |
8、查看sql的执行计划
explain sql |
学会查看sql的执行计划，优化业务逻辑 ，减少job的数据量。
9、在脚本中并行
在实际的开发中，我们写好的sql是放到脚本中去跑 hive -f xxx.sql 文件，然后在cron里面设置个定时任务跑，所以可以在脚本中用到并行的跑sql文件，其实是放到后台跑sql文件，sql文件之间是不相关的，且不能用union all 连接起来的sql（如果可以写成一个sql的话设置一下并行执行就可以了）。如：
#！/bin/bash hive -f aa.sql & hive -f bb.sql & #(aa和bb里面的sql同时执行) wait #（等待aa 和 bb 执行完后在 执行 xxx.sql文件） hive -f xxx.sql |
附录优化点及详细参数配置情况
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 ，默认为false
hive.exec.parallel.thread.number=8
3、Strict Mode：hive.mapred.mode=true，严格模式不允许执行以下查询：
分区表上没有指定了分区
没有limit限制的order by语句
笛卡尔积：JOIN时没有ON语句
4.动态分区：
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打开多少个文件
5.推测执行：
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：是否提供虚拟列
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中会做部分聚集操作，效率更高但需要更多的内存。
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.使用索引：
hive.optimize.index.filter：自动使用索引
hive.optimize.index.groupby：使用聚合索引优化GROUP BY操作
12.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.95TaskTracker数)：每个任务最大的reduce数目
reducer数=min(参数2,总输入数据量/参数1)
set mapred.reduce.tasks：每个任务默认的reduce数目。典型为0.99reduce槽数，hive将其设置为-1，自动确定reduce数目。
