[Big data] SparkSql join predicate pushdown query processing (b)

This article first appeared in Internet technology vivo micro-channel public number https://mp.weixin.qq.com/s/II48YxGfoursKVvdAXYbVg
Author: Li Yong

Contents:
1. pushdown rear left table join condition
2. In the left table join without pushdown
3. The right table in the join condition pushdown
4. The right table join in without pushdown
5. Summary

In " SparkSql connection predicate pushdown query processing (a) ", we introduce some basic concepts and push down some basic rules in connection queries are analyzed.

This article is to introduce the - rule predicate pushdown outer join query, compared to regular connections within this more complicated, but using a simple spreadsheet for analysis also can be analyzed clearly. First on the list:

We left outer join query with an example, to sum up the rules as follows:

Next to the table rules a detailed analysis.

1. Left table after the join condition pushdown

Query as follows:

Previously mentioned, for join the conditions, if placed jo **** in performing the operation, it may be made as a correct result of comparison. So first of two tables left connected with the following results:

Then LT.id >. 1 the join condition was filtered, the results are as follows:

To analyze LT.id > 1 results pushed down to the left table data filtering, after LT.id > 1 After filtration, the left table becomes:

此时再和右表进行左连接,左表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中对于外连接查询时的过滤条件,并不能在所有情况下都用来进行数据源的过滤,如果使用得当会极大的提升查询性能,如果使用不当,则会产生错误的查询结果,而这种错误结果又不易发觉,所以使用时要格外小心。

更多内容敬请关注 vivo 互联网技术 微信公众号

注:转载文章请先与微信号:labs2020 联系。

Guess you like

Origin www.cnblogs.com/vivotech/p/10972501.html