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)