【Hive_05】企业调优1（资源配置、explain、join优化）

1、计算资源配置
- 1.1 Yarn资源配置
- 1.2 MapReduce资源配置
2、 Explain查看执行计划（重点）
- 2.1 Explain执行计划概述
- 2.2 基本语法
- 2.3 案例实操
3、分组聚合优化
- 3.1 优化说明
- - （1）map-side 聚合相关的参数
- 3.2 优化案例
4、join优化
- 4.1 Join算法概述
- - （1）Common Join
  - （2）Map Join
  - （3）Bucket Map Join
  - （4）Sort Merge Bucket Map Join
- 4.2 使用说明
- - （1）map join
  - （2）map join案例
  - （3）Bucket Map Join
  - （4）Bucket Map Join案例
  - （5） Sort Merge Bucket Map Join

关于调优，重要的是理解每一个优化手段的思路。理解优化需要配置的每个参数的实际作用。

1、计算资源配置

计算环境为Hive on MR。计算资源的调整主要包括Yarn和MR。

1.1 Yarn资源配置

1）Yarn配置说明

需要调整的Yarn参数均与CPU、内存等资源有关，核心配置参数如下

（1）yarn.nodemanager.resource.memory-mb

该参数的含义是，一个NodeManager节点分配给Container使用的内存。该参数的配置，取决于NodeManager所在节点的总内存容量和该节点运行的其他服务的数量。
考虑上述因素，此处可将该参数设置为64G，如下：

<property>
    <name>yarn.nodemanager.resource.memory-mb</name>
    <value>65536</value>
</property>

该参数默认使用8G内存去跑任务。
需要手动调整，一般给到总内存的1/2或者2/3。

（2）yarn.nodemanager.resource.cpu-vcores

该参数的含义是，一个NodeManager节点分配给Container使用的CPU核数。该参数的配置，同样取决于NodeManager所在节点的总CPU核数和该节点运行的其他服务。
考虑上述因素，此处可将该参数设置为16。

<property>
    <name>yarn.nodemanager.resource.cpu-vcores</name>
    <value>16</value>
</property>

（3）yarn.scheduler.maximum-allocation-mb

该参数的含义是，单个Container能够使用的最大内存。推荐配置如下：

<property>
    <name>yarn.scheduler.maximum-allocation-mb</name>
    <value>16384</value>
</property>

（4）yarn.scheduler.minimum-allocation-mb

该参数的含义是，单个Container能够使用的最小内存，推荐配置如下：

<property>
    <name>yarn.scheduler.minimum-allocation-mb</name>
    <value>512</value>
</property>

2）Yarn配置实操

（1）修改$HADOOP_HOME/etc/hadoop/yarn-site.xml文件

（2）修改如下参数

<property>
    <name>yarn.nodemanager.resource.memory-mb</name>
    <value>65536</value>
</property>
<property>
    <name>yarn.nodemanager.resource.cpu-vcores</name>
    <value>16</value>
</property>
<property>
    <name>yarn.scheduler.maximum-allocation-mb</name>
    <value>16384</value>
</property>
<property>
    <name>yarn.scheduler.minimum-allocation-mb</name>
    <value>512</value>
</property>

（3）分发该配置文件

（4）重启Yarn。

1.2 MapReduce资源配置

MapReduce资源配置主要包括Map Task的内存和CPU核数，以及Reduce Task的内存和CPU核数。核心配置参数如下：

1）mapreduce.map.memory.mb

该参数的含义是，单个Map Task申请的container容器内存大小，其默认值为1024。该值不能超出yarn.scheduler.maximum-allocation-mb和yarn.scheduler.minimum-allocation-mb规定的范围。

该参数需要根据不同的计算任务单独进行配置，在hive中，可直接使用如下方式为每个SQL语句单独进行配置：

set  mapreduce.map.memory.mb=2048;

2）mapreduce.map.cpu.vcores

该参数的含义是，单个Map Task申请的container容器cpu核数，其默认值为1。该值一般无需调整。

3）mapreduce.reduce.memory.mb

该参数的含义是，单个Reduce Task申请的container容器内存大小，其默认值为1024。该值同样不能超出yarn.scheduler.maximum-allocation-mb和yarn.scheduler.minimum-allocation-mb规定的范围。

该参数需要根据不同的计算任务单独进行配置，在hive中，可直接使用如下方式为每个SQL语句单独进行配置：

set  mapreduce.reduce.memory.mb=2048;

4）mapreduce.reduce.cpu.vcores

该参数的含义是，单个Reduce Task申请的container容器cpu核数，其默认值为1。该值一般无需调整。

2、 Explain查看执行计划（重点）

2.1 Explain执行计划概述

Explain呈现的执行计划，由一系列Stage组成，这一系列Stage具有依赖关系，每个Stage对应一个MapReduce Job，或者一个文件系统操作等。

stage可以对应mr，也可以对应文件系统操作。因为不是所有的sql语句的底层都是mr。比如说load语句，底层就不是mr而是文件系统操作。
有些sql复杂，需要多个mr才能计算，这个时候对应的也就有多个stage，多个stage之间也是有依赖关系的。依赖关系也就表明了哪个mr先执行，哪个后面执行。

若某个Stage对应的一个MapReduce Job，其Map端和Reduce端的计算逻辑分别由Map Operator Tree和Reduce Operator Tree进行描述，Operator Tree由一系列的Operator组成，一个Operator代表在Map或Reduce阶段的一个单一的逻辑操作，例如TableScan Operator，Select Operator，Join Operator等。

下图是由一个执行计划绘制而成：
在这里插入图片描述

常见的Operator及其作用如下：

TableScan：表扫描操作，通常map端第一个操作肯定是表扫描操作
Select Operator：选取操作
Group By Operator：分组聚合操作
Reduce Output Operator：输出到 reduce 操作
Filter Operator：过滤操作，对应sql语句的where或者having
Join Operator：join 操作
File Output Operator：文件输出操作
Fetch Operator 客户端获取数据操作，因为进行查询之后，会把数据写入到hdfs的临时表当中，通过fetch可以展示在终端。

2.2 基本语法

基本语法其实就是在sql的最前面加上explain

EXPLAIN [FORMATTED | EXTENDED | DEPENDENCY] query-sql

注：FORMATTED、EXTENDED、DEPENDENCY关键字为可选项，各自作用如下。

FORMATTED：将执行计划以格式化的JSON字符串的形式输出

在这里插入图片描述

EXTENDED：输出执行计划中的额外信息，通常是读写的文件名等信息
DEPENDENCY：输出执行计划读取的表及分区

在这里插入图片描述

2.3 案例实操

hive (default)> 
explain
select
    user_id,
    count(*)
from order_detail
group by user_id;

在这里插入图片描述

3、分组聚合优化

3.1 优化说明

Hive中未经优化的分组聚合，是通过一个MapReduce Job实现的。Map端负责读取数据，并按照分组字段分区，通过Shuffle，将数据发往Reduce端，各组数据在Reduce端完成最终的聚合运算。

聚合之后数据量不可能变大，但是有可能数据量不变。

Hive对分组聚合的优化主要围绕着减少Shuffle数据量进行，具体做法是map-side聚合。所谓map-side聚合，就是在map端维护一个hash table，利用其完成部分的聚合，然后将部分聚合的结果，按照分组字段分区，发送至reduce端，完成最终的聚合。map-side聚合能有效减少shuffle的数据量，提高分组聚合运算的效率。

（1）map-side 聚合相关的参数

1、启用map-side聚合

set hive.map.aggr=true;

该参数默认是开启的。

2、用于检测源表数据是否适合进行map-side聚合。检测的方法是：先对若干条数据进行map-side聚合，若聚合后的条数和聚合前的条数比值小于该值，则认为该表适合进行map-side聚合；否则，认为该表数据不适合进行map-side聚合，后续数据便不再进行map-side聚合。

set hive.map.aggr.hash.min.reduction=0.5;

如果hive.map.aggr.hash.min.reduction的值为1，则所有的数据不会判断，直接全部进行map端聚合。

3、用于检测源表是否适合map-side聚合的条数。

set hive.groupby.mapaggr.checkinterval=100000;

4、map-side聚合所用的hash table，占用map task堆内存的最大比例，若超出该值，则会对hash table进行一次flush。

set hive.map.aggr.hash.force.flush.memory.threshold=0.9;

3.2 优化案例

select
    product_id,
    count(*)
from order_detail
group by product_id;

1、优化前（跑了46s）

set hive.map.aggr=false;

手动将该参数设置为false
在这里插入图片描述

在这里插入图片描述
2、优化后（跑了46s）

在这里插入图片描述

原因：和product_id的分组字段在这张表上的分布有关，因为hive在进行hive.groupby.mapaggr.checkinterval这个参数的校验时不是随机的去进行校验，只会对每个map的前面一部分数据进行判断。可能恰好前面的数据在进行分组聚合的时候，product_id的值都相同。

在这里插入图片描述

也就是hive判断是否适合分组聚合的不是很智能，这个时候我们可以让其强制进行分组聚合。

set hive.map.aggr.hash.min.reduction=1;

此时时间跑了32秒，比之前快了10秒。

在这里插入图片描述

按道理product_id只有100万数据，为什么这里map端输出的数据会大于100万？原因是因为触发了flush，也就是上面的第四个参数。例如，在flush之前已经有product_id=1的数据了，flush之后会重新用一个hash table，这样product_id可能就会输出多次了。

那么如果flush的次数多了，分组聚合的效果也不会很好，这个时候可以怎么办？
1、调整参数阈值。

set hive.map.aggr.hash.force.flush.memory.threshold=0.9;

2、如果调整之后效果还是不明显，说明hive的总内存小，则可以调整下面这个参数：

set  mapreduce.map.memory.mb=2048;

4、join优化

4.1 Join算法概述

Hive拥有多种join算法，包括Common Join，Map Join，Bucket Map Join，Sort Merge Buckt Map Join等，下面对每种join算法做简要说明：

（1）Common Join

Common Join是Hive中最稳定的join算法，其通过一个MapReduce Job完成一个join操作。Map端负责读取join操作所需表的数据，并按照关联字段进行分区，通过Shuffle，将其发送到Reduce端，相同key的数据在Reduce端完成最终的Join操作。如下图所示：

在这里插入图片描述

如果是A join B join C ，这种时候是使用1个MR还是2个MR呢？
如果join的字段都是相同的，这种时候没有必要使用两个MR，一个MR就够了，如下图所示。
如果join的字段不相同，就不能使用一个MR，因为map分区的字段不同的。这种情况下只能A和B去进行common join，之后在对join之后的中间结果与C表进行另一个common join。

因此，sql语句中的join操作和执行计划中的Common Join任务并非一对一的关系，一个sql语句中的相邻的且关联字段相同的多个join操作可以合并为一个Common Join任务。

例如：

hive (default)> 
select 
    a.val, 
    b.val, 
    c.val 
from a 
join b on (a.key = b.key1) 
join c on (c.key = b.key1)

上述sql语句中两个join操作的关联字段均为b表的key1字段，则该语句中的两个join操作可由一个Common Join任务实现，也就是可通过一个Map Reduce任务实现。

hive (default)> 
select 
    a.val, 
    b.val, 
    c.val 
from a 
join b on (a.key = b.key1) 
join c on (c.key = b.key2)

上述sql语句中的两个join操作关联字段各不相同，则该语句的两个join操作需要各自通过一个Common Join任务实现，也就是通过两个Map Reduce任务实现。

在这里插入图片描述

（2）Map Join

Map Join有两种触发方式，一种是用户在SQL语句中增加hint提示，另外一种是Hive优化器根据参与join表的数据量大小，自动触发。

Map Join算法可以通过两个只有map阶段的Job完成一个join操作。其适用场景为大表join小表。若某join操作满足要求，则第一个job会读取小表数据，将其制作为hash table，并上传至Hadoop 分布式缓存（本质上是上传至HDFS）。第二个job会先从分布式缓存中读取小表数据，并缓存在Map Task 的内存中，然后扫描大表数据，这样在map端即可完成关联操作。如下图所示:

在这里插入图片描述

在map阶段完成join，比在reduce阶段完成join的效率要更高，因为这样可以省去shuffle的时间。
map join核心的点在于：要将小表的数据都缓存到mapper的内存里面，所以map join有瓶颈：不能适用于大表join大表的情况。
但是并不是所有的join都能在map阶段完成，适用场景是：大表join小表。

（3）Bucket Map Join

Bucket Map Join是对Map Join算法的改进，其打破了Map Join只适用于大表join小表的限制，可用于大表join大表的场景。

Bucket Map Join的核心思想是：【要满足下面几个条件】

1、参与join的表均为分桶表
2、关联字段为分桶字段
3、其中一张表的分桶数量是另外一张表分桶数量的整数倍

满足上面三个条件则能保证参与join的两张表的分桶之间具有明确的关联关系，就可以在两表的分桶间进行Map Join操作了。

这样一来，第二个Job的Map端就无需再缓存小表的全表数据了，而只需缓存其所需的分桶即可。其原理如图所示：

在这里插入图片描述

bucket map join和map join的核心原理是一致的，同样是分两个阶段去做，第一个阶段也是要由本地任务去读取相对来说小一点的表的数据，这里读B的数据，之后制作hash表。这里hash表是根据分桶的数据操作的。
有几个桶就会有几个mapper。

（4）Sort Merge Bucket Map Join

Sort Merge Bucket Map Join（简称SMB Map Join）基于Bucket Map Join。SMB Map Join要求，参与join的表均为分桶表，且需保证分桶内的数据是有序的，且分桶字段、排序字段和关联字段为相同字段，且其中一张表的分桶数量是另外一张表分桶数量的整数倍。

SMB Map Join同Bucket Join一样，同样是利用两表各分桶之间的关联关系，在分桶之间进行join操作，不同的是，分桶之间的join操作的实现原理。Bucket Map Join，两个分桶之间的join实现原理为Hash Join算法；而SMB Map Join，两个分桶之间的join实现原理为Sort Merge Join算法。

Hash Join和Sort Merge Join均为关系型数据库中常见的Join实现算法。Hash Join的原理相对简单，就是对参与join的一张表构建hash table，然后扫描另外一张表，然后进行逐行匹配。Sort Merge Join需要在两张按照关联字段排好序的表中进行，其原理如图所示：

在这里插入图片描述

SMB Map Join与Bucket Map Join相比的优势是什么？
1、不需要在制作hash表，分桶在匹配的时候也不需要使用hash表。
2、对内存的要求更低，不需要将桶在放到第二个join的内存当中，因为桶内的数据已经有序了。

Hive中的SMB Map Join就是对两个分桶的数据按照上述思路进行Join操作。可以看出，SMB Map Join与Bucket Map Join相比，在进行Join操作时，Map端是无需对整个Bucket构建hash table，也无需在Map端缓存整个Bucket数据的，每个Mapper只需按顺序逐个key读取两个分桶的数据进行join即可。

4.2 使用说明

（1）map join

Map Join有两种触发方式，一种是用户在SQL语句中增加hint提示，另外一种是Hive优化器根据参与join表的数据量大小，自动触发。

1）Hint提示

用户可通过如下方式，指定通过map join算法，并且ta将作为map join中的小表。这种方式已经过时，不推荐使用。

hive (default)> 
select /*+ mapjoin(ta) */
    ta.id,
    tb.id
from table_a ta
join table_b tb
on ta.id=tb.id;

在这里插入图片描述

2）自动触发

Hive在编译SQL语句阶段，起初所有的join操作均采用Common Join算法实现。

之后在物理优化阶段，Hive会根据每个Common Join任务所需表的大小判断该Common Join任务是否能够转换为Map Join任务，若满足要求，便将Common Join任务自动转换为Map Join任务。

但有些Common Join任务所需的表大小，在SQL的编译阶段是未知的（例如对子查询进行join操作），所以这种Common Join任务是否能转换成Map Join任务在编译阶是无法确定的。

针对这种情况，Hive会在编译阶段生成一个条件任务（Conditional Task），其下会包含一个计划列表，计划列表中包含转换后的Map Join任务以及原有的Common Join任务。
在这里插入图片描述

这个条件任务会包含所有可能的map join任务。
原有的Common Join任务是作为一个后备任务的。

最终具体采用哪个计划，是在运行时决定的。大致思路如下图所示：

在这里插入图片描述

在表已知大小的情况下，就不需要使用这个conditional task了。

在这里插入图片描述
假设现在是a表 join b表

寻找大表候选人阶段：
1、如果是left join，则大表候选人为a表。
2、如果是inner join，则大表候选人为a表和b表。
3、如果是right join，则大表候选人为b表。
4、如果是full join，则这种情况下无法进行map join。因为这时候必须保证返回a和b的全部数据。但是map join的原理是缓存大表，遍历小表，因此无法做到。

在这里插入图片描述

在这里插入图片描述
图中涉及到的参数如下：

1、启动Map Join自动转换

set hive.auto.convert.join=true;

2、一个Common Join operator转为Map Join operator的判断条件,若该Common Join相关的表中,存在n-1张表的已知大小总和<=该值,则生成一个Map Join计划,此时可能存在多种n-1张表的组合均满足该条件,则hive会为每种满足条件的组合均生成一个Map Join计划,同时还会保留原有的Common Join计划作为后备(back up)计划,实际运行时,优先执行Map Join计划，若不能执行成功，则启动Common Join后备计划。

set hive.mapjoin.smalltable.filesize=250000;

3、开启无条件转Map Join

set hive.auto.convert.join.noconditionaltask=true;

4、无条件转Map Join时的小表之和阈值,若一个Common Join operator相关的表中，存在n-1张表的大小总和<=该值,此时hive便不会再为每种n-1张表的组合均生成Map Join计划,同时也不会保留Common Join作为后备计划。而是只生成一个最优的Map Join计划。

set hive.auto.convert.join.noconditionaltask.size=10000000;

（2）map join案例

（1）首先查看下面的sql语句优化前是如何执行的。

在这里插入图片描述

可以看到这是多表join，并且关联的字段是不同的。字段不同，因此是两个common join task。

不进行优化，所以下面这个参数需要关闭，下面这个参数是自动进行map join优化的子开关。

set hive.auto.convert.join=false;

使用explain查看执行计划

在这里插入图片描述

stage1做了什么？

stage1的第一个tablescan

在这里插入图片描述
stage1的第二个tablescan

在这里插入图片描述

stage1的reduce阶段

在这里插入图片描述

stage2做了什么？

在这里插入图片描述

经过上面的分析发现：

我们自己写的sql语句的多表join的顺序，和真正执行计划当中表的join顺序是不同的。hive会选取最小代价的方式进行多表join。

（2）优化思路

进行优化的时候，必须考虑表的大小，不能脱离表的大小去考虑优化思路。

经分析，参与join的三张表，数据量如下

表名	大小
order_detail	1176009934（约1122M）【大表】
product_info	25285707（约24M）【小表】
province_info	369（约0.36K）【小表】

在这里插入图片描述

注：可使用如下语句获取表/分区的大小信息

hive (default)> 
desc formatted table_name partition(partition_col='partition');

通过partition(partition_col=‘partition’)，这个参数，则只会打印’partition这个分区的信息了。

三张表中，product_info和province_info数据量较小，可考虑将其作为小表，进行Map Join优化。

根据前文Common Join任务转Map Join任务的判断逻辑图，可得出以下优化方案：

方案一：（9min41s）

启用Map Join自动转换。

hive (default)> 
set hive.auto.convert.join=true;

不使用无条件转Map Join，因此会产生条件任务。

hive (default)> 
set hive.auto.convert.join.noconditionaltask=false;

调整hive.mapjoin.smalltable.filesize参数，使其大于等于product_info。这样的话可以保证product_info表和province_info表都放到内存里面。

hive (default)> 
set hive.mapjoin.smalltable.filesize=25285707;

这样可保证将两个Common Join operator均可转为Map Join operator，并保留Common Join作为后备计划，保证计算任务的稳定。

在这里插入图片描述
调整优化参数之后再次查看执行计划：

在这里插入图片描述

stage5和stage6是将第三张表和中间结果各自当成大表，生成的执行任务。

将流程图放大如下所示：

在这里插入图片描述

方案二：（4min52s）

启用Map Join自动转换。

hive (default)> 
set hive.auto.convert.join=true;

使用无条件转Map Join。也就是不需要条件任务了。因为我们三张表的大小都知道了，就不需要了。

hive (default)> 
set hive.auto.convert.join.noconditionaltask=true;

没有条件任务之后，就不用再调整hive.mapjoin.smalltable.filesize参数了，而要调整

调整hive.auto.convert.join.noconditionaltask.size参数，使其大于等于product_info和province_info之和。

hive (default)> 
set hive.auto.convert.join.noconditionaltask.size=25286076;

这样可直接将两个Common Join operator转为两个Map Join operator，并且由于两个Map Join operator的小表大小之和小于等于hive.auto.convert.join.noconditionaltask.size，故两个Map Join operator任务可合并为同一个。这个方案计算效率最高，但需要的内存也是最多的。

方案二的执行计划如下图所示，相比于方案一要简洁很多。

在这里插入图片描述

分析：为什么方案二比方案一更快
方案一虽然两个都是map join，但是没有进行合并。方案二不要条件任务，并且在内存充足的情况下，可以将两个map join进行合并，

方案三：（时间和方案一差不多）

启用Map Join自动转换。

hive (default)> 
set hive.auto.convert.join=true;

使用无条件转Map Join。

hive (default)> 
set hive.auto.convert.join.noconditionaltask=true;

调整hive.auto.convert.join.noconditionaltask.size参数，使其等于product_info。

hive (default)> 
set hive.auto.convert.join.noconditionaltask.size=25285707;

这样可直接将两个Common Join operator转为Map Join operator，但不会将两个Map Join的任务合并。该方案计算效率比方案二低，但需要的内存也更少。

在这里插入图片描述

需要注意的是，文件在磁盘当中占用的空间，和加载到内存当中占用空间的大小是不同的。例如：数据从文件当中加载到内存当中需要有一个解序列化的过程，解序列化之后数据会变大的，除此之外，数据来到内存当中，可能会封装成对象，也会有一些额外的开销。这种情况下文件的大小是远小于加载到内存当中的大小的。大小一般是10倍的差距。也就是如果文件是1G的话，内存当中会是10G。

在这里插入图片描述

（3）Bucket Map Join

在MR当中，Bucket Map Join不支持自动转换，发须通过用户在SQL语句中提供如下Hint提示，并配置如下相关参数，方可使用。

1）Hint提示

hive (default)> 
select /*+ mapjoin(ta) */
    ta.id,
    tb.id
from table_a ta
join table_b tb on ta.id=tb.id;

2）相关参数

1、关闭cbo优化，cbo会导致hint信息被忽略

set hive.cbo.enable=false;

2、map join hint默认会被忽略(因为已经过时)，需将如下参数设置为false

set hive.ignore.mapjoin.hint=false;

3、启用bucket map join优化功能

set hive.optimize.bucketmapjoin = true;

（4）Bucket Map Join案例

1）示例SQL

hive (default)> 
select
    *
from(
    select
        *
    from order_detail
    where dt='2020-06-14'
)od
join(
    select
        *
    from payment_detail
    where dt='2020-06-14'
)pd
on od.id=pd.order_detail_id;

2）优化前

上述SQL语句共有两张表一次join操作，故优化前的执行计划应包含一个Common Join任务，通过一个MapReduce Job实现。执行计划如下图所示：

在这里插入图片描述

上面的图使用的是common join

3）优化思路

经分析，参与join的两张表，数据量如下。

表名	大小
order_detail	1176009934（约1122M）
payment_detail	334198480（约319M）

这里的大小是在底层文件的大小，而不是在内存当中的大小。

如果此时使用map join将payment_detail当成小表的话，按照之前的规律，319M*10大于3G，在内存当中需要占用3G多才能缓存小表的Hash表。

因此这个使用考虑使用bucket map join。首先确保这两张表是分桶表，分桶个数成倍数，且两张表的分桶字段需要相同。

首先需要依据源表创建两个分桶表，order_detail建议分16个bucket，payment_detail建议分8个bucket,注意分桶个数的倍数关系以及分桶字段。

–订单表

hive (default)> 
drop table if exists order_detail_bucketed;
create table order_detail_bucketed(
    id           string comment '订单id',
    user_id      string comment '用户id',
    product_id   string comment '商品id',
    province_id  string comment '省份id',
    create_time  string comment '下单时间',
    product_num  int comment '商品件数',
    total_amount decimal(16, 2) comment '下单金额'
)
clustered by (id) into 16 buckets
row format delimited fields terminated by '\t';

–支付表

hive (default)> 
drop table if exists payment_detail_bucketed;
create table payment_detail_bucketed(
    id              string comment '支付id',
    order_detail_id string comment '订单明细id',
    user_id         string comment '用户id',
    payment_time    string comment '支付时间',
    total_amount    decimal(16, 2) comment '支付金额'
)
clustered by (order_detail_id) into 8 buckets
row format delimited fields terminated by '\t';

然后向两个分桶表导入数据。

订单表：

hive (default)> 
insert overwrite table order_detail_bucketed
select
    id,
    user_id,
    product_id,
    province_id,
    create_time,
    product_num,
    total_amount   
from order_detail
where dt='2020-06-14';

分桶表：

hive (default)> 
insert overwrite table payment_detail_bucketed
select
    id,
    order_detail_id,
    user_id,
    payment_time,
    total_amount
from payment_detail
where dt='2020-06-14';

然后设置以下参数：

1、关闭cbo优化，cbo会导致hint信息被忽略，需将如下参数修改为false

set hive.cbo.enable=false;

2、map join hint默认会被忽略(因为已经过时)，需将如下参数修改为false

set hive.ignore.mapjoin.hint=false;

3、启用bucket map join优化功能,默认不启用，需将如下参数修改为true

set hive.optimize.bucketmapjoin = true;

最后在重写SQL语句，如下：

hive (default)> 
select /*+ mapjoin(pd) */
    *
from order_detail_bucketed od
join payment_detail_bucketed pd on od.id = pd.order_detail_id;

优化后的执行计划如图所示：

在这里插入图片描述

上面的图使用的是map join

在这里插入图片描述

（5） Sort Merge Bucket Map Join

Sort Merge Bucket Map Join有两种触发方式，包括Hint提示和自动转换。Hint提示已过时，不推荐使用。

下面是自动转换的相关参数：

1、启动Sort Merge Bucket Map Join优化

set hive.optimize.bucketmapjoin.sortedmerge=true;

2、使用自动转换SMB Join

set hive.auto.convert.sortmerge.join=true;

使用和上一个案例相同的数据（分桶之后多加了一个桶内有序），得到的结果如下图所示：

在这里插入图片描述