Spark 4.1: Support parallel orphan file deletion - #17796
Closed
aarushigupta132 wants to merge 1 commit into
Closed
Conversation
Author
|
Closing |
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.
Summary
This draft adds a
parallel_deletesoption to the Spark 4.1remove_orphan_filesprocedure. When enabled, orphan files are deleted from Spark executors rather than sequentially on the driver.The option is disabled by default, preserving the existing driver-side deletion behavior.
FileIOimplementations that support bulk operations delete one Spark partition at a time; other implementations delete files individually within each partition. Orphan paths continue to flow back to the driver so the procedure can produce its existing result count and path sample.Motivation
remove_orphan_filescurrently identifies orphan files with Spark but performs deletion on the driver. Even when listing and the metadata anti-join are distributed, deletion throughput is therefore limited by one node. Executor-side deletion allows the work to scale with the number of Spark partitions.This is complementary to #17790, which distributes prefix-based file listing. The cached orphan-file dataset remains the correct input to deletion because files must not be removed until the metadata anti-join and prefix-mismatch validation have completed.
Open questions and follow-ups
This is a draft because the API and failure semantics need review. In particular:
dry_run => truecurrently supplies a no-op delete function, which the parallel path bypasses. The two options must be rejected together or made safe before this is ready to merge.DELETE_GROUP_SIZE.max_concurrent_deletesand custom delete functions should be validated explicitly.Testing
Tests are still to be added for executor-side bulk and non-bulk deletion, dry-run behavior, option interactions, partition batching, and task retry behavior.