feat(shuffleV2): support multi-CN via serve-all-buckets mode#24940
Open
aunjgr wants to merge 14 commits into
Open
feat(shuffleV2): support multi-CN via serve-all-buckets mode#24940aunjgr wants to merge 14 commits into
aunjgr wants to merge 14 commits into
Conversation
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
When maxHolders == 1 (single worker on multi-CN source scope), Call() serves full batches from all buckets instead of only CurrentShuffleIdx. This lets dispatch route data to the correct target CNs. Also swap multi-CN compile constructors to use v2 operators: - constructShuffleOperatorForJoin: v1 -> v2 - constructShuffleArgForGroup: v1 -> v2 Add vm.ShuffleV2 serialization/deserialization in remoterun.go.
- Prepare defaults maxHolders to 1; dupOperator overrides with SetMaxHolders - allStop checks stoppers >= holders instead of stoppers == maxHolders - Call() serves all buckets when maxHolders == 1 (single worker) - hashShuffle returns const/constNull directly instead of through pool - Remove DEDUP hash join gate in compileJoin - Add getAnyFullBatch/getAnyLastBatch to ShufflePoolV2
aunjgr
force-pushed
the
feat/multi-cn-shuffle-v2
branch
from
dd22de8 to
d6eb4d8
Compare
- compileJoin: remove mcpu check and V1 compileShuffleJoin fallback; always route to compileShuffleJoinV2 - compileShuffleJoinV2: keep fast path for simple single-CN case (paired scopes, no dispatch overhead); all other cases (multi-CN, merged scopes, mismatched parallelism) go through newShuffleJoinScopeList + V2-specific join construction (shuffleV2=true) - newShuffleJoinScopeList: always use constructShuffleOperatorForJoinV2 instead of switching between V1 (single-CN) and V2 (multi-CN) Together these changes eliminate every remaining V1 code path from production shuffle joins and groups.
The old len(leftscopes) != len(rightscopes) assertion panicked when a probe side (e.g. table scan → 1 scope with Mcpu=dop) was joined with a build side that was itself the result of a previous shuffled join and thus had dop scopes each with Mcpu=1 (from newShuffleJoinScopeList). Fix: remove the assertion; the fast path now requires equal scope counts as part of its condition. When scopes don't match, the general path (newShuffleJoinScopeList) handles arbitrary scope configurations.
…in general path In the general path (newShuffleJoinScopeList with multiple scopes per CN), ShuffleIdx=-1 breaks the 1-to-1 hash-build/hash-join pairing because each scope receives different partition data from the dispatch routing (ShuffleToRegIndex or ShuffleToMultiMatchedReg). A hash join could receive the JoinMap from a different scope's hash build, producing wrong results. Fix: use per-scope ShuffleIdx=i (shuffleV2=false) in the general path. The shuffle operators themselves remain V2 (non-blocking, pipelined). The fast path (single CN, single scope) keeps ShuffleIdx=-1 since there's exactly one hash-build/hash-join pair with no ambiguity.
Deleted (all zero callers): - constructShuffleOperatorForJoin (V1) — dead - constructShuffleArgForGroup (V1) — dead - compileShuffleJoin (V1) — dead - compileShuffleGroup (V1) — dead Renamed (drop V2 suffix): - constructShuffleOperatorForJoinV2 → constructShuffleOperatorForJoin - constructShuffleArgForGroupV2 → constructShuffleArgForGroup - compileShuffleJoinV2 → compileShuffleJoin - compileShuffleGroupV2 → compileShuffleGroup - Test helpers: newCompileForShuffleGroupV2Test etc → newCompileForShuffleGroup etc
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
Which issue(s) this PR fixes:
issue #24097
What this PR does / why we need it:
Shuffle v2 (in-process
ShufflePoolV2) was only used on single-CN because itsCall()method only served the current worker's bucket. On multi-CN source scopes whereMcpu=1(maxHolders==1), the single worker wrote rows to all N buckets but only drained bucket 0 — data for remote CNs was stranded in the pool.Fix: When
maxHolders == 1,Call()usesgetAnyFullBatch()/getAnyLastBatch()to serve batches from all buckets. This lets the downstreamDispatchoperator route each batch to the correct target CN based onShuffleIDX.Compile changes: The multi-CN constructor paths (
constructShuffleOperatorForJoinandconstructShuffleArgForGroup) now create v2 shuffle operators instead of v1. Single-CN paths (compileShuffleJoinV2/compileShuffleGroupV2) are unchanged.remoterun.go: Added
vm.ShuffleV2serialization/deserialization.How scattering/gathering works:
🤖 Generated with Claude Code