Hive执行计划之hive依赖及权限查询和常见使用场景

这篇具有很好参考价值的文章主要介绍了Hive执行计划之hive依赖及权限查询和常见使用场景。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

目录
  • 概述
  • 1.explain dependency的查询与使用
  • 2.借助explain dependency解决一些常见问题
    • 2.1.识别看似等价的SQL代码实际上是不等价的:
    • 2.2 通过explain dependency验证将过滤条件在不同位置的查询区别
  • 3.查看SQL操作涉及到的相关权限信息

概述

Hive查看执行计划的命令中还有两个不怎么常用但很重要的命令,接下来详细介绍一下。

有一个问题:如何在hiveSQL执行之前就探查到这段逻辑的血缘依赖关系?

hive血缘是很多生产级数仓必须要提供的功能,大多数解决方案都是使用hive hooks的方法通过SQL执行后解析得到hive表的依赖关系

这个方案能细粒度到字段级依赖,属于很完善的一个解决方案,但有很多场景我们需要在SQL执行之前就得到依赖关系,那么如何解决的呢?

1.explain dependency的查询与使用

explain dependency 提供了这样的一个解决方案,它可以查询一段SQL需要的数据来源,以JSON的形式展现结果数据。里面主要包含两部分内容:

  • input_tables:描述一段SQL依赖的数据来源表,里面存储的是hive表名的列表,格式如下:

    {"tablename":"库名@表名","tabletype":"表的类型(外部表/内部表)"}

  • input_partitions:描述一段SQL依赖的数据来源表分区,里面存储的是分区名称的列表,格式如下:

    {"partitionName":"库名@表名@分区列=分区列的值"}

    如果查询的表为非分区表,则显示为空。

可以通过以下例子来进行比对,其中例1是查询非分区普通表SQL的explain dependency,例2是查询分区表SQL的explain dependency。

例1 使用explain dependency查看SQL非分区普通表。

explain dependency
-- 统计年龄小于30岁各个年龄里,昵称里带“小”的人数
select age,count(0) as num from temp.user_info_all_no
where age < 30 and nick like '%小%'
group by age;

输出结果内容:

{"input_tables":[{"tablename":"temp@user_info_all_no","tabletype":"MANAGED_TABLE"}],"input_partitions":[]}

例2 使用explain dependency查看SQL查询分区表。

explain dependency
-- 统计年龄小于30岁各个年龄里,昵称里带“小”的人数,其中ymd字段为分区字段
select age,count(0) as num from temp.user_info_all where ymd >= '20230501'
and age < 30 and nick like '%小%'
group by age;

输出结果内容:

{"input_tables":[{"tablename":"temp@user_info_all","tabletype":"MANAGED_TABLE"}],"input_partitions":[{"partitionName":"temp@user_info_all@ymd=20230501"},{"partitionName":"temp@user_info_all@ymd=20230502"},{"partitionName":"temp@user_info_all@ymd=20230503"},{"partitionName":"temp@user_info_all@ymd=20230504"},{"partitionName":"temp@user_info_all@ymd=20230505"},{"partitionName":"temp@user_info_all@ymd=20230529"}]}

2.借助explain dependency解决一些常见问题

explain dependency的使用场景有以下几个:

场景一,快速排除。快速排除因为读不到相应分区的数据而导致任务数据输出异常。例如,在一个以天为分区的任务中,上游任务因为生产过程不可控因素出现异常或者空跑,导致下游任务引发异常。通过这种方式,可以快速查看SQL读取的分区是否出现异常。

场景二,理清表的输入,帮助理解程序的运行,特别是有助于理解有多重子查询,多表连接的依赖输入。

场景三,提前通过解析hiveSQL脚本进行血缘依赖解析,用于一些定制化数据平台工具开发中的血缘构建。

explain dependency的使用能帮助开发者解决哪些问题呢?

2.1.识别看似等价的SQL代码实际上是不等价的:

对于接触SQL不久的程序员来说,很多人容易将

select * from a left join b on a.no=b.no and a.f>1 and a.f<3;

这段逻辑等价于 select * from a left join b on a.no=b.no where a.f>1 and a.f<3;

这两段的逻辑的区别是在多表left join的时候where 后加条件是否等价与on后面加条件。

我们通过实例来看看其中的区别:

例3 使用explain dependency识别看似等价的SQL代码。

-- 代码1
explain dependency
select a.uid from temp.user_info_all a
left outer join temp.user_act_info b
on a.uid = b.uid and a.ymd = b.ymd and a.ymd >= '20230501' and a.ymd <= '20230502';

-- 代码2
explain dependency
select a.uid from temp.user_info_all a
left outer join temp.user_act_info b
on a.uid = b.uid and a.ymd = b.ymd 
where a.ymd >= '20230501' and a.ymd <= '20230502';

输出结果内容:

// 代码1输出结果
{"input_tables":[{"tablename":"temp@user_info_all","tabletype":"MANAGED_TABLE"},{"tablename":"temp@user_act_info","tabletype":"MANAGED_TABLE"}],"input_partitions":[{"partitionName":"temp@user_info_all@ymd=20230430"},{"partitionName":"temp@user_info_all@ymd=20230501"},{"partitionName":"temp@user_info_all@ymd=20230502"},{"partitionName":"temp@user_info_all@ymd=20230503"},{"partitionName":"temp@user_info_all@ymd=20230504"},{"partitionName":"temp@user_info_all@ymd=20230505"},{"partitionName":"temp@user_info_all@ymd=20230529"},{"partitionName":"temp@user_act_info@ymd=20230501"},{"partitionName":"temp@user_act_info@ymd=20230502"},{"partitionName":"temp@user_act_info@ymd=20230503"},{"partitionName":"temp@user_act_info@ymd=20230606"}]}

// 代码2输出结果
{"input_tables":[{"tablename":"temp@user_info_all","tabletype":"MANAGED_TABLE"},{"tablename":"temp@user_act_info","tabletype":"MANAGED_TABLE"}],"input_partitions":[{"partitionName":"temp@user_info_all@ymd=20230501"},{"partitionName":"temp@user_info_all@ymd=20230502"},{"partitionName":"temp@user_act_info@ymd=20230501"},{"partitionName":"temp@user_act_info@ymd=20230502"}]}

通过以上输出结果可以看出,上面例子里的两段SQL其实并不等价。在left join(left outer join)的连接条件中加入非等值的过滤条件后,这里特指作用于a表,也就是连接的基表,并没有将左外连接的左右两个表按照过滤条件进行过滤,左外连接在执行时会读取所有分区数据,然后进行关联数据过滤操作。

left outer join 针对左表非等值条件on和where查询数据on条件查询数据大于where条件查询数据。

下面查看left outer join对右表的过滤条件实例:

例4 使用explain dependency识别left outer join 右表过滤非等值条件区别

-- 代码1
explain dependency
select a.uid from temp.user_info_all a
left outer join temp.user_act_info b
on a.uid = b.uid and a.ymd = b.ymd and b.ymd >= '20230501' and b.ymd <= '20230502';

-- 代码2
explain dependency
select a.uid from temp.user_info_all a
left outer join temp.user_act_info b
on a.uid = b.uid and a.ymd = b.ymd 
where b.ymd >= '20230501' and b.ymd <= '20230502';

输出结果内容:

// 代码1输出结果,on后跟非等值条件
{"input_tables":[{"tablename":"temp@user_info_all","tabletype":"MANAGED_TABLE"},{"tablename":"temp@user_act_info","tabletype":"MANAGED_TABLE"}],"input_partitions":[{"partitionName":"temp@user_info_all@ymd=20230430"},{"partitionName":"temp@user_info_all@ymd=20230501"},{"partitionName":"temp@user_info_all@ymd=20230502"},{"partitionName":"temp@user_info_all@ymd=20230503"},{"partitionName":"temp@user_info_all@ymd=20230504"},{"partitionName":"temp@user_info_all@ymd=20230505"},{"partitionName":"temp@user_info_all@ymd=20230529"},{"partitionName":"temp@user_act_info@ymd=20230501"},{"partitionName":"temp@user_act_info@ymd=20230502"}]}

// 代码2输出结果,where后跟非等值条件
{"input_tables":[{"tablename":"temp@user_info_all","tabletype":"MANAGED_TABLE"},{"tablename":"temp@user_act_info","tabletype":"MANAGED_TABLE"}],"input_partitions":[{"partitionName":"temp@user_info_all@ymd=20230430"},{"partitionName":"temp@user_info_all@ymd=20230501"},{"partitionName":"temp@user_info_all@ymd=20230502"},{"partitionName":"temp@user_info_all@ymd=20230503"},{"partitionName":"temp@user_info_all@ymd=20230504"},{"partitionName":"temp@user_info_all@ymd=20230505"},{"partitionName":"temp@user_info_all@ymd=20230529"},{"partitionName":"temp@user_act_info@ymd=20230501"},{"partitionName":"temp@user_act_info@ymd=20230502"},{"partitionName":"temp@user_act_info@ymd=20230503"},{"partitionName":"temp@user_act_info@ymd=20230606"}]}

可以看到left outer join 针对右表非等值条件on和where查询数据左表都是全表扫描,右表on条件是条件过滤,where条件是全表扫描。

接下来对inner join,right outer join,full outer join进行测试。会发现

inner join 的类似针对左右表非等值条件on和where查询数据是等价的。

right outer join和left join相反。

full outer join都是全表扫描。

那么可以很好的判断出一下两段SQL的过滤条件数据读取范围是完全不一样的。就不贴执行结果了。

例5 left outer join下的对左表和右表不等值条件过滤。

-- 代码1
explain dependency
select a.uid from temp.user_info_all a
left outer join temp.user_act_info b
on a.uid = b.uid and a.ymd = b.ymd and a.ymd >= '20230501' and a.ymd <= '20230502';

-- 代码2
explain dependency
select a.uid from temp.user_info_all a
left outer join temp.user_act_info b
on a.uid = b.uid and a.ymd = b.ymd and b.ymd >= '20230501' and b.ymd <= '20230502';

以上不同join类型数据查询范围不一致主要原因和hive对join和where的谓词下推支持不同有关。通过explain dependency可以直接验证hive对join和where进行谓词下推规则的验证。

Hive执行计划之hive依赖及权限查询和常见使用场景

谓词下推可详细查看什么是谓词下推,看这一篇就够了

2.2 通过explain dependency验证将过滤条件在不同位置的查询区别

如果要使用外连接并需要对左右两个表进行条件过滤,做好的方式是将过滤条件放到就近处,即如果已经知道表数据过滤筛选条件,那么在使用该表前,就先用过滤条件进行过滤,然后进行其他操作。

一些SQL内置优化器会做一些过滤下推优化,但部分条件还是不会进行下推。所以我们在写SQL时尽量养成先过滤而后进行其他操作(聚合,关联)的习惯。

可以看如下实例:

例6 left outer join对左表过滤数据的优化对比。

-- 代码1
explain dependency
select a.uid from temp.user_info_all a
left outer join temp.user_act_info b
on a.uid = b.uid and a.ymd = b.ymd 
where a.ymd >= '20230501' and a.ymd <= '20230502';

-- 代码2
explain dependency
select a.uid from (
	select uid,ymd from temp.user_info_all
  -- 在子查询内部进行过滤
  where ymd >= '20230501' and ymd <= '20230502'  
) a
left outer join temp.user_act_info b
on a.uid = b.uid and a.ymd = b.ymd;

-- 代码3
explain dependency
select a.uid from (
	select uid,ymd from temp.user_info_all
  -- 在子查询内部进行过滤
  where ymd >= '20230501' and ymd <= '20230502'  
) a
left outer join (
	select uid,ymd from temp.user_act_info
  where ymd >= '20230501' and ymd <= '20230502'
) b
on a.uid = b.uid and a.ymd = b.ymd;

执行结果:

//代码1,左右表都进行了过滤
{"input_tables":[{"tablename":"temp@user_info_all","tabletype":"MANAGED_TABLE"},{"tablename":"temp@user_act_info","tabletype":"MANAGED_TABLE"}],"input_partitions":[{"partitionName":"temp@user_info_all@ymd=20230501"},{"partitionName":"temp@user_info_all@ymd=20230502"},{"partitionName":"temp@user_act_info@ymd=20230501"},{"partitionName":"temp@user_act_info@ymd=20230502"}]}

//代码2,右表进行了全表扫描
{"input_tables":[{"tablename":"temp@user_act_info","tabletype":"MANAGED_TABLE"},{"tablename":"temp@user_info_all","tabletype":"MANAGED_TABLE"}],"input_partitions":[{"partitionName":"temp@user_info_all@ymd=20230501"},{"partitionName":"temp@user_info_all@ymd=20230502"},{"partitionName":"temp@user_act_info@ymd=20230501"},{"partitionName":"temp@user_act_info@ymd=20230502"},{"partitionName":"temp@user_act_info@ymd=20230503"},{"partitionName":"temp@user_act_info@ymd=20230606"}]}

//代码3,左右表都进行了过滤
{"input_tables":[{"tablename":"temp@user_info_all","tabletype":"MANAGED_TABLE"},{"tablename":"temp@user_act_info","tabletype":"MANAGED_TABLE"}],"input_partitions":[{"partitionName":"temp@user_info_all@ymd=20230501"},{"partitionName":"temp@user_info_all@ymd=20230502"},{"partitionName":"temp@user_act_info@ymd=20230501"},{"partitionName":"temp@user_act_info@ymd=20230502"}]}

可以看到left outer join对左表过滤数据的优化中代码1片段等价于代码3片段,即两表都在就近处都过滤。

例7 left outer join对右表过滤数据的优化对比。

-- 代码1
explain dependency
select a.uid from temp.user_info_all a
left outer join temp.user_act_info b
on a.uid = b.uid and a.ymd = b.ymd 
where b.ymd >= '20230501' and b.ymd <= '20230502';

-- 代码2
explain dependency
select a.uid from (
	select uid,ymd from temp.user_info_all
  -- 在子查询内部进行过滤
  where ymd >= '20230501' and ymd <= '20230502'  
) a
left outer join (
	select uid,ymd from temp.user_act_info
  where ymd >= '20230501' and ymd <= '20230502'
) b
on a.uid = b.uid and a.ymd = b.ymd;

-- 代码3
explain dependency
select a.uid from temp.user_info_all a
left outer join (
	select uid,ymd from temp.user_act_info
  where ymd >= '20230501' and ymd <= '20230502'
) b
on a.uid = b.uid and a.ymd = b.ymd;

执行结果内容:

// 代码1 ,左右表都进行了全表扫描
{"input_tables":[{"tablename":"temp@user_info_all","tabletype":"MANAGED_TABLE"},{"tablename":"temp@user_act_info","tabletype":"MANAGED_TABLE"}],"input_partitions":[{"partitionName":"temp@user_info_all@ymd=20230430"},{"partitionName":"temp@user_info_all@ymd=20230501"},{"partitionName":"temp@user_info_all@ymd=20230502"},{"partitionName":"temp@user_info_all@ymd=20230503"},{"partitionName":"temp@user_info_all@ymd=20230504"},{"partitionName":"temp@user_info_all@ymd=20230505"},{"partitionName":"temp@user_info_all@ymd=20230529"},{"partitionName":"temp@user_act_info@ymd=20230501"},{"partitionName":"temp@user_act_info@ymd=20230502"},{"partitionName":"temp@user_act_info@ymd=20230503"},{"partitionName":"temp@user_act_info@ymd=20230606"}]}

//代码2,左右表都进行了过滤
{"input_tables":[{"tablename":"temp@user_info_all","tabletype":"MANAGED_TABLE"},{"tablename":"temp@user_act_info","tabletype":"MANAGED_TABLE"}],"input_partitions":[{"partitionName":"temp@user_info_all@ymd=20230501"},{"partitionName":"temp@user_info_all@ymd=20230502"},{"partitionName":"temp@user_act_info@ymd=20230501"},{"partitionName":"temp@user_act_info@ymd=20230502"}]}

//代码3,右表都进行了过滤
{"input_tables":[{"tablename":"temp@user_info_all","tabletype":"MANAGED_TABLE"},{"tablename":"temp@user_act_info","tabletype":"MANAGED_TABLE"}],"input_partitions":[{"partitionName":"temp@user_act_info@ymd=20230501"},{"partitionName":"temp@user_act_info@ymd=20230502"},{"partitionName":"temp@user_info_all@ymd=20230430"},{"partitionName":"temp@user_info_all@ymd=20230501"},{"partitionName":"temp@user_info_all@ymd=20230502"},{"partitionName":"temp@user_info_all@ymd=20230503"},{"partitionName":"temp@user_info_all@ymd=20230504"},{"partitionName":"temp@user_info_all@ymd=20230505"},{"partitionName":"temp@user_info_all@ymd=20230529"}]}

可以看到left outer join对右表过滤数据的优化中代码2是最优,代码3次之,代码1最差。

3.查看SQL操作涉及到的相关权限信息

通过explain authorization可以知道当前SQL访问的数据来源(INPUTS) 和数据输出(OUTPUTS),以及当前Hive的访问用户 (CURRENT_USER)和操作(OPERATION)。

可以看以下实例:

例8 使用explain authorization查看权限相关信息。

explain authorization
select a.uid from temp.user_info_all a
left outer join temp.user_act_info b
on a.uid = b.uid and a.ymd = b.ymd 
where a.ymd >= '20230501' and a.ymd <= '20230502';

执行结果:

INPUTS: 
  temp@user_info_all
  temp@user_act_info
  temp@user_info_all@ymd=20230501
  temp@user_info_all@ymd=20230502
  temp@user_act_info@ymd=20230501
  temp@user_act_info@ymd=20230502
OUTPUTS: 
  hdfs://nameservice1/tmp/hive/hdfs/a88cc133-c310-4129-bfa0-28011ac23904/hive_2023-06-07_19-42-55_464_2777807904847671424-1/-mr-10000
CURRENT_USER: 
  hdfs
OPERATION: 
  QUERY
AUTHORIZATION_FAILURES: 
  Permission denied: Principal [name=hdfs, type=USER] does not have following privileges for operation QUERY [[SELECT] on Object [type=TABLE_OR_VIEW, name=temp.user_act_info], [SELECT] on Object [type=TABLE_OR_VIEW, name=temp.user_info_all]]

从上面的信息可知:

上面案例的数据来源是temp数据库中的 user_info_all表和user_act_info表;

数据的输出路径是hdfs://nameservice1/tmp/hive/hdfs/a88cc133-c310-4129-bfa0-28011ac23904/hive_2023-06-07_19-42-55_464_2777807904847671424-1/-mr-10000;

当前的操作用户是hdfs,操作是查询(QUERY);

观察上面的信息我们还会看到AUTHORIZATION_FAILURES信息,提示对当前的输入没有查询权限,但如果运行上面的SQL的话也能够正常运行。为什么会出现这种情况?Hive在默认不配置权限管理的情况下不进行权限验证,所有的用户在Hive里面都是超级管理员,即使不对特定的用户进行赋权,也能够正常查询。

通过上面对explain相关参数的介绍,可以发现explain中有很多值得我们去研究的内容,读懂 explain 的执行计划有利于我们优化Hive SQL,同时也能提升我们对SQL的掌控力。

下一期:Hive执行计划之什么是hiveSQL向量化模式及优化详解

按例,欢迎点击此处关注我的个人公众号,交流更多知识。

后台回复关键字 hive,随机赠送一本鲁边备注版珍藏大数据书籍。文章来源地址https://www.toymoban.com/news/detail-474767.html

到了这里,关于Hive执行计划之hive依赖及权限查询和常见使用场景的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Hive执行计划之只有map阶段SQL性能分析和解读

    目录 目录 概述 1.不带函数操作的select-from-where型简单SQL 1.1执行示例 1.2 运行逻辑分析 1.3 伪代码解释 2.带普通函数和运行操作符的普通型SQL执行计划解读 2.1 执行计划解读 2.2 伪代码解释逻辑 可能所有的SQLboy刚接触SQL语句的时候都是select xxx from xxx where xxx。在hive中,我们把这

    2024年02月08日
    浏览(35)
  • hive使用时的用户权限问题

    0: jdbc:hive2://node1:10000 create role root; Error: Error while processing statement: FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. Current user : ljr is not allowed to add roles. User has to belong to ADMIN role and have it as current role, for this action. (state=08S01,code=1) 对于由于用户权限引起的报错,我

    2024年02月09日
    浏览(28)
  • 权限管理-Ranger的介绍和使用(集成Hive)

    介绍 Apache Ranger是一个Hadoop平台上的全方位数据安全管理框架,它可以为整个Hadoop生态系统提供全面的安全管理。 随着企业业务的拓展,企业可能在多用户环境中运行多个工作任务,这就需要一个可以对安全策略进行集中管理,配置和监控用户访问的框架。Ranger由此产生!

    2024年02月10日
    浏览(32)
  • Hive使用中常见的问题及解决方法

            Hive是基于Hadoop的一个数据仓库工具,可以将结构化的数据文件映射为一张表,并提供SQL查询功能。在工作中大部分场景都会用到,下面列出几个 hive 使用中常见的问题及解决方法。 1)Hive 默认的输入格式处理是CombineHiveInputFormat,会对小文件进行合并 hive (default

    2024年02月10日
    浏览(35)
  • Hive常见时间日期函数的使用与问题整理

    这里整理一下Hive常见的时间函数和日期函数和用法,作为平时数据处理过程的一个检索和记录。 平时在数据处理过程中,如果不经常使用时间函数,一时间遇到一些时间上的处理,难免会想不起来。 hive本身提供的时间函数已经很丰富了,基本上能满足我们所有的需求,一些

    2024年02月08日
    浏览(36)
  • SQL使用技巧(3.2)递归层次查询Hive、Orcale和TDH

    场景一:员工信息表,根据某一员工编号查找其上级及上级的上级,直至最高权力者;或者下级及下级的下级,直至其管理下的最基层员工。 场景二:机构树,查询某一机构所对应的上级机构,直至最高机构;或者下级机构直至最末级机构 场景三:号码更换(银行卡换号不

    2024年02月08日
    浏览(26)
  • Hive【Hive(三)查询语句】

            今天是中秋节,早上七点就醒了,干啥呢,大一开学后空教室紧缺,还不趁着假期来学校等啥呢。顺便偷偷许个愿吧,希望在明年的这个时候,秋招不知道赶不赶得上,我希望拿几个国奖,蓝桥杯、中国大学生计算机设计大赛、挑战杯、软件杯... 。最大的愿望还

    2024年02月08日
    浏览(27)
  • Hive权限管理

    1、hive授权模型介绍 (1)Storage Based Authorization in the Metastore Server 基于存储的授权 - 可以对Metastore中的元数据进行保护,但是没有提供更加细粒度的访问控制(例如:列级别、行级别)。 (2)SQL Standards Based Authorization in HiveServer2 基于SQL标准的Hive授权 - 完全兼容SQL的授权模型

    2024年01月24日
    浏览(23)
  • Hive 表权限授权

      近期,总给其他部门的人开数据表权限,如果单独给每一个用户开权限,有点杂乱也不太好管理,所以抽空理了一下hive数据表权限相关的知识点。 目录 目录 参数配置 角色创建删除 授权及回收角色权限   1.授予某个库(表)的某个权限给某个用户 2.回收某个用户的某个库(表

    2024年02月21日
    浏览(27)
  • Hive 的权限管理

    目录 ​编辑 一、Hive权限简介 1.1 hive中的用户与组 1.1.1 用户 1.1.2 组 1.1.3 角色 1.2 使用场景 1.2.1 hive cli 1.2.2 hiveserver2 1.2.3 hcatalog api 1.3 权限模型 1.3.1 Storage Based Authorization in the Metastore Server 1.3.2 SQL Standards Based Authorization in HiveServer2 1.3.3 Default Hive Authorization (Legacy Mode) 1.4 hive的超

    2024年02月05日
    浏览(25)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包