Spark3 新特性之DPP

最新推荐文章于 2024-05-26 17:05:19 发布

Shyllin

最新推荐文章于 2024-05-26 17:05:19 发布

阅读量897

点赞数

分类专栏： Spark 文章标签：大数据 spark 分布式

本文链接：https://blog.csdn.net/Shyllin/article/details/129202728

版权

Spark 专栏收录该内容

13 篇文章 1 订阅

订阅专栏

文章目录

Spark3 新特性之DPP

Spark3 新特性之DPP

DPP

DPP（Dynamic Partition Pruning，动态分区剪裁），它指的是在星型数仓的数据关联场景中，可以充分利用过滤之后的维度表，大幅削减事实表的数据扫描量，从整体上提升关联计算的执行性能。

分区剪裁

在星型（Start Schema）数仓中，我们有两张表，一张是订单表 orders，另一张是用户表 users。订单表是事实表（Fact），而用户表是维度表（Dimension）。业务需求是统计所有头部用户贡献的营业额，并按照营业额倒序排序。

// 订单表orders关键字段
userId, Int
itemId, Int
price, Float
quantity, Int

// 用户表users关键字段
id, Int
name, String
type, String //枚举值，分为头部用户和长尾用户

-- 查询sql
select (orders.price * order.quantity) as income, users.name
from orders inner join users on orders.userId = users.id
where users.type = ‘Head User’
group by users.name
order by income desc

由于查询语句中事实表（orders）上没有过滤条件，Spark SQL 全表扫描，维度表（users）上有过滤条件 users.type = ‘Head User’，Spark SQL 可以谓词下推，把过滤操作下推到数据源之上，来减少必需的磁盘 I/O 开销。

虽然谓词下推已经很给力了，但如果用户表支持分区剪裁（Partition Pruning），I/O 效率的提升就会更加显著。那什么是分区剪裁呢？实际上，分区剪裁是谓词下推的一种特例，它指的是在分区表中下推谓词，谓词是分区目录。分区表是通过指定分区键，然后使用 partitioned by 语句创建的数据表，或者是使用 partitionBy 语句存储的列存文件（如 Parquet、ORC 等）。

分区表分不同的目录存储数据。假设用户表是分区表，且以 type 字段作为分区键，那么用户表会有两个子目录，分别是“Head User”和“Tail User”。

**如果过滤谓词中包含分区键，那么 Spark SQL 对分区表做扫描的时候，是完全可以跳过（剪掉）不满足谓词条件的分区目录，这就是分区剪裁。**例如，在我们的查询语句中，用户表的过滤谓词是“users.type = ‘Head User’”。假设用户表是分区表，那么对于用户表的数据扫描，Spark SQL 可以完全跳过前缀为“Tail User”的子目录。

对于实际工作中的绝大多数关联查询来说，事实表都不满足分区剪裁所需的前提条件。比如说，要么事实表不是分区表，要么事实表上没有过滤谓词，或者就是过滤谓词不包含分区键。

动态分区剪裁

DPP 指的是在数据关联的场景中，Spark SQL 利用维度表提供的过滤信息，减少事实表中数据的扫描量、降低 I/O 开销，从而提升执行性能。

在这里插入图片描述

首先，过滤条件 users.type = ‘Head User’会帮助维度表过滤一部分数据。维度表保留下来的 ID 值，仅仅是维度表 ID 全集的一个子集，如图中的步骤 1 所示。

然后，在关联关系 orders.userId = users.id 的作用下，过滤效果会通过 users 的 ID 字段传导到事实表的 userId 字段，也就是图中的步骤 2。满足关联关系的 userId 值，是事实表 userId 全集中的一个子集。

之后，把满足条件的 userId 作为过滤条件，应用（Apply）到事实表的数据源，就可以做到减少数据扫描量，提升 I/O 效率，如图中的步骤 3 所示。

DPP 正是基于上述逻辑，把维度表中的过滤条件，通过关联关系传导到事实表，从而完成事实表的优化。

数据关联使用DPP需要满足三个额外的条件:

事实表必须是分区表，而且分区字段（可以是多个）必须包含Join Key
DPP 仅支持等值 Joins
维度表过滤之后的数据集要小于广播阈值

为什么需要满足 “维度表过滤之后的数据集要小于广播阈值” ?

实现 DPP 机制的关键在于，需要让处理事实表的计算分支，能够拿到满足过滤条件的 Join Key 列表，然后用这个列表来对事实表做分区剪裁。那么问题来了，用什么办法才能拿到这个列表呢？

Spark SQL 选择了一种“一箭双雕”的做法：使用广播变量封装过滤之后的维度表数据。在维度表做完过滤之后，Spark SQL 在其上构建哈希表（Hash Table），这个哈希表的 Key 是用于关联的 Join Key。在我们的例子中，Key 是满足过滤 users.type = ‘Head User’条件的 users.id，Value是users.name。

哈希表构建完毕之后，Spark SQL 将其封装到广播变量中，这个广播变量的作用有二：

第一个作用：给事实表用来做分区剪裁，哈希表中的 Key Set 用来给事实表过滤符合条件的数据分区；

第二个作用：参与后续的 Broadcast Join 数据关联，这里的哈希表，本质上就是 Hash Join 中的 Build Table，其中的 Key、Value，记录着数据关联中所需的所有字段，如 users.id、users.name，刚好拿来和事实表做 Broadcast Hash Join。

Spark SQL 选择了广播变量来有效利用 DPP 优化机制，必须要谨慎设置spark.sql.autoBroadcastJoinThreshold。

DPP的“硬伤”，Join Keys往往是高基数（cardinality）的字段，比如userId；而分区键往往要选择低基数的字段，否则数据的存储就会非常的分散。需要在存储效率和DPP之间做权衡，如果查询效率是第一优先级，那么我们其实还是可以强行对cardinality较高的Join Key做分区键。但如果相反，存储效率最大的concern，那么也就只好放弃取Join Key做分区键，放弃DPP优化机制。