上月听了本部门sparksql大牛的sparksql调优分享,当时对一个点不是很理解,回去好好理了一下,整理成文。
基本概念:谓词下推(predicate pushdown)属于逻辑优化。优化器可以将谓词过滤下推到数据源,从而使物理执行跳过无关数据。在使用Parquet或者orcfile的情况下,更可能存在文件被整块跳过的情况,同时系统还通过字典编码把字符串对比转换为开销更小的整数对比。
说白了,就是把查询相关的条件下推到数据源进行提前的过滤操作,之所以这里说是查询相关的条件,而不直接说是where 后的条件,是因为sql语句中除了where后的有条件外,join时也有条件。本文讨论的主要就是join时的条件的处理。
那么这两类不同的条件,在外连接查询中是否都会下推呢?不是的,是否下推是遵循一定规则的,对于左连接查询,可以归纳为下表:
左表 | 右表 | |
---|---|---|
Join中条件 | 不下推 | 下推 |
Join后条件 | 下推 | 不下推 |
帽子很高,其实就是对2中表格中的规则一个一个来分析。
3.1. 左表join后条件下推
左表:
Id | value |
---|---|
1 | one |
2 | two |
右表:
id | value |
---|---|
1 | one |
2 | two |
来分析一下LT.id>1下推到左表左表进行数据过滤的结果:
经过LT.id>1过滤后,左表变为:
Id | value |
---|---|
2 | two |
此时再和右表进行左连接,流程如下:
左表id为2的行,在右表中能join上,则连接结果如下:
LT.id | LT.value | RT.value |
---|---|---|
2 | two | two |
可见,条件下推过滤了左表整整50%的数据,相当牛叉,虽然只有两条。究其原因,是因为在sparksql中,把以上的查询解析成了如下的子查询:
3.2. 左表join中条件不下推
查询语句如下:
左表:
Id | value |
---|---|
1 | one |
2 | two |
右表:
id | value |
---|---|
1 | one |
2 | two |
来看看不下推的情况下计算出的正确结果,join过程如下:
第一步:左表id为1的行在右表中能找到相等的id,但是左表的id为1,是不满足第二个join条件的,所以左表这一条相当于没有和右表join上,所以左表的值value保留,而右表的value为null。
第二步:左表id为2 的行在右表中能找到,而且左表id为2的行的id大于1,两个join条件都满足,所以算是和右表join上了,所以左表和右表的value都保留。
LT.id | LT.value | RT.value |
---|---|---|
1 | one | null |
2 | two | two |
3.3. 右表join中条件下推
查询语句如下:
现在把RT.id>1这个右表join中条件下推,来过滤右表,过滤后如下:
Id | value |
---|---|
2 | two |
然后左表再和右表进行左连接,流程如下:
第一步:左表id为1的行在右表中没有,此时左表值保留,右表为null
第二步:左表id位2的行在右表中有,并且RT.id大于1,两个join条件都满足,则左表和右表的值都保留。
LT.id | LT.value | RT.value |
---|---|---|
1 | one | null |
2 | two | two |
那么如果不下推,来看看结果,流程如下:
第一步:左表id为1的行在右表中有,但是不满足第二个join条件,所以这行算是没join上,所以左表数据保留,右表为null
第二步:左表id为2的行在右表中有,也满足第二个join条件,所以左右表的数据都保留。
LT.id | LT.value | RT.value |
---|---|---|
1 | one | null |
2 | wo | two |
可见,右表join中条件下推不下推,结果一样,所以,干吗不下推?可以过滤掉一半的数据呢。Sparksql中的等价处理语句是:
这个应该是最违反常规理解的查询了,查询语句如下:
首先来看,join后条件不下推的情况,流程如下:
第一步:左表id为1的行在右表中可以找到,但是此时仅仅满足join条件,在使用where条件判断这条连接后数据时,发现右表的id不满足RT.id>1的条件,所以这条join结果不保留(注意,这里是不保留,全都不保留,左表右表都不保留,要跟上边的没join上,右表的值为null的情况区别开,这也是关键所在)
第二步:左表id为2的行和右表id为2的行join上了,同时也满足RT.id>1的where条件。
LT.id | LT.value | RT.value |
---|---|---|
2 | two | two |
很明显,这是一条符合语义的正确的查询结果。
好了,接下来看看右表join后条件下推的情况:
第一步:使用RT.id>1过滤右表,过滤后右表只剩一行id为2的行
第二步:左表id为1的行在右表中没有,此时左表值保留,右表值为null
第三步:左表id为2的行在右表中有,此时左表值保留,右表值也保留。
结果如下:
LT.id | LT.value | RT.value |
---|---|---|
1 | one | null |
2 | two | two |
这其实是一个错误的结果。
好了分析结束,其实大家也看出来了,我是打着sparksql的幌子骗点击的,任何数据库其实都会按照这个规则处理的,不是sparksql所特有的。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。