今天有个小伙伴问我，什么是谓词下推，然后我就开启巴拉巴拉模式，说了好长一段时间，结果发现他还是懵的。
最后我概述给他一句话：所谓谓词下推，就是将尽可能多的判断更贴近数据源，以使查询时能跳过无关的数据。用在SQL优化上来说，就是先过滤再做聚合等操作。
看到这里的朋友可能就已经明白了什么是谓词下推，如果仅为了解有啥用，看到这里就可以退出了，如果想告诉别人这是个啥（高大上）那且听我细细道来。
要理解谓词下推，应该从两个方面来看，即谓词和下推两部分。
1.什么是谓词
predicate push down 翻译为谓词下推，这个翻译很准确，明确的告诉了我们这个操作是一个什么动作，但是为人诟病的是，什么是谓词，结合起来是什么意思，就比较难以理解。
predicate push down 又可以叫做 Filter Push down，这个叫法准确的描述了动作，但没有精准定位什么能被称之为Filter。全局来看，还是predicate push down较为准确。
predicate（谓词）即条件表达式，在SQL中，谓词就是返回boolean值即true和false的函数，或是隐式转换为bool的函数。SQL中的谓词主要有 LKIE、BETWEEN、IS NULL、IS NOT NULL、IN、EXISTS其结果为布尔值，即true或false。
谓词的使用场景：在SELECT语句的WHERE子句或HAVING子句中，确定哪些行与特定查询相关。 ps:并非所有谓词都可以在HAVING子句中使用。
那么反过来想，是不是在以上的场景中使用的，用来判断true或false的就是谓词呢？是的！
这样是不是就可以很好的理解了什么是谓词。
2.什么是下推
理解了什么是谓词后，我们再看看什么是下推，哪里被称为下，哪里被称为上呢？看图说话。
如图，下是table_A和table_B，即数据源头。
上是Result，即数据结果。
蓝色部分是未采用谓词下推运算过程，黄色部分是采用了谓词下推的运算过程。
3.什么是谓词下推
看到这里，我们可能已经理解了什么是谓词下推，基本的意思predicate pushdown 是将SQL语句中的部分语句( predicates 谓词部分) 可以被 “pushed” 下推到数据源或者靠近数据源的部分。
根据上图对比可以看出通过尽早过滤掉数据，这种处理方式能大大减少数据处理的量，降低资源消耗，在同样的服务器环境下，极大地减少了查询/处理时间。
在Hive SQL和Spark SQL等一系列SQL ON Hadoop的解析语法树时都在谓词下推方面作出了优化，其实在使用SQL的过程，我们心中记住这是一种将过滤尽可能在靠近数据源（取数据）的时候完成的一种操作，是数据库的一种经典的优化手段。
我们平时的SQL优化手段中，谓词下推也是一种被频繁使用的方式，简洁且有效。
4.一些常见的应用
4.1传统数据库应用
在传统数据库的查询系统中谓词下推作为优化手段很早就出现了，谓词下推的目的就是通过将一些过滤条件尽可能的在最底层执行可以减少每一层交互的数据量，从而提升性能。
例如下面这个例子：
select count(0) 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(0) from (select * from A where a>10) A1
Join (
select * from B where b<100
)B1 on A1.id = B1.id;
4.2Hive中的谓词下推
下面说说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为保留行表（先扫描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采用的规则如下：
实验结果表格形式：
总结如下：
-
对于Join(Inner Join)、Full outer Join，条件写在on后面，还是where后面，性能上面没有区别；
-
对于Left outer Join ，右侧的表写在on后面、左侧的表写在where后面，性能上有提高；
-
对于Right outer Join，左侧的表写在on后面、右侧的表写在where后面，性能上有提高；
-
当条件分散在两个表时，谓词下推可按上述结论2和3自由组合；
-
所谓下推，即谓词过滤在map端执行；所谓不下推，即谓词过滤在reduce端执行
注意：如果在表达式中含有不确定函数，整个表达式的谓词将不会被pushed，例如
select a.* from a join b on a.id = b.id
where a.ds = '2022-08-15' and a.create_time = unix_timestamp();
因为unix_timestamp是不确定函数，在编译的时候无法得知，所以，整个表达式不会被pushed，即ds='2022-08-15'也不会被提前过滤。类似的不确定函数还有rand()等。
4.3列式存储中的谓词下推
无论是行式存储还是列式存储，都可以在将过滤条件在读取一条记录之后执行以判断该记录是否需要返回给调用者，在ORC File和Parquet文件存储格式中又利用该思想做了更进一步的优化。
以Parquet为例，优化的方法是对每一个Row Group的每一个Column Chunk在存储的时候都计算对应的统计信息，包括该Column Chunk的最大值、最小值和空值个数。通过这些统计值和该列的过滤条件可以判断该Row Group是否需要扫描。另外Parquet未来还会增加诸如Bloom Filter和Index等优化数据，更加有效的完成谓词下推。
在使用Parquet的时候可以通过如下两种策略提升查询性能：1、类似于关系数据库的主键，对需要频繁过滤的列设置为有序的，这样在导入数据的时候会根据该列的顺序存储数据，这样可以最大化的利用最大值、最小值实现谓词下推。2、减小行组大小和页大小，这样增加跳过整个行组的可能性，但是此时需要权衡由于压缩和编码效率下降带来的I/O负载。
ORC File也是类似的操作，具体在讲解ORC File时详细说明。
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.category = ‘book’
使用谓词下推，会将表达式 item.category = ‘book’下推到join条件order.item_id = item.id之前。
再往高大上的方面说，就是将过滤表达式下推到存储层直接过滤数据，减少传输到计算层的数据量。
以上，就是完整的谓词下推理解了。
参考资料：
https://blog.csdn.net/strongyoung88/article/details/81156271
上一期：
Hive存储格式之RCFile详解，RCFile的过去现在未来
下期预告：Hive存储格式之ORC File详解
按例，我的个人公众号：鲁边社，点击关注
后台回复关键字 hive，随机赠送一本鲁边备注版珍藏大数据书籍。
标签：key,s2,s1,下推,就够,过滤,谓词 来源： https://www.cnblogs.com/lubians/p/16590243.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。