Spark中contiguous shuffle partition是什么？求非连续示例及差异

一、Contiguous Shuffle Partition 定义 #

在Spark自适应查询执行（AQE）的「合并后shuffle分区」逻辑里，**连续shuffle分区（Contiguous Shuffle Partition）**就是指编号连续、且数据量都远低于AQE阈值（默认128MB）的一组shuffle输出分区。AQE会自动把这些连续的小分区合并成一个或几个更大的分区，以此减少后续阶段的任务数量，降低调度和执行的开销。

简单说就是：编号连在一起的小分区，会被AQE打包合并。

二、Non-Contiguous Shuffle Partition 示例 #

举个实际场景：假设一次shuffle操作生成了10个分区（编号0-9），经过数据过滤后：

• 分区0、2、4的数据量都只有10MB（远低于128MB阈值），但它们的编号是分散的，中间隔了1、3、5这些数据量正常的分区
• 这三个分区就是非连续shuffle分区（Non-Contiguous Shuffle Partition），AQE不会把它们合并，因为它们的编号没有形成连续的区间，只能保留为独立的小任务执行。

再比如：某电商订单数据按用户ID哈希shuffle后，分区1、3、7对应的用户群体刚好是被过滤掉的测试用户，导致这三个分区数据量极小，但它们的编号不连续，这也是典型的非连续小分区。

三、二者核心差异 #

• 编号特征：
  • Contiguous：分区编号是连续的区间（比如0-3、6-8）
  • Non-Contiguous：分区编号分散，没有连续的区间（比如1、4、7）
• AQE处理方式：
  • Contiguous：会被AQE自动合并，减少后续任务数，提升效率
  • Non-Contiguous：无法被AQE的合并逻辑处理，仍以小分区形式存在，带来不必要的调度开销
• 产生场景：
  • Contiguous：多是shuffle时某段key范围的数据量天然偏小（比如某地区用户订单量少，对应哈希区间的分区连续且小）
  • Non-Contiguous：多因数据过滤、key分布极度不均导致（比如零散的测试数据对应分散的分区编号，过滤后这些分区数据量骤降）

内容的提问来源于stack exchange，提问作者Pavel Orekhov