hive的优化点，能够提升的效率差异

比较重要是头几个和后几个，尤其是最后两个，性能提升效果是最明显的。但是会同时开启更多的MR任务，这就需要一个平衡了。

嵌套SQL并行执行优化:

set hive.exec.parallel=true;

set hive.exec.parallel.thread.number=16;

效率可提升至少100%

某job需要11个stage：

非并行35分钟

并行8个job执行10分钟

并行16个job执行6分钟

Hive查询的优化：

一、数据量大的表和数据量小的表做关联的时候，把数据量小的表放到join前面去select。

原因是在 Join 操作的 Reduce 阶段，位于 Join 操作符左边的表的内容会被加载进内存，将条目少的表放在左边，可以有效减少发生内存溢出错误的几率。

二、Join优化

Join查找操作中如果存在多个join，且所有参与join的表中其参与join的key都相同，则会将所有的join合并到一个mapred程序中。

例：

SELECT a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key1) 在一个mapre程序中执行join

SELECT a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key2) 在两个mapred程序中执行join

Map join的关键在于join操作中的某个表的数据量很小

例：

SELECT /*+ MAPJOIN(b) */ a.key, a.value FROM a join b on a.key = b.key

三、用sum() group by的方式来替换count(distinct)。

四、排序优化

Order by 实现全局排序，一个reduce实现，效率低

Sort by 实现部分有序，单个reduce输出的结果是有序的，效率高，通常和DISTRIBUTE BY关键字一起使用(DISTRIBUTE BY关键字 可以指定map 到 reduce端的分发key)

CLUSTER BY col1 等价于DISTRIBUTE BY col1 SORT BY col1.

五、合并小文件

文件数目过多，会给 HDFS 带来压力，并且会影响处理效率，可以通过合并 Map 和 Reduce 的结果文件来尽量消除这样的影响

hive.merge.mapfiles = true是否和并 Map 输出文件，默认为 True

hive.merge.mapredfiles = false是否合并 Reduce 输出文件，默认为 False

hive.merge.size.per.task = 25610001000合并文件的大小。

这里的参数没有写到上面的表格里是因为这是可以根据任务不同临时设置的，而不一定非要是全局设置。有时候全局设置了反而对大文件的操作有性能影响。

六、使用分区，RCFile，lzo，ORCFile等

Hive中的每个分区都对应hdfs上的一个目录，分区列也不是表中的一个实际的字段，而是一个或者多个伪列，在表的数据文件中实际上并不保存分区列的信息与数据。Partition关键字中排在前面的为主分区(只有一个)，后面的为副分区

静态分区：静态分区在加载数据和使用时都需要在sql语句中指定

例：(stat_date='20160625',province='hunan')

动态分区：使用动态分区需要设置hive.exec.dynamic.partition参数值为true，默认值为false，在默认情况下，hive会假设主分区时静态分区，副分区使用动态分区;如果想都使用动态分区，需要设置set hive.exec.dynamic.partition.mode=nostrick，默认为strick

例：(stat_date='20160625',province)

七、使用外部表而尽量少用内部表，这主要从数据的安全性上考量。
八、Hive参数优化：

image.png