【大数据 】SparkSQL连接查询中的谓词下推处理(二)

简介: 本篇文章要介绍的是--外连接查询中的谓词下推规则,这相比内连接中的规则要复杂一些,不过使用简单的表格来进行分析也是可以分析清楚的。

目录:
1.左表 join 后条件下推
2.左表join中条件不下推
3.右表join中条件下推
4.右表join中条件不下推
5.总结

在《SparkSql连接查询中的谓词下推处理(一)》中,我们介绍了一些基本的概念,并对内连接查询时的一些基本下推规则进行了分析。

本篇文章要介绍的是--外连接查询中的谓词下推规则,这相比内连接中的规则要复杂一些,不过使用简单的表格来进行分析也是可以分析清楚的。先上表:

我们以左外连接查询为例,先总结规矩如下:

接下来对这个表格中的规则进行详细的分析。

1.左表join后条件下推

查询语句如下:

前文有提到,对于join后条件,如果放在join操作后执行,是可以作为正确结果进行比对的。那么先对两表进行左连接,结果如下:

然后使用LT.id>1这个join后条件进行过滤,结果如下:

来分析一下LT.id>1下推到左表进行数据过滤的结果,经过LT.id>1过滤后,左表变为:

此时再和右表进行左连接,左表id为2的行,在右表中能找到id为2的行,则连接结果如下:

可见,两种处理方法结果一致。条件下推过滤了左表整整50%的数据(相当牛,虽然只过滤了一条)。究其原因,是因为在SparkSQL中,把以上的查询解析成了如下的子查询:

这是一个非相关子查询,即完全可以先完成子查询,再完成父查询,子查询在查询过程中和外部查询没有关联关系。

2.左表join中条件不下推

查询语句如下:

来看看不下推的情况下计算出的正确结果,join过程如下:

第一步:左表id为1的行在右表中能找到相等的id,但是左表的id为1,是不满足第二个join条件(LT.id>1)的,所以左表这一条相当于没有和右表join上,所以左表的值value保留,而右表的valuenull(你没满足join中条件没join上还把你的值保留,给我搞个空值?没办法,就是这么任性)。

第二步:左表id为2的行在右表中能找到,而且左表id为2的行的id大于1,两个join条件都满足,所以算是和右表join上了,所以左表和右表的value都保留。最终的查询结果如下:

那么如果把"LT.id>1"这个条件下推到做表,会得到什么结果呢?

首先左表经过"LT.id>1"过滤后,如下:

此时再和右表连接,左表id为2的行在右表中能找到,且满足"LT.id = RT.id AND LT.id > 1"这个join中条件,所以两表的value都被保留。左表中已经没有数据了,查询结束,查询结果如下:

这个查询结果和不下推的正确结果不一致,是个错误的结果,所以左表join中条件是不能下推进行数据过滤的。分析原因:主要是因为join中条件和join后条件对结果的处理方式不同,前者在不满足join条件时会保留一部分结果,而后者在不满足条件时任何东西都不保留。

3.右表join中条件下推

查询语句如下:

现在把RT.id>1这个右表join后条件下推,来过滤右表,过滤后如下:

然后左表再和右表进行左连接,流程如下:

第一步:左表id为1的行在右表中没有,此时左表值保留,右表为null

第二步:左表id位2的行在右表中有,并且RT.id大于1,两个join条件都满足,则左表和右表的值都保留。查询结果如下:

那么如果不下推(为了得到正确结果),来看看结果,流程如下:

第一步:左表id为1的行在右表中有,但是不满足第二个join条件,所以这行算是没join上,所以左表数据保留,右表为null

第二步:左表id为2的行在右表中有,也满足第二个join条件,所以左右表的数据都保留。

可见,右表join中条件下推不下推,结果一样,所以,干吗不下推?可以过滤掉一半的数据呢。SparkSQL中的等价处理语句是:

可以看出,也是解析成了一个非相关子查询来处理的。

4.右表join中条件不下推

这个应该是最违反常规理解的查询了,查询语句如下:

首先来看,join后条件不下推的情况,流程如下:

第一步:左表id为1的行在右表中可以找到,但是此时仅仅满足join条件,在使用where条件判断这条连接后数据时,发现右表的id不满足RT.id>1的条件,所以这条join结果不保留(注意:这里是不保留,全都不保留,左表右表都不保留,要跟上边的没join上而右表的值保留为null的情况区别开,这也是关键所在);

第二步:左表id为2的行和右表id为2的行join上了,同时也满足RT.id>1where条件。

这是一条符合语义的正确的查询结果。

好了,接下来看看右表join后条件下推的情况:

第一步:使用RT.id>1过滤右表,过滤后右表只剩一行id为2的行;

第二步:左表id为1的行在过滤后的右表中没有,此时左表值保留,右表值为null

第三步:左表id为2的行在右表中有,此时左表值保留,右表值也保留。

结果如下:

很明显这其实是一个错误的结果。

总结

至此,左连接查询的四条规则分析完了。可以看出,在SparkSQL中对于外连接查询时的过滤条件,并不能在所有情况下都用来进行数据源的过滤,如果使用得当会极大的提升查询性能,如果使用不当,则会产生错误的查询结果,而这种错误结果又不易发觉,所以使用时要格外小心。

相关实践学习
基于MaxCompute的热门话题分析
Apsara Clouder大数据专项技能认证配套课程:基于MaxCompute的热门话题分析
目录
相关文章
|
5月前
|
SQL 分布式计算 大数据
SparkSQL 入门指南:小白也能懂的大数据 SQL 处理神器
在大数据处理的领域,SparkSQL 是一种非常强大的工具,它可以让开发人员以 SQL 的方式处理和查询大规模数据集。SparkSQL 集成了 SQL 查询引擎和 Spark 的分布式计算引擎,使得我们可以在分布式环境下执行 SQL 查询,并能利用 Spark 的强大计算能力进行数据分析。
|
7月前
|
存储 缓存 分布式计算
OSS大数据分析集成:MaxCompute直读OSS外部表优化查询性能(减少数据迁移的ETL成本)
MaxCompute直读OSS外部表优化方案,解决传统ETL架构中数据同步延迟高、传输成本大、维护复杂等问题。通过存储格式优化(ORC/Parquet)、分区剪枝、谓词下推与元数据缓存等技术,显著提升查询性能并降低成本。结合冷热数据分层与并发控制策略,实现高效数据分析。
216 2
|
10月前
|
SQL 大数据 数据挖掘
玩转大数据:从零开始掌握SQL查询基础
玩转大数据:从零开始掌握SQL查询基础
386 35
|
11月前
|
SQL 分布式计算 数据挖掘
阿里云 MaxCompute MaxQA 开启公测,公测可申请 100CU 计算资源解锁近实时高效查询体验
阿里云云原生大数据计算服务 MaxCompute 推出 MaxQA(原 MCQA2.0)查询加速功能,在独享的查询加速资源池的基础上,对管控链路、查询优化器、执行引擎、存储引擎以及缓存机制等多个环节进行全面优化,显著减少了查询响应时间,适用于 BI 场景、交互式分析以及近实时数仓等对延迟要求高且稳定的场景。现正式开启公测,公测期间可申请100CU(价值15000元)计算资源用于测试,欢迎广大开发者及企业用户参与,解锁高效查询体验!
阿里云 MaxCompute MaxQA 开启公测,公测可申请 100CU 计算资源解锁近实时高效查询体验
|
负载均衡 大数据
大数据散列分区查询频率
大数据散列分区查询频率
156 5
|
存储 大数据 数据管理
大数据分区提高查询性能
大数据分区提高查询性能
360 2
|
存储 负载均衡 大数据
大数据水平分区提高查询性能
【11月更文挑战第2天】
254 4
|
存储 分布式计算 安全
MaxCompute Bloomfilter index 在蚂蚁安全溯源场景大规模点查询的最佳实践
MaxCompute 在11月最新版本中全新上线了 Bloomfilter index 能力,针对大规模数据点查场景,支持更细粒度的数据裁剪,减少查询过程中不必要的数据扫描,从而提高整体的查询效率和性能。
|
存储 JSON 监控
大数据-167 ELK Elasticsearch 详细介绍 特点 分片 查询
大数据-167 ELK Elasticsearch 详细介绍 特点 分片 查询
912 4
|
消息中间件 资源调度 大数据
大数据-112 Flink DataStreamAPI 程序输入源 DataSource 基于文件、集合、Kafka连接器
大数据-112 Flink DataStreamAPI 程序输入源 DataSource 基于文件、集合、Kafka连接器
260 0