什么是谓词

首先我们要了解什么是谓词。需要说明的是这是一个翻译问题，导致很难理解

在SQL中，谓词就是返回boolean值即true和false的函数，或是隐式转换为bool的函数。SQL中的谓词主要有 LKIE、BETWEEN、IS NULL、IS NOT NULL、IN、EXISTS.

接下来了解什么是谓词下推，谓词下推的基本思想即：

将过滤表达式尽可能移动至靠近数据源的位置，以使真正执行时能直接跳过无关的数据。

也就是尽早的将无用数据删除，加快计算速度。

传统数据库：

在传统数据库的查询系统中谓词下推作为优化手段很早就出现了，谓词下推的目的就是通过将一些过滤条件尽可能的在最底层执行可以减少每一层交互的数据量，从而提升性能。例如下面这个例子：

-- 没有经过谓词下推
SELECT 
COUNT(1) AS NUM 
FROM A JOIN B 
ON A.ID = B.ID 
WHERE A.a >10 and B.b <100;

以上为例，在处理Join操作之前，需要首先对表A和表B执行TableScan操作，然后再进行Join，再执行过滤，最后计算聚合函数返回，但是如果把过滤条件A.a > 10和B.b < 100分别移到A表的TableScan和B表的TableScan的时候执行，可以大大降低Join操作的输入数据。优化后的语句如下：

-- 经过谓词下推
SELECT 
COUNT(1) AS NUM 
FROM (SELECT * FROM A WHERE a > 10) A1 
JOIN (SELECT * FROM B WHEREb < 100) B1
ON A1.ID = B1.ID

无论是行式存储还是列式存储，都可以在将过滤条件在读取一条记录之后执行以判断该记录是否需要返回给调用者，

在Parquet做了更进一步的优化，优化的方法是：对每一个Row Group的每一个Column Chunk在存储的时候都计算对应的统计信息，包括该Column Chunk的最大值、最小值和空值个数。

通过这些统计值和该列的过滤条件可以判断该Row Group是否需要扫描。另外Parquet未来还会增加诸如Bloom Filter和Index等优化数据，更加有效的完成谓词下推。

在使用Parquet的时候可以通过如下两种策略提升查询性能：

1、类似于关系数据库的主键，对需要频繁过滤的列设置为有序的，这样在导入数据的时候会根据该列的顺序存储数据，这样可以最大化的利用最大值、最小值实现谓词下推。

2、减小行组大小和页大小，这样增加跳过整个行组的可能性，但是此时需要权衡由于压缩和编码效率下降带来的I/O负载。

列式存储中的谓词下推思想

RF算法中，用了谓词下推思想。大小表进行broadcast hash join时，用小表的join列数据构建BloomFilter，广播到大表的所有partition，使用该BloomFilter对大表join列数据进行过滤。最后将大表过滤后得到的数据与小表数据进行hashJoin。

这个过程如下图：

这样的好处是：

• 在存储层即过滤了大量大表无效数据，减少扫描无效数据列的同行其他列数据IO
• 减少存储进程到计算进程传输的数据
• 减少hashjoin开销

如这个sql:

SELECT ITEM.NAME , ORDER.* FROM ORDER,ITEM 
WHERE ORDER.ITEM_ID = ITEM.ID 
AND ITEM.CATEGRORY ='book'

使用谓词下推，会将表达式 item.category = ‘book’下推到join条件order.item_id = item.id之前。再往高大上的方面说，就是将过滤表达式下推到存储层直接过滤数据，减少传输到计算层的数据量。

HIVE中的谓词下推（下推规则同样适用于SparkSQL）

Hive中的Predicate Pushdown简称谓词下推，简而言之，就是在不影响结果的情况下，尽量将过滤条件提前执行。

谓词下推后，过滤条件在map端执行，减少了map端的输出，降低了数据在集群上传输的量，节约了集群的资源，也提升了任务的性能。

具体配置项是hive.optimize.ppd，默认为true，即开启谓词下推

PPD规则：

规则的逻辑描述如下：

• During Join predicates cannot be pushed past Preserved Row tables.

join条件过滤不能下推到保留行表中。

比如以下选择，left join中左表s1为保留行表，所以on条件（join过滤条件）不能下推到s1中

SELECT s1.key, s2.key
FROM src s1
     LEFT JOIN src s2
               ON s1.key > '2';

而s2表不是保留行，所以s2.key>2条件可以下推到s2表中：

SELECT s1.key, s2.key
FROM src s1
     LEFT JOIN src s2
               ON s2.key > '2';

• After Join predicates cannot be pushed past Null Supplying tables.

where条件过滤不能下推到NULL补充表。

比如以下选择left join的右表s2为NULL补充表所以，s1.key>2 where条件可以下推到s1：

select s1.key, s2.key from src s1 left join src s2 where s1.key > '2';而以下选择由于s2未NULL补充表所以s2.key>2过滤条件不能下推

SELECT s1.key, s2.key
FROM src s1
     LEFT JOIN src s2
WHERE s2.key > '2';

关于join和where采用ppd的规则如下：

1、对于Join(Inner Join)、Full outer Join，条件写在on后面，还是where后面，性能上面没有区别；

2、对于Left outer Join ，右侧的表写在on后面、左侧的表写在where后面，性能上有提高；

3、对于Right outer Join，左侧的表写在on后面、右侧的表写在where后面，性能上有提高；

4、所谓下推，即谓词过滤在map端执行；所谓不下推，即谓词过滤在reduce端执行

注意：如果在表达式中含有不确定函数，整个表达式的谓词将不会被pushed，例如

SELECT A.*
FROM A JOIN B ON A.ID = B.ID
WHERE A.DS ='2020-01-01' AND A.CERATE_TIME = UNIX_TIMESTAMP();
因为unix_timestamp是不确定函数，在编译的时候无法得知，所以，整个表达式不会被pushed，即ds='2019-10-09'也不会被提前过滤。类似的不确定函数还有rand()等。

谓词下推的使用

set hive.optimize.ppd = true; 开启谓词下推，默认开启

一、join

1.where 里写筛选条件

筛选左右表字段都不会影响谓词下推，扫描时过滤

2.where 里对筛选字段使用函数

筛选左右表字段都不会影响谓词下推，扫描时过滤

3.where里对筛选字段使用reflect

筛选左右表字段都会使谓词下推失效，join后过滤

4.on 里写筛选条件

筛选左右表字段都不会影响谓词下推，扫描时过滤

5.on里对筛选字段使用函数

筛选左右表字段都不会影响谓词下推，扫描时过滤

6.on里对筛选字段使用reflect

筛选左右表字段都会使谓词下推失效，且都只过滤自身表，扫描后join前过滤

二、left join

1.where 里写筛选条件

筛选左右表字段都不会影响谓词下推，扫描时过滤

2.where 里对筛选字段使用函数

筛选左表字段不会影响谓词下推，扫描时过滤；筛选右表字段会使谓词下推失效，join后过滤

3.where里对筛选字段使用reflect

筛选左右表字段都会使谓词下推失效，join后过滤

4.on 里写筛选条件

筛选左表字段谓词下推失效，扫描后join前过滤，且左右表都过滤，无论右表有没有该字段；筛选右表字段，只会对右表谓词下推，筛选左右表关联建的情况下也只对右表生效，扫描时过滤

5.on里对筛选字段使用函数

筛选左表字段谓词下推失效，扫描后join前过滤，且左右表都过滤，无论右表有没有该字段；筛选右表字段，只会对右表谓词下推，筛选左右表关联建的情况下也只对右表生效，扫描时过滤

6.on里对筛选字段使用reflect

筛选左表字段谓词下推失效，扫描后join前过滤，且左右表都过滤，无论右表有没有该字段；筛选右表字段，只会对右表谓词下推，筛选左右表关联建的情况下也只对右表生效，扫描时过滤

三、full join

1.where 里写筛选条件

筛选左右表字段都不会影响谓词下推

2.where 里对筛选字段使用函数

筛选左右表字段都会使谓词下推失效，join后过滤

3.where里对筛选字段使用reflect

筛选左右表字段都会使谓词下推失效，join后过滤

4.on 里写筛选条件

筛选左右表字段都会使谓词下推失效，且都只过滤自身表，扫描后join前过滤

5.on里对筛选字段使用函数

筛选左右表字段都会使谓词下推失效，且都只过滤自身表，扫描后join前过滤

6.on里对筛选字段使用reflect

筛选左右表字段都会使谓词下推失效，且都只过滤自身表，扫描后join前过滤

使用感受

谓词下推思想还是挺好的，使用的时候还是尽量让左右表都小一点
因为咱们也不可能写的时候就一直想着谓词下推这个事情，它能下推当然是好时候，如果因为某些原因下推不了也正常
所以养成一个好习惯，左右表数据尽可能早过滤。

参考文献：

https://cwiki.apache.org/confluence/display/Hive/OuterJoinBehavior#OuterJoinBehavior-Examples

https://blog.csdn.net/strongyoung88/article/details/81156271

https://blog.csdn.net/baichoufei90/article/details/85264100