[
https://issues.apache.org/jira/browse/HUDI-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17261507#comment-17261507
]
satish commented on HUDI-1276:
------------------------------
[~vinoth] high level looks reasonable. Few edge cases below.
> once there is a replace, the next clean should be able to delete the whole
> thing.
The absolute worst case example for this is use case that does only
'insert_overwrite' every N minutes (no upserts/bulk_insert/insert used). So,
with this approach, there will only be one version of dataset making rollback,
restore etc difficult. My understanding is there can also be long running
queries that might still be using f1_c1, f1_c2 for some large datasets even
after they are replaced. There could also be time-travel queries that still
need this data. But, probably we can ask users to KEEP_LATEST_COMMITS for these
usecases?
>savepoint
I noticed archival stops if theres a savepoint
https://github.com/apache/hudi/blob/master/hudi-client/hudi-client-common/src/main/java/org/apache/hudi/table/HoodieTimelineArchiveLog.java#L170.
So we may be already covered here
> Once replaced, we should be able to delete based on cleaning policy.
Sounds good. I think executing that compaction is going to fail. so
operationally, we may need something to 'cancel' that compaction so other
subsequent compactions can make progress. But this is probably easy to add and
can be added in docs for now.
> 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: satish
> 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)
