Skip to content
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

[HUDI-7507] Adding timestamp ordering validation before creating requested instant #11580

Open
wants to merge 3 commits into
base: branch-0.x
Choose a base branch
from

Conversation

nsivabalan
Copy link
Contributor

@nsivabalan nsivabalan commented Jul 5, 2024

Change Logs

When multiple writers trigger table services, there is a chance that one of them could create requested in a different ordering compared to the actual timestamp. Linked jira has more details of the scenario w/ an illustration. This patch, ensure that before creating a requested entry in the timeline, there is no other instant greater than the current instant time.

Major reason is, a writer could generate a new commit time in memory (say t10), and then take a long time to do some computation and eventually add the requested instant to timeline very late (say t100). In b/w these two time, there could be another concurrent writer choosing t25 as commit time and proceed. This might lead to unexpected behaviors as called out in the jira.

This patch is for 0.x branch.
here is the equivalent 1.x branch PR #11344

Impact

Describe any public API or user-facing feature change or any performance impact.

Risk level (write none, low medium or high below)

If medium or high, explain what verification was done to mitigate the risks.

Documentation Update

Describe any necessary documentation update if there is any new feature, config, or user-facing change. If not, put "none".

  • The config description must be updated if new configs are added or the default value of the configs are changed
  • Any new feature or user-facing change requires updating the Hudi website. Please create a Jira ticket, attach the
    ticket number here and follow the instruction to make
    changes to the website.

Contributor's checklist

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

@github-actions github-actions bot added the size:M PR with lines of changes in (100, 300] label Jul 5, 2024
@@ -931,6 +932,7 @@ private void startCommit(String instantTime, String actionType, HoodieTableMetaC
"Found pending restore in active timeline. Please complete the restore fully before proceeding. As of now, "
+ "table could be in an inconsistent state. Pending restores: " + Arrays.toString(inflightRestoreTimeline.getInstantsAsStream()
.map(instant -> instant.getTimestamp()).collect(Collectors.toList()).toArray()));
TimestampUtils.validateForLatestTimestamp(metaClient, instantTime);
Copy link
Contributor

Choose a reason for hiding this comment

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

As discussed, this will need to be under a transaction as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

addressed this

Copy link
Contributor Author

@nsivabalan nsivabalan left a comment

Choose a reason for hiding this comment

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

hey @yihua or @codope or @danny0405 : can one of you review this patch

@hudi-bot
Copy link

CI report:

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

@@ -113,6 +113,7 @@ protected Option<HoodieRollbackPlan> requestRollback(String startRollbackTime) {
HoodieRollbackPlan rollbackPlan = new HoodieRollbackPlan(new HoodieInstantInfo(instantToRollback.getTimestamp(),
instantToRollback.getAction()), rollbackRequests, LATEST_ROLLBACK_PLAN_VERSION);
if (!skipTimelinePublish) {
table.validateForLatestTimestamp(rollbackInstant.getTimestamp());
Copy link
Contributor

Choose a reason for hiding this comment

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

Only the compaction instant timestamp should be kept serial with the regular instant timestamps, the other table actions are okay (for e.g. clustering, rollback, cleaning).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
size:M PR with lines of changes in (100, 300]
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants