[
https://issues.apache.org/jira/browse/HUDI-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17261638#comment-17261638
]
Vinoth Chandar commented on HUDI-1276:
--------------------------------------
Case 1: So, we can only restore within the configured cleaner retained commits,
right? We only delete f1_c1, f1_c2, f1_c3 when f2_c4 is cleanable. i.e enough
commits have happened after t4. We don't clean based on c1,c2,c3 i.e the
replaced file's commit times, it can be arbitrarily in the past.
So yes, as long as t4 is not not cleaned, f1_c1 wont be deleted and we should
be able to restore, by deleting everything else. Replace simply follows the
same rules as commits.
Case 2: I think the above answers this as well. We clean based on the
replacecommit's timestamp not the "replaced" file group's timestamps.
> In other words, f1_c1 wont be deleted until t1 has not been archived.
What I am doing is even more conservative and IMO the correct thing. f1_c1 wont
be deleted until t4 is cleaned.
yes. we can think about simplifying cleaning etc, once RFC-15 is fully baked in
the next month or so.
> delete replaced file groups during clean
> ----------------------------------------
>
> Key: HUDI-1276
> URL: https://issues.apache.org/jira/browse/HUDI-1276
> Project: Apache Hudi
> Issue Type: Sub-task
> Reporter: satish
> Assignee: Vinoth Chandar
> Priority: Blocker
> Fix For: 0.7.0
>
>
> We clean replaced file groups during archival as part of PR#2048. But we may
> want do this during clean stage to prevent storage overhead.
> Outstanding questions:
> 1) With KEEP_LATEST_VERSIONS, when is a replaced file eligible to clean?
> Assume file slice has f1_c1, f1_c2. After that 'f1' is replaced by some other
> file groups. If KEEP_LATEST_VERSIONS=2 When can we delete f1_c1, f1_c2?
> Options:
> * We can introduce new policy to delete replaced files. For example, we could
> fallback to KEEP_LATEST_COMMITS for replaced files
> * Build 'slice' across file groups. If we know the new files that are
> replacing 'f1', then we can treat as single slice and delete oldest versions.
> This can get really complicated because f1 can be replaced by multiple file
> groups which can then be replaced by some other file groups
> 2)If there is a savepoint on the fileId that is eligible to clean, can we
> delete it?
> Options:
> * Do not delete the file. Clean and archival cannot make progress. We need a
> mechanism to notify that clean and archival are blocked.
> * Ignore savepoints and delete the file. This is breaking contract. (This is
> current behavior with deleting files during archival)
> 3)If there is a pending/inflight compaction on the fileId that is eligible to
> clean, can we delete it? What happens to compaction scheduled if we delete it?
> * This is unlikely to happen because we dont replace files that have pending
> compaction. Also, after a file is replaced, it is not visible to compaction,
> so any further compaction cannot be scheduled. However, if for any reason,
> we see replaced files that have pending compaction, and are eligible to
> clean, its probably better to block clean and archival
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
