Hive及Spark中Join中过滤下推优化分析

本文介绍SparkSQL中的PushPredicateThroughJoin优化规则,该规则基于Hive的Join行为进行设计。主要包含两条法则:一是Join条件过滤不能下推到保留行表;二是Where条件过滤不能下推到NULL补充表。

前言: 在Spark SQL中有一条PushPredicateThroughJoin优化规则,其原理是参考Hive中的Join规则完成的,具体参考本文的规则1/2。

Definitions

  • Preserved Row table: The table in an Outer Join that must return all rows. For left outer joins this is the Left table, for right outer joins it is the Right table, and for full outer joins both tables are Preserved Row tables.

  • Null Supplying table: This is the table that has nulls filled in for its columns in unmatched rows. In the non-full outer join case, this is the other table in the Join. For full outer joins both tables are also Null Supplying tables.

  • During Join predicate: A predicate that is in the JOIN ON clause. For example, in ‘R1 join R2 on R1.x = 5’ the predicate ‘R1.x = 5’ is a During Join predicate.

  • After Join predicate: A predicate that is in the WHERE clause.

Predicate Pushdown Rules

The logic can be summarized by these two rules:

  • During Join predicates cannot be pushed past Preserved Row tables.
  • After Join predicates cannot be pushed past Null Supplying 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';

第二条法则: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';

引用网页:https://cwiki.apache.org/confluence/display/Hive/OuterJoinBehavior#OuterJoinBehavior-Examples

### 谓词下推的概念 在 Hive 中,**谓词下推(Predicate Pushdown)** 是一种查询优技术,其核心思想是将查询中的过滤条件(即谓词)尽可能地下推到数据读取阶段,从而在数据扫描和传输的早期阶段就进行过滤,减少后续计算层需要处理的数据量,提高查询效率 [^1]。 这种优通常会将过滤条件应用在数据源(如 HDFS 文件)的读取过程中,使得在表扫描阶段就只加载符合条件的数据,而不是将所有数据加载后再进行过滤。这种方式可以显著减少中间数据的传输和处理开销,特别是在处理大规模数据集时效果尤为明显 [^3]。 --- ### 谓词下推的作用 谓词下推的主要作用包括: - **减少数据扫描量**:通过在存储层就过滤掉不需要的数据,减少从磁盘读取的数据量。 - **降低网络传输开销**:减少从存储节点传输到计算节点的数据量,提升整体执行效率。 - **提升查询性能**:减少不必要的数据处理,加快查询响应时间 [^1]。 例如,以下查询中,`item.category = 'book'` 会被下推到 `JOIN` 操作之前,从而减少参与连接的数据量: ```sql SELECT * FROM orders o JOIN items i ON o.item_id = i.id WHERE i.category = 'book'; ``` 在这个例子中,Hive 会将 `i.category = 'book'` 的过滤条件应用在 `items` 表的扫描阶段,而不是等到 `JOIN` 操作之后才进行过滤 [^1]。 --- ### 谓词下推的实现原理 谓词下推的实现依赖于 Hive 的查询优器(CBO,Cost-Based Optimizer)以及底层的执行引擎(如 MapReduce、Tez 或 Spark)。其基本流程如下: 1. **查询解析与优**:Hive 解析 SQL 查询,生成逻辑执行计划,并由优器决定哪些谓词可以下推。 2. **谓词下推决策**:根据表连接类型(如 `INNER JOIN`、`LEFT JOIN` 等)和保留表(Preserved Row Table)的特性,决定是否将某个谓词下推到数据扫描阶段。 - 在 `INNER JOIN` 中,`ON` 条件和 `WHERE` 条件都可以下推。 - 在 `LEFT JOIN` 中,左表的过滤条件不会下推,而右表的过滤条件会下推。 - 在 `FULL JOIN` 中,任何表的 `ON` 条件都不会下推 [^2]。 3. **执行阶段**:在执行时,Hive 会将这些谓词直接作用于数据扫描操作,例如在读取 Parquet 或 ORC 文件时,利用文件格式的谓词下推能力进行过滤 [^4]。 此外,Hive 的谓词下推还可能与列裁剪(Column Pruning)等优技术结合使用,进一步减少需要处理的数据量 [^3]。 --- ### 谓词下推的适用场景 - **Join 操作中的过滤**:在多表连接时,将过滤条件下推到连接操作之前,减少参与连接的数据量。 - **分区表与桶表查询**:结合分区裁剪和桶过滤,进一步优查询性能。 - **列式存储格式**:如 ORC 和 Parquet,支持高效的谓词下推,可以在读取数据时跳过不满足条件的行 [^1]。 --- ### 示例代码 以下是一个典型的谓词下推示例: ```sql -- 查询订单中书籍类商品的订单信息 SELECT o.order_id, o.user_id, i.name FROM orders o JOIN items i ON o.item_id = i.id WHERE i.category = 'book'; ``` 在这个查询中,Hive 会将 `i.category = 'book'` 下推到 `items` 表的扫描阶段,使得只有符合条件的 `items` 数据才会参与 `JOIN` 操作,从而减少中间结果的数据量 [^1]。 --- ### 相关问题 1. Hive 中如何判断某个查询是否触发了谓词下推? 2. Hive 中的谓词下推与列裁剪有什么区别? 3. Hive 中的谓词下推对不同类型的 Join 有哪些影响? 4. 如何在 Hive 中禁用谓词下推功能? 5. Hive 谓词下推在 ORC 和 Parquet 文件格式中的实现有何不同?
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值