关于hive的优化

首先hive本质就是mapreduce，那么优化就从mapreduce开始入手。

然而mapreduce的执行快慢又和map和reduce的个数有关，所以我们先从这里下手，调整并发度。

关于map的优化：

　　1.调整block

　　　　作业会通过input的目录产生一个或者多个map任务。set dfs.block.size

　　　　因为没份数据都是block，而block的大小直接影响了split切分的分数，如果切分的更细一点，那么split个数会增加，那直接会影响map的增加，所以blocksize是直接影响并发度的因素

　　　　通过该配置参数来调整map个数：

　　　　　　set mapred.max.split.size=100000000;

　　　　　　set mapred.min.split.size.per.node=100000000;

　　　　　　set mapred.min.split.size.per.rack=100000000;

　　　　　　set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;

　　　　还可以直接设置map个数：

　　　　　　set mapred.map.tasks=10;

　　　　　　注：这种方式进行设置，并不一定会生效

　　　　开启combiners

　　　　　　Map端聚合 hive.map.aggr=true

　　　　　　注：用的好了，可以提高性能，用的不好了，反而影响结果（可以参考mapreduce的combiner）

关于reduce的优化：

　　hive.exec.reducers.bytes.per.reducer；reduce任务处理的数据量

　　　　这个参数可以在提交sql的时候设置这个参数，这个参数可以直接设置一个数字，这个数字会直接影响reduce的个数

　　　　reduce个数的计算公式（hive.exec.reducers.bytes.per.reducer）：

　　　　　　reduce个数 = InputFileSize  / bytes pre reduce（整个数据的大小 / 每一个reduce可以处理的大小）

　　　　　　hive.exec.reducers.bytes.per.reducer这个参数设置的就是每个reduce可以处理的大小

　　　set mapred.reduce.tasks=10（也是设置reduce的个数）

　　　　如果hive.exec.reducers.bytes.per.reducer和set mapred.reduce.tasks同时设置了，set mapred.reduce.tasks 优先级高

---------------------------------------------------------------------------------------------------------------------------------------------------------------

　　例如：1）查询count这种聚合函数，如果使用的group by的话会多个reduce来运行，而没有使用group by的话就是单个reduce来运行，所以面对大量数据做聚合，使用group by

　　　　　where pt=‘20190308’ 单个reduce运行 （bed case）

　　　　　where pt=‘20190308’ group by pt 多个reduce运行 （good case）

　　　　　2）两张表做join的时候，使用on是多个reduce来运行，而不使用on则是一个reduce来运行（两张表做join，一定要用on）

　　　　　select id,xxx from table_A  A join table_B B on A.id=B.id  多个reduce运行 （good case）

　　　　　select id,xxx from table_A A join table_B B where A.id=B.id 单个reduce运行  （bed case）

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

partition做分区，直接定位到分区，省去一些不必要的过滤

　　分区的问题看上一篇博客

Map Join：类似一种检索配置的形式

　　　　/*+ MAPJOIN(tablelist) */，必须是小表，不要超过1G，或者50万条记录

　　　　有A,B两张表，A想joinB     A.join（B）

　　　　如果A是小表，B是大表，可以将A放入内存（小表有多小？尽量不要超过1G）

Union操作：合并去重操作

　　　　table_A: A,B,C    table_B:B,C,D   Union:A,B,C,D

Union all操作：直接追加不做去重

　　　　table_A: A,B,C    table_B:B,C,D   Union:A,B,C,B,C,D

　　　　Union all不去重，性能明显高于Union

　　　　先做union all再做join或group by等操作可以有效减少mapreduce过程，尽管是多个Select，最终只有一个mapreduce

　　　　明确数据不相同或者有相同不需要去重就用Union all，有相同就用Union

Automatic merge：

　　执行hive的过程中，中间可能产生一些小文件，在中间做一些文件的合并

　　　　– hive.merge.mapfiles = true 是否和并 Map 输出文件，默认为 True

　　　　– hive.merge.mapredfiles = false 是否合并 Reduce 输出文件，默认为 False

　　　　– hive.merge.size.per.task = 256*1000*1000 合并文件的大小

Multi-Count Distinct：　　

　　当我们写一个sql的时候

　　　　sql（group by key）------>一个MR job

　　　　map相同的key------->同一个reduce

　　　　假设数据源存在数据倾斜问题

　　　　所有的reduce都完成了，最后等1个reduce

　　　　怎么优化？（mapreduce中：对key改写来解决此类问题）

　　　　hive中：set hive.groupby.skewindata=true  （会自动的帮你完成负载均衡）

--------------------------------------------------------------------------------------------------------

在mapreduce中，什么时候会耗时比较严重呢？

　　在做join的时候会耗时比较严重

　　hive是可以支持多表链接的

　　　　一个mapreduce的例子：

　　　　　　select a.val, b.val, c.val from a join b on(a.key = b.key1) join c on(a.key = c.key1)  一个MR job（good case）

　　　　　　select a.val, b.val, c.val from a join b on(a.key = b.key1) join c on(b.key2 = c.key)  多个MR job （bad case）

　　　　如果join多张表，join的key是同一个的时候，会生成一MR job

　　

Hive的 Join 优 化 — — 表连接顺序　　

　　hive会默认把左边的数据放入内存，右边的数据做类似流数据（最好每次写join的是，小标放左边，大表放右边）

　　A.join（B）

　　reducer会尝试把A表进行缓存，因为A在前面B在后面（它会把最后一张表前的所有表都尝试进行缓存）如果A完全可以放入内存中去，对B进行遍历，进行join，如果B有n条记录，那它的时间复杂度就是O（n）

　如果A，B都不在内存中，A的大小是m，B的大小是n,那它的时间复杂度就是O（m*n）

　　 当大小表的顺序有问题，又不想改写顺序：

　　　　SELECT /*+ STREAMTABLE(a) */ a.val, b.val, c.val FROM a  JOIN b ON (a.key = b.key1)  JOIN c ON (c.key = b.key1)；     a表被视为大表

　　　　SELECT /*+ MAPJOIN(b) */ a.key, a.value FROM a JOIN b ON a.key = b.key;      MAPJION会把小表全部读入内存中，在map阶段直接拿另外一个表的数据和内存中表数据做匹配，由于在map是进行了join操作，省去了reduce运行的效率也会高很多

-------------------

　　左连接时，左表中出现的JOIN字段都保留，右表没有连接上的都为空。

　　SELECT a.val, b.val FROM a LEFT OUTER JOIN b ON (a.key=b.key) WHERE a.ds='2009-07-07' AND b.ds='2009-07-07'

　　　　　　执行顺序是，首先完成2表JOIN，然后再通过WHERE条件进行过滤，这样在JOIN过程中可能会输出大量结果，再对这些结果进行过滤，比较耗时。

　   SELECT a.val, b.val FROM a LEFT OUTER JOIN b ON (a.key=b.key AND a.ds='2009-07-07' AND b.ds='2009-07-07')

　　　　　　可以进行优化，将WHERE条件放在ON后，在JOIN的过程中，就对不满足条件的记录进行了预先过滤。

Hive的优化 — — 并行执行

　　同步执行hive的多个阶段，hive在执行过程，将一个查询转化成一个或者多个阶段。某个特定的job可能包含众多的阶段，而这些阶段可能并非完全相互依赖的，也就是说可以并行执行的，这样可能使得整个job的执行时间缩短。

　　hive执行开启：set hive.exec.parallel=true

　　　　

数据倾斜：

　　我们优化大部分的目标都是为了解决数据倾斜的问题　　

　　• 操作

　　　　• Join
　　　　• Group by
　　　　• Count Distinct　　

　　• 原因
　　　　• key分布不均导致的
　　　　• 人为的建表疏忽
　　　　• 业务数据特点

　　• 症状

　　　　• 任务进度长时间维持在99%（或100%），查看任务监控页面，发现只有少量（1个或几个）reduce子任务未完成

　　　　• 查看未完成的子任务，可以看到本地读写数据量积累非常大，通常超过10GB可以认定为发生数据倾斜

　　• 倾斜度

　　　　• 平均记录数超过50w且最大记录数是超过平均记录数的4倍

　　　　• 最长时长比平均时长超过4分钟，且最大时长超过平均时长的2倍

　　• 万能方法

　　　　• hive.groupby.skewindata=true

Hive的优化 ------数据倾斜------大小表关联

　　• 原因

　　　　• Hive在进行join时，按照join的key进行分发，而在join左边的表的数据会首先读入内存

　　　　　　如果左边表的key相对分散，读入内存的数据会比较小，join任务执行会比较快；

　　　　　　如果左边的表key比较集中，而这张表的数据量很大，那么数据倾斜就会比较严重；

　　• 思路

　　　　• 将key相对分散，并且数据量小的表放在join的左边，这样可以有效减少内存溢出错误发生的几率

　　　　• 使用map join让小的维度表先进内存

　　• 方法

　　　　• Small_table join big_table

　　　　　　

Hive的优化 ------数据倾斜------大大表关联

　　• 原因

　　　　• 日志中有一部分的userid是空或者是0的情况，导致在用user_id进行hash分桶的时候，会将日志中userid为0或者空的数据分到一起，导致了过大的斜率

　　• 思路

　　　　• 把空值的key变成一个字符串加上随机数，把倾斜的数据分到不同的reduce上，由于null值关联不上，处理后并不影响最终结果

　　

Hive的优化 ------数据倾斜------聚合时存在大量特殊值

　　• 原因

　　　　• 做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 <> ‘ ‘