Hive 性能调优大全

前言
Hive 作为大数据领域常用的数据仓库组件，在平时设计和查询的时候要特别注意效率 。影响 Hive 效率的几乎从不是数据量过大，而是数据倾斜、数据冗余、Job或I/O过多、MapReduce 分配不合理等等。 对Hive 的调优既包含 Hive 的建表设计方面，对 HiveHQL 语句本身的优化，也包含 Hive 配置参数 和 底层引擎 MapReduce 方面的调整 。

为了不盲目地学习，我们需要先知道 Hive 调优的重要性：在保证业务结果不变的前提下，降低资源的使用量，减少任务的执行时间。

调优须知
        在开始之前，需要对下面的“ 注意事项” 有个大致的印象 。

对于大数据计算引擎来说：数据量大不是问题，数据倾斜是个问题。

Hive的复杂HQL底层会转换成多个MapReduce Job并行或者串行执行，Job数比较多的作业运行效率相对比较低，比如即使只有几百行数据的表，如果多次关联多次汇总，产生十几个Job，耗时很长。原因是 MapReduce 作业初始化的时间是比较长的 。

在进行Hive大数据分析时，常见的聚合操作比如 sum，count，max，min，UDAF等 ，不怕数据倾斜问题，MapReduce 在 Mappe阶段 的预聚合操作，使数据倾斜不成问题 。

好的建表设计，模型设计事半功倍。

设置合理的 MapReduce 的 Task 并行度，能有效提升性能。(比如，10w+数据量 级别的计算，用 100 个 reduceTask，那是相当的浪费，1个足够，但是如果是 亿级别的数据量，那么1个Task又显得捉襟见肘)

了解数据分布，自己动手解决数据倾斜问题是个不错的选择。这是通用的算法优化，但算法优化有时不能适应特定业务背景，开发人员了解业务，了解数据，可以通过业务逻辑精确有效地解决数据倾斜问题。

数据量较大的情况下，慎用 count(distinct)，group by 容易产生倾斜问题。

对小文件进行合并，是行之有效地提高调度效率的方法，假如所有的作业设置合理的文件数，对任务的整体调度效率也会产生积极的正向影响 。

优化时把握整体，单个作业最优不如整体最优。

调优具体细节
        好了， 下面正式开始谈论调优过程中的细节。

Hive建表设计层面
        Hive的建表设计层面调优，主要讲的怎么样合理的组织数据，方便后续的高效计算。比如建表的类型，文件存储格式，是否压缩等等。

利用分区表优化

        先来回顾一下 hive 的表类型有哪些？

1、分区表 

2、分桶表

        分区表 是在某一个或者几个维度上对数据进行分类存储，一个分区对应一个目录。如果筛选条件里有分区字段，那么 Hive 只需要遍历对应分区目录下的文件即可，不需要遍历全局数据，使得处理的数据量大大减少，从而提高查询效率 。

        你也可以这样理解：当一个 Hive 表的查询大多数情况下，会根据某一个字段进行筛选时，那么非常适合创建为分区表，该字段即为分区字段。

        举个例子：

select1: select .... where country = "china" 
 
select2: select .... where country = "china" 
 
select3: select .... where country = "china" 
 
select4: select .... where country = "china"