hadoop - Drop Hive Table和MSCK修复失败，表存储在Google云存储桶中

Question

我正在使用下面的SQL语句在Google Cloud Bucket中创建配置单元表。

CREATE TABLE schema_name.table_name (column1 decimal(10,0), column2 int, column3 date) 
   PARTITIONED BY(column7 date) STORED AS ORC
   LOCATION 'gs://crazybucketstring/' 
   TBLPROPERTIES('ORC.COMPRESS'='SNAPPY');

然后，我使用distcp命令将数据加载到该表中，现在，当我尝试删除表时，它失败并显示以下错误消息，即使我尝试删除空表也失败了。

hive>>DROP TABLE schema_name.table_name; 

**Error:** Error while processing statement: 
FAILED: Execution Error, return code 1 from 
org.apache.hadoop.hive.ql.exec.DDLTask.MetaException
(message:java.lang.IllegalArgumentException: `hadoopPath must not be null`)
(state=08S01,code=1)

我还使用gsutil rm -r gs://命令从Google Cloud Storage存储桶中删除了文件，但仍然无法删除表并给出相同的错误
同样在运行msck repair table时，它给出以下错误。

FAILED: 
Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask (state=08S01,code=1) 

任何想法可能有什么问题吗？

Answer 1

问题与存储桶位置有关。我将尝试逐步解释如何重新创建它以及如何解决它。同样的问题也导致无法运行msck repair命令。
如何重新创建它:

首先，我创建了一个表(T1)，其位置指向此处给出的存储桶:LOCATION 'gs://crazybucketstring/'

然后我在子文件夹中用给定的位置创建了另一个表(T2)内存储桶
下面LOCATION gs://crazybucketstring/schemname/tableaname/

现在，当我尝试删除第一个表(T1)时，它将引发整个错误
存储桶的行为与表相同，它不能删除存储桶，它只能
删除文件。

当我尝试删除表(T2)时，我可以删除它，并且存储桶子目录中的文件也被删除，因为它是托管表。表T1仍然令人头疼。

为了删除表T1，我拼命地删除了存储桶，并使用gsutil rm -r命令清空了存储桶，并尝试了msck repair table tablename，奇怪的是msck repair命令失败，并显示以下错误消息

>>  msck repair table tablename
Error: Error while processing statement: FAILED: 
Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask (state=08S01,code=1)

像往常一样，DROP命令仍然不起作用。
解决方案:
最终我得到了可行的想法。

我更改了表T1并将其位置设置到存储桶(而不是裸存储桶)内的子目录中。ALTER TABLE TABLENAME SET LOCATION gs://crazybucketstring/schemname/tableaname/

现在，我进行“msck修复”，并且不会引发任何错误。

我发出了DROP Table命令，它起作用了。

This issue is related to Table Location which we should deal with carefully while creating more than 1 Table in same bucket. Best practice is to use different subdirectories inside bucket to create different tables and avoid using just bucket path as table location specially if you have to create multiple tables in same bucket. Thank you and feel free to reach out to Me for Big Data issues.