「干货」Hive调优的六板斧！你是否全部掌握？『Hive系列4』

解决痛点：仅仅几行SQL代码为什么运行这么慢？本篇文章带你揭开调优面纱。

00

序言

本篇文章为Hive系列的第四篇，之前三篇内容，感兴趣的同学可以戳蓝字部分：

第一篇：Hive常用函数及避坑点汇总

第二篇：Hive常用十大应用技巧

第三篇：Hive运行原理详解

本篇将接着第三篇文章，在了解Hive运行原理的基础上，分享一些「Hive调优的技巧」。根据侧重点，可以划分为两大方面：代码调优、运行调优。以下将从这两个方面进行展开。

01

代码调优

第一板斧：代码中最好不用Select *

原因：在原表量级很大且字段数很多的情况下，应用Select * 会输出很多无效的字段，占用处理资源，造成资源浪费。

建议：筛选所需的字段，Select A, B, C。

第二板斧：代码中需要对空值做处理

基于Hive运行原理，相同Key的数据会在同一个Reduce中进行处理。如果Key的空值量级较大，在遇到Join等操作时，会使得空值全部集中在一个Reduce中，导致内存不足，效率极低。针对这种情况，可以在码代码时做一些处理。

空值的处理也分为两种情况：空值无需输出、空值需要输出，具体处理方式如下图：

02

运行调优

第三板斧：设置合理的Map/Reduce数量

上篇文章中，小火龙和大家分享过Hive的实现原理。那么是否Map和Reduce数量是多多益善呢？答案肯定是否定的。

Map数量：主要通过输入文件的大小、数量来决定。如果在输入时有很多小文件，会导致Map数量过多，从而引起初始化时间大大增加，造成资源浪费。

Reduce数量：Reduce数量同样需要设置在合理的范围内，如果不特意指定数量，Hive会给予一个推测数量。过多的Reduce数量，同样会造成资源浪费。

那么可以通过哪些参数来调整Map/Reduce的数量呢？如下图：

第四板斧：设置并行执行

Hive查询是通过多个阶段执行的，如果阶段不是相互依赖，是可以并行实现的，从而提高运行效率。通过设置以下参数来实现：

set hive.exec.parallel=true; --打开任务并行执行，默认为false。

set hive.exec.parallel.thread.number=16; --单SQL最大并行度，默认为8。

这里有一点需要大家注意，并行的前提是在资源有空闲的情况下才可行的，如果资源紧张，即便设置了参数，也无法实现。

第五板斧：设置严格模式

严格模式，主要是Hive为了预防安全性行为而设置的限制条件。主要涵盖以下两点：

第一点：分区表查询必须指定分区。很多分区表拥有大量数据，少则上千万、多则上亿，如不限制分区，会使得查询资源消耗巨大，甚至带崩整个集群。

设置参数：set hive.strict.checks.no.partition.filter=true; --开启限制（默认为False）。

第二点：Order by应用必须增加Limit。Order by执行排序，会将所有数据分发到一个Reduce中进行执行，有些平台会强行加上Limit条件，以防运行时间过久。

设置参数：set hive.strict.checks.orderby.no.limit=true; --开启限制（默认为False）。

第六板斧：代码性能分析

在运行SQL代码时，有时希望拆解下代码运行的顺序及性能，这时可以在代码前加上Explain进行分析，格式如下：

查询语句执行情况：explain select * from tmp;

查询语句详细执行情况：explain extended select * from tmp;