全方位揭秘！大数据从0到1的完美落地之Hive企业级调优

Hive企业级调优

调优原则已经在MR优化阶段已经有核心描述,优化Hive可以按照MR的优化思路来执行

优化的主要考虑方面:

环境方面：服务器的配置、容器的配置、环境搭建
具体软件配置参数：
代码级别的优化

调优的主要原则:

20/80原则非常重要,简单的说80%的程序时间执行时间花费在20%的代码上,所以重点就先要找到这关键的20%代码做重点优化.

explain和explain extended

explain ：只有对hql语句的解释。
explain extended：对hql语句的解释，以及抽象表达式树的生成。

当执行上面两个语句时.一般会分为多个stage

stage 相当于一个job，一个stage可以是limit、也可以是一个子查询、也可以是group by等。
Hive默认一次只执行一个stage，但是如果stage之间没有相互依赖，将可以并行执行。
任务越复杂，hql代码越复杂，stage越多，运行的时间一般越长。

explain代码测试:

explain select * from text1;
explain extended select * from text1;explain extended
select
d.deptno as deptno,
d.dname as dname
from dept d
union all
select
d.dname as dname,
d.deptno as deptno
from dept d;

Join优化

Hive的查询永远是小表(结果集)驱动大表(结果集)
Hive中的on的条件只能是等值连接
注意:Hive是否配置普通join转换成map端join、以及MapJoin小表文件大小的阀值

limit的优化

Limit语句是大家经常使用到的，经常使用CLI的用户都会使用到。不过，在很多情况下Limit语句还是需要执行整个查询语句，然后再返回部分结果的。因为这种情况通常是浪费的，所以应该尽可能地避免出现这种情况。Hive 有一个配置属性可以开启，当使用Limit语句时，其可以对源数据进行抽样:

hive> set hive.limit.optimize.enable=false  (如果limit较多时建议开启)
hive> set hive.limit.row.max.size=100000
hive> set hive.limit.optimize.limit.file=10
hive> set hive.limit.optimize.fetch.max=50000

本地模式

大多数的Hadoop Job是需要Hadoop提供的完整的可扩展性来处理大数据集的。不过，有时Hive的输入数据量是非常小的。在这种情况下，为查询触发执行任务的时间消耗可能会比实际job的执行时间要多得多。对于大多数这种情况，Hive 可以通过本地模式在单台机器上(或某些时候在单个进程中)处理所有的任务。对于小数据集，执行时间可以明显被缩短。用户可以按照如下这个例子中所演示的方式，在执行过程中临时启用本地模式

当一个job满足如下条件才能真正使用本地模式：

job的输入数据大小必须小于参数：hive.exec.mode.local.auto.inputbytes.max(默认128MB)
job的map数必须小于参数：hive.exec.mode.local.auto.tasks.max(默认4)
job的reduce数必须为0或者1

hive> set hive.exec.mode.local.auto=true
hive> set hive.exec.mode.local.auto.inputbytes.max=134217728
hive> set hive.exec.mode.local.auto.input.files.max=4

并行执行

Hive会将一个查询转化成一一个或者多个阶段。这样的阶段可以是MapReduce阶段、抽祥阶段、合并阶段、limit 阶段，或者Hive执行过程中可能需要的其他阶段。默认情况下，Hive一次只会执行一个阶段。

不过，某个特定的job可能包含众多的阶段，而这些阶段可能并非完全互相依赖的，也就是说有些阶段是可以并行执行的，这样可能使得整个job的执行时间缩短。不过，如果有更多的阶段可以并行执行，那么job可能就越快完成。
通过设置参数hive.exec.parallel值为true,就可以开启并发执行。不过在共享集群中，需要注意下，如果job中并行执行的阶段增多，那么集群利用率就会增加:

hive> set hive.exec.parallel=false   (建议开启)
hive> set hive.exec.parallel.thread.number=8

严格模式

Hive提供了一个严格模式，可以防止用户执行那些可能产生意想不到的不好的影响的查询。
通过设置属性hive.mapred.mode值为strict 可以禁止3种类型的查询。

其一，对于分区表，除非WHEHRE语句中含有分区字段过滤条件来限制数据范围,否则不允许执行。换句话说，就是用户不允许扫描所有分区。进行这个限制的原因是，通常分区表都拥有非常大的数据集，而且数据增加迅速。没有进行分区限制的查询可能会消耗令人不可接受的巨大资源来处理这个表

其二，对于使用了ORDER BY语句的查询，要求必须使用LIMIT语句。因为ORDER BY为了执行排序过程会将所有的结果数据分发到同一个reducer 中进行处理，强制要求用户增加这个LIMIT语句可以防止reducer额外执行很长一段时间.

其三，也就是最后一种情况，就是限制笛卡尔积的查询。对关系型数据库非常了解的用户可能期望在执行JOIN查询的时候不使用ON语句而是使用WHERE语句，这样关系型数据库的执行优化器就可以高效地将WHERE语句转化成那个ON语句。不幸的是，Hive并不会执行这种优化，因此，如果表足够大，那么这个查询就会出现不可控的情况,下面是系统中默认的严格模式要求:

hive> set hive.mapred.mode=nonstrict
Cartesian Product.
No partition being picked up for a query.
Orderby without limit.
Comparing bigints and strings.
Comparing bigints and doubles.

mapper和reducer的个数

Hive通过将查询划分成一个或者多个MapReduce任务达到并行的目的。每个任务都可能具有多个mapper和reducer任务，其中至少有一些是可以并行执行的。确定最佳的mapper个数和reducer个数取决于多个变量，例如输人的数据量大小以及对这些数据执行的操作类型等。
保持平衡性是有必要的。如果有太多的mapper 或reducer 任务，就会导致启动阶段、调度和运行job过程中产生过多的开销;而如果设置的数量太少，那么就可能没有充分利用好集群内在的并行性.

不是mapper和reducer个数越多越好，也不是越少越好。

手动设置：
set mapred.map.tasks=2;reducer的个数(自动决定和手动设置)：
hive> set mapred.reduce.tasks=-1
hive> set hive.exec.reducers.max=1009

配置jvm重用

JVM重用是Hadoop调优参数的内容，其对Hive的性能具有非常大的影响，特别是对于很难避免小文件的场景或task特别多的场景，这类场景大多数执行时间都很短。
Hadoop的默认配置通常是使用派生JVM来执行map和reduce任务的。这时JVM的启动过程可能会造成相当大的开销，尤其是执行的job包含有成百上千个task任务的情况。
JVM重用可以使得JVM实例在同一个job中重新使用N次。N的值可以在Hadoop的
mapred-site.xml文件(位于HADOOP_HOME/conf目录下)中进行设置:

<property><name>mapred.job.reuse.jvm.num.tasks</name><value>10</value><description>How many tasks to run per jvm. If set to -1，there is nolimit.</description>
</property>

这个功能的一个缺点是，开启JVM重用将会一直占用使用到的task资源，以便进行重用，直到任务完成后才能释放。如果某个“不平衡的"的job中有某几个reduce task执行的时间要比其他reduce task 消耗的时间多得多的话，那么保留的插槽就会一直空闲着却无法被其他的job使用，直到所有的task 都结束了才会释放.

hive> set mapreduce.job.jvm.numtasks=1
hive> set mapred.job.reuse.jvm.num.tasks=1

数据倾斜

数据倾斜：由于key分布不均匀造成的数据向一个方向偏离的现象。譬如每个省的人口数(西藏要比河南少很多),每天的交易数(双十一就巨大)等

造成数据倾斜的几个原因

本身数据就倾斜
join语句容易造成
count(distinct col) 很容易造成倾斜
group by 也可能会造成

解决方法:

找到造成数据倾斜的key，然后再通过hql语句避免。
hive> set hive.map.aggr=true
hive> set hive.groupby.skewindata=false  (建议开启)
hive> set hive.optimize.skewjoin=falseWhether to enable skew join optimization. The algorithm is as follows: At runtime, detect the keys with a large skew. Instead ofprocessing those keys, store them temporarily in an HDFS directory. In a follow-up map-reducejob, process those skewed keys. The same key need not be skewed for all the tables, and so,the follow-up map-reduce job (for the skewed keys) would be much faster, since it would be amap-join.

索引

索引可以用来加快含有GROUP BY语句的查询的计算速度.
Hive从0.8版本后增加一个bitmap的索引实现。bitmap索引一般在指定的列排虫后的值比较小时进行使用.相对于比较新,要评估后才能使用

分区

动态分区INSERT语句可以通过简单的SELECT语句向分区表中创建很多新的分区。这是一个非常强大的功能，不过如果分区的个数非常得多，那么就会在系统中产生大量的输出控制流。对于Hadoop来说，这个种情况并不是常见的使用场景，因此，其通常会一次创建很多的文件，然后会向这些文件中写人大量的数据。

跳出这些框框，Hive可以通过配置限制动态分区插人允许创建的分区数在1000个左右。虽然太多的分区对于表来说并不好，不过，通常还是将这个值设置的更大以便这些查询执行。
具体动态分区细节可以参考动态分区一节进行温习.

推测执行

类似于Hadoop,在Hive中也提供了配置项用来做推测执行,具体要经过严格测试后才能推行.