SparkSQL 中动态分区裁剪 DPP 失效导致的性能问题

在 Spark SQL 中，动态分区裁剪 (Dynamic Partition Pruning, 简称 DPP) 是自 Spark 3.0 引入的一项关键性能优化机制。它主要用于解决“星型模型”或“雪花模型”中，大事实表与小维度表进行关联时的性能瓶颈。

当维度表上有过滤条件时，DPP 能够在运行期（Runtime）动态计算出符合过滤条件的分区键值，并直接将这些键值推送给事实表的扫描阶段，从而避免扫描事实表中不必要的 Partition，大幅减少 I/O 损耗和网络传输。

如果 DPP 失效，Spark 将退化为扫描事实表的所有分区，引发严重的全表扫描、I/O 暴增、内存溢出 (OOM) 以及整体任务严重变慢等性能问题。

一、 DPP 失效的常见原因

DPP 的触发有一套严格的优化器规则，以下任意一个环节不满足，都可能导致 DPP 失效：

1. Join 键不匹配事实表的分区键

原因：DPP 必须依赖事实表的分区信息。如果事实表 fact_table 确实分区了（例如按 date_col 分区），但与维度表进行关联的 Join Key 却不是 date_col，那么优化器无法进行分区裁剪。

2. 维度表过大，未触发广播（Broadcast）

原因：DPP 默认极其依赖 广播哈希关联 (Broadcast Hash Join, BHJ)。Spark 会在维度表上运行过滤并生成一个临时子查询，将符合条件的 key 广播给所有的 Executor。
如果维度表的数据量超过了广播阈值（由 spark.sql.autoBroadcastJoinThreshold 控制，默认 10MB），Spark 会放弃 BHJ，转而使用 排序归并关联 (Sort Merge Join, SMJ)。在 SMJ 下，如果估算成本不合算，DPP 往往不会生效。

3. 维度表上缺乏过滤条件（Selective Filter）

原因：DPP 的本质是“利用维度表的过滤结果去裁剪事实表”。如果 SQL 中对维度表没有任何 WHERE 过滤，那么理论上事实表的所有分区都需要参与关联，此时 DPP 自然不会触发。

4. Join 键存在隐式类型转换（Implicit Cast）

原因：如果事实表的分区键是 INT 类型，而维度表的关联键是 BIGINT 类型，Spark 优化器会在物理计划中插入隐式的 CAST 转换。
表达式如 CAST(fact_col AS BIGINT) = dim_col 会导致优化器无法将该过滤条件直接识别为事实表的分区裁剪条件，从而导致静态和动态分区裁剪同时失效。

5. 在分区键/Join 键上使用了函数或复杂表达式

原因：类似于类型转换，如果在关联或过滤条件中对分区键应用了函数（如 WHERE YEAR(date_partition) = 2026 或 ON SUBSTR(fact.p_date, 1, 4) = dim.year），优化器将无法直接把结果映射回底层的物理分区目录，导致 DPP 失效。

6. Join 类型（Join Type）不支持

原因：DPP 目前主要支持 Inner Join、Left Semi Join（事实表在左）以及部分 Outer Join（如事实表在右时的 Right Outer Join）。如果是 Full Outer Join 或不合理的 Left/Right Outer Join（会导致事实表无法安全过滤），DPP 将无法被应用。

7. 缺少准确的表统计信息（Table Statistics）

原因：Spark 的基于成本的优化器 (CBO) 依赖表的 Stats（如行数、大小）来决定是否生成 DPP 子查询。如果表没有经过 ANALYZE 收集统计信息，优化器在估算时可能会高估维度表或低估裁剪收益，从而保守地放弃 DPP。

二、如何排查 DPP 是否失效

要确定一个查询是否触发了 DPP，可以通过以下两种常见方式：

1. 查看物理执行计划 (`EXPLAIN`)

在 Spark 中对查询执行 .explain()，并仔细观察物理计划：

正常触发 DPP 的标志：
在事实表扫描的节点（如 FileScan parquet 或 BatchScan）中，其 PartitionFilters 里会包含：
dynamicpruningexpression(....) 或者是 DynamicPartitionPruningSubquery 相关的子查询。
失效的标志：
PartitionFilters 为空，或者只含有静态的硬编码过滤条件，这意味着 Spark 正在对整个事实表进行分区扫描。

2. 通过 Spark UI 的 SQL 选项卡 (SQL Tab)

在 Spark UI 中找到对应的 Query：

如果 DPP 生效，你会在 DAG 图中看到一个独立的子查询分支（Subquery Broadcast）从维度表的过滤输出拉出，并直接指向事实表 Scan 操作的输入端。
在 Scan 节点的 Metrics 指标中，可以对比 "number of partitions read"。如果该数值远小于事实表的总分区数，说明动态裁剪生效了；如果几乎等于总分区数，说明失效。

三、解决方案与优化策略

1. 确保关联键的类型和定义完全一致

操作：检查并确保事实表的分区键与维度表的关联键在 DDL 中定义为完全相同的数据类型（例如同为 STRING 或同为 INT），避免任何隐式类型转换。
避免函数：不在 Join Condition 或过滤条件中对分区键施加 SUBSTR、DATE_FORMAT 等函数，保持键的“干净”。

2. 强行触发广播连接（Broadcast Hint）

如果是因为维度表略微超过默认的 10MB 导致没有走 Broadcast Join，可以使用 Hint 显式指定：

sql

SELECT /*+ BROADCAST(dim) */ f.*, dim.*
FROM fact_table f
JOIN dim_table dim ON f.partition_key = dim.join_key
WHERE dim.filter_col = 'some_value';

或者在 Spark 属性中适当调大广播阈值（需注意内存承受能力）：

plaintext

spark.sql.autoBroadcastJoinThreshold = 52428800  -- 调大至 50MB

3. 定期运行 ANALYZE 收集统计信息

确保 Spark 优化器拥有最新的元数据，这能帮助它更自信地做出 DPP 的决策：

sql

-- 针对事实表和维度表运行
ANALYZE TABLE fact_table COMPUTE STATISTICS;
ANALYZE TABLE dim_table COMPUTE STATISTICS FOR COLUMNS join_key;

4. 开启自适应查询执行 (AQE)

自适应查询执行（Adaptive Query Execution）与 DPP 有极佳的协同效应。在运行过程中，AQE 如果发现实际过滤后的维度表足够小，会动态将 Sort-Merge Join 转换为 Broadcast Hash Join，从而在运行期重新激活 DPP。