详解HiveSQL执行筹划

卖不甜枣  金牌会员 | 2024-8-26 08:22:25 | 显示全部楼层 | 阅读模式
打印 上一主题 下一主题
楼主

主题 564|帖子 564|积分 1692

0、前言

Hive SQL的执行筹划描述SQL实际执行的整体表面，通过执行筹划能相识SQL程序在转换成相应计算引擎的执行逻辑，掌握了执行逻辑也就能更好地把握程序出现的瓶颈点，从而能够实现更有针对性的优化。别的还能资助开发者辨认看似等价的SQL其实是不等价的，看似不等价的SQL其实是等价的SQL。可以说执行筹划是打开SQL优化大门的一把钥匙。
要想学SQL执行筹划，就需要学习查看执行筹划的命令：explain，在查询语句的SQL前面加上关键字explain是查看执行筹划的根本方法。
学会explain，能够给我们工作中使用hive带来极大的便利！

一、SQL的执行筹划

Hive提供的执行筹划现在可以查看的信息有以下几种：
命令使用方式阐明
explain查看执行筹划的根本信息
explain dependencydependency在explain语句中使用会产生有关筹划中输入的额外信息。它体现了输入的各种属性
explain authorization查看SQL操纵相关权限的信息
explain vectorization查看SQL的向量化描述信息，体现为什么未对Map和Reduce进行矢量化。从 Hive 2.3.0 开始支持
explain analyze用实际的行数注释筹划。从 Hive 2.2.0 开始支持
explain cbo输出由Calcite优化器天生的筹划。CBO 从 Hive 4.0.0 版本开始支持
explain locks这对于相识体系将得到哪些锁以运行指定的查询很有用。LOCKS 从 Hive 3.2.0 开始支持
explain ast输出查询的抽象语法树。AST 在 Hive 2.1.0 版本删除了，存在bug，转储AST大概会导致OOM错误，将在4.0.0版本修复
explain extended加上 extended 可以输出有关筹划的额外信息。这通常是物理信息，比方文件名，这些额外信息对我们用处不大
二、explain的用法 

Hive提供了explain命令来展示一个查询的执行筹划，这个执行筹划对于我们相识底层原理，Hive 调优，排查数据倾斜等很有资助。
使用语法如下：
  1. explain query;
复制代码
在 hive cli 中输入以下命令(hive 2.3.7)：
  1. explain select sum(id) from test1;
复制代码
 得到结果：
  1. STAGE DEPENDENCIES:
  2.   Stage-1 is a root stage
  3.   Stage-0 depends on stages: Stage-1
  5. STAGE PLANS:
  6.   Stage: Stage-1
  7.     Map Reduce
  8.       Map Operator Tree:
  9.           TableScan
  10.             alias: test1
  11.             Statistics: Num rows: 6 Data size: 75 Basic stats: COMPLETE Column stats: NONE
  12.             Select Operator
  13.               expressions: id (type: int)
  14.               outputColumnNames: id
  15.               Statistics: Num rows: 6 Data size: 75 Basic stats: COMPLETE Column stats: NONE
  16.               Group By Operator
  17.                 aggregations: sum(id)
  18.                 mode: hash
  19.                 outputColumnNames: _col0
  20.                 Statistics: Num rows: 1 Data size: 8 Basic stats: COMPLETE Column stats: NONE
  21.                 Reduce Output Operator
  22.                   sort order:
  23.                   Statistics: Num rows: 1 Data size: 8 Basic stats: COMPLETE Column stats: NONE
  24.                   value expressions: _col0 (type: bigint)
  25.       Reduce Operator Tree:
  26.         Group By Operator
  27.           aggregations: sum(VALUE._col0)
  28.           mode: mergepartial
  29.           outputColumnNames: _col0
  30.           Statistics: Num rows: 1 Data size: 8 Basic stats: COMPLETE Column stats: NONE
  31.           File Output Operator
  32.             compressed: false
  33.             Statistics: Num rows: 1 Data size: 8 Basic stats: COMPLETE Column stats: NONE
  34.             table:
  35.                 input format: org.apache.hadoop.mapred.SequenceFileInputFormat
  36.                 output format: org.apache.hadoop.hive.ql.io.HiveSequenceFileOutputFormat
  37.                 serde: org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe
  39.   Stage: Stage-0
  40.     Fetch Operator
  41.       limit: -1
  42.       Processor Tree:
  43.         ListSink
复制代码
  1. 看完以上内容有什么感受，是不是感觉都看不懂，不要着急，下面将会详细讲解每个参数，相信你学完下面的内容之后再看 explain 的查询结果将游刃有余。
复制代码
  一个HIVE查询被转换为一个由一个或多个stage构成的序列（有向无环图DAG）。这些stage可以是MapReduce stage，也可以是负责元数据存储的stage，也可以是负责文件体系的操纵（比如移动和重定名）的stage。
  我们将上述结果拆分看，先从最外层开始，包含两个大的部分：

  • stage dependencies：各个stage之间的依赖性
  • stage plan：各个stage的执行筹划
先看第一部分 stage dependencies ，包含两个 stage，Stage-1 是根stage，阐明这是开始的stage，Stage-0 依赖 Stage-1，Stage-1执行完成后执行Stage-0。
再看第二部分 stage plan，内里有一个 Map Reduce，一个MR的执行计分别为两个部分：

  • Map Operator Tree：MAP端的执行筹划树
  • Reduce Operator Tree：Reduce端的执行筹划树
这两个执行筹划树内里包含这条sql语句的 operator：
operator类型阐明
TableScan表扫描操纵，map端第一个操纵肯定是加载表，所以就是表扫描操纵，常见的属性：
●alias：表名称
●Statistics：表统计信息，包含表中数据条数，数据大小等
Select Operator选取操纵，常见的属性 ：
●expressions：需要的字段名称及字段类型
●outputColumnNames：输出的列名称
●Statistics：表统计信息，包含表中数据条数，数据大小等
Group By Operator常见的属性：
●aggregations：体现聚合函数信息
●mode：聚合模式，值有 hash：随机聚合，就是hash partition；partial：局部聚合；final：最终聚合
●keys：分组的字段，假如没有分组，则没有此字段
●outputColumnNames：聚合之后输出列名
●Statistics：表统计信息，包含分组聚合之后的数据条数，数据大小等
Reduce Output Operator输出到reduce操纵，常见属性：
●sort order：值为空 不排序；
  ○值为 + 正序排序
  ○值为 - 倒序排序；
  ○值为 +-  排序的列为两列，第一列为正序，第二列为倒序
Filter Operator过滤操纵，常见的属性：
●predicate：过滤条件，如sql语句中的where id>=1，则此处体现(id >= 1)
Map Join Operator●join 操纵，常见的属性：
●condition map：join方式 ，如Inner Join 0 to 1 Left Outer Join0 to
●keys: join 的条件字段
●outputColumnNames：join 完成之后输出的字段
●Statistics：join 完成之后天生的数据条数，大小等
File Output Operator文件输出操纵，常见的属性
●compressed：是否压缩
●table：表的信息，包含输入输出文件格式化方式，序列化方式等
Fetch Operator客户端获取数据操纵，常见的属性：
●limit，值为 -1 表示不限制条数，其他值为限制的条数
2.1 explain的使用场景 

2.1.1 案例一：join 语句会过滤 null 的值吗？

现在，我们在hive cli 输入以下查询筹划语句
  1. select a.id,b.user_name from test1 a join test2 b on a.id=b.id;
复制代码
问：上面这条 join 语句会过滤 id 为 null 的值吗
执行下面语句：
  1. explain select a.id,b.user_name from test1 a join test2 b on a.id=b.id;
复制代码
我们来看结果 (为了适应页面展示，仅截取了部分输出信息)：
  1. TableScan
  2. alias: a
  3. Statistics: Num rows: 6 Data size: 75 Basic stats: COMPLETE Column stats: NONE
  4. Filter Operator
  5.     predicate: id is not null (type: boolean)
  6.     Statistics: Num rows: 6 Data size: 75 Basic stats: COMPLETE Column stats: NONE
  7.     Select Operator
  8.         expressions: id (type: int)
  9.         outputColumnNames: _col0
  10.         Statistics: Num rows: 6 Data size: 75 Basic stats: COMPLETE Column stats: NONE
  11.         HashTable Sink Operator
  12.            keys:
  13.              0 _col0 (type: int)
  14.              1 _col0 (type: int)
  15. ...
复制代码
从上述结果可以看到 predicate: id is not null 如许一行，阐明 join 时会自动过滤掉关联字段为 null 值的环境，但 left join 或 full join 是不会自动过滤null值的，大家可以自行尝试下。
2.1.2 案例二：group by 分组语句会进行排序吗？

看下面这条sql
  1. select id,max(user_name) from test1 group by id;
复制代码
问：group by 分组语句会进行排序吗
直接来看 explain 之后结果 (为了适应页面展示，仅截取了部分输出信息)
  1. TableScan
  2.     alias: test1
  3.     Statistics: Num rows: 9 Data size: 108 Basic stats: COMPLETE Column stats: NONE
  4.     Select Operator
  5.         expressions: id (type: int), user_name (type: string)
  6.         outputColumnNames: id, user_name
  7.         Statistics: Num rows: 9 Data size: 108 Basic stats: COMPLETE Column stats: NONE
  8.         Group By Operator
  9.            aggregations: max(user_name)
  10.            keys: id (type: int)
  11.            mode: hash
  12.            outputColumnNames: _col0, _col1
  13.            Statistics: Num rows: 9 Data size: 108 Basic stats: COMPLETE Column stats: NONE
  14.            Reduce Output Operator
  15.              key expressions: _col0 (type: int)
  16.              sort order: +
  17.              Map-reduce partition columns: _col0 (type: int)
  18.              Statistics: Num rows: 9 Data size: 108 Basic stats: COMPLETE Column stats: NONE
  19.              value expressions: _col1 (type: string)
  20. ...
复制代码
我们看 Group By Operator，内里有 keys: id (type: int) 阐明按照 id 进行分组的，再往下看还有 sort order: + ，阐明是按照 id 字段进行正序排序的。
2.1.3 案例三：哪条sql执行效率高呢？

观察两条sql语句:
  1. SELECT
  2. a.id,
  3. b.user_name
  4. FROM
  5. test1 a
  6. JOIN test2 b ON a.id = b.id
  7. WHERE
  8. a.id > 2;
复制代码
  1. SELECT
  2. a.id,
  3. b.user_name
  4. FROM
  5. (SELECT * FROM test1 WHERE id > 2) a
  6. JOIN test2 b ON a.id = b.id;
复制代码
这两条sql语句输出的结果是一样的，但是哪条sql执行效率高呢？
有人说第一条sql执行效率高，因为第二条sql有子查询，子查询会影响性能；
有人说第二条sql执行效率高，因为先过滤之后，在进行join时的条数淘汰了，所以执行效率就高了。
到底哪条sql效率高呢，我们直接在sql语句前面加上 explain，看下执行筹划不就知道了嘛！
在第一条sql语句前加上 explain，得到如下结果：
  1. hive (default)> explain select a.id,b.user_name from test1 a join test2 b on a.id=b.id where a.id >2;
  2. OK
  3. Explain
  4. STAGE DEPENDENCIES:
  5.   Stage-4 is a root stage
  6.   Stage-3 depends on stages: Stage-4
  7.   Stage-0 depends on stages: Stage-3
  9. STAGE PLANS:
  10.   Stage: Stage-4
  11.     Map Reduce Local Work
  12.       Alias -> Map Local Tables:
  13.         $hdt$_0:a
  14.           Fetch Operator
  15.             limit: -1
  16.       Alias -> Map Local Operator Tree:
  17.         $hdt$_0:a
  18.           TableScan
  19.             alias: a
  20.             Statistics: Num rows: 6 Data size: 75 Basic stats: COMPLETE Column stats: NONE
  21.             Filter Operator
  22.               predicate: (id > 2) (type: boolean)
  23.               Statistics: Num rows: 2 Data size: 25 Basic stats: COMPLETE Column stats: NONE
  24.               Select Operator
  25.                 expressions: id (type: int)
  26.                 outputColumnNames: _col0
  27.                 Statistics: Num rows: 2 Data size: 25 Basic stats: COMPLETE Column stats: NONE
  28.                 HashTable Sink Operator
  29.                   keys:
  30.                     0 _col0 (type: int)
  31.                     1 _col0 (type: int)
  33.   Stage: Stage-3
  34.     Map Reduce
  35.       Map Operator Tree:
  36.           TableScan
  37.             alias: b
  38.             Statistics: Num rows: 6 Data size: 75 Basic stats: COMPLETE Column stats: NONE
  39.             Filter Operator
  40.               predicate: (id > 2) (type: boolean)
  41.               Statistics: Num rows: 2 Data size: 25 Basic stats: COMPLETE Column stats: NONE
  42.               Select Operator
  43.                 expressions: id (type: int), user_name (type: string)
  44.                 outputColumnNames: _col0, _col1
  45.                 Statistics: Num rows: 2 Data size: 25 Basic stats: COMPLETE Column stats: NONE
  46.                 Map Join Operator
  47.                   condition map:
  48.                        Inner Join 0 to 1
  49.                   keys:
  50.                     0 _col0 (type: int)
  51.                     1 _col0 (type: int)
  52.                   outputColumnNames: _col0, _col2
  53.                   Statistics: Num rows: 2 Data size: 27 Basic stats: COMPLETE Column stats: NONE
  54.                   Select Operator
  55.                     expressions: _col0 (type: int), _col2 (type: string)
  56.                     outputColumnNames: _col0, _col1
  57.                     Statistics: Num rows: 2 Data size: 27 Basic stats: COMPLETE Column stats: NONE
  58.                     File Output Operator
  59.                       compressed: false
  60.                       Statistics: Num rows: 2 Data size: 27 Basic stats: COMPLETE Column stats: NONE
  61.                       table:
  62.                           input format: org.apache.hadoop.mapred.SequenceFileInputFormat
  63.                           output format: org.apache.hadoop.hive.ql.io.HiveSequenceFileOutputFormat
  64.                           serde: org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe
  65.       Local Work:
  66.         Map Reduce Local Work
  68.   Stage: Stage-0
  69.     Fetch Operator
  70.       limit: -1
  71.       Processor Tree:
  72.         ListSink
复制代码
在第二条sql语句前加上 explain，得到如下结果:
  1. hive (default)> explain select a.id,b.user_name from(select * from  test1 where id>2 ) a join test2 b on a.id=b.id;
  2. OK
  3. Explain
  4. STAGE DEPENDENCIES:
  5.   Stage-4 is a root stage
  6.   Stage-3 depends on stages: Stage-4
  7.   Stage-0 depends on stages: Stage-3
  9. STAGE PLANS:
  10.   Stage: Stage-4
  11.     Map Reduce Local Work
  12.       Alias -> Map Local Tables:
  13.         $hdt$_0:test1
  14.           Fetch Operator
  15.             limit: -1
  16.       Alias -> Map Local Operator Tree:
  17.         $hdt$_0:test1
  18.           TableScan
  19.             alias: test1
  20.             Statistics: Num rows: 6 Data size: 75 Basic stats: COMPLETE Column stats: NONE
  21.             Filter Operator
  22.               predicate: (id > 2) (type: boolean)
  23.               Statistics: Num rows: 2 Data size: 25 Basic stats: COMPLETE Column stats: NONE
  24.               Select Operator
  25.                 expressions: id (type: int)
  26.                 outputColumnNames: _col0
  27.                 Statistics: Num rows: 2 Data size: 25 Basic stats: COMPLETE Column stats: NONE
  28.                 HashTable Sink Operator
  29.                   keys:
  30.                     0 _col0 (type: int)
  31.                     1 _col0 (type: int)
  33.   Stage: Stage-3
  34.     Map Reduce
  35.       Map Operator Tree:
  36.           TableScan
  37.             alias: b
  38.             Statistics: Num rows: 6 Data size: 75 Basic stats: COMPLETE Column stats: NONE
  39.             Filter Operator
  40.               predicate: (id > 2) (type: boolean)
  41.               Statistics: Num rows: 2 Data size: 25 Basic stats: COMPLETE Column stats: NONE
  42.               Select Operator
  43.                 expressions: id (type: int), user_name (type: string)
  44.                 outputColumnNames: _col0, _col1
  45.                 Statistics: Num rows: 2 Data size: 25 Basic stats: COMPLETE Column stats: NONE
  46.                 Map Join Operator
  47.                   condition map:
  48.                        Inner Join 0 to 1
  49.                   keys:
  50.                     0 _col0 (type: int)
  51.                     1 _col0 (type: int)
  52.                   outputColumnNames: _col0, _col2
  53.                   Statistics: Num rows: 2 Data size: 27 Basic stats: COMPLETE Column stats: NONE
  54.                   Select Operator
  55.                     expressions: _col0 (type: int), _col2 (type: string)
  56.                     outputColumnNames: _col0, _col1
  57.                     Statistics: Num rows: 2 Data size: 27 Basic stats: COMPLETE Column stats: NONE
  58.                     File Output Operator
  59.                       compressed: false
  60.                       Statistics: Num rows: 2 Data size: 27 Basic stats: COMPLETE Column stats: NONE
  61.                       table:
  62.                           input format: org.apache.hadoop.mapred.SequenceFileInputFormat
  63.                           output format: org.apache.hadoop.hive.ql.io.HiveSequenceFileOutputFormat
  64.                           serde: org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe
  65.       Local Work:
  66.         Map Reduce Local Work
  68.   Stage: Stage-0
  69.     Fetch Operator
  70.       limit: -1
  71.       Processor Tree:
  72.         ListSink
复制代码
  1. 大家有什么发现，除了表别名不一样，其他的执行计划完全一样，都是先进行 where 条件过滤，在进行 join 条件关联。<strong>说明 hive 底层会自动帮我们进行优化，所以这两条sql语句执行效率是一样的</strong>。
复制代码
2.1.4  定位产生数据倾斜的代码段

数据倾斜大多数都是大 key 问题导致的。怎样判定是大 key 导致的问题，可以通过下面方法：
1. 通逾期间判定
假如某个 reduce 的时间比其他 reduce 时间长的多，如下图，大部分 task 在 1 分钟之内完成，只有 r_000000 这个 task 执行 20 多分钟了还没完成。

注意：要清除两种环境：

  • 假如每个 reduce 执行时间差不多，都特别长，不一定是数据倾斜导致的，大概是 reduce 设置过少导致的。
  • 偶尔候，某个 task 执行的节点大概有问题，导致任务跑的特别慢。这个时候，mapreduce 的推测执行，会重启一个任务。假如新的任务在很短时间内能完成，通常则是由于 task 执行节点问题导致的个别 task 慢。但是假如推测执行后的 task 执行任务也特别慢，那更阐明该 task 大概会有倾斜问题。
2. 通过任务 Counter 判定
Counter 会记录整个 job 以及每个 task 的统计信息。counter 的 url 一样平常类似：
   http://bd001:8088/proxy/application_1624419433039_1569885/mapreduce/singletaskcounter/task_1624419433039_1569885_r_000000/org.apache.hadoop.mapreduce.FileSystemCounter
  通过输入记录数，普通的 task counter 如下，输入的记录数是 13 亿多：


而 task=000000 的 counter 如下，其输入记录数是 230 多亿。是其他任务的 100 多倍：

 定位 SQL 代码
1. 确定任务卡住的 stage


  • 通过 jobname 确定 stage：
    一样平常 Hive 默认的 jobname 名称会带上 stage 阶段，如下通过 jobname 看到任务卡住的为 Stage-4：



  • 假如 jobname 是自定义的，那大概没法通过 jobname 判定 stage。需要借助于任务日志：
    找到执行特别慢的那个 task，然后 Ctrl+F 搜索 “CommonJoinOperator: JOIN struct” 。Hive 在 join 的时候，会把 join 的 key 打印到日志中。如下：

上图中的关键信息是：struct<_col0:string, _col1:string, _col3:string>
这时候，需要参考该 SQL 的执行筹划。通过参考执行筹划，可以断定该阶段为 Stage-4 阶段：
 

 2. 确定 SQL 执行代码
确定了执行阶段，即 Stage-4 阶段。通过执行筹划，则可以判定出是执行哪段代码时出现了倾斜。还是从此图，这个 Stage-4 阶段中进行连接操纵的表别名是 d：

就可以推测出是在执行下面红框中代码时出现了数据倾斜，因为这行的表的别名是 d：

2.2 explain dependency的用法

explain dependency用于描述一段SQL需要的数据泉源，输出是一个json格式的数据，内里包含以下两个部分的内容：


  • input_partitions：描述一段SQL依赖的数据泉源表分区，内里存储的是分区名的列表，假如整段SQL包含的全部表都是非分区表，则体现为空。
  • input_tables：描述一段SQL依赖的数据泉源表，内里存储的是Hive表名的列表。
 使用explain dependency查看SQL查询非分区普通表，在 hive cli 中输入以下命令：
  1. explain dependency select s_age,count(1) num from student_orc;
复制代码
得到结果：
  1. {
  2.     "input_partitions": [],
  3.     "input_tables": [
  4.         {
  5.             "tablename": "default@student_tb _orc",
  6.             "tabletype": "MANAGED_TABLE"
  7.         }
  8.     ]
  9. }
复制代码
使用explain dependency查看SQL查询分区表，在 hive cli 中输入以下命令：
  1. explain dependency select s_age,count(1) num from student_orc_partition;
复制代码
 得到结果：
  1. {"input_partitions":[{"partitionName":"default@student_orc_partition@ part=0"},
  2. {"partitionName":"default@student_orc_partition@part=1"},
  3. {"partitionName":"default@student_orc_partition@part=2"},
  4. {"partitionName":"default@student_orc_partition@part=3"},
  5. {"partitionName":"default@student_orc_partition@part=4"},
  6. {"partitionName":"default@student_orc_partition@part=5"},
  7. {"partitionName":"default@student_orc_partition@part=6"},
  8. {"partitionName":"default@student_orc_partition@part=7"},
  9. {"partitionName":"default@student_orc_partition@part=8"},
  10. {"partitionName":"default@student_orc_partition@part=9"}],
  11. "input_tables":[{"tablename":"default@student_orc_partition", "tabletype":"MANAGED_TABLE"}]
复制代码
explain dependency的使用场景有两个：


  • 场景一：快速清除。快速清除因为读取不到相应分区的数据而导致任务数据输出异常。比方，在一个以天分区的任务中，上游任务因为生产过程不可控因素出现异常大概空跑，导致下游任务引发异常。通过这种方式，可以快速查看SQL读取的分区是否出现异常。
  • 场景二：理清表的输入，资助明白程序的运行，特别是有助于明白有多重子查询，多表连接的依赖输入。
下面通过两个案例来看explain dependency的实际运用：
2.2.1 案例一：辨认看似等价的代码

对于刚接触SQL的程序员，很轻易将
   select * from a inner join b on a.no=b.no and a.f>1 and a.f<3;
  等价于
   select * from a inner join b on a.no=b.no where a.f>1 and a.f<3;
  我们可以通过案例来查看下它们的区别：
代码1：
  1. select
  2. a.s_no
  3. from student_orc_partition a
  4. inner join
  5. student_orc_partition_only b
  6. on a.s_no=b.s_no and a.part=b.part and a.part>=1 and a.part<=2;
复制代码
代码2：
  1. select
  2. a.s_no
  3. from student_orc_partition a
  4. inner join
  5. student_orc_partition_only b
  6. on a.s_no=b.s_no and a.part=b.part
  7. where a.part>=1 and a.part<=2;
复制代码
我们看下上述两段代码explain dependency的输出结果：
代码1的explain dependency结果：
  1. {"input_partitions":
  2. [{"partitionName":"default@student_orc_partition@part=1"},
  3. {"partitionName":"default@student_orc_partition@part=2"},
  4. {"partitionName":"default@student_orc_partition_only@part=0"},
  5. {"partitionName":"default@student_orc_partition_only@part=1"},
  6. {"partitionName":"default@student_orc_partition_only@part=2"}],
  7. "input_tables": [{"tablename":"default@student_orc_partition","tabletype":"MANAGED_TABLE"}, {"tablename":"default@student_orc_partition_only","tabletype":"MANAGED_TABLE"}]}
复制代码
代码2的explain dependency结果：
  1. {"input_partitions":
  2. [{"partitionName":"default@student_orc_partition@part=1"},
  3. {"partitionName" : "default@student_orc_partition@part=2"},
  4. {"partitionName" :"default@student_orc_partition_only@part=1"},
  5. {"partitionName":"default@student_orc_partition_only@part=2"}],
  6. "input_tables": [{"tablename":"default@student_orc_partition","tabletype":"MANAGED_TABLE"}, {"tablename":"default@student_orc_partition_only","tabletype":"MANAGED_TABLE"}]}
复制代码
  1. 通过上面的输出结果可以看到，其实上述的两个SQL并不等价，代码1在内连接（inner join）中的连接条件（on）中加入非等值的过滤条件后，并没有将内连接的右表按照过滤条件进行过滤，内连接在执行时会多读取part=0的分区数据。而在代码2中，会过滤掉不符合条件的分区。
复制代码
2.2.2 案例二：辨认SQL读取数据范围的差别

代码1：
  1. explain dependency
  2. select
  3. a.s_no
  4. from student_orc_partition a
  5. left join
  6. student_orc_partition_only b
  7. on a.s_no=b.s_no and a.part=b.part and b.part>=1 and b.part<=2;
复制代码
代码2：
  1. explain dependency
  2. select
  3. a.s_no
  4. from student_orc_partition a
  5. left join
  6. student_orc_partition_only b
  7. on a.s_no=b.s_no and a.part=b.part and a.part>=1 and a.part<=2;
复制代码
以上两个代码的数据读取范围是一样的吗？答案是不一样，我们通过explain dependency来看下：
代码1的explain dependency结果：
  1. {"input_partitions":
  2. [{"partitionName": "default@student_orc_partition@part=0"},
  3. {"partitionName":"default@student_orc_partition@part=1"}, …中间省略7个分区
  4. {"partitionName":"default@student_orc_partition@part=9"},
  5. {"partitionName":"default@student_orc_partition_only@part=1"},
  6. {"partitionName":"default@student_orc_partition_only@part=2"}],
  7. "input_tables": [{"tablename":"default@student_orc_partition","tabletype":"MANAGED_TABLE"}, {"tablename":"default@student_orc_partition_only","tabletype":"MANAGED_TABLE"}]}
复制代码
代码2的explain dependency结果：
  1. {"input_partitions":
  2. [{"partitionName":"default@student_orc_partition@part=0"},
  3. {"partitionName":"default@student_orc_partition@part=1"}, …中间省略7个分区
  4. {"partitionName":"default@student_orc_partition@part=9"},
  5. {"partitionName":"default@student_orc_partition_only@part=0"},
  6. {"partitionName":"default@student_orc_partition_only@part=1"}, …中间省略7个分区
  7. {"partitionName":"default@student_orc_partition_only@part=9"}],
  8. "input_tables": [{"tablename":"default@student_orc_partition","tabletype":"MANAGED_TABLE"}, {"tablename":"default@student_orc_partition_only","tabletype":"MANAGED_TABLE"}]}
复制代码
可以看到，对左外连接在连接条件中到场非等值过滤的条件，假如过滤条件是作用于右表（b表）有起到过滤的效果，则右表只要扫描两个分区即可，但是左表（a表）会进行全表扫描。假如过滤条件是针对左表，则完全没有起到过滤的作用，那么两个表将进行全表扫描。这时的环境就如同全外连接一样都需要对两个数据进行全表扫描。
在使用过程中，轻易认为代码片段2可以像代码片段1一样进行数据过滤，通过查看explain dependency的输出结果，可以知道不是如此。
2.3 explain authorization 的用法

通过explain authorization可以知道当前SQL访问的数据泉源（INPUTS） 和数据输出（OUTPUTS），以及当前Hive的访问用户 （CURRENT_USER）和操纵（OPERATION）。
在 hive cli 中输入以下命令：
  1. explain authorization
  2. select variance(s_score) from student_tb_orc;
复制代码
结果如下：
  1. INPUTS:
  2.   default@student_tb_orc
  3. OUTPUTS:
  4.   hdfs://node01:8020/tmp/hive/hdfs/cbf182a5-8258-4157-9194- 90f1475a3ed5/-mr-10000
  5. CURRENT_USER:
  6.   hdfs
  7. OPERATION:
  8.   QUERY
  9. AUTHORIZATION_FAILURES:
  10.   No privilege 'Select' found for inputs { database:default, table:student_ tb_orc, columnName:s_score}
复制代码
从上面的信息可知：
上面案例的数据泉源是defalut数据库中的 student_tb_orc表；
数据的输出路径是hdfs://node01:8020/tmp/hive/hdfs/cbf182a5-8258-4157-9194-90f1475a3ed5/-mr-10000;
当前的操纵用户是hdfs，操纵是查询；
观察上面的信息我们还会看到AUTHORIZATION_FAILURES信息，提示对当前的输入没有查询权限，但假如运行上面的SQL的话也能够正常运行。为什么会出现这种环境？Hive在默认不配置权限管理的环境下不进行权限验证，全部的用户在Hive内里都是超等管理员，即使不对特定的用户进行赋权，也能够正常查询。
[code][/code]   参考资料：
  1.wx公众号(五分钟学大数据)-《万字长文详解HiveSQL执行筹划》
   


免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
回复

使用道具 举报

0 个回复

倒序浏览
返回列表

快速回复

高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

卖不甜枣

金牌会员
这个人很懒什么都没写!

楼主热帖

标签云

挺好的 服务器
微信订阅号
微信服务号
微信客服
小程序
H5
关于我们 商务合作 网站地图
©Copyright 2022-2024 杭州祥升科技有限公司 版权所有 浙ICP备20004199号
快速回复 返回顶部 返回列表