背景

Join是一个非常耗费资源耗费时间的操作，特别是数据量很大的情况下。一般流程上会涉及底层表的扫描/shuffle/Join等过程, 如果我们能够尽可能的在靠近源头上减少参与计算的数据，一方面可以提高查询性能，另一方面也可以减少资源的消耗(网络/IO/CPU等)，在同样的资源的情况下可以支撑更多的查询。

目前在SparkSQL中有Filter下推优化，包括两个维度:

生成Filter

SparkSQL会从用户的SQL语句中获取到Filter

直接显示获取
```
select * from A where a=1
```
生成Filter(a=1) on A

隐式推断

select * from A, B where A.a = B.b and A.a=1

推断出Filter(b=1) on B

Filter优化

利用生成的Filter算子可以优化，比如:

将Filter尽量下推到靠近DataSource端
如果Filter中的列是分区列，可以提前对DataSource进行分区裁剪，只扫描需要的分区数据

Runtime Filter是针对Equi-Join场景提出的一种新的生成Filter的方式，通过动态获取Filter内容来做相关优化。

Runtime Filter原理

优化对象

Equi Join, 形如

select x,y from A join B on A.a = B.b

其中A是一个小表(如维表)，B是一个大表(如事实表)
备注: A/B也可以是一个简单的子查询

优化思路

如上述小表A和大表B进行Join，Join条件为A.a=B.b，实际Join过程中需要对大表进行全表扫描才能完成Join操作，极端情况下如A.a仅仅只有一条记录，也需要对B表全表扫描，影响性能。

如果在B表扫描之前，能获取A表的a的相关信息(如所有的a值，或者a的min/max/Bloomfilter等统计信息)，并在实际执行Join之前将这些信息对B表的数据进行过滤，而不是全表扫描，可以大大提高性能。

两种场景

根据大表B参与join的key(b)的属性，可以分别采集小表A参与join的key(a)的信息:

b是分区列

如上b为大表B的一个分区列，则可以提前收集A.a列的所有值，然后利用A.a的值对B表的b列进行分区裁剪

b不是分区列

不能做分区裁剪，只能在实际数据扫描的过程中进行过滤。可以提前收集A.a列的min/max/Bloomfilter的统计信息，然后利用这些统计信息对B表进行数据过滤，这个过滤又可以分成两种粒度:

可下推到存储层，减少数据扫描
如底层文件格式是Parquet/ORC, 可以将相关过滤谓词(min/max等)下推到存储层面，从而减少实际扫描的数据。
扫描后数据过滤
不能下推到存储层的，可以在数据被扫描后做条件过滤，减少后续参与计算的数据量(如shuffle/join等)

Runtime Filter实现

Runtime Filter的实现主要在Catalyst中，分为4个步骤:

谓词合成

在用户SQL生成的逻辑执行计划树(logical plan)中，寻找满足条件的Equi-Join节点，然后根据上面的思路，在Join的大表B侧插入一个新的Filter节点，如Filter(In(b, Seq(DynamicValue(a, A))), B)

谓词下推

上面生成的新的Filter会经过PushDownPredicate的Rule，尽量下推靠近DataSource附近

物理执行计划生成

该阶段会将上面下推的Filter(In(b, Seq(DynamicValue(a, A))), B)转换成物理节点(FilterExec)，根据上面两种场景会生成两种不同的FilterExec

b是分区列
b是分区列，采集的是a列的所有值,如:

case class DynamicPartitionPruneFilterExec(
  child: SparkPlan, collectors: Seq[(Expression, SparkPlan)])
  extends DynamicFilterUnaryExecNode with CodegenSupport with PredicateHelper

其中colletors就是用于采集信息的SparkPlan，因为要跑一个SQL来采集a列的所有值(select a from A group by a);
因为有可能会有多个分区列，所以这个地方是一个Seq.

b是非分区列
b是非分区列，采集的是a列的min/max/bloomfilter统计信息，如

case class DynamicMinMaxFilterExec(
  child: SparkPlan, collectors: Seq[(Expression, SparkPlan)])
extends DynamicFilterUnaryExecNode with CodegenSupport with PredicateHelper

同理上面collectors也是用户采集信息的SparkPlan，如select min(a),max(a) from A

执行

在物理执行计划实际执行的过程中，会在DynamicPartitionPruneFilterExec/DynamicMinMaxFilterExec物理算子内先执行collectors获取到a列的相关信息，然后对底层B的执行计划进行改写，比如利用采集到的信息做分区裁剪/数据过滤等。

Runtime Filter性能测试

以TPC-DS 10TB的Query54为例:

Runtime Filter 关闭

Runtime Filter 打开

经过DynamicPartitionPruneFilter对catalog_sales的分区进行了裁剪，实际对表的扫描从14,327,953,968减少到136,107,053，然后经过min/max的过滤继续减少到135,564,763;另外Runtime Filter减少了大表的扫描，shuffle的数据量以及参加Join的数据量，所以对整个集群IO/网络/CPU有比较大的节省

总结

针对Equi-Join的场景，可以额外的采集小表侧的信息，然后在Join之前对大表进行分区裁剪或者扫描后过滤，从而提高查询性能，减少资源消耗。

EMR Spark Runtime Filter性能优化

背景