hive优化

优化
（1）map优化——调整block大小——>并发度调整
set mapred.max.split.size=100000000; // 每个map处理最大文件大小，单位B，确认启动多少map数量
set mapred.min.split.size.per.node=100000000; // 节点中可以处理最小的文件大小
set mapred.min.split.size.per.rack=100000000; // 机架中可以处理最小的文件大小
mapreduce —— combine优化
set hive.map.aggr=true
（2）reduce优化：
mapred.reduce.tasks=10
（3）痛点1：整理一下在mapreduce哪些情况时会产生1个reduce的现象：
1）没有group by——有聚合函数的时候，要求有group by
2）order by——会产生1个reduce（全局排序）
优化方法：用distribute by和sort by来替代
sort by：不是全局排序，保证每个reduce内部是排序的，但不保证全局是有序的
distribute by：控制map端如何拆分数据给reduce，可以把它想象成partition（分桶）
例子：select * from table distribute by key_id sort by col_1 desc;
cluster by：相当于把sort by和distribute by结合起来了，默认只能升序
例子：
select * from table distribute by key_id sort by key_id;
改写为：
select * from table cluster by key_id
（4）痛点2：加快查询速度
加速方法：
1）分区裁剪：partition
2）笛卡尔积：join要带on
3）map-join：指定小表，内存处理，通常不超过1G，或50w记录 /+MAPJOIN(table1)/
4）union all：union all(不去重)和union（去重）区别
5）multi-insert & multi group by

从一份基础表中按照不同的维度，一次组合出不同的数据
– FROM from_statement
– INSERT OVERWRITE TABLE tablename1 [PARTITION (partcol1=val1)] select_statement1 group by key1
– INSERT OVERWRITE TABLE tablename2 [PARTITION(partcol2=val2 )] select_statement2 group by key2

6）automatic merge：对多个小文件进行合并
hive.merge.mapfiles = true?是否和并 Map 输出文件，默认为 True
hive.merge.mapredfiles = false?是否合并 Reduce 输出文件，默认为 False
hive.merge.size.per.task = 25610001000?合并文件的大小
7）Multi-Count Distinct

必须先设置参数：set hive.groupby.skewindata=true;
select dt, count(distinct uniq_id), count(distinct ip)
from ods_log where dt=20170301 group by dt

负载均衡
set hive.groupby.skewindata=true;
（5）痛点3：join操作
1）语句优化：
a）多表连接：如果join中，多个表的join key是同一个，则join会转化为单个mr任务
b）表的连接顺序： /*+STREAMTABLE(table2)*/
2）条件判断角度：避免join过程中出现大量结果，尽量在on中完成所有条件判断,也可子查询再join
3）并行执行：set hive.exec.parallel=true
主要目标：解决数据倾斜问题：
总结：
1）大表和小表之间的关联
原因
• Hive在进行join时，按照join的key进行分发，而在join左边的表的数据会首先读入内存，如果左边表的key相对分散，读入内存的数据会比较小，join任务执行会比较快；而如果左边的表key比较集中，而这张表的数据量很大，那么数据倾斜就会比较严重，而如果这张表是小表，则还是应该把这张表放在join左边。
思路
• 将key相对分散，并且数据量小的表放在join的左边，这样可以有效减少内存溢出错误发生的几率
• 使用map join让小的维度表先进内存。
方法
• Small_table join big_table

2）大表和大表之间的关联
• 原因
• 日志中有一部分的userid是空或者是0的情况，导致在用user_id进行hash分桶的时候，会将日志中userid为0或者
空的数据分到一起，导致了过大的斜率。
• 思路
• 把空值的key变成一个字符串加上随机数，把倾斜的数据分到不同的reduce上，由于null值关联不上，处理后并不
影响最终结果。
• 方法
• on case when (x.uid = '-' or x.uid = '0‘ or x.uid is null) then concat('dp_hive_search',rand()) else x.uid
end = f.user_id;

案例 业务消减
• Select * from dw_log t join dw_user t1 on t.user_id=t1.user_id
• 现象：两个表都上千万，跑起来很悬
• 思路
• 当天登陆的用户其实很少
• 方法
• Select /*+MAPJOIN(t12)*/ * 
• from dw_log t11 
• join (
• select /*+MAPJOIN(t)*/ t1.*
• from (
• select user_id from dw_log group by user_id
• ) t
• join dw_user t1
• on t.user_id=t1.user_id
• ) t12 
• on t11.user_id=t12

案例 聚合时存在大量特殊值
• 原因
• 做count distinct时，该字段存在大量值为NULL或空的记录。
• 思路
• count distinct时，将值为空的情况单独处理，如果是计算count distinct，可以不用处理，直接过滤，在最后结
果中加1。
• 如果还有其他计算，需要进行group by，可以先将值为空的记录单独处理，再和其他计算结果进行union
• 方法
• select cast(count(distinct(user_id))+1 as bigint) as user_cnt
• from tab_a
• where user_id is not null and user_id <> ''


案例 空间换时间
• Select day,count(distinct session_id),count(distinct user_id) from log a group by day
• 问题
• 同一个reduce上进行distinct操作时压力很大
• 方法
• select day,
• count(case when type='session' then 1 else null end) as session_cnt,
• count(case when type='user' then 1 else null end) as user_cnt
• from ( 
• select day,session_id,type
• from (
• select day,session_id,'session' as type
• from log
• union all
• select day user_id,'user' as type
• from log
• )
• group by day,session_id,type
• ) t1
• group by day