关于HiveQL的常用语法总结(四)——其它技巧(hive代码优化)

大数据有一个特点，就是数据量大，因此如果能提高代码本身的运行效率，或者是使得代码在分布式机器上能更好的进行计算，就会极大的节省时间成本或者是资源成本。所以，本节想给大家分享下hive的优化。

引言——优化思路

首先是一个思路的问题。hive代码该怎么去优化呢？从哪里着手？
显然这是代码跑的比较慢之后，最先想到的两个问题。要先回答这个问题，我们得搞清楚hive代码的运行机制，有多少个步骤，在每个步骤上是否有优化空间。
其实HiveQL是一个映射器，将MapReduce过程映射成了HiveQL代码，因此代码的执行过程大致也就是三个步骤：将HiveQL代码解析成MP过程、Map阶段和Reduce阶段。
所以我们hive代码的优化也是围绕着这三个阶段来进行的。

hive优化总结

最近看到了一篇博客，觉得还不错，给大家分享下：
http://blog.csdn.net/liyaohhh/article/details/50697519

文中讲到了几种优化策略：
1、控制Hive中Map和reduce的数量。 Hive中的sql查询会生成执行计划，执行计划以MapReduce的方式执行，那么结合数据和集群的大小，map和reduce的数量就会影响到sql执行的效率。
除了要控制Hive生成的Job的数量，也要控制map和reduce的数量。

在此，博主提到了Map和Reduce个数的计算方式：
Map的个数

map的数量，通常情况下和split的大小有关系。 如果要减少map数量, 可以调大mapred.max.split.size,
否则调小即可. 其特点是: 一个块至多作为一个map的输入，一个文件可能有多个块，一个文件可能因为块多分给做为不同map的输入，
一个map可能处理多个块，可能处理多个文件。

reduce的个数

reduce数量由以下三个参数决定， mapred.reduce.tasks(强制指定reduce的任务数量)
hive.exec.reducers.bytes.per.reducer（每个reduce任务处理的数据量，默认为1000^3=1G）
hive.exec.reducers.max（每个任务最大的reduce数，默认为999） 计算reducer数的公式很简单N=min(
hive.exec.reducers.max ，总输入数据量/ hive.exec.reducers.bytes.per.reducer )
只有一个reduce的场景： a、没有group by 的汇总 b、order by c、笛卡尔积

2、join和Group的优化
2.1 对于普通的join操作，会在map端根据key的hash值，shuffle到某一个reduce上去，在reduce端做join连接操作，内存中缓存join左边的表，遍历右边的表，一次做join操作。所以在做join操作时候，将数据量多的表放在join的右边。
当数据量比较大，并且key分布不均匀，大量的key都shuffle到一个reduce上了，就出现了数据的倾斜。
2.2 对于Group操作，首先在map端聚合，最后在reduce端坐聚合，hive默认是这样的，以下是相关的参数
· hive.map.aggr = true是否在 Map 端进行聚合，默认为 True
· hive.groupby.mapaggr.checkinterval = 100000在 Map 端进行聚合操作的条目数目

当然有的hive操作，不存在数据倾斜的问题，比如数据聚合类的操作，像sum、count，因为已经在map端做了聚合操作了，到reduce端的数据相对少一些，所以不存在这个问题。

3、小文件的合并
大量的小文件导致文件数目过多，给HDFS带来压力，对hive处理的效率影响比较大，可以合并map和reduce产生的文件。

· hive.merge.mapfiles = true是否和并 Map 输出文件，默认为 True
· hive.merge.mapredfiles = false是否合并 Reduce 输出文件，默认为 False
· hive.merge.size.per.task = 256*1000*1000合并文件的大小

4、in/exists（not）
通过left semi join 实现 in操作，一个限制就是join右边的表只能出现在join条件中

5、分区裁剪
通过在条件中指定分区，来限制数据扫描的范围，可以极大提高查询的效率。

6、排序
order by 排序，只存在一个reduce，这样效率比较低。
可以用sort by操作,通常结合distribute by使用做reduce分区键
7、数据倾斜
其实地2点已经讲到了数据倾斜，但是在此还是想再深化一下数据倾斜。
大数据不怕大就怕倾斜，一旦数据倾斜了，相当于用一台机器或者少量的几台机器完成大量任务，完全没有发挥分布式的优势。

数据倾斜就是由于数据分布不均匀，数据大量集中到一点上，造成数据热点。大多数情况下，分为一下三种情况：

map端执行比较快，reduce执行很慢，因为partition造成的数据倾斜。
某些reduce很快，某些reduce很慢，也是因为partition造成的数据倾斜。
某些map执行很快，某些map执行很慢，这是因为数据本身的分布的不合理性造成的。

造成上面reduce和map任务运行很缓慢本质上就两种情况：

第一：reduce缓慢是因为partition造成滴；
第二：map端缓慢是因为数据本身的分布不合理性。

下面介绍map缓慢和reduce缓慢

Reduce端缓慢：两个table的join操作会造成数据倾斜，会造成reduce缓慢，这个相对比较好解决，我们不是有三种解决join性能的方案吗？mapjoin，common join，smbJoin可以解决数据倾斜。另外，有些情况下造成的reduce缓慢无法解决，因为数据本身也不是服从均匀分布。大多数还是高斯分布。
reduce性能本质上是由于groupby操作导致的，而count(distinct)内部本质也是有groupby实现

map端缓慢：这种情况是由于每条数据的相对位置造成的。有两种方案：

第一：设置在map端聚合，set hive.map.aggr=true 可以减小压力(默认开启)
第二：可以set hive.groupby.skewindata=true(默认关闭)，此时hive的执行在MR后台会存在两个map一个reduce，第一个map本质上就是先对数据进行shuffle，第二个map就可以对shuffle之后的数据进行操作。