[
https://issues.apache.org/jira/browse/HIVE-25535?focusedWorklogId=652991&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-652991
]
ASF GitHub Bot logged work on HIVE-25535:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 20/Sep/21 14:16
Start Date: 20/Sep/21 14:16
Worklog Time Spent: 10m
Work Description: deniskuzZ commented on a change in pull request #2651:
URL: https://github.com/apache/hive/pull/2651#discussion_r712203180
##########
File path: ql/src/java/org/apache/hadoop/hive/ql/txn/compactor/Cleaner.java
##########
@@ -179,6 +180,13 @@ private void clean(CompactionInfo ci, long minOpenTxnGLB,
boolean metricsEnabled
txnHandler.markCleaned(ci);
return;
}
+ if (MetaStoreUtils.isNoCleanUpSet(t.getParameters())) {
+ // The table was marked no clean up true.
+ LOG.info("Skipping " + ci.getFullTableName() + " clean up, as
NO_CLEANUP set to true");
+ txnHandler.markCleaned(ci);
Review comment:
if we won't call ````markCleaned```` that would lead to the accumulation
of COMPACTION_QUEUE entries in READY_FOR_CLEANING state (mil of duplicates) +
infinite re-try every 5 sec (default).
However, if we do - some of the obsolete files could stay forever when there
are no new writes after the user re-enables the config. I don't think this is
applicable to the use-case this JIRA is trying to address.
PS: would it be sufficient to have a config that disables the Cleaner
completely?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscr...@hive.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 652991)
Time Spent: 1h 10m (was: 1h)
> Control cleaning obsolete directories/files of a table via property
> -------------------------------------------------------------------
>
> Key: HIVE-25535
> URL: https://issues.apache.org/jira/browse/HIVE-25535
> Project: Hive
> Issue Type: Improvement
> Reporter: Ashish Sharma
> Assignee: Ashish Sharma
> Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> *Use Case* -
> When external tool like [SPARK_ACID |https://github.com/qubole/spark-acid]try
> to access hive metastore directly instead of accessing LLAP or hs2 which
> lacks the ability of take acquires locks on the metastore artefacts. Due to
> which if any spark acid jobs starts and at the same time compaction happens
> in hive with leads to exceptions like *FileNotFound* for delta directory
> because at time of spark acid compilation phase delta files are present but
> when execution start delta files are deleted by compactor.
> Inorder to tackle problem like this I am proposing to add a config
> "NO_CLEANUP" is table properties and partition properties which provide
> higher control on table and partition compaction process.
> We already have
> "[HIVE_COMPACTOR_DELAYED_CLEANUP_ENABLED|https://github.com/apache/hive/blob/71583e322fe14a0cfcde639629b509b252b0ed2c/common/src/java/org/apache/hadoop/hive/conf/HiveConf.java#L3243]";
> which allow us to delay the deletion of "obsolete directories/files" but it
> is applicable to all the table in metastore where this config will provide
> table and partition level control.
> *Solution* -
> Add "NO_CLEANUP" in the table properties enable/disable the table-level and
> partition cleanup and prevent the cleaner process from automatically cleaning
> obsolete directories/files.
> Example -
> ALTER TABLE <tablename> SET TBLPROPERTIES('NO_CLEANUP'=FALSE/TRUE);
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
