HIve优化（包含数据倾斜）--单独从基础篇拿出来

6.Hive的优化（重要）：
6.1Map优化：
1.如何合并小文件，减少map数
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat = true
set mapred.max.split.size = 10000000
set mapred.min.split.size.per.node = 1000000
set mapred.min.split.size.per.rack=100000000
2.如何适当的增加map数
set mapred.map.tasks = 10
3.Map端聚合
hive.map.aggr = true
6.2Reduce优化
调整reduce的个数：
1.设置reduce处理的数据量
hive.exec.reducers.bytes.per.reducer
2.set mapred.reduce.tasks = 10
只有一个reduce的情况
没有group by order by
笛卡尔积
6.3分区查询（partition）
where中的分区条件，会提前生效，不必特意做子查询，直接join和groupby
6.4笛卡尔积
join的时候不加on条件或者无效的on条件，hive只能使用一个reduce完成笛卡尔积
6.5Map join
-/ +MAPJOIN（tablelist）/，必须是小表，不要超过1G，或者50W条记录
6.6Union all /distinct
先做union all 再做join或者groupby 等操作可以有效的减少MR过程，尽管是多个select，最终只有一个MR
6.7Multi-insert & multi-group by
从一份基础表中按照不同的维度，一次组合出不同的数据
比如
from student
insert overwrite table tablename select XX group by K1
insert overwrite table tablename select YY group by K2
6.8Automatic merge
当文件大小比阈值小的时候，hive会启动一个MR进行合并
6.9Multi-Count Distinct
必须设置参数 set hive.groupby.skewindata= true
select id,count(distinct id),count(ip) from table
7.hive 的join优化
7.1— 表 连 接 顺 序
按照JOIN顺序中的最后一个表应该尽量是大表，因为JOIN前一阶段生成的数据会存在于 Reducer的buffer中，通过stream最后面的表，直接从Reducer的buffer中读取已经缓冲的中间 结果数据（这个中间结果数据可能是JOIN顺序中，前面表连接的结果的可以，数据量相对较小，内存开销较小），这样与后面的大表进行连接时，只需要从buffer中读取缓存的key，与大表中指定的key进行连接，速度会更快
7.2使用mapjoin加载小表到内存
使用STREAMTABLE(a)将a表视为大表
7.3where条件放置在join on 的条件后面，这样就不行对结果进行与过滤
8.Hive的优化–并行执行
hive并行执行开启：set hive.exec.parallel = true
并行实行： – 同步执行hive的多个阶段，hive在执行过程，将一个查询转化成一个或者多个阶段。某个特 定的job可能包含众多的阶段，而这些阶段可能并非完全相互依赖的，也就是说可以并行执行 的，这样可能使得整个job的执行时间缩短。
9.hive优化—数据倾斜
1.原因：1>key分布不均匀导致
2>人为的建表疏忽，类型不匹配
3>业务数据特点
2.症状：
1》任务进度长时间维持在99%，查看spark界面，发现只有少量的reduce子任务没有完成
2》查看没有完成的子任务，看到本地读写数据量积累非常大，通常超过10G可以认为发生数据倾斜
3.倾斜度：
1》平均记录超过50W并且最大记录是超过平均记录的4倍
2》最长时长并平均时长超过4分钟，且最大时长超过平均时长的2倍
4.万能方法：
设置hive.groupby.skwindata = true
9.2hive优化—数据倾斜—大小表关联
1.原因：
小表优先放左边，如果两张小表，key相对分散的放左边。
Hive在进行join时，按照join的key进行分发，而在join左边的表的数据会首先读入内存，如果左边表的key相对分 散，读入内存的数据会比较小，join任务执行会比较快；而如果左边的表key比较集中，而这张表的数据量很大， 那么数据倾斜就会比较严重，而如果这张表是小表，则还是应该把这张表放在join的左边
2.思路：
将key相对分散，且相对较小的表放在join的左边
使用map join 让小维度的表先进内存
------------
1.原因：日志中有一部分的userid是空或者是0的情况，导致在用user_id进行hash分桶的时候，会将日志中userid为0或者 空的数据分到一起，导致了过大的斜率。
2.思路：
把空值的可以变成一个字符串加上随机数，把倾斜的数据分到不同的reduce上，由于null值关联不上，处理后并不影响最终的结果
方法：
on case when (x.uid = ‘-’ or x.uid = ‘0’ or x.uid is null)
then concat(‘-’,rand())
else x.uid
end = f.user_id
9.3Hive 优化-----数据倾斜----大大表关联（思路：业务削减）
如果遇到两个大表互相关联，从业务逻辑出发，过滤掉不相关的数据，比如，两个用户登录的表，可以按照时间过滤，只统计今天登录的用户，这样就会大大减少表的数据量
9.4hive优化----数据倾斜—聚合时存在大量特殊值
1.原因：做count distinct时，该字段存在大量值为NULL或空的记录。
2.思路：count distinct时，将之唯恐的情况单独处理，如果是计算count distinct，可以不用处理，直接过滤掉，在最后结果中加1
如果还有其他计算，需要进行group by ，可以先将值为空的记录单独处理，在和其他计算结果进行union
9.5-----HIve优化----数据倾斜—空间换时间