实际项目来说，join相关优化占了Hive优化的大部分内容
数据倾斜：数据没有平均的分布到每个节点。往往是数据本身的原因或者分布算法的原因。数据本身原因：虽然数据量一样但是有的数据不好算。
优化不良习惯引起的
在实际 Hive SQL 开发的过程中， Hive SQL 性能的问题上实际只有一小部分和数据倾斜相关 很多时候， Hive SQL 运行得慢是由开发人员对于使用的数据了解不够以及一些不良的使用习惯引起的
1.数据来源找已经汇总好的、
2.需要多少分区就扫描多少分区。要一周就够就不要拿一年的
3.不要select*
4.输入的文件不要是大量小文件。
Join无关的优化
group by 引起的倾斜
groupby是根据 groupby key进行任务分发的。有的key数据量大，造成了倾斜。
解决办法：
set hive.map.aggr = true
set hive.groupby.skewindata = true
这样就会进行两次MapReduce。第一次随机分配，不追求相同的key在一起
第二次再将第一次的输出重分布到reduce，最后完成最终的聚合操作。
count distinct优化
在Hive开发过程中，小心使用count distinct，因为要去重，map的输出会全部分布到一个ReduceTASK上。此时很容易引起性能问题。
select count（*）
from
( select user
from some_table
group by user
) a
其原理为：利用group by 去重，再统计groupby 的行数目。
（巧妙啊 记住记住）
JOIN有关的优化
大表join小表优化
在查询语句前面加 /+mapjoin(b)/
mapjoin是默认开启的，设置参数为： set hive.auto.convert.join = true;
这种情况往往会出现倾斜。我们在map阶段进行join。这样就不需要分发任务。自然没有倾斜问题。
因为有一个小表，把小表全量复制到每一个Map任务节点，然后每一个任务lookup小表即可。小表默认25m
大表join大表优化
方案一：对B表做筛选，使其变小。达到大表JOIN小表的结果。
方案二：对引起倾斜的值随机分配到Reduce。HIve会自动对此进行优化。我们需要设置参数一下参数
set hive.optimize.skewinfo=table_B:(seller_id)[(“0”)(“1”)]; *//把一直引起倾斜的字段值输进去就好
set hive.optimize.skewjoin=true;
只能解决倾斜的值是明确的而且数量很少，比如null值引起的倾斜。
方案三：