hive优化数据倾斜
hive数据倾斜产⽣的原因
数据倾斜的原因很⼤部分是join倾斜和聚合倾斜两⼤类
⼀、Hive倾斜之group by聚合倾斜
原因：
分组的维度过少，每个维度的值过多，导致处理某值的reduce耗时很久；
对⼀些类型统计的时候某种类型的数据量特别多，其他的数据类型特别少。当按照类型进⾏group by的时候，会将相同的group by字
段的reduce任务需要的数据拉取到同⼀个节点进⾏聚合，⽽当其中每⼀组的数据量过⼤时，会出现其他组的计算已经完成⽽这个
reduce还没有计算完成，其他的节点⼀直等待这个节点的任务执⾏完成，所以会⼀直看到map 100% reduce99%的情况；
解决⽅法：
set hive.map.aggr=true;
set hive.groupby.skewindata=true;
原理：
hive.map.aggr=true 这个配置代表开启map端聚合；
hive.groupby.skewindata=true，当选项设定为true，⽣成的查询计划会有两个MR Job。当第⼀个MR Job中，Map的输出结果结
合会随机分布到Reduce中，每个Reduce做部分聚合操作，并输出结果。这样处理的结果是相同的Group By Key有可能被分发到不同
的Reduce中，从⽽达到负载均衡的⽬的。第⼆个MR Job再根据预处理的数据结果按照Group By Key分布到reduce中，这个过程可
以保证相同的key被分到同⼀个reduce中，最后完成最终的聚合操作。
⼆、Hive倾斜之Map和Reduce优化
原因1：当出现⼩⽂件过多，需要合并⼩⽂件。可以通过set hive.merge.mapredfiles=true来解决；
原因2：输⼊数据存在⼤块和⼩块的严重问题，⽐如 说：⼀个⼤⽂件128M，还有1000个⼩⽂件，每 个1KB。 解决⽅法：任务输⼊
前做⽂件合并，将众多⼩⽂件合并成⼀个⼤⽂件。通过set hive.merge.mapredfiles=true解决；
原因3：单个⽂件⼤⼩稍稍⼤于配置的block块的⼤⼩，此时需要适当增加map的个数。解决⽅法：set mapred.map.tasks的个数；
原因4：⽂件⼤⼩适中，但是map端计算量⾮常⼤，如：select id,count(*),sum(case when…),sum(case when …)…需要增加map
个数。解决⽅法：set mapred.map.tasks个数，set mapred.reduce.tasks个数；
三、Hive倾斜之HQL中包含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;
四、Hive倾斜之HQL中join优化
原因：当遇到⼀个⼤表和⼀个⼩表进⾏join操作时。使⽤mapjoin将⼩表加载到内存中。如：select /*+ MAPJOIN(a) */ a.c1, b.c1,b.c2 from a join b where a.c1 = b.c1;
遇到需要进⾏join，但是关联字段有数据为null，如表⼀的id需要和表⼆的id进⾏关联；
hive数据倾斜的优化核心思想：
1、减少数据量
利用分区或者分桶，不过分桶用的很少，影响数据同步的效率，还有就是列比较多的表，做个裁剪，把列变少
2、避免数据倾斜
简单的讲，数据倾斜就是我们在计算数据的时候，数据的分散度不够，由于数据分布不均匀，造成数据大量的集中到一点，造成数据热点，查询卡住啦，
比如hivesql里的distinct、 group By、join就会出现这个现象。
1）一般我会用group by替换distinct，
2）group by的时候把数据量大的分组单独计算再用union all合并到一起
3）开启mapjoin
select /* +mapjoin(e)*/ from mydb.emp e;
3、使用一些语句的优化
比如使用with as临时表啊，group by替换distinct啊等等
4、参数配置优化
之前平台工程师或者数据组长会配置一些参数，我们开发一般很少配置
5、使用高效的查询引擎
我们后期使用了sparksql，这个明显提升了效率啦
6、存储格式（压缩）优化
我们还会使用ORC格式，这个对查询效率也有提升
7、根据业务逻辑对业务实现的整体进行优化
还有就是我们设置合理的分层，让数据逐步处理
