You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@hudi.apache.org by "Ethan Guo (Jira)" <ji...@apache.org> on 2024/03/29 00:35:00 UTC
[jira] [Updated] (HUDI-5722) Re-think restore for MOR table
[ https://issues.apache.org/jira/browse/HUDI-5722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ethan Guo updated HUDI-5722:
----------------------------
Component/s: restore
table-service
> Re-think restore for MOR table
> ------------------------------
>
> Key: HUDI-5722
> URL: https://issues.apache.org/jira/browse/HUDI-5722
> Project: Apache Hudi
> Issue Type: Improvement
> Components: dev-experience, restore, table-service, writer-core
> Reporter: sivabalan narayanan
> Priority: Critical
>
> As of now, our restore is triggering N rollbacks in reverse chronological order.
> for MOR table, we need to re-think this, since our rollbacks are log appends, even if we want to restore to a delta commit just before last compaction, instead of directly cleaning up the lastest file slice, we are triggering rollbacks of N delta commits and finally cleaning up the entire file slice when the compaction instant is being rolledback.
>
> we can optimize things better here for MOR table. we just need to re-think restore from scratch w/o the need for going thru N rollbacks.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)