hive的优化，
Hive SQL的各种优化方法基本 都和数据倾斜密切相关。
Hive的优化分为join相关的优化和join无关的优化，从项目的实际来说，join相关的优化占了Hive优化的大部分内容，而join相关的优化又分为mapjoin可以解决的join优化和mapjoin无法解决的join优化。
**
1、数据倾斜
**
倾斜来自于统计学里的偏态分布。所谓偏态分布，即统计数据峰值与平均值不相等的频率分布，根据峰值小于或大于平均值可分为正偏函数和负偏函数，其偏离的程度可用偏态系数刻画。
对应分布式数据处理来说，希望数据平均分布到每个处理节点。如果以每个处理节点为X轴，每个节点处理的数据为Y轴，我希望的柱状图如下
但是实际上由于业务数据本身的问题或者分布算法的问题，每个节点分配到的数据量很可能是下面的样式：
更极端情况出现下面的样式：
也就是说，只有待分到最多数据的节点处理完数据，整个数据处理任务才算完成，此时分布式的意义大大折扣了。实际上，即使每个节点分配到的数据量大致相同，数据仍然可能倾斜，
**
2、Hive优化
**
在实际的Hive SQL开发的过程中，Hive SQL 性能的问题上实际上只有一小部分和数据倾斜有关，很多时候，Hive SQL运行慢是由于开发人员对于使用的数据了解不够以及一些不良的习惯引起的。
开发人员需要确定以下几点：
1、 需要计算的指标真的需要从数据仓库公共明细层来自行汇总吗？ 是不是数据公共层团队开发公共汇总层已经可以满足自己的需求？对应大众的、KPI相关的指标等通常设计良好的数据仓库公共层
肯定已经包含了，直接使用即可。
2、真的需要扫描那么多分区吗，比如对于销售事务明细表来说，扫描一年的分区和扫描一周的分区所带来的计算、IO开销完全是两个数量级，所耗费时间肯定是不同的，所以开发人员要仔细考虑因为需求，
尽量不浪费计算和存储资源。
3、尽量不要使用select * from your_table这样的方式，用到哪些列就指定哪些列，另外WHERE条件中尽量添加过滤条件，以去掉无关的行，从而减少整个MapReduce任务宠需要处理、分发的数据量。
4、输入文件不要是大量的小文件，Hive默认的Input Split是128MB（可配置），小文件可先合并成大文件。