[SPARK-58412][SQL] Prevent incomplete and stale cache materialization statistics - #57617
Open
sunchao wants to merge 1 commit into
Open
[SPARK-58412][SQL] Prevent incomplete and stale cache materialization statistics#57617sunchao wants to merge 1 commit into
sunchao wants to merge 1 commit into
Conversation
sunchao
marked this pull request as ready for review
July 28, 2026 22:44
dongjoon-hyun
approved these changes
Jul 28, 2026
dongjoon-hyun
left a comment
Member
There was a problem hiding this comment.
+1, LGTM (Pending CIs). Thank you, @sunchao !
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
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.
Why are the changes needed?
SPARK-58412 tracks two lifecycle gaps in the cache-materialization bookkeeping introduced by SPARK-57547. That earlier change replaced raw cache-task completion counters with partition-keyed statistics so duplicate computations cannot make an
InMemoryRelationappear materialized too early.First,
CachedRDDBuildercurrently publishes a task's partition statistics whenever the task completes successfully, even if a downstream consumer stops before exhausting the cache-building iterator. This can happen when a memory-only block cannot be stored and Spark returns the partially unrolled iterator to its consumer. Because the statistics accumulator is last-write-wins per partition, a partially consumed recomputation can replace that partition's complete row and byte counts while the cache still appears fully materialized. For example, a completed(10 rows, N bytes)entry can be replaced with(0 rows, 0 bytes)without removing the partition key, allowing AQE to treat a non-empty cache as empty.Second,
clearCacheresets the existing accumulator in place. Tasks from the retired cache generation have already captured that same accumulator, so late completions can write stale partition keys and values into the rebuilt generation. If those stale keys cover every partition, the new cache can appear complete before its own partitions finish.These are general
InMemoryRelationcorrectness issues. They were identified while working on runtime-filter support in #57443, but they affect cache materialization independently of that optimizer feature.What changes were proposed in this PR?
This change makes cache statistics represent only complete work from the current cache generation.
A task now publishes its partition statistics only after the wrapped cache iterator has been exhausted and the task finishes without failure or interruption. A successful consumer that stops early therefore cannot overwrite a complete partition's statistics with partial values.
Clearing a cache now installs a newly registered
PartitionKeyedAccumulatorinstead of resetting the previous accumulator. Each cache-building RDD captures the accumulator for its own generation, so tasks finishing afterclearCachecan update only the retired generation. The cache contents and storage semantics are unchanged; this change only tightens the lifecycle of materialization metadata.How was this PR tested?
The existing
CachedTableSuiteclear-cache regression now injects late updates through the retired generation's accumulator before and after rebuilding the cache. It verifies that the new generation remains unloaded until its own partitions complete and that its row and byte statistics remain exact.A new
ConcurrentInMemoryRelationSuiteregression forces a cached partition to be recomputed, then runs a successful consumer that does not consume the returned cache iterator. It verifies that the partial attempt cannot replace the complete partition statistics.The following validation passed:
The two affected suites ran 108 tests successfully.