Skip to content

[HUDI-7507] Fixing Rollbacks and Cleaning to acquire locks as needed #13064

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

nsivabalan
Copy link
Contributor

@nsivabalan nsivabalan commented Mar 31, 2025

Change Logs

  • If there are two concurrent rollback planning by 2 concurrent writers, each could write two rollback plans to timeline. We are fixing that in this patch. Also, following up on [HUDI-7507] Adding timestamp ordering validation before creating requested instant #11580, we are adding locks to rollback planning as well.
  • Also, for cleaning, we added timestamp validation in PR 11580, but locks were not taken. We are adding locks to clean as well for performing timestamp validation.

This is targetted against 0.x branch.

Impact

Robust rollback planning even in the event of concurrent writers/planners.

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

low

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

…s before adding new rollback requested to timeline
@github-actions github-actions bot added the size:M PR with lines of changes in (100, 300] label Mar 31, 2025
@github-actions github-actions bot added size:L PR with lines of changes in (300, 1000] and removed size:M PR with lines of changes in (100, 300] labels Mar 31, 2025
@nsivabalan nsivabalan changed the title [HUDI-7507] Fixing rollbacks for concurrent rollback planning [HUDI-7507] Fixing Rollbacks and Cleaning to acquire locks as needed Apr 3, 2025
@@ -153,6 +156,7 @@ protected HoodieTable(HoodieWriteConfig config, HoodieEngineContext context, Hoo
this.index = getIndex(config, context);
this.storageLayout = getStorageLayout(config);
this.taskContextSupplier = context.getTaskContextSupplier();
this.txnManager = new TransactionManager(config, metaClient.getStorage());
Copy link
Contributor

Choose a reason for hiding this comment

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

Not sure we introduce txnManager into hoodie table? It looks like it is only used for rollback, can we move it out?

@nsivabalan
Copy link
Contributor Author

hey @danny0405 :
wrt to not introducing TransactionManager in HoodieTable, here are the changes it might introduce.

  1. Flink: CompactionPlanOperator instantiate TransactionManager and pass it to CompactionUtil.rollbackCompaction(table). Or instantiate TransactionManager in CompactionUtil.
  2. RunCompactionActionExecutor.execute() calls into preCommit which can trigger rollback. And so, this percolates to HoodieTable.logCompact, HoodieTable.compact
    -> which in turn goes into HoodieTableServiceClient.logCompact and HoodieTableServiceClient.comact().
    but this means, we need to change public apis in HoodieTable for compact() and logCompact(), rollback APIs to take in an Option. All of our public apis are very tightly designed. This causes divergence.
  3. Flink: CompactionCommitSink calls into rollbackCompaction(). We need to introduce TransactionManager in CompactionCommitSink.
  4. HoodieFlinkCompactor.compact() could call into rollbackCompaction(). Might have to add TransactionManager to HoodieFlinkCompactor.
  5. BaseHoodieTableServiceClient.purgePendingClustering() can call into rollback. BaseHoodieTableServiceClient.cluster() also could call into rollback. We just need to pass in the TransactionManager.

May main concern is the change in public apis like HoodieTable.compact(), HoodieTable.logCompact(), HoodieTable.rollback*() APIs.

Attaching pic on the APIs we have in HoodieTable :
image
image

For Flink specifically, I might need some help as well (whether CompactionCommitSink is the right place to introduce the TransactionManager or not).

Also, I was looking at places where we instantiate TransactionManager, looks like we don't have it clean either.
image

We have many usages in ActionExecutors which are expected to be called from Hoodie*Table. So, not sure if its worth cleaning it up in this patch where we are looking to fix rollback scheduling. This could be much larger scope if we wanted to clean up the instantiations of TransactionManager to standardize it and keep it at either WriteClient or TableServiceClient.

Let me know what do you think.

@danny0405
Copy link
Contributor

May main concern is the change in public apis like HoodieTable.compact(), HoodieTable.logCompact(), HoodieTable.rollback*() APIs.

The scheduling of clean and rollback should be already separeted from other write APIs I think, maybe just add the fresh new txn manager for these 3 APIs should be good already.

@hudi-bot
Copy link

hudi-bot commented Jun 2, 2025

CI report:

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

@nsivabalan
Copy link
Contributor Author

@danny0405 : ready for review based on our sync up yesterday.

@nsivabalan
Copy link
Contributor Author

image

@nsivabalan nsivabalan merged commit 31dbd89 into apache:branch-0.x Jun 5, 2025
47 of 48 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
size:L PR with lines of changes in (300, 1000]
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants