Hive优化补充（十六）

1. 限制调整

LIMIT语句是经常使用到的，不过在执行时，还是需要执行整个查询语句，然后再返回部分结果。这种情况是十分浪费计算资源的，应该尽可能地避免。Hive有一个配置属性可以开启，当使用LIMIT语句时，其可以对源数据进行抽象：

<name>hive.limit.optimize.enable</name>
<value>true</value>

一旦属性hive.limit.optimize.enable的值设置为true，那么还会有两个参数可以控制这个操作：

<name>hive.limit.row.max.size</name>
<value>100000</value>

<name>hive.limit.optimize.limit.file</name>
<value>10</value>

这个功能的一个缺点就是，有可能输入中有用的数据永远不会被处理到。例如：join，group by操作，以及聚合函数大多数调用，等等，将会产生很不同的结果。也许这个差异在很多情况下是可以接受的，可以灵活使用。

2. 列裁剪和分区裁剪

所谓列裁剪就是在查询时只读取需要的列，分区裁剪就是只读取需要的分区。以我们的日历记录表为例：
当列很多或者数据量很大时，如果select *或者不指定分区，全列扫描和全表扫描效率都很低。

3. 谓词下推

将SQL语句中的where谓词逻辑都尽可能提前执行，减少下游处理的数据量。

对forum_topic做过滤的where语句写在子查询内部，而不是外部。

4. sort by代替order by

HiveSQL中的order by与其他SQL的功能一样，就是将结果按某字段全局排序，这会导致所有map端数据都进入一个reducer中，在数据量大时可能会长时间计算不完。如果使用sort by，那么还是会视情况启动多个reducer进行排序，并且保证每个reducer内局部有序。

5. group by配置调整

5.1 map端调整

在执行group by时，如果先起一个combiner在map端做部分预聚合，可以有效减少shuffle数据量。预聚合的配置项是hive.map.aggr，默认值true，对应的优化器为GroupByOptimizer，简单方便。
通过hive.groupby.mapaggr.checkinterval参数也可以设置map端预聚合的行数阈值，超过该值就会分拆job，默认值100000。

5.2 倾斜均衡配置项

在执行group by时，如果某些key对应的数据量过大，就会发生数据倾斜。Hive自带了一个均衡数据倾斜的配置项hive.groupby.skewindata，默认值false。
其实现方法是在group by时启动两个MR job。第一个job会将map端数据随机输入reducer，每个reducer做部分聚合，相同的key就会分布在不同的reducer中。第二个job再将前面预处理过的数据按key聚合并输出结果，这样就起到了均衡的效果。

6. MapReduce优化

6.1 调整mapper数

mapper数量与输入文件的split数息息相关，如果输入文件是少量大文件，就减少mapper数；如果输入文件是大量非小文件，就增大mapper数。

6.2 调整reducer数

如果reducer数太多，会产生大量小文件，对HDFS造成压力。如果reducer数太少，每个reducer要处理很多数据，容易拖慢运行时间或者造成OOM

7. 严格模式

所谓严格模式，就是强制不允许用户执行3种有风险的HiveSQL语句，一旦执行会直接失败。这3种语句是：

• 查询分区表时不限定分区列的语句；
• 两表join产生了笛卡尔积的语句；
• 用order by来排序但没有指定limit的语句。

8. 推测执行

推测执行是Hadoop中的一个功能，其可以触发执行一些重复的任务，尽管这样会因对重复的数据进行计算而导致消耗更多的计算资源，不过这个功能的目标是通过加快获取单个task的结果以及进行侦测将执行慢的TaskTracker加入到黑名单的方式来提高整体的任务执行效率。

<name>mapred.reduce.tasks.speculative.execution</name>
<value>true</value>

如果用户对于运行时的偏差非常敏感的话，就不需要这个功能。