hive的优化

1. map side join

a. mapJoin的主要意思就是，当连接的两个表是一个比较小的表和一个特别大的表的时候，可以把比较小的table直接放到内存中去，然后再对比较大的表格进行map操作，此时join就发生在map操作的时候，每当扫描一个大的table中的数据，就要去去查看小表的数据，哪条与之相符，继而进行连接。这里的join并不会涉及reduce操作。map端join的优势就是在于没有shuffle，在实际的应用中，设置方式：set hive.auto.convert.join=true;

b. hive有一个参数：hive.mapjoin.smalltable.filesize，默认值是25mb（其中一个表小于25mb时，自动启用mapjoin）

c. 要求：在hive做join时，要求小表在前(左）

2. join语句优化

优化前：select m.cid,u.id form order m join customer u on m.cid=u.id where m.dt=’20160801’;

优化后：select m.cid,u.id from (select cid from order where dt=’20160801’)m join customer u on m.cid = u.id

3. group by 优化

调优参数:set hive.groupby.skewindata=true;

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

由上面可以看出起到至关重要的作用的其实是第二个参数的设置，它使计算变成了两个mapreduce，先在第一个中在 shuffle 过程 partition 时随机给 key 打标记，使每个key 随机均匀分布到各个 reduce 上计算，但是这样只能完成部分计算，因为相同key没有分配到相同reduce上，所以需要第二次的mapreduce,这次就回归正常 shuffle,但是数据分布不均匀的问题在第一次mapreduce已经有了很大的改善，因此基本解决数据倾斜

4. count distinct 优化

优化前：select count(distinct id )from tablename

优化后：select count(*) from (select distinct id from tablename)tmp;

分析：

a. 优化前

i. 由于对id=引入了distinct操作，所以在Map阶段无法利用combine对输出结果去消重，必须将id作为key输出

ii. 在reduce阶段再对来自于不同的MapTask的结果进行消重，计入最终统计值

iii. 由于ReduceTask的数量默认为1，所以导致MapTask的所有结果都只能由这一个ReduceTask处理，这就使得ReduceTask的执行效率成为整个任务的瓶颈

iv. 虽然在使用hive的时候可以通过set mapred.reduce.tasks设置ReduceTask的数量，但是Hive在处理COUNT这种“全聚合(full aggregates)”计算时，它会忽略用户指定的Reduce Task数，而强制使用1

b. 优化后：

i. 利用Hive对嵌套语句的支持，将原来一个MapReduce作业转换为两个作业：在第一阶段选出全部的非重复id，在第二阶段再对这些已消重的id进行计数

ii. 在第一阶段我们可以通过增大Reduce的并发数，并发处理Map输出

iii. 在第二阶段，由于id已经消重，因此COUNT(*)操作在Map阶段不需要输出原id数据，只输出一个合并后的计数即可。这样即使第二阶段Hive强制指定一个Reduce Task，极少量的Map输出数据也不会使单一的Reduce Task成为瓶颈

iv. 这一优化使得在同样的运行环境下，优化后的语句执行只需要原语句20%左右的时间

5. 调整切片数（map任务数）

a. Hive底层自动对小文件做了优化，用了CombineTextInputFormat，将多个小文件切片合成一个切片。如果合成完之后的切片大小>mapred.max.split.size 的大小，就会生成一个新的切片

b. mapred.max.split.size 默认是128MB，设置方式为：set mapred.max.split.size=134217728（128MB)    单位为字节

c. 对于切片数（MapTask）数量的调整，要根据实际业务来定，比如一个100MB的文件包含了有1千万条数据，此时可以调成10个MapTask，则每个MapTask处理1百万条数据。

6. JVM重利用

a. 设置方式：set mapred.job.reuse.jvm.num.tasks=20(默认是1个）

b. JVM重用是hadoop调优参数的内容，对hive的性能具有非常大的影响，特别是对于很难避免小文件的场景或者task特别多的场景，这类场景大多数执行时间都很短。这时JVM的启动过程可能会造成相当大的开销，尤其是执行的job包含有成千上万个task任务的情况

c. JVM重用可以使得一个JVM进程在同一个JOB中重新使用N次后才会销毁。

7. 启用严格模式

a. 用户可以通过 set hive.mapred.mode=strict 来设置严格模式，改成unstrict则为非严格模式

b. 在严格模式下，用户在运行如下query的时候会报错：

i. 分区表的查询没有使用分区字段来限制

ii. 使用了order by 但没有使用limit语句（如果不使用limit，会对查询结果进行全局排序，消耗时间长）

iii. 产生了笛卡尔积

8. 关闭推测执行机制

通常在测试环境下机会确定应用程序是否跑通，如果还加上推测执行，那么在数据分片本来就会发生数据倾斜，执行执行时间就是比其他的时间长，那么hive就会把这个执行时间长的job当作运行失败，继而又产生一个相同的job去运行，造成资源的浪费。可通过如下设置关闭推测执行：

set mapreduce.map.speculative=false

set mapreduce.reduce.speculative=false

set hive.mapred.reduce.tasks.speculative.execution=false