-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[Spark] Fast Drop Feature Command (#3867)
<!-- Thanks for sending a pull request! Here are some tips for you: 1. If this is your first time, please read our contributor guidelines: https://github.com/delta-io/delta/blob/master/CONTRIBUTING.md 2. If the PR is unfinished, add '[WIP]' in your PR title, e.g., '[WIP] Your PR title ...'. 3. Be sure to keep the PR description updated to reflect all changes. 4. Please write your PR title to summarize what this PR proposes. 5. If possible, provide a concise example to reproduce the issue for a faster review. 6. If applicable, include the corresponding issue number in the PR title and link it in the body. --> #### Which Delta project/connector is this regarding? <!-- Please add the component selected below to the beginning of the pull request title For example: [Spark] Title of my pull request --> - [x] Spark - [ ] Standalone - [ ] Flink - [ ] Kernel - [ ] Other (fill in here) ## Description <!-- - Describe what this PR changes. - Describe why we need the change. If this PR resolves an issue be sure to include "Resolves #XXX" to correctly link and close the issue upon merge. --> This is base PR for Fast Drop feature. This is a new implementation of the DROP FEATURE command that requires no waiting time and no history truncation. The main difficulty when dropping a feature is that after the operation is complete the history of the table still contains traces of the feature. This may cause the following problems: 1. Reconstructing the state of the latest version may require replaying log records prior to feature removal. Log replay is based on checkpoints, an auxiliary data structure, which is used by clients as a starting point for replaying history. Any actions before the checkpoint do not need to be replayed. However, checkpoints are not permanent and may be deleted any time. 2. Clients may create checkpoints in historical versions when do not support the required features. The proposed solution is `CheckpointProtectionTableFeature`. This is a new writer feature that ensures that the entire history until a certain table version, V, can only be cleaned up in its entirety or not at all. Alternatively, the writer can delete commits and associated checkpoints up to any version (less than V) as long as it validates against all protocols included in the commits/checkpoints planing to remove. We protect against the anomalies above as follows: - All checkpoints before the transition table version are protected. This prevents anomaly (1) by turning checkpoints into reliable barriers that can hide unsupported log records behind them. - Because log cleanup is disabled for the older versions, this also removes the only reason why writers would create new checkpoints, preventing anomaly (2). This still uses a writer feature, but is a step forward compared to previous solutions because it allows the table to be readable by older clients immediately, instead of after 24 hours. Compatibility with older writers can subsequently be achieved by truncating the history after a 24-hour waiting period. ## How was this patch tested? <!-- If tests were added, say they were added here. Please make sure to test the changes thoroughly including negative and positive cases if possible. If the changes were tested in any way other than unit tests, please clarify how you tested step by step (ideally copy and paste-able, so that other reviewers can test and check, and descendants can verify in the future). If the changes were not tested, please explain why. --> Added `DeltaFastDropFeatureSuite` as well as tests in `DeltaProtocolTransitionsSuite`. ## Does this PR introduce _any_ user-facing changes? <!-- If yes, please clarify the previous behavior and the change this PR proposes - provide the console output, description and/or an example to show the behavior difference if possible. If possible, please also clarify if this is a user-facing change compared to the released Delta Lake versions or within the unreleased branches such as master. If no, write 'No'. --> No.
- Loading branch information
1 parent
e65d06e
commit 860438f
Showing
9 changed files
with
466 additions
and
150 deletions.
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
Oops, something went wrong.