-
Notifications
You must be signed in to change notification settings - Fork 2.5k
[HUDI-5569] Maintain commit timeline even in case of long standing inflights #8783
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
@suryaprasanna Thanks for the contribution ~, can you elaborate a little more what are we want to improve for archiving? |
9dbf3aa to
0cce98b
Compare
|
@danny0405 Thanks for reviewing this PR. Added more context to the PR. Please take a look. |
I'm wondering what instant the reader is holding to query the table, we have a check inside the fs view, only fileslice with the complete instant can be explosed to readers. |
|
The bug where reader's are reading from inflight instant is resolved. With this change, I am trying to consolidate the approach of handling inflight commits. Since, we are handling pending compaction and replacecommits separately and it could lead to various corner cases. That is why I am trying to keep largestCompletedInstant that is less than the oldestInflightinstant from getting archived. |
This could not happen. |
| // oldestCommitToRetain is the highest completed commit instant that is less than the oldest inflight instant. | ||
| // By filter out any commit >= oldestCommitToRetain, we can ensure there are no gaps in the timeline | ||
| // when inflight commits are present. | ||
| return oldestCommitToRetain |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this simplifies a lot :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it can fix #7738, although a little obscure to understand.
| } | ||
| } | ||
|
|
||
| @Test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we add some java docs on what we are testing here.
simple illustration of timeline might also help
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added.
| + "after 101 and also to maintain timeline have at least one completed commit before pending commit"); | ||
| assertTrue(timeline.containsInstant(new HoodieInstant(State.INFLIGHT, HoodieTimeline.REPLACE_COMMIT_ACTION, "101")), | ||
| "Inflight replacecommit must still be present"); | ||
| assertTrue(timeline.containsInstant(new HoodieInstant(false, HoodieTimeline.COMMIT_ACTION, "102")), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you declare a list of instants to expect in active timeline. and run it in a for loop rather than 1 line for each instant
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, refactored the code.
| assertTrue(timeline.containsInstant(new HoodieInstant(false, HoodieTimeline.COMMIT_ACTION, "102")), | ||
| "Instants greater than oldest pending commit must be present"); | ||
| assertTrue(timeline.containsInstant(new HoodieInstant(State.REQUESTED, HoodieTimeline.COMPACTION_ACTION, "103")), | ||
| "Instants greater than oldest pending commit must be present"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here
| // not for replaced file groups. So, last clean instant can be considered as a lower bound, since | ||
| // the cleaner would have removed all the file groups until then. But there is a catch to this logic, | ||
| // while cleaner is running if there is a pending replacecommit then those files are not cleaned. | ||
| // TODO: This case has to be handled. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you file a tracking ticket for this and link here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Created couple of tickets please review them.
https://issues.apache.org/jira/browse/HUDI-6351
https://issues.apache.org/jira/browse/HUDI-6352
|
@suryaprasanna Hi, can you update and fix the test failures? |
Summary: Maintain commit timeline even in case of long standing inflights Test Plan: Will include unit tests. Reviewers: satishkotha, O955 Project Hoodie Project Reviewer: Add blocking reviewers Reviewed By: satishkotha, O955 Project Hoodie Project Reviewer: Add blocking reviewers JIRA Issues: HUDI-1259 Differential Revision: https://code.uberinternal.com/D6483879
|
@danny0405 My bad, noticed that a fix went in recently(Jan 2023) which will block the issue from happening. |
3b336af to
da86a92
Compare
danny0405
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, I love this fix.
Change Logs
Leaving inflight files in the timeline can cause various problems. In the past we have seen issues, when oldest inflight commit is the first commit in the timeline. In that case readers treated the files written by the oldest files as valid.
In the existing logic there are lot of checks for multiwriter case, pending compaction and replacecommit etc. This proposed change has a unified approach to address all of such cases.
The change is to keep the timeline intact by finding the greatest completed commit in the timeline that is lower than oldest inflight commit, this commit is called oldestCommitToRetain. And any instant that is greater than or equal to this commit value is not eligible for archival.
Impact
Instead of tracking the oldestInflight commit, now we are tracking the completed commit that is before this inflight commit.
Risk level (write none, low medium or high below)
Added unit tests to test the changes.
Documentation Update
This changes effects internal features required documentation is provided as part of the comments.
Contributor's checklist