摘要:
众所周知,msck命令可以将分区目录的分区信息存储于元数据中,也就手动创建分区目录后,msck可以增加分区,但是如果分区已经存在,我删除分区文件后,msck命令是否能将删除的分区文件对应分区也drop掉呢?
问题:
今天创建的表,历史同步出问题,dt>=今天(21号)就可以,dt>=昨天就不行报错,而第一次运行dt>=今天的时候其实也可以,但第二次就死活不行了,但是不应该啊,就算我大于等于公元前也不该有问题啊
报错:
Input path does not exist: hdfs://HDFSNS/Data/d1/hive/warehouse/ods_binlog.db/ods_binlog/table=ods_binlog_minishop_utf8_avatar_doctorinviterecords_di/dt=2022-10-20
一直报错分区文件找不到
查文件:
![](https://i-blog.csdnimg.cn/blog_migrate/1aa0f035025bd309c326517ca2854d0f.png)
这就很奇怪,确实只有10月21的分区目录,看来报错没假,但为什么呢?难道是有昨天的分区?出bug了?
查分区:
![](https://i-blog.csdnimg.cn/blog_migrate/86aefb8b2774dd04bc7a0806fbf20d68.png)
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;
![](https://i-blog.csdnimg.cn/blog_migrate/f4eafab2de6467d03f98581b404969d0.png)
![](https://i-blog.csdnimg.cn/blog_migrate/ebc6c672fa3d8ac8636c92b06dc84580.png)
果真如此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中的过期元数据信息
![](https://i-blog.csdnimg.cn/blog_migrate/5e11497292baffe325888d2a9ecf6cc6.png)
![](https://i-blog.csdnimg.cn/blog_migrate/b7eb763df2b0295518a47a3be19508b9.png)
翻译为:msck repair table<tablename>通常用于将新分区作为目录加载到HDFS或S3上,并且用户希望批量创建丢失的分区的环境中。但是,目前它只支持添加缺少的分区。
如果有任何分区存在于元存储中但不存在于文件系统中,它也应该删除它们,以便真正修复表元数据。也就是说这些版本是支持删除分区的
解决方案:
创建一个20号的空分区目录
手动drop分区:
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