Hive 优化汇总

参考：

http://www.cnblogs.com/yshb/p/3147710.html

http://www.cnblogs.com/sandbank/p/6408762.html

一 join时注意点：

1. 小表放前面

Hive假定查询中最后的一个表是大表。它会将其它表缓存起来，然后扫描最后那个表。

2. 使用相同的连接键

当对3个或者更多个表进行join连接时，如果每个on子句都使用相同的连接键的话，那么只会产生一个MapReduce job。

3. 尽量尽早地过滤数据

减少每个阶段的数据量,对于分区表要加分区，同时只选择需要使用到的字段。

4. 尽量原子化操作

尽量避免一个SQL包含复杂逻辑，可以使用中间表来完成复杂的逻辑

二. map join

1. Map Join 的使用场景：

关联操作中有一张表非常小
不等值的链接操作

2. 语法：

使用 hint 的方式指定join时使用mapjoin。

select   /*+ mapjoin(c)*/    -- hint

   c.tag,b.yemaozi_pre

from

(select

    row_number() over(partition by 1 order by yemaozi_pre)  yemaozi_rank,

    yemaozi_pre

 from  customer_purchase_time_pre

) b       -- 大表

join

(select

    count(buyer_nick) total_buyer,'yemaozi' as tag

 from customer_purchase_time_pre

) c        -- 小表，只有一行

where b.yemaozi_rank=round(c.total_buyer*0.9);

用时才发现了个细节：

/*+mapjoin( c ) */ 这个语法里面的c 是join的小表的名字！

3. 原理：

　MAPJION会把小表全部读入内存中，在map阶段直接拿另外一个表的数据和内存中表数据做匹配，由于在map是进行了join操作，省去了reduce，运行的效率也会高很多。　

4. 分析：

例子中的小表参与join，没使用map join时，会导致数据倾斜严重。某个reduce上落太多数据，reduce时内存会严重占用，甚至不足。
不等连接时，reduce会进行笛卡儿积，效率很低。
使用map join后 join操作会在map阶段完成。

如果join数据两大，加上如下参数避免内存溢出：

set mapreduce.reduce.shuffle.input.buffer.percent =0.6;

set mapreduce.reduce.shuffle.parallelcopies = 5;

三 union all 注意点

如果union all的部分个数大于2，或者每个union部分数据量大，应该拆成多个insert into 语句

四常用的参数设置

-- 并发执行

hive.exec.parallel=true; -- 默认为false
hive.exec.parallel.thread.number=8;

-- 防止数据倾斜

hive.map.aggr=true; -- 在map中会做部分聚集操作, 效率更高但需要更多的内存。

-- Strict Mode：
hive.mapred.mode=true;

-- 动态分区开关

set hive.exec.dynamic.partition.mode=nonstrict;

-- 负载均衡

hive.groupby.skewindata=true：

数据倾斜时负载均衡，当选项设定为true，生成的查询计划会有两个MRJob。

第一个MRJob 中，Map的输出结果集合会随机分布到Reduce中，每个Reduce做部分聚合操作，并输出结果，这样处理的结果是相同的GroupBy Key，有可能被分发到不同的Reduce中，从而达到负载均衡的目的；

第二个MRJob再根据预处理的数据结果按照GroupBy Key分布到Reduce中（这个过程可以保证相同的GroupBy Key被分布到同一个Reduce中），最后完成最终的聚合操作。

-- 合并小文件

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。

-- 使用索引：

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

五查询注意

1. order by & sort by

order by : 对查询结果进行全局排序，消耗时间长。需要 set hive.mapred.mode=nostrict

sort by : 局部排序，并非全局有序，提高效率。

2. limit 快速抽样结果

一般情况下，Limit语句还是需要执行整个查询语句，然后再返回部分结果。

有一个配置属性可以开启，避免这种情况---对数据源进行抽样

hive.limit.optimize.enable=true --- 开启对数据源进行采样的功能

hive.limit.row.max.size --- 设置最小的采样容量

hive.limit.optimize.limit.file --- 设置最大的采样样本数

缺点：有可能部分数据永远不会被处理到

3. 设置严格的查询限制： set hive.marped.mode=strict

防止用户执行那些可能意想不到的不好的影响的查询

-- 1）分区表，必须选定分区范围

-- 2）对于使用order by的查询，要求必须使用limit语句。因为order by为了执行排序过程会将所有的结果数据分发到同一个reducer中进行处理。

-- 3）限制笛卡尔积查询：两张表join时必须有on语句

4. 如果没有聚合的简单查询，可以用fetch task 而不需要起 MR任

set hive.fetch.task.conversion=minimal -- 默认情况下是minimal

两种模式，minimal和more。

在minimal下，我们执行select * ，limit，filter在一个表所属的分区表上操作，这三种情况都会直接进行数据的拿去，也就是直接把数据从对应的表格拿出来，不用跑mr代码，这样会快点儿运行程序。

在more模式下，运行select，filter，limit，都是运行数据的fetch，不跑mr应用，所以感觉more模式会更好点儿。

六数据倾斜

表现：

任务进度长时间维持在99%（或100%），查看任务监控页面，发现只有少量（1个或几个）reduce子任务未完成。因为其处理的数据量和其他reduce差异过大。

单一reduce的记录数与平均记录数差异过大，通常可能达到3倍甚至更多。最长时长远大于平均时长。

原因：

1)、key分布不均匀

2)、业务数据本身的特性

3)、建表时考虑不周

4)、某些SQL语句本身就有数据倾斜

关键词	情形	后果
join	其中一个表较小，但是key集中	分发到某一个或几个Reduce上的数据远高于平均值
join	大表与大表，但是分桶的判断字段0值或空值过多	这些空值都由一个reduce处理，灰常慢
group by	group by 维度过小，某值的数量过多	处理某值的reduce灰常耗时
count distinct	某特殊值过多	处理此特殊值reduce耗时

解决方案：

hive.map.aggr=true； -- 在map中会做部分聚集操作, 效率更高但需要更多的内存。