你的数据倾斜了吗？

1. hive数据倾斜的吧表现
   发现所有的map tast全部完成，并且99%的reduct tast完成，只剩下一个或者少数几个reduce tast一直在执行，这种情况下一般是发生了数据倾斜。hive 的数据倾斜本质上就是mapreduce的数据倾斜
   hive数据倾斜的原因
   大量相同的key被分配到一个reduce里，造成一个reduce任务类的要死，其他reduce任务闲的要死，查看任务进度，发现长时间停留在99%或100%，检查任务监控界面，只有少量的reduce子任务未完成。
   key 分布不均匀。
   业务问题后业务数据本身的问题，造成某些数据比较集中。
   join小表：其中一个表是小表，但是key值比较集中，导致某些reduce值偏高。
   空值或无意义的值：如果缺失的项很多，在join时这些空值就会非常集中，拖累进度。
   group by :导致分组数据不均。
   distinct:导致最终只有一个reduce。
   hive数据倾斜解决
   group by 代替distinct 要统计某一列的去重数时，如果数据量很大，count(distinct)就回非常慢，原因与order by 类似，count(distinct)逻辑的最终的结果是只有一个reduce。
   group by 配置调整
   1.map端预聚合 group by 时，conbiner在map端做部分预聚合，有效减少shuffle时的数据量。
   checkinterval:设置map端预聚合的行数的阈值，超过该值就会分拆job。

hive.map.aggr=true; //默认
hive.groupby.mapaggr.checkinterval=100000;默认

倾斜均衡配置 hive 自带一个均衡数据倾斜的配置项。其实现方法就是在group by时同时启动两个MRjob。第一个job会将map端的数据随机输入reducer，每个reduce 做部分聚合，相同的key就会分配到不同的reduce中，第二个job再将前面预处理的数据按key聚合并输出结果，这样就起到了均衡的效果。

hive.groupby.skewindata=false //默认

但是，不同的语句执行效果不同，以下三种情况会转成两个job。

语句	job数	hive.groupby.skewindata=true		hive.groupby.skewindata=false
count distinct	2	partitials+final	1	mergepartitial
count * distinct …group by	2	partitials+final	1	mergepartitial
count * ,count distinct	2	partitials+final	1	mergepartitial

 join基础优化
 hive在解析join的sql的语句时，会默认将最后一个表作为大表，将前面的表作为小表，将他们读进内存。如果表顺序写反，如果大表在前面，引发OOM。不过hive自带优化。
 map join :适合大小表的join的情况，大小表的join在map端完成，没有reduce，效率很高。
 多表join时key相同：会将多个join合并为一个mr job来处理，两个join条件不相同，就会拆成多个 MR job来计算。
 sort by 代替 order by
 将结果按照某些字段全局排序，这会导致所有的map端数据进入一个reduce中，在数据量大时，会导致很长时间计算不完。使用 sort by,那么还是会视情况启动多个ruduce 进行排序，并且保证每个reduce内部有序。为了控制map端数据分配到reducer 的key,往往还要配合distribute by一同使用，如果不加distribute by的话，map端数据就会随机分配到reducer。
 单独处理倾斜的key
 一般来说倾斜的key都比较少，我们科技将他们抽样出来，对应的行单独存入临时表中，然后打上随机前缀，最后进行聚合。或者先对key做一层hash,先将数据随机打散让他的并行度变大，在汇聚。