关于msck是否可以删除分区

最新推荐文章于 2024-08-15 14:09:45 发布

不会Hive的啊扬

最新推荐文章于 2024-08-15 14:09:45 发布

阅读量221

点赞数

文章标签：大数据 hive hdfs Powered by 金山文档

本文链接：https://blog.csdn.net/m0_70949976/article/details/129349525

版权

文章讨论了在Hive2.1.1版本中，msckrepairtable命令只能添加而不能删除分区的情况。作者通过实验验证了这一行为，并提出在某些新版本的Hive中，该命令支持删除过期元数据。为了解决这个问题，作者建议手动删除不存在的分区或创建空分区来修复元数据。

摘要由CSDN通过智能技术生成

摘要：

众所周知，msck命令可以将分区目录的分区信息存储于元数据中，也就手动创建分区目录后，msck可以增加分区，但是如果分区已经存在，我删除分区文件后，msck命令是否能将删除的分区文件对应分区也drop掉呢？

问题：

今天创建的表，历史同步出问题，dt>=今天(21号)就可以，dt>=昨天就不行报错，而第一次运行dt>=今天的时候其实也可以，但第二次就死活不行了，但是不应该啊，就算我大于等于公元前也不该有问题啊

报错：

一直报错分区文件找不到

查文件：

这就很奇怪，确实只有10月21的分区目录，看来报错没假，但为什么呢？难道是有昨天的分区？出bug了？

查分区：

show partitions后发现确实是有今天和昨天两个分区，location也确实记录了昨天的目录，难道说在中间这个时间点，组内的同事今天刚好在删昨天的binlog导致？

因为有kudu表，昨天肯定有分区文件，但是昨晚任务失败了。该删却没删掉，一开始没删，是可以正常跑的，丢失分区就被添加到了元数据中，后来第二次的时候正好同事在跑昨晚失败的任务，将分区文件删掉了，我在跑就出问题了

修复分区试试：

msck后发现查询的结果依然是两个分区，难道说，msck只能修复增加的分区文件，无法修复删除的分区文件？

测试：

我刚好这里有tmp.zhangyang的内部表和tmp.zhangyang1的外部表，都Location对应相同的文件，我把内部表删掉，文件就刚好消失，观察外部表分区变化情况即可

drop table tmp.zhangyang;
msck repair table tmp.zhangyang1;
select * from tmp.zhangyang1;
show partitions tmp.zhangyang1;

果真如此select的时候确实没数据了，文件也确实被删除了，但就算修复分区，分区还是不会被删除

所以说，msck repair table命令在我们使用的 2.1.1版本只能自动化的add分区，而不能drop分区

补充：

在一些新版本的Hive中（比如Fix Version/s:3.0.0, 2.4.0, 3.1.0 ），MSCK REPAIR TABLE 命令能删除掉metastore中的过期元数据信息

翻译为：msck repair table＜tablename＞通常用于将新分区作为目录加载到HDFS或S3上，并且用户希望批量创建丢失的分区的环境中。但是，目前它只支持添加缺少的分区。

如果有任何分区存在于元存储中但不存在于文件系统中，它也应该删除它们，以便真正修复表元数据。也就是说这些版本是支持删除分区的

解决方案：

alter table ods_binlog.ods_binlog_minishop_utf8_avatar_doctorinviterecords_di drop partition(dt='2022-10-20');

补充：可以一次性删除多个分区，例如drop partition(dt<'2022-10-20')是支持的

总结：

msck命令在大多数版本中是不支持drop分区的，只支持add

关注