hive的学习_优化

一.表连接：
1.将大表放后头
Hive假定查询中最后的一个表是大表。它会将其它表缓存起来，然后扫描最后那个表。
因此通常需要将小表放前面，或者标记哪张表是大表：/*streamtable(table_name) */。否则会引起磁盘和内存的大量消耗。
2. 使用相同的连接键
当对3个或者更多个表进行join连接时，如果每个on子句都使用相同的连接键的话，那么只会产生一个MapReduce job。
3. 尽量尽早地过滤数据
减少每个阶段的数据量,对于分区表要加分区，同时只选择需要使用到的字段。
4. 尽量原子化操作
尽量避免一个SQL包含复杂逻辑，可以使用中间表来完成复杂的逻辑
5.大大表关联：
把空值的key变成一个字符串加上随机数，把倾斜的数据分到不同的reduce上，由于null值关联不上，处理后并不会影响最终结果。

二.用insert into替换union all
如果union all的部分个数大于2，或者每个union部分数据量大，应该拆成多个insert into 语句，实际测试过程中，执行时间能提升50%

三.order by & sort by 
order by : 对查询结果进行全局排序，消耗时间长。需要 set hive.mapred.mode=nostrict
sort by : 局部排序，并非全局有序，提高效率。

五. limit 语句快速出结果
一般情况下，Limit语句还是需要执行整个查询语句，然后再返回部分结果。
有一个配置属性可以开启，避免这种情况---对数据源进行抽样
hive.limit.optimize.enable=true --- 开启对数据源进行采样的功能
hive.limit.row.max.size --- 设置最小的采样容量
hive.limit.optimize.limit.file --- 设置最大的采样样本数
缺点：有可能部分数据永远不会被处理到

六. 并行执行
hive会将一个查询转化为一个或多个阶段，包括：MapReduce阶段、抽样阶段、合并阶段、limit阶段等。
默认情况下，一次只执行一个阶段。 不过，如果某些阶段不是互相依赖，是可以并行执行的。
set hive.exec.parallel=true,可以开启并发执行。
set hive.exec.parallel.thread.number=16; //同一个sql允许最大并行度，默认为8。
会比较耗系统资源。

七. 调整mapper和reducer的个数
1.减少map数
若有大量小文件（小于128M），会产生多个map，处理方法是：
set mapred.max.split.size=100000000;    -- 决定每个map处理的最大的文件大小，单位为B
set mapred.min.split.size.per.node=100000000;  -- 节点中可以处理的最小的文件大小
set mapred.min.split.size.per.rack=100000000;-- 机架中可以处理的最小的文件大小
mapred.max.split.size <= mapred.min.split.size.per.node <= mapred.min.split.size.per.rack 
大于文件块大小128m的，按照128m来分隔，
小于128m,大于100m的，按照100m来分隔，
把那些小于100m的（包括小文件和分隔大文件剩下的）进行合并
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat; -- 执行前进行小文件合并
2.增加map数
当input的文件都很大，任务逻辑复杂，map执行非常慢的时候，
可以考虑增加Map数，来使得每个map处理的数据量减少，从而提高任务的执行效率。
set mapred.map.tasks=?
set hive.map.aggr = true     map端的聚合
使大数据量利用合适的map数；使单个map任务处理合适的数据量。
3 Reduce阶段优化
调整方式：
-- set mapred.reduce.tasks=?   （更优先）
-- set hive.exec.reducers.bytes.per.reducer = ?-- 每个reduce处理的数据量,默认256MB
一般根据输入文件的总大小,用它的estimation函数来自动计算reduce的个数：reduce个数 = InputFileSize / bytes per reducer
4.一个reduce的情况
对于一个没有group by，而你有做了count这种聚合类的函数的时候它最后跑出的reduce的个数肯定是一个redeuce。
笛卡儿积：join的时候如果你要对两个表聚合的时候，如果是不用这种带on的情况下它最后也会一个reduce来运行。
使大数据量利用合适的reduce数；使单个reduce任务处理合适的数据量；

八.map join 
set hive.auto.convert.join = true; # 默认为false  
该参数为true时，Hive自动对左边的表统计量，如果是小表就加入内存，即对 小表使用Map join
/*+STREAMTABLE(a)+*/  指明哪张表是大表。对其它小表放入内存中。
/*+MAPJOIN(b)+*/  指明小表，并且放入内存中

九.Automatic merge:
hive.merge.mapfiles = true 是否合并map输出文件，默认为true
hive.merge.mapredfiles = false 是否合并Reduce 输出文件 默认为false
hive.merge.size.per.task = 256*1000*1000 合并文件的大小

十.并行：
set hive.exec.parallel=true设置为true。
要把那些没有相互依赖之间的关系的一些节点就可以能够尽可能的并行。

十一.严格模式
set hive.marped.mode=strict ------ 防止用户执行那些可能意想不到的不好的影响的查询
-- 分区表，必须选定分区范围
-- 对于使用order by的查询，要求必须使用limit语句。因为order by为了执行排序过程会将所有的结果数据分发到同一个reducer中进行处理。
-- 限制笛卡尔积查询：两张表join时必须有on语句

十一.数据倾斜
对sum，count来说，不存在数据倾斜问题。
原因
1)、key分布不均匀
2)、业务数据本身的特性
3)、建表时考虑不周
4)、某些SQL语句本身就有数据倾斜
关键词 情形后果
join 其中一个表较小，但是key集中分发到某一个或几个Reduce上的数据远高于平均值
join 大表与大表，但是分桶的判断字段0值或空值过多这些空值都由一个reduce处理，灰常慢
group by group by 维度过小，某值的数量过多 处理某值的reduce灰常耗时
count distinct某特殊值过多 处理此特殊值reduce耗时

解决方案：
1）参数调节:
hive.map.aggr=true map端部分聚合，当于 combiner
hive.groupby.skewindta = true  万能的方法  有数据倾斜时负载均衡  <--  一个job转换为2个job
2）sql语句调节
如何join：关于驱动表的选取，应选分布均匀的作为驱动表；做好列剪裁与 filter 操作，
达到两表 join 时，数量变小的效果。
大小表join：使用map join，让小表先进内存，在 map 端完成reduce 。
大表 join 大表：把空值null的key变成字符串加上随机数，倾斜数据分到不同 reduce 上。
groupby 维度过小：采用sum() group by 代替count (distinct) 完成计算。
不同数据类型关联的数据倾斜：把数值类型转化为 string。
eg. select *from a left join b on (a.id = cast(b.id as string))
3）小表加到内存中。
大大表关联：
userid 为空或者为0的情况：
把这个key变成一个字符串，并且加一个随机数，然后把倾斜的数据能够尽可能的分散开来，分散到不同的桶里面去