Commit c15aa12
[SPARK-58185][CORE] Define PipelinedShuffleDependency and route shuffles to a ShuffleManager by dependency type
### What changes were proposed in this pull request?
This PR routes each shuffle to a `ShuffleManager` **by its dependency type**, so a
`PipelinedShuffleDependency` (added in the previous PR) is served by an incremental shuffle
implementation while every other shuffle continues to use the regular one.
`SparkEnv` now holds two shuffle managers, keyed by **kind** rather than a default and an override:
- `spark.shuffle.manager` — the **blocking** manager (a `BlockingShuffleManager`), serving all
regular (materialized) shuffles and owning block-by-id resolution. Defaults to `sort`, as before.
- `spark.shuffle.manager.incremental` — the **pipelined** manager (a `PipelinedShuffleManager`),
serving pipelined (incrementally-readable) shuffle dependencies. Defaults to the built-in
`streaming` manager, just as the blocking manager defaults to `sort`.
Routing is a single pure function, `SparkEnv.shuffleManagerFor(dependency)`: a
`PipelinedShuffleDependency` goes to the pipelined manager, every other `ShuffleDependency` to the
blocking manager. Both managers always exist, so there is no fallback path. Because the decision is
a pure function of the (serialized, deterministic) dependency, the driver at `registerShuffle` and
every executor at `getWriter` / `getReader` agree without any shared routing state or config
re-read. All shuffle-I/O sites route through it (`Dependency.shuffleHandle`, `ShuffleWriteProcessor`,
`ShuffledRDD`, `CoGroupedRDD`, `SubtractedRDD`, `ShuffledRowRDD`, `ShuffleExchangeExec`).
To make the manager APIs harder to misuse, `ShuffleManager` is split by kind:
```
ShuffleManager (declare a kind by extending one of the two subtypes)
BlockingShuffleManager <- materialized output, served as block-manager blocks via a
ShuffleBlockResolver (SortShuffleManager)
PipelinedShuffleManager <- incrementally-readable, served out-of-band, no resolver
(StreamingShuffleManager)
```
`shuffleBlockResolver` moves off `ShuffleManager` onto `BlockingShuffleManager`, so a manager's type
now says whether it serves block-manager-addressed blocks at all -- instead of the old contract
where every manager had a `shuffleBlockResolver` that some implementations threw from. Block-by-id
resolution (reads, push-based merge, decommission migration, external-shuffle-service cleanup) is
served through a new `SparkEnv.shuffleBlockResolver: Option[ShuffleBlockResolver]`, sourced from the
blocking manager; it is `None` only before the shuffle manager is initialized. This is correct
because a pipelined shuffle is served out-of-band and produces no block-manager blocks, so those
paths only ever resolve regular shuffles.
`initializeShuffleManager` validates each slot's kind and fails fast otherwise: the
`spark.shuffle.manager` slot must be a `BlockingShuffleManager` and the
`spark.shuffle.manager.incremental` slot a `PipelinedShuffleManager`. A manager that declares
neither kind is rejected from both slots. This is the "declare your kind" enforcement, and it
applies to reflectively-loaded managers too, so `ShuffleManager` itself is **not** sealed -- the
SPARK-45762 third-party extension point (a user-jar manager implementing the interface) stays open.
Supporting changes:
- `SparkEnv.blockingShuffleManager` and `SparkEnv.pipelinedShuffleManager` are the explicit
by-kind accessors (e.g. sort-shuffle detection in `ShuffleExchangeExec` reads
`blockingShuffleManager`); the bare `SparkEnv.shuffleManager` accessor is deprecated in favor of
`shuffleManagerFor` / `blockingShuffleManager` so the routing decision is explicit at each call
site.
- `spark.shuffle.manager.incremental` accepts the same style of short aliases as
`spark.shuffle.manager` -- `streaming` (the default) resolves to `StreamingShuffleManager`, and
`sort` / `tungsten-sort` resolve to `SortShuffleManager` (though a blocking manager is then
rejected from this slot by the kind validation).
- The `StreamingShuffleOutputTracker` is initialized when the pipelined manager is a
`StreamingShuffleManager` (the default) or the blocking manager is a `MultiShuffleManager`.
- `MultiShuffleManager` (the legacy cluster-level single-slot way to mix streaming and regular
shuffle) is deprecated in favor of this per-dependency routing. The routing code does not use it;
`SparkEnv` still recognizes it for tracker initialization (with a TODO to drop that once
`MultiShuffleManager` is removed).
- `spark.shuffle.manager.incremental` declares `ConfigBindingPolicy.NOT_APPLICABLE` (a shuffle
manager is a physical-execution choice and does not change how a view/UDF body resolves).
This is a follow-up in the stack that begins with `PipelinedShuffleDependency`; a later
`DAGScheduler` change adds the concurrent (pipelined-group) stage scheduling that actually
constructs these dependencies.
### Why are the changes needed?
`PipelinedShuffleDependency` marks a shuffle whose consumer reads output incrementally, but a marker
type alone does nothing until the shuffle layer can serve it with an incremental implementation
while regular shuffles keep using the existing one. A cluster needs both to coexist and to be chosen
per shuffle, not per cluster. This PR provides that: a dependency-typed routing point plus two
coexisting managers keyed by kind, so batch (sort) and pipelined (e.g. streaming real-time mode)
shuffles can run in the same application, each served by the right implementation. Splitting
`ShuffleManager` by kind (`BlockingShuffleManager` / `PipelinedShuffleManager`) encodes in the type
system the invariant the routing relies on -- that only a blocking manager serves
block-manager-addressed blocks -- so callers can no longer accidentally reach a resolver that does
not exist.
### Does this PR introduce _any_ user-facing change?
No user-visible behavior change for existing workloads: regular shuffles are still served by
`spark.shuffle.manager` (default `sort`) exactly as before, query results are unchanged, and the
block-by-id paths (reads, push-based merge, decommission, ESS cleanup) are unchanged. Nothing
constructs a `PipelinedShuffleDependency` yet, so no shuffle is routed to the pipelined manager in
this PR.
One internal behavior change worth calling out: `spark.shuffle.manager.incremental` now defaults to
the built-in streaming manager (rather than being unset), so a `StreamingShuffleOutputTracker` is
initialized in every `SparkEnv`. The new config, the `BlockingShuffleManager` /
`PipelinedShuffleManager` traits, and the `SparkEnv` routing accessors are `private[spark]`; the only
externally visible API change is that the `DeveloperApi` `SparkEnv.shuffleManager` accessor is now
`deprecated` (still functional, pointing callers to the explicit accessors).
### How was this patch tested?
New unit tests in `PipelinedShuffleRoutingSuite` (16 tests) verify the routing and the manager-kind
model:
- `shuffleManagerFor` routes a regular dependency to the blocking manager and a
`PipelinedShuffleDependency` to the pipelined manager;
- the handle a dependency mints comes from the routed manager (so driver and executor agree), and
`blockingShuffleManager` is the plain configured manager (no wrapper installed in front of it);
- the id-only cleanup path notifies both managers (and is a no-op, not an NPE, before the managers
are initialized), and both managers are stopped on `SparkContext` stop;
- `spark.shuffle.manager.incremental` resolves the same short aliases as `spark.shuffle.manager`, a
bad incremental class name fails fast at startup, a blocking manager in the incremental slot is
rejected, and a pipelined manager in the default slot is rejected;
- a manager's type declares its kind (`SortShuffleManager` is a `BlockingShuffleManager`;
`StreamingShuffleManager` is a `PipelinedShuffleManager` and not a `BlockingShuffleManager`), and
`SparkEnv.shuffleBlockResolver` is defined for the blocking manager.
`StreamingShuffleManagerSuite` verifies the streaming output tracker is initialized by default (the
streaming incremental manager), for an explicit incremental `StreamingShuffleManager`, and for a
`MultiShuffleManager` default. Existing coverage of the block-by-id and cleanup paths was updated
and rerun: `BlockManagerSuite` (including the deferred-`ShuffleManager` init and unsupported-resolver
paths), `ContextCleanerSuite` (the real `RemoveShuffle` RPC through `BlockManagerMasterEndpoint`),
`SortShuffleSuite`, `SparkSubmitSuite` (the SPARK-45762 user-jar `ShuffleManager` plugin, now
implementing `BlockingShuffleManager`), and `ShuffleDependencySuite` (which also asserts a
`PipelinedShuffleDependency` never allows push-based shuffle merge).
```
build/sbt 'core/testOnly org.apache.spark.shuffle.PipelinedShuffleRoutingSuite'
...
Tests: succeeded 16, failed 0
```
### Was this patch authored or co-authored using generative AI tooling?
Co-authored: Claude Code (Opus 4.8)
Closes #57286 from jerrypeng/stack/pipelined-shuffle-pr2-routing.
Authored-by: Boyang Jerry Peng <jerry.peng@databricks.com>
Signed-off-by: Wenchen Fan <wenchen@databricks.com>1 parent 2608b6b commit c15aa12
30 files changed
Lines changed: 878 additions & 158 deletions
File tree
- core/src
- main/scala/org/apache/spark
- errors
- internal/config
- rdd
- shuffle
- sort
- streaming
- storage
- test/scala/org/apache/spark
- deploy
- internal/plugin
- scheduler
- shuffle
- streaming
- storage
- sql/core/src/main/scala/org/apache/spark/sql/execution
- exchange
- streaming/src/test/scala/org/apache/spark/streaming
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
134 | 134 | | |
135 | 135 | | |
136 | 136 | | |
137 | | - | |
| 137 | + | |
| 138 | + | |
| 139 | + | |
| 140 | + | |
138 | 141 | | |
139 | 142 | | |
140 | 143 | | |
| |||
258 | 261 | | |
259 | 262 | | |
260 | 263 | | |
| 264 | + | |
| 265 | + | |
| 266 | + | |
| 267 | + | |
| 268 | + | |
| 269 | + | |
| 270 | + | |
| 271 | + | |
| 272 | + | |
| 273 | + | |
| 274 | + | |
| 275 | + | |
| 276 | + | |
| 277 | + | |
| 278 | + | |
| 279 | + | |
| 280 | + | |
| 281 | + | |
| 282 | + | |
| 283 | + | |
| 284 | + | |
| 285 | + | |
| 286 | + | |
| 287 | + | |
| 288 | + | |
| 289 | + | |
| 290 | + | |
| 291 | + | |
| 292 | + | |
| 293 | + | |
| 294 | + | |
| 295 | + | |
| 296 | + | |
| 297 | + | |
| 298 | + | |
| 299 | + | |
| 300 | + | |
| 301 | + | |
| 302 | + | |
| 303 | + | |
| 304 | + | |
| 305 | + | |
| 306 | + | |
| 307 | + | |
| 308 | + | |
| 309 | + | |
| 310 | + | |
| 311 | + | |
| 312 | + | |
| 313 | + | |
| 314 | + | |
| 315 | + | |
| 316 | + | |
| 317 | + | |
| 318 | + | |
| 319 | + | |
| 320 | + | |
| 321 | + | |
| 322 | + | |
| 323 | + | |
| 324 | + | |
| 325 | + | |
| 326 | + | |
| 327 | + | |
| 328 | + | |
| 329 | + | |
| 330 | + | |
| 331 | + | |
261 | 332 | | |
262 | 333 | | |
263 | 334 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
45 | 45 | | |
46 | 46 | | |
47 | 47 | | |
48 | | - | |
| 48 | + | |
| 49 | + | |
49 | 50 | | |
50 | 51 | | |
51 | 52 | | |
| |||
76 | 77 | | |
77 | 78 | | |
78 | 79 | | |
79 | | - | |
80 | | - | |
81 | | - | |
| 80 | + | |
| 81 | + | |
| 82 | + | |
| 83 | + | |
| 84 | + | |
| 85 | + | |
| 86 | + | |
| 87 | + | |
| 88 | + | |
| 89 | + | |
| 90 | + | |
| 91 | + | |
| 92 | + | |
| 93 | + | |
| 94 | + | |
| 95 | + | |
| 96 | + | |
| 97 | + | |
82 | 98 | | |
83 | 99 | | |
84 | 100 | | |
85 | 101 | | |
86 | 102 | | |
87 | | - | |
| 103 | + | |
| 104 | + | |
| 105 | + | |
| 106 | + | |
| 107 | + | |
| 108 | + | |
| 109 | + | |
| 110 | + | |
| 111 | + | |
| 112 | + | |
| 113 | + | |
| 114 | + | |
| 115 | + | |
| 116 | + | |
| 117 | + | |
| 118 | + | |
| 119 | + | |
| 120 | + | |
| 121 | + | |
| 122 | + | |
| 123 | + | |
| 124 | + | |
| 125 | + | |
| 126 | + | |
| 127 | + | |
| 128 | + | |
| 129 | + | |
| 130 | + | |
| 131 | + | |
| 132 | + | |
| 133 | + | |
| 134 | + | |
| 135 | + | |
| 136 | + | |
| 137 | + | |
| 138 | + | |
| 139 | + | |
| 140 | + | |
| 141 | + | |
| 142 | + | |
| 143 | + | |
| 144 | + | |
| 145 | + | |
| 146 | + | |
| 147 | + | |
| 148 | + | |
| 149 | + | |
| 150 | + | |
| 151 | + | |
| 152 | + | |
| 153 | + | |
| 154 | + | |
| 155 | + | |
| 156 | + | |
| 157 | + | |
| 158 | + | |
| 159 | + | |
| 160 | + | |
| 161 | + | |
| 162 | + | |
| 163 | + | |
| 164 | + | |
| 165 | + | |
| 166 | + | |
| 167 | + | |
| 168 | + | |
| 169 | + | |
| 170 | + | |
| 171 | + | |
| 172 | + | |
| 173 | + | |
| 174 | + | |
| 175 | + | |
| 176 | + | |
| 177 | + | |
| 178 | + | |
88 | 179 | | |
89 | 180 | | |
90 | 181 | | |
| |||
102 | 193 | | |
103 | 194 | | |
104 | 195 | | |
105 | | - | |
| 196 | + | |
106 | 197 | | |
107 | 198 | | |
108 | 199 | | |
| |||
185 | 276 | | |
186 | 277 | | |
187 | 278 | | |
188 | | - | |
189 | | - | |
| 279 | + | |
| 280 | + | |
| 281 | + | |
| 282 | + | |
| 283 | + | |
190 | 284 | | |
191 | 285 | | |
192 | 286 | | |
| |||
295 | 389 | | |
296 | 390 | | |
297 | 391 | | |
298 | | - | |
299 | | - | |
| 392 | + | |
| 393 | + | |
300 | 394 | | |
301 | | - | |
| 395 | + | |
| 396 | + | |
| 397 | + | |
| 398 | + | |
| 399 | + | |
| 400 | + | |
| 401 | + | |
| 402 | + | |
| 403 | + | |
| 404 | + | |
| 405 | + | |
| 406 | + | |
| 407 | + | |
| 408 | + | |
| 409 | + | |
| 410 | + | |
| 411 | + | |
| 412 | + | |
| 413 | + | |
| 414 | + | |
| 415 | + | |
| 416 | + | |
| 417 | + | |
| 418 | + | |
| 419 | + | |
| 420 | + | |
| 421 | + | |
| 422 | + | |
| 423 | + | |
| 424 | + | |
| 425 | + | |
| 426 | + | |
| 427 | + | |
302 | 428 | | |
303 | 429 | | |
304 | 430 | | |
305 | 431 | | |
306 | 432 | | |
307 | 433 | | |
308 | 434 | | |
309 | | - | |
310 | | - | |
| 435 | + | |
| 436 | + | |
| 437 | + | |
311 | 438 | | |
312 | 439 | | |
313 | 440 | | |
| |||
323 | 450 | | |
324 | 451 | | |
325 | 452 | | |
326 | | - | |
327 | | - | |
328 | | - | |
329 | | - | |
330 | | - | |
331 | | - | |
332 | | - | |
333 | | - | |
| 453 | + | |
| 454 | + | |
| 455 | + | |
| 456 | + | |
| 457 | + | |
| 458 | + | |
| 459 | + | |
| 460 | + | |
| 461 | + | |
| 462 | + | |
| 463 | + | |
| 464 | + | |
| 465 | + | |
| 466 | + | |
| 467 | + | |
| 468 | + | |
334 | 469 | | |
335 | | - | |
336 | | - | |
337 | | - | |
338 | | - | |
339 | | - | |
340 | | - | |
341 | | - | |
342 | | - | |
343 | | - | |
344 | | - | |
345 | | - | |
346 | | - | |
| 470 | + | |
| 471 | + | |
| 472 | + | |
| 473 | + | |
| 474 | + | |
| 475 | + | |
| 476 | + | |
| 477 | + | |
| 478 | + | |
| 479 | + | |
| 480 | + | |
| 481 | + | |
| 482 | + | |
| 483 | + | |
| 484 | + | |
| 485 | + | |
| 486 | + | |
347 | 487 | | |
| 488 | + | |
348 | 489 | | |
349 | 490 | | |
350 | 491 | | |
| |||
550 | 691 | | |
551 | 692 | | |
552 | 693 | | |
553 | | - | |
554 | 694 | | |
555 | 695 | | |
556 | 696 | | |
| |||
0 commit comments