3.11-3.14 Hive 企业使用优化2

一、查看HQL执行计划explain

1、explain

hive在执行的时候会把所对应的SQL语句都会转换成mapreduce代码执行，但是具体的MR执行信息我们怎样才能看出来呢？
这里就用到了explain的关键字，他可详细的表示出在执行所对应的语句所对应的MR代码。
语法格式如下。extended关键字可以更加详细的列举出代码的执行过程。

Hive提供了一个EXPLAIN显示查询执行计划的命令。该语句的语法如下：
EXPLAIN [EXTENDED|CBO|AST|DEPENDENCY|AUTHORIZATION|LOCKS|VECTORIZATION|ANALYZE] query

explain会把查询语句转化成阶段组成的序列，主要由三方面组成：
*查询的抽象语法树
*计划的不同阶段之间的依赖关系
*每个阶段的描述

2、使用

#explain基本使用
hive (default)> explain select * from emp;
OK
Explain
STAGE DEPENDENCIES:
  Stage-0 is a root stage

STAGE PLANS:
  Stage: Stage-0
    Fetch Operator
      limit: -1
      Processor Tree:
        TableScan
          alias: emp
          Statistics: Num rows: 2 Data size: 659 Basic stats: COMPLETE Column stats: NONE
          Select Operator
            expressions: empno (type: int), ename (type: string), job (type: string), mgr (type: int), hiredate (type: string), sal (type: double), comm (type: double), deptno (type: int)
            outputColumnNames: _col0, _col1, _col2, _col3, _col4, _col5, _col6, _col7
            Statistics: Num rows: 2 Data size: 659 Basic stats: COMPLETE Column stats: NONE
            ListSink

Time taken: 0.063 seconds, Fetched: 17 row(s)

二、并行执行

1、

hive会将一个查询转化为一个或多个阶段，包括：MapReduce阶段、抽样阶段、合并阶段、limit阶段等。
默认情况下，一次只执行一个阶段。 不过，如果某些阶段不是互相依赖，是可以并行执行的。

set hive.exec.parallel=true,可以开启并发执行。
set hive.exec.parallel.thread.number=15;     //同一个sql允许最大并行度，默认为8，一般10-20之间。

并行执行是在系统资源比较空闲的时候才有优势，否则，没资源，并行也起不来。

三、JVM重用

JVM重用是hadoop调优参数的内容，对hive的性能具有非常大的影响，特别是对于很难避免小文件的场景或者task特别多的场景，
这类场景大多数执行时间都很短。hadoop默认配置是使用派生JVM来执行map和reduce任务的，这是jvm的启动过程可能会造成相当大的开销，
尤其是执行的job包含有成千上万个task任务的情况。     JVM重用可以使得JVM实例在同一个JOB中重新使用N次，N的值可以在Hadoop的mapre-site.xml文件中进行设置      mapred.job.reuse.jvm.num.tasks   也可在hive的执行设置：     set  mapred.job.reuse.jvm.num.tasks=8;  #此值一般不超过9    JVM的一个缺点是，开启JVM重用将会一直占用使用到的task插槽，以便进行重用，直到任务完成后才能释放。
如果某个“不平衡“的job中有几个reduce task 执行的时间要比其他reduce task消耗的时间多得多的话，那么保留的插槽
就会一直空闲着却无法被其他的job使用，直到所有的task都结束了才会释放。

四、map、Reduce数目

1、map数目

map数量：
  算法

    MapTask的个数=输入文件总大小/分片尺寸，个人理解就是输出的文件数量

         原因：系统对输入的源文件依照Block的尺寸分片，并在执行Job时安排一个Map Task处理一个Block的

    或者由mapred.map.task数量决定，但是如果这个参数不合理的话，会失效

    小文件不分片

    压缩文件无法被切分

######优化建议########

优化原因
：
    map数量过少则导致并发度减小，job过长；若大量作业，则会堵塞；

减小map数量：合并小文件（hive0.7之后会自动合并） ，是优化的策略

map阶段会输出过多小文件，而初始化和创建map的开销很大，在 block 数据量偏少的情况下，单个任务运行的时间就少，
那么任务开启的开销很可 能占据总开销的大量比例
；

如果已知数据源中小文件过多，用户最好在向新表导入数据之前就打开automerge 开关，使一个 Task 处理多个 block。
因为同属一个 Task 的结果将被返回在同一个文件中，因此导入数据时做任务的合并处理可达到小文件合并效果。
然后关闭automerge 开关，今后都不用再对该表开启
；

除了检查 block 的大小，还可以通过在 4040 端口查看任务第一阶段 Tasks 的数量和每Task 的运行时间判断是否
需要 automerge

第一阶段的 Task 负责 Map 端任务，默认每个Task 对应一个 block，所以如果第一阶段 Task 过多而且单个执行时间短，
表示小体积 block 多，Task 运行效率低，需要启用 automerge。注意，不建议为每个线程安排过多的 block。
在调整相关参数时注意，所设计的下限要尽量保证单个 Task 的处理时间不要低于 2s，调 整的上线不能使对应的；

合并之后的大小最好控制在 256M以内，能实现较好的性能（这只是个参 考值，具体情况需根据实际数据量和列数而定）

查看实际运行时 GC的状况，如果大部分 Tasks的 GC时间占Task运行时间的 15%以内，可以合并的更多一些。
GC时间可以在 4040界面观察  ；

查看每个Task的执行时间，最好不要超过２分钟。如果太长，很可能 会产生 GC问题和拖尾效应，
即某个 Task过长而导致的整体运行时间 过长。这时应适当增加 Task
；

选取 automerge参数时，在设计下限的时候，尽量保证单个 Task 的处理时间不要低于 2s

增加map数量：上一个job的reduce

2、reduce数目

##reduce数量
过少：如果数据量很大，会导致这个reduce异常的慢，从而导致这个任务不能结束，也有可能会OOM

过多：产生的小文件太多，合并起来代价太高，namenode的内存占用也会增大。如果我们不指定mapred.reduce.tasks，
hive会自动计算需要多少个reducer
；

由map端数据复制到Reduce端的数据大小决定；

有很多任务是没有reduce的过程的
；

可以通过设置mapred.reduce.task来控制reduce数
；

Hive的估计机制很弱，不指定reducer个数的情况下，Hive会猜测确定一个reducer个数，基于以下两个设定：

    1. hive.exec.reducers.bytes.per.reducer（默认为1000^3）

        这个参数控制一个job会有多少个reducer来处理，依据的是输入文件的总大小。默认1GB

    2. hive.exec.reducers.max（默认为999）

        如果 input / bytes per reduce > max  则会启动这个参数所指定的reduce个数。  这个并不会影响mapre.reduce.tasks参数的设置

计算reducer数的公式很简单：N=min(参数2，总输入数据量/参数1)

通常情况下，有必要手动指定reducer个数。考虑到map阶段的输出数据量通常会比输入有大幅减少，因此即使不设定reducer个数，重设参数2还是必要的。依据Hadoop的经验，可以将参数2设定为0.95*(集群中TaskTracker个数)

通常(不是绝对)，大表 JOIN或者 GROUPBY后，产生的数据量相对原始数据小很多。这时可以减少后面 ReduceTask的数目，使 Reduce Task的启动 更有价值

针对 GROUP BY、JOIN、INRTERSACT、EXCEPT、EXTRACT 这五个操作，改变两个 Task数目比例分别对应的语句：

    SEThive.groupby.aggregateratio=0.6;

    SEThive.join.aggregateratio=1.0;

    SEThive.intersect.aggregateratio=1.0;

    SEThive.except.aggregateratio=1.0;

    SEThive.extract.aggregateratio=1.0;

小文件过多时参数设置：

set ngmr.partition.automerge=true;
set ngmr.partition.mergesize.mb=-1

   合并以后每个task最多处理的数据量大小，-1表示关闭该参数

   默认8M；优先级大于ngmr.partition;mergesize

   设置一个Block大小，单位MB，-1默认不执行

   可以根据任务设置大小，比如200、300等

set ngmr.partition.mergesize=3;

   表示将 n 个 block 安排给单个线程处理
；
   参数3代表当前3个tasks合并成一个task
；
   可以根据需要仅设置这两个参数（mergesize.mb）其中之一，默认使用方法 mergesize.mb来控制
；
   如果需要使用方法 mergesize，需要将 mergesize.mb 设为-1。

五、推测执行

在分布式集群环境下，因为程序Bug（包括Hadoop本身的bug），负载不均衡或者资源分布不均等原因，会造成同一个作业的多个任务之间运行速度不一致，
有些任务的运行速度可能明显慢于其他任务（比如一个作业的某个任务进度只有50%，而其他所有任务已经运行完毕），则这些任务会拖慢作业的整体执行进度。
为了避免这种情况发生，Hadoop采用了推测执行（Speculative Execution）机制，它根据一定的法则推测出“拖后腿”的任务，并为这样的任务启动一个备份任务，
让该任务与原始任务同时处理同一份数据，并最终选用最先成功运行完成任务的计算结果作为最终结果。

关于调优这些推测执行变量，还很难给一个具体的建议。如果用户对于运行时的偏差非常敏感的话，那么可以将这些功能开启。

如果用户因为输入数据量很大而需要执行长时间的map或者Reduce task的话，那么启动推测执行造成的浪费是非常巨大大。

mapreduce.map.speculative        true
hive.mapred.reduce.tasks.speculative.execution        true
mapreduce.reduce.speculative    true

六、动态分区调整

往hive分区表中插入数据时，如果需要创建的分区很多，比如以表中某个字段进行分区存储，则需要复制粘贴修改很多sql去执行，效率低。
(比如按天进行分区，一天一个，......太多了)
因为hive是批处理系统，所以hive提供了一个动态分区功能，其可以基于查询参数的位置去推断分区的名称，从而建立分区。

-动态分区属性：设置为true表示开启动态分区功能（默认为false）
hive.exec.dynamic.partition=true;

-动态分区属性：设置为nonstrict，表示允许所有分区都是动态的（默认为strict）
-设置为strict，表示必须保证至少有一个分区是静态的
hive.exec.dynamic.partition.mode=strict;

-动态分区属性；每个mapper 或reducer可以创建的最大动态分区个数
hive.exec.max.dynamic.partitions.pernode=100;

-动态分区属性：一个动态分区创建语句可以创建的最大动态分区个数
hive.exec.max.dynamic.partitions=1000;

-动态分区属性：全局可以创建的最大文件个数
hive.exec.max.created.files=100000;

尽量不要用动态分区，因为动态分区的时候，将会为每一个分区分配reducer数量，当分区数量多的时候，
reducer数量将会增加，对服务器是一种灾难。

七、严格模式(strict mode)

对分区表进行查询，在where子句中没有加分区过滤的话，将禁止提交任务（默认：nonstrict）

set hive.mapred.mode=strict;

注：使用严格模式可以禁止3种类型的查询：
（1）对于分区表，不加分区字段过滤条件，不能执行
（2）对于order by 语句，必须使用limit语句。
（3）限制笛卡尔积的查询（join的时候不使用on，而使用where的）。