Hive优化

列裁剪

设置参数 hive.optimize.cp=true
在读取数据时，只读取查询中需要用到的列，而忽略其他列，例如：

select a,b from t where e < 5;

其中，对于表t包含的5个列(a,b,c,d,e)，经过列裁剪，列c和d将会被忽略，执行中会只读取a,b,e列。

分区裁剪

设置参数 hive.optimize.pruner=true
在查询中可以减少不必要的分区读取，例如：

select * from (select a , count(1) from t from group by a ) s where s.partition = 100;

经过分区裁剪优化的查询，会在子查询中就考虑 s.partirtion = 100 的条件，从而减少分区的数目。

Join优化

小表一定要放在大表左边。 连续查询中的表大小从左到右是依次增加的
当使用有Join操作的查询语句时，有一条原则：应该将条目少的表/子查询放在Join操作符的左边。原因是在Join操作的Reduce阶段，Join操作符左边表中的内容会被加载到内存中，将条目少的表放在左边可以有效减少发生内存溢出的几率。
标记哪张表是大表：/*streamtable(table_name) */

使用相同的连接键
如果Join的Key相同，那不管有多少个表，都会合并为一个Map Reduce。

Map Join

小表可以完全放到内存中，才可以进行MapJoin
如果一个表足够小，那么可以在最大的表通过map的时候将小表完全放到内存中，Hive可以在map 端执行连接过程(按照key连接)，这是因为hive可以和内存中的小表进行逐一匹配，从而省略掉shuffle常规连接操作所需要的reduce过程。
设置参数 hive.auto.convert.join=true
可以自己设置小表的默认值（单位是字节）
hive.mapjoin.smalltable.filesize=25000000 (25M)

本地模式

设置参数 hive.exec.mode.local.auto=true
对于小数据集，为查询触发执行任务消耗的时间>实际执行job的时间，因此可以通过本地模式，在单台机器上（或某些时候在单个进程上）处理所有的任务。

严格模式

设置属性 hive.mapred.mode=strict
对于分区表，不允许扫描所有分区
对于分区表，除非where语句含有分区字段过滤条件来限制数据范围，否则不允许执行。进行这个限制的原因是，通常分区表都拥有非常大的数据集，而且数据增加迅速。没有进行分区限制的查询可能会消耗令人不可接受的巨大资源来处理这个表。
对于使用OrderBy语句查询，要求必须使用Limit语句
因为OrderBy为了执行排序过程会将所有的结果数据分发到同一个reduce中进行处理，强制要求用户增加Limit语句可以防止reduce额外执行很长一段时间
限制笛卡尔积的查询
两个大表的笛卡尔积会很可怕

并行执行

设置参数 hive.exec.parallel=true
Hive会将一个查询转化成一个或者多个阶段，这样的阶段可以是Map Reduce阶段、抽样阶段、合并阶段、Limit阶段、或者Hive执行过程中可能需要的其他阶段。默认情况下，Hive一次只会执行一个阶段。不过，某个特定的job可能包含众多的阶段，而这些阶段可能并非完全相互依赖的，也就是说有些阶段是可以并行执行的，这样可能使得整个job的执行时间缩短。

限制调整（Limit）

一般情况下，Limit语句还是需要执行整个查询语句，然后再返回部分结果。
Hive有一个配置属性可以开启，当使用Limit语句时，其可以对数据源进行抽样
设置属性 hive.limit.optimize.enable=true
可以自行设置最小的采样容量
hive.limit.row.max.size = 100000
自行设置最大的采样样本数
hive.limit.optimize.limit.file = 10
缺点：有可能输入中有用的数据永远不会被处理到

JVM重用

JVM重用是Hadoop调优参数的内容，其对Hive的性能具有非常的的影响，特别是对于很难避免小文件的场景或task特别多的场景，这类场景大多数执行时间都很短。
设置属性 mapred.job.reuse.jvm.num.tasks =10 (这是数按需求设置，Hadoop的mapred-site.xml）
JVM重用可以使得JVM实例在同一个job中重新使用N次。
缺点：开启JVM重用将会一直占用使用到的task插槽，以便进行重用，直到任务完成后才释放。如果某个“不平衡” 的job中有某几个reduce task执行的时间要比其他reduce task消耗的时间多得多的话，那么保留的插槽就会一直空闲着却无法被其他的job使用，直到所有的task都结束了才会释放。

Group By

默认情况下，Map阶段同一Key数据分发给一个reduce，当一个key数据过大时就倾斜了。
并不是所有的聚合操作都需要在Reduce端完成，很多聚合操作都可以先在Map端进行部分聚合，最后在Reduce端得出最终结果。

Count(Distinct) 去重统计

数据量大的情况下，由于COUNT DISTINCT操作需要用一个Reduce Task来完成，这一个Reduce需要处理的数据量太大，就会导致整个Job很难完成，一般COUNT DISTINCT使用先GROUP BY再COUNT的方式替换
开启Map端聚合参数设置
（1）是否在Map端进行聚合，默认为True
hive.map.aggr = true
（2）在Map端进行聚合操作的条目数目
hive.groupby.mapaggr.checkinterval = 100000
（3）有数据倾斜的时候进行负载均衡（默认是false）
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中），最后完成最终的聚合操作。

调整mapper和reducer的个数

此项最核心的原则就是合理设置，合理并不能确定，只能靠经验和实际的情况来定，以下是设置的大体策略：
Map阶段
map个数的主要的决定因素有： input的文件总个数，input的文件大小，集群设置的文件块大小（默认128M）。
减少Map数：（小文件很多，会产生多个map，通过合并小文件，来减少map数）
在map执行前合并小文件，减少map数：CombineHiveInputFormat具有对小文件进行合并的功能（系统默认的格式）。

set hive.input.format= org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;

增加Map数：（input的文件都很大，任务逻辑复杂）
当input的文件都很大，任务逻辑复杂，map执行非常慢的时候，可以考虑增加Map数，来使得每个map处理的数据量减少，从而提高任务的执行效率。
增加map的方法为：调整maxSize最大值。让maxSize最大值低于blocksize（128M）就可以增加map的个数。

mapreduce.input.fileinputformat.split.maxsize=100;

Reduce阶段
在设置reduce个数的时候也需要考虑这两个原则：处理大数据量利用合适的reduce数；使单个reduce任务处理数据量大小要合适。
1．调整reduce个数方法一（系统默认的方法）
（1）每个Reduce处理的数据量默认是256MB
hive.exec.reducers.bytes.per.reducer=256000000
（2）每个任务最大的reduce数，默认为1009
hive.exec.reducers.max=1009
（3）计算reducer数的公式
N=min(参数2，总输入数据量/参数1)
2．调整reduce个数方法二（自行设置）
在hadoop的mapred-default.xml文件中修改
设置每个job的Reduce个数
set mapreduce.job.reduces = 15;

数据倾斜

表现：任务进度长时间维持在99%（或100%），查看任务监控页面，发现只有少量（1个或几个）reduce子任务未完成。因为其处理的数据量和其他reduce差异过大。
单一reduce的记录数与平均记录数差异过大，通常可能达到3倍甚至更多。 最长时长远大于平均时长。
原因：
1)、key分布不均匀
2)、业务数据本身的特性
3)、建表时考虑不周
4)、某些SQL语句本身就有数据倾斜
解决：
1）合理设置map数
2）小文件进行合并
3）复杂文件增加Map数
4）合理设置Reduce数