Hive的企业优化

傷城~ 2022-11-20 08:02 137阅读 0赞

### 目录 ###

*   *  一、Hive企业优化之Fetch Task讲解
     *  二、Hive企业优化之执行计划讲解
     *  三、Hive企业优化之表拆分方案讲解
     *  四、Hive企业优化之外部分区表优化方案
     *  五、Hive企业优化之SQL优化
     *  六、Hive企业优化之Job并行度
     *  七、Hive企业优化之推测执行及JVM重用
     *  八、Hive企业优化之Strict Mode
     *  九、Hive企业优化之join优化方案
     *  十、Hive企业优化之数据倾斜解决方案
     *  十一、Hive企业优化之limit优化

## 一、Hive企业优化之Fetch Task讲解 ##

hive.fetch.task.conversion

Fetch 抓取是指，Hive 中对某些情况的查询可以不必使用 MapReduce 计算。启用 MapReduce Job 是会消耗系统开销的。对于这个问题，从 Hive0.10.0 版本开始，对于简单的不需要聚合的类似 `select <col> from <table> limit n`语句，不需要起 MapReduce job，直接通过 Fetch task 获取数据。

比如：select \* from user\_table;在这种情况下，Hive 可以简单地读取 user\_table 对应的存储目录下的文件，然后输出查询结果到控制台。

在 hive-default.xml.template 文件中hive.fetch.task.conversion默认是 more，老版本 hive 默认是 minimal，该属性修改为 more 以后，在全局查找、字段查找、limit 查找等都不走 MapReduce。

>>none:所有的语句都走MR
    
    >>minimal:
            select *  ;
            select * from order where day ='20180910';
            select * from order limit 5;
    如以上查询方式都不会执行mapreduce程序
    
    >>more:
    		select *,select column...
    如以上查询方式都不会执行mapreduce程序

<property>
        <name>hive.fetch.task.conversion</name>
        <value>more</value>
        <description>
          Expects one of [none, minimal, more].
          Some select queries can be converted to single FETCH task minimizing latency.
          Currently the query should be single sourced not having any subquery and should not have
          any aggregations or distincts (which incurs RS), lateral views and joins.
          0. none : disable hive.fetch.task.conversion
          1. minimal : SELECT STAR, FILTER on partition columns, LIMIT only
          2. more    : SELECT, FILTER, LIMIT only (support TABLESAMPLE and virtual columns)
        </description>
    </property>

## 二、Hive企业优化之执行计划讲解 ##

EXPLAIN [EXTENDED|DEPENDENCY|AUTHORIZATION|LOCKS|VECTORIZATION] query

不跑MapReduce的情况执行计划

explain select * from order;

Explain
    STAGE DEPENDENCIES:
      Stage-0 is a root stage
    
    STAGE PLANS:
      Stage: Stage-0
        Fetch Operator
          limit: -1
          Processor Tree:
            TableScan
              alias: order
              Statistics: Num rows: 1 Data size: 346 Basic stats: COMPLETE Column stats: NONE
              Select Operator
                expressions: userid (type: string), username (type: string), order_date (type: string), product_name (type: string), price (type: int), city (type: string)
                outputColumnNames: _col0, _col1, _col2, _col3, _col4, _col5
                Statistics: Num rows: 1 Data size: 346 Basic stats: COMPLETE Column stats: NONE
                ListSink

group by执行计划如下:

explain select count(1) city_nun,city from order group by city;

Explain
    STAGE DEPENDENCIES:
      Stage-1 is a root stage
      Stage-0 depends on stages: Stage-1
    
    STAGE PLANS:
    
      Stage: Stage-1
      
        Map Reduce
          Map Operator Tree:
              TableScan
                alias: order
                Statistics: Num rows: 3 Data size: 346 Basic stats: COMPLETE Column stats: NONE
                Select Operator
                  expressions: city (type: string)
                  outputColumnNames: city
                  Statistics: Num rows: 3 Data size: 346 Basic stats: COMPLETE Column stats: NONE
                  Group By Operator
                    aggregations: count(1)
                    keys: city (type: string)
                    mode: hash
                    outputColumnNames: _col0, _col1
                    Statistics: Num rows: 3 Data size: 346 Basic stats: COMPLETE Column stats: NONE
                    Reduce Output Operator
                      key expressions: _col0 (type: string)
                      sort order: +
                      Map-reduce partition columns: _col0 (type: string)
                      Statistics: Num rows: 3 Data size: 346 Basic stats: COMPLETE Column stats: NONE
                      value expressions: _col1 (type: bigint)
          Reduce Operator Tree:
            Group By Operator
              aggregations: count(VALUE._col0)
              keys: KEY._col0 (type: string)
              mode: mergepartial
              outputColumnNames: _col0, _col1
              Statistics: Num rows: 1 Data size: 115 Basic stats: COMPLETE Column stats: NONE
              Select Operator
                expressions: _col1 (type: bigint), _col0 (type: string)
                outputColumnNames: _col0, _col1
                Statistics: Num rows: 1 Data size: 115 Basic stats: COMPLETE Column stats: NONE
                File Output Operator
                  compressed: false
                  Statistics: Num rows: 1 Data size: 115 Basic stats: COMPLETE Column stats: NONE
                  table:
                      input format: org.apache.hadoop.mapred.TextInputFormat
                      output format: org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat
                      serde: org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe
    
      Stage: Stage-0
        Fetch Operator
          limit: -1
          Processor Tree:
            ListSink

## 三、Hive企业优化之表拆分方案讲解 ##

在实际应用中，根据我们的业务需求会将部分的大表拆分成多个小表。

1）大表拆分小表：
    
       源数据  ——>  拆分（中间表） ->  轻量分析
    
    2）抽取共性数据到中间表
     
       select * from (select * from a,b,c where a.id = b.id and b.id = c.id)
    
       共性提取（中间表）：select * from a,b,c where a.id = b.id and b.id = c.id

方案一：对一个大表，根据不同的业务，拆分成多个小表，做业务分析。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70_pic_center]  
方案二：可以将之前每部分的业务表共性的数据提取出来组成一个中间表  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70_pic_center 1]  
方案三：如果不同的业务都需要一个大表中的共同的几个数据字段，那么可以先提取一个公共数据  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70_pic_center 2]

## 四、Hive企业优化之外部分区表优化方案 ##

在实际的应用中：
      >>外部表和分区表结合使用
      >>多级分区   partition(yean = '2018',month='09',day='01')
    
      合并输入结果方式一：
      select count(1) from order where day = '01'
      UNION ALL
      select count(1) from order where day = '02'
    
      合并输入结果方式二：
      [-getmerge [-nl] <src> <localdst>]

## 五、Hive企业优化之SQL优化 ##

1.数据格式和压缩

>>数据存储格式:textFile、orcFile、parquet
      >>数据压缩：snappy
    
      大数据平台:CDH

2.SQL语句

注重SQL执行的性能

3.reduce number

根据业务数据量多次测试得出合适的number

## 六、Hive企业优化之Job并行度 ##

**在实际应用中，复杂的hive sql语句在执行的过程中会有多个job,如果说在这些个job中，没有相互依赖关系的job我们可以设定让他们并行执行**

如图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70_pic_center 3]  
job-1、job-3、job-4、job-6有相互依赖的关系，job-2、job-5和其他没有相互依赖的关系，那么没有相互依赖关系的job我们可以设定让他们并行执行。

<property>
        <name>hive.exec.parallel</name>
        <value>false</value>
        <description>Whether to execute jobs in parallel</description>
      </property>
    
      <property>
        <name>hive.exec.parallel.thread.number</name>
        <value>8</value>
        <description>How many jobs at most can be executed in parallel</description>
      </property>

set hive.exec.parallel = true;		 //打开任务并行执行
     set hive.exec.parallel.thread.number=8;  //同一个sql允许最大并行度，默认为8。

首先测试不设置并行度：

select count(1) from order group by username union all select count(1) from order group by city;

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70_pic_center 4]  
它有3个job，在不设置并行度的情况下，他们是依次执行MR程序。

再测试设置了并行度的情况：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70_pic_center 5]  
由此可以看出stage-1和stage-3并行执行，查看执行计划，stage-2依赖于stage-1和stage-3。  
![在这里插入图片描述][20201027182244426.png_pic_center]

## 七、Hive企业优化之推测执行及JVM重用 ##

**1.jvm重用**  
当job提交到Yarn之后，每个job中的map任务或者reduce任务，都会分配一个container容器，map或者reduce任务的执行的资源由container提供,每个map任务或者reduce任务执行开始前都要初始化container，任务执行完成之后要销毁container。如果我们采用jvm重用，那么每一个任务执行完成之后，不需要销毁容器，container直接接受新的map任务或者reduce任务。

mapreduce.job.jvm.numtasks  默认值：1 （不重用）  >1 重用  建议值：3或者5 不要超过8

**2.推测执行**  
当某一个map任务或者reduce任务执行时间过长，并一直没有完成，这个时候MR会对这个任务进行推测执行，也就是MR认为这个任务有问题，需要发送到其他的节点上重新执行，任务执行结果以最快完成的那个节点为准。在hive的配置中，MR默认推测执行。

在实际的企业应用中，推测执行会被关闭

set hive.mapred.reduce.tasks.speculative.execution = false; (建议设为false)

<property>
        <name>hive.mapred.reduce.tasks.speculative.execution</name>
        <value>true</value>
        <description>Whether speculative execution for reducers should be turned on. </description>
    </property>

## 八、Hive企业优化之Strict Mode ##

**strict mode（严格检查模式）**

在生产环境中，我们一般会将strict mode设置为严格检查模式。

set hive.mapred.mode = strict;

<property>
      <name>hive.mapred.mode</name>
      <value>nonstrict</value>
      <description>
        The mode in which the Hive operations are being performed. 
        In strict mode, some risky queries are not allowed to run. They include:
          Cartesian Product.
          No partition being picked up for a query.
          Comparing bigints and strings.
          Comparing bigints and doubles.
          Orderby without limit.
      </description>
    </property>

使用严格检查模式可以禁止3中类型的查询：

1.对分区表的查询，如果不加分区字段的过滤，不能被执行；

正常情况下，分区表要加分区字段过滤
       select * from order where day = '09'(一定要加分区字段过滤)

2.对于order by 查询，必须要加limit语句的限制。如果不加会被禁止执行。

正常情况下：
       select * from order order by price limit 10;

3.限制笛卡尔积的查询(两个表的链接，如果不用join,而用where连接，会被禁止执行)

select * from a,b where a.id = b.id ;(这种方式被禁止执行)
    
       select * from a left join b on a.id = b.id(尽可能用这种方式)

## 九、Hive企业优化之join优化方案 ##

1.map join

场景：小表与大表的join，将小表数据加载到内存中。然后在map端完成与大表数据的join

setup()
      map()
      cleaup()

2.reduce join/shuffle join/common join

两个表的数据作为map端的输入，在reduce端进行相同key的value值合并。

cumtomer表和order表，根据两个表的连接字段userid进行合并<userid,List(customer + order表)>

场景：两个表的数据量都比较大的时候，我们会采用shuffle join。

关于MR的join表，详细请看这篇文章  
[https://blog.csdn.net/weixin\_45366499/article/details/109137735][https_blog.csdn.net_weixin_45366499_article_details_109137735]

3.SMB join (Sort-Merge-Bucket)优化

SMB 存在的目的主要是为了解决大表与大表间的 Join 问题，分桶其实就是把大表化成了“小表”，然后 Map-Side Join 解决之，这是典型的分而治之的思想

customer表       userid字段
     (bucket -1 ) 0001 ---- 0009   
     (bucket -2 ) 0010 -----0020
     (bucket -3 ) 0021 -----0030   
    
    
                  order表        userid字段
     (bucket -1 ) 0001 ---- 0009   
     (bucket -2 ) 0010 -----0020
     (bucket -3 ) 0021 -----0030

set hive.auto.convert.sortmerge.join=true;
    set hive.optimize.bucketmapjoin = true;
    set hive.optimize.bucketmapjoin.sortedmerge = true;

## 十、Hive企业优化之数据倾斜解决方案 ##

**数据倾斜：一般的是由于数据的分布不均匀，造成大量的数据集中到一点，造成数据的热点。**

1.哪些情况下会发生数据倾斜：

1).数据在节点上分布不均匀
    
       block   ->  map  (5M)
       block   ->  map  (100M)
    
    2).join时，key中存在个别值得数据量比较大(比如null值)group  
    
       select * from a left join b on a.id =  b.id  
    
    3)count(distinct key)  在数据量大的情况下，也是容易出现数据倾斜。因为distinct的时候，也是按照group by 字段进行分组

2.针对以上的数据倾斜，我们有哪些措施或者解决方案：

1)针对group by的情况
    
     >>>在map端进行部分数据的合并
    
      默认是true,也就是在map端进行合并
    
        <property>
    	    <name>hive.map.aggr</name>
    	    <value>true</value>
    	    <description>Whether to use map-side aggregation in Hive Group By queries</description>
    	</property>
    
    	<property>
    	    <name>hive.groupby.mapaggr.checkinterval</name>
    	    <value>100000</value>
    	    <description>Number of rows after which size of the grouping keys/aggregation classes is performed</description>
    	</property>
    
    
     >>> 负载均衡
        
        第一个mr job中，首先会将map输出的结果随机分布到reduce中，每个reduce做部分聚合操作并输出结果。这样的话结果相同的
        group by key 有可能被分发到不同的reduce中，从而达到负载均衡的目的。
    
        第二个mr job中，会根据每个reduce预处理的结果完成最终的聚合操作
    
       
    	  <property>
    	    <name>hive.groupby.skewindata</name>
    	    <value>false</value>
    	    <description>Whether there is skew in data to optimize group by queries</description>
    	  </property>
    
        set hive.groupby.skewindata = true;
        当设置为true时，会变成两个MapReduce.
        默认是false,不负载均衡。
    
    2)针对count(distinct xx)  
    
      当xx字段存在大量的某个值是，比如null或者空记录时，容易数据倾斜
    
      解决思路：
    
           对于特定的值，我们选择特定的处理方式：
    
           比如null,要么通过where 条件过滤掉；要么重新设置一个新的值，但这个值不影响数据分析

## 十一、Hive企业优化之limit优化 ##

在时候select查询的时候通常会和limit一起使用。通常情况下使用limit是将所有的数据全部加载一遍，然后再从缓存的结果中去取其中几条，这样对于大量数据来操作会非常消耗性能，这里可以设置一个参数来优化一下，设置过之后就不需要全部加载，而是直接从HDFS文件中选几条数据

hive (db_hive)> select * from order limit 5;

<property>
      <name>hive.limit.optimize.enable</name>
      <value>false</value>
      <description>Whether to enable to optimization to trying a smaller subset of data for simple LIMIT first.</description>
    </property>

实际应用中，会设置为

set hive.limit.optimize.enable = true;

--------------------

以上内容仅供参考学习，如有侵权请联系我删除！  
如果这篇文章对您有帮助，左下角的大拇指就是对博主最大的鼓励。  
您的鼓励就是博主最大的动力！

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70_pic_center]: /images/20221120/d9710fd8fb2b4cb8982ff0a3d0f78774.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221120/14fcdd669aa641fd864740d426d3fbe5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221120/1d9de9887e14487796e4082914b3820e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70_pic_center 3]: https://img-blog.csdnimg.cn/20201027181555413.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70_pic_center 4]: https://img-blog.csdnimg.cn/20201027181920467.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70_pic_center 5]: https://img-blog.csdnimg.cn/20201027182110546.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ==,size_16,color_FFFFFF,t_70#pic_center
[20201027182244426.png_pic_center]: https://img-blog.csdnimg.cn/20201027182244426.png#pic_center
[https_blog.csdn.net_weixin_45366499_article_details_109137735]: https://blog.csdn.net/weixin_45366499/article/details/109137735