Skip to content

Conversation

@suryaprasanna
Copy link
Contributor

@suryaprasanna suryaprasanna commented May 22, 2023

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

  • Read through contributor's guide
  • Change Logs and Impact were stated clearly
  • Adequate tests were added if applicable
  • CI passed

@suryaprasanna suryaprasanna changed the title Archival enhaceements Archival enhancements May 22, 2023
@danny0405
Copy link
Contributor

@suryaprasanna Thanks for the contribution ~, can you elaborate a little more what are we want to improve for archiving?

@danny0405 danny0405 self-assigned this May 23, 2023
@danny0405 danny0405 added area:table-service Table services metadata area:performance Performance optimizations priority:medium Moderate impact; usability gaps labels May 23, 2023
@suryaprasanna suryaprasanna changed the title Archival enhancements Maintain commit timeline even in case of long standing inflights May 26, 2023
@suryaprasanna
Copy link
Contributor Author

@danny0405 Thanks for reviewing this PR. Added more context to the PR. Please take a look.

@danny0405
Copy link
Contributor

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

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.

@suryaprasanna
Copy link
Contributor Author

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.
For example, when cleaner's earliestToRetain can cross the inflight instant and when this inflight file is committed, we will have different versions of the files left in the partitions. These kind of various cases can play out.
So, I was thinking we need to have similar logic for both archival and cleaner. So, if there is a inflight commit present then both the archival and cleaner cannot cross the largestCompletedInstant i.e. < oldestInflighiInstant.
We can say cleaner's earliestCommitToRetain similarly archival's max instant to archive cannot cross this commit.

That is why I am trying to keep largestCompletedInstant that is less than the oldestInflightinstant from getting archived.

@danny0405
Copy link
Contributor

when cleaner's earliestToRetain can cross the inflight instant

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this simplifies a lot :)

Copy link
Contributor

@danny0405 danny0405 Jun 1, 2023

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
Copy link
Contributor

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

Copy link
Contributor Author

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")),
Copy link
Contributor

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

Copy link
Contributor Author

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");
Copy link
Contributor

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.
Copy link
Contributor

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nsivabalan nsivabalan changed the title Maintain commit timeline even in case of long standing inflights [HUDI-5569] Maintain commit timeline even in case of long standing inflights Jun 1, 2023
@danny0405 danny0405 added priority:critical Production degraded; pipelines stalled and removed priority:medium Moderate impact; usability gaps labels Jun 5, 2023
@danny0405
Copy link
Contributor

@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
@suryaprasanna
Copy link
Contributor Author

@danny0405 My bad, noticed that a fix went in recently(Jan 2023) which will block the issue from happening.

@hudi-bot
Copy link
Collaborator

CI report:

Bot commands @hudi-bot supports the following commands:
  • @hudi-bot run azure re-run the last Azure build

Copy link
Contributor

@danny0405 danny0405 left a 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:performance Performance optimizations area:table-service Table services priority:critical Production degraded; pipelines stalled

Projects

Status: ✅ Done

Development

Successfully merging this pull request may close these issues.

4 participants