hive调优

Hive数据倾斜解决方法总结
数据倾斜是进行大数据计算时最经常遇到的问题之一。当我们在执行HiveQL或者运行MapReduce作业时候，如果遇到一直卡在map100%,reduce99%一般就是遇到了数据倾斜的问题。数据倾斜其实是进行分布式计算的时候，某些节点的计算能力比较强或者需要计算的数据比较少，早早执行完了，某些节点计算的能力较差或者由于此节点需要计算的数据比较多，导致出现其他节点的reduce阶段任务执行完成，但是这种节点的数据处理任务还没有执行完成。
　　在hive中产生数据倾斜的原因和解决方法：
　　1）group by,我使用Hive对数据做一些类型统计的时候遇到过某种类型的数据量特别多，而其他类型数据的数据量特别少。当按照类型进行group by的时候，会将相同的group by字段的reduce任务需要的数据拉取到同一个节点进行聚合，而当其中每一组的数据量过大时，会出现其他组的计算已经完成而这里还没计算完成，其他节点的一直等待这个节点的任务执行完成，所以会看到一直map 100% reduce 99%的情况。
　　解决方法：set hive.map.aggr=true
　　　　　　　set hive.groupby.skewindata=true
　　原理：hive.map.aggr=true 这个配置项代表是否在map端进行聚合
　　　　　hive.groupby.skwindata=true 当选项设定为 true，生成的查询计划会有两个 MR Job。第一个 MR Job 中，Map 的输出结果集合会随机分布到 Reduce 中，每个 Reduce 做部分聚合操作，并输出结果，这样处理的结果是相同的 Group By Key 有可能被分发到不同的 Reduce 中，从而达到负载均衡的目的；第二个 MR Job 再根据预处理的数据结果按照 Group By Key 分布到 Reduce 中（这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce 中），最后完成最终的聚合操作。
　　2）map和reduce优化。
　　　　1.当出现小文件过多，需要合并小文件。可以通过set hive.merge.mapfiles=true来解决。
　　　 2.单个文件大小稍稍大于配置的block块的大写，此时需要适当增加map的个数。解决方法：set mapred.map.tasks个数
　 　　 3.文件大小适中，但map端计算量非常大，如select id,count(),sum(case when…),sum(case when…)…需要增加map个数。解决方法：set mapred.map.tasks个数，set mapred.reduce.tasks个数
　　3）当HiveQL中包含count（distinct）时
如果数据量非常大，执行如select a,count(distinct b) from t group by a;类型的SQL时，会出现数据倾斜的问题。
解决方法：使用sum…group by代替。如select a,sum(1) from (select a, b from t group by a,b) group by a;
　　4）当遇到一个大表和一个小表进行join操作时。
　　 解决方法：使用mapjoin 将小表加载到内存中。
　 　如：select /+ MAPJOIN(a) */ 　a.c1, b.c1 ,b.c2　from a join b where a.c1 = b.c1;
　　5）遇到需要进行join的但是关联字段有数据为空，如表一的id需要和表二的id进行关联
　　 解决方法1：id为空的不参与关联
　　　　比如：select * from log a 　join users b 　on a.id is not null and a.id = b.id 　union all 　select * from log a 　where a.id is null;
　　　解决方法2：给空值分配随机的key值
　　　　　　如：select * from log a
　　　　　　　　left outer join users b
　　　　　　　　on
　　　　　　　　case when a.user_id is null
　　　　　　　　then concat(‘hive’,rand() )
　　　　　　　　else a.user_id end = b.user_id;

数据倾斜就是key分布不均匀，导致分发到不同的reduce上，个别reduce任务特别重，导致其他reduce都完成，而这些个别的reduce迟迟不完成的情况。 发生数据倾斜的原因有
key分布不均匀。
map端数据倾斜，输入文件太多且大小不一 。
reduce端数据倾斜，分区器问题
业务数据本身的特征。
hive中的解决方案：
1.调节hive配置参数
设置hive.map.aggr = true map端部分聚合，相当于Combiner
设置hive.groupby.skewindata = true 有数据倾斜时，查询计划生成两个mr job， 第一个job先进行key随机分配处理，先缩小数据量。第二个job再进行真正的group by key处理。
2.SQL语句优化
大小表进行连接时，使用map join让小表先进内存，在map端完成reduce。
大表连接大表时，如果是空值造成数据倾斜，那么把空值变成一个字符串加上随机数，把这部分倾斜的数据分发到不同的reduce上。
如果count distinct有大量相同特殊值 （如空值） 空值可以不用处理，直接最后count结果加1即可。或者空值单独拿出来处理，最后再union回去。
不同数据类型关联 默认的hash操作会按其中一种类型的值进行分配，导致别一种类型全部分发到同一个reduce中。把两个关联的类型转换成相同类型。
MR解决方案
假设A、B两张表关联，A中存在数据倾斜的key 。
先对A表进行采样，将造成数据倾斜的key的记录存入一个临时表tmp1。
一般来说造成数据倾斜的key不会太多，所以tmp1会是一个小表。
故可以将tmp1和B表进行map join，生成tmp2，再把tmp2分发到distribute file cache。
map读入A表和B表，假如记录来自A表，则判断key是否在tmp2中，如果是，输出到本地文件a，如果不是，则生成对，假如记录来自B表，生成对，进入reduce阶段。
将文件a和步骤3中reduce输出文件合并起来写到hdfs。
也可以设置Combine, 聚合精简数据。也可以考虑将数据分为倾斜和非倾斜部分进行处理。这样倾斜部分会是小文件，可以使用map join处理，非倾斜部分则可以按正常reduce处理，最后合并起来即可。

小文件是如何产生的
1.动态分区插入数据，产生大量的小文件，从而导致map数量剧增。
2.reduce数量越多，小文件也越多(reduce的个数和输出文件是对应的)。
3.数据源本身就包含大量的小文件。
小文件问题的影响
1.从Hive的角度看，小文件会开很多map，一个map开一个JVM去执行，所以这些任务的初始化，启动，执行会浪费大量的资源，严重影响性能。
2.在HDFS中，每个小文件对象约占150byte，如果小文件过多会占用大量内存。这样NameNode内存容量严重制约了集群的扩展。
小文件问题的解决方案
从小文件产生的途经就可以从源头上控制小文件数量，方法如下：
1.使用Sequencefile作为表存储格式，不要用textfile，在一定程度上可以减少小文件。
2.减少reduce的数量(可以使用参数进行控制)。
3.少用动态分区，用时记得按distribute by分区。
对于已有的小文件，我们可以通过以下几种方案解决：
1.使用hadoop archive命令把小文件进行归档。
2.重建表，建表时减少reduce数量。
3.通过参数进行调节，设置map/reduce端的相关参数，如下：
设置map输入合并小文件的相关参数：
//每个Map最大输入大小(这个值决定了合并后文件的数量)
set mapred.max.split.size=256000000;
//一个节点上split的至少的大小(这个值决定了多个DataNode上的文件是否需要合并)
set mapred.min.split.size.per.node=100000000;
//一个交换机下split的至少的大小(这个值决定了多个交换机上的文件是否需要合并)
set mapred.min.split.size.per.rack=100000000;
//执行Map前进行小文件合并
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;

设置map输出和reduce输出进行合并的相关参数：
//设置map端输出进行合并，默认为true
set hive.merge.mapfiles = true
//设置reduce端输出进行合并，默认为false
set hive.merge.mapredfiles = true
//设置合并文件的大小
set hive.merge.size.per.task = 25610001000
//当输出文件的平均大小小于该值时，启动一个独立的MapReduce任务进行文件merge。
set hive.merge.smallfiles.avgsize=16000000