一文了解 Apache Spark 3.0 动态分区裁剪(Dynamic Partition Pru

一文了解 Apache Spark 3.0 动态分区裁剪(Dynamic Partition Pruning)

过往记忆大数据 过往记忆大数据

静态分区裁剪(Static Partition Pruning)

用过 Spark 的同学都知道,Spark SQL 在查询的时候支持分区裁剪,比如我们如果有以下的查询:

SELECT * FROM Sales_iteblog WHERE day_of_week = 'Mon'

Spark 会自动进行以下的优化:

如果想及时了解Spark、Hadoop或者Hbase相关的文章,欢迎关注微信公共帐号:iteblog_hadoop
从上图可以看到,Spark 在编译 SQL 的时候自动将 Filter 算子下推到数据源,也就是在 Scan 前进行了 Filter 操作,将 day_of_week = 'Mon' 的数据全部拿出来,其他数据不需要的拿出,这样 Spark SQL 中处理的数据就变少了,整个 SQL 的查询数据就会变快,这一切都是编译的时候(compile time)进行的,所以这个叫做静态分区裁剪(Static Partition Pruning)。
上面的 SQL 查询在 Spark 进行了算子下推,已经能够满足我们的查询性能的提升。但是现实世界数据的查询可不会都这么简单,我们来看看下面的查询语句:

SELECT * FROM Sales JOIN Date WHERE Date.day_of_week = 'Mon'

比较差的查询引擎是这么做的:

如果想及时了解Spark、Hadoop或者Hbase相关的文章,欢迎关注微信公共帐号:iteblog_hadoop
从上图可以看出,查询引擎直接忽略了 Date.day_of_week = 'Mon' 这个过滤条件,上来就是两表 join,然后 join 的结果再进行过滤,这个可能导致很多无效的计算,如果 Date.day_of_week = 'Mon' 可以过滤掉大量的无用数据,肯定可以提升查询性能。在 Spark SQL 里面能够很好的处理这种情况,它会把 Date.day_of_week = 'Mon' 过滤条件下推到 Date 表的 Scan 之前进行:

如果想及时了解Spark、Hadoop或者Hbase相关的文章,欢迎关注微信公共帐号:iteblog_hadoop
动态分区裁剪(Dynamic Partition Pruning)
上面 Spark SQL 进行的算子下推是不是不能再提升查询性能呢?有没有一种更好的方法进一步过滤掉一些无用的数据?这就是本文要介绍的动态分区裁剪。动态分区裁剪这个功能是 Spark 3.0 引入的,详见 SPARK-11150、SPARK-28888。
什么是动态分区裁剪?所谓的动态分区裁剪就是基于运行时(run time)推断出来的信息来进一步进行分区裁剪。举个例子,我们有如下的查询:

SELECT * FROM dim_iteblog JOIN fact_iteblog ON (dim_iteblog.partcol = fact_iteblog.partcol) WHERE dim_iteblog.othercol > 10

动态查询的执行计划如下:

如果想及时了解Spark、Hadoop或者Hbase相关的文章,欢迎关注微信公共帐号:iteblog_hadoop
从上面可以看出,拥有动态分区裁剪,Spark 能够在运行的时候先对 fact_iteblog 表的 partcol 进行了一次过滤,然后再和 dim_iteblog 表进行 Join,可想而知这个性能一般都会有提升的,特别是在 fact_iteblog 表有很多无用的数据时性能提升会非常大的。
Databricks 公司在10台配置为 i3.xlarge 的集群上进行 TPC-DS 测试,得到的结论是在 102 查询中相比 Spark 2.4 有 60 个查询的查询性能提升了 2 - 18 倍的提升。


在 Query 98 的查询中,性能提升了 100 倍!

©著作权归作者所有:来自51CTO博客作者mob604756f47778的原创作品,如需转载,请注明出处,否则将追究法律责任