hive迁移后修复分区慢，怎么办？

我有1个30TB的分区表，客户给的带宽只有600MB，按照150%的耗时来算，大概要迁移17小时。

使用hive自带的修复分区命令（一般修复分区比迁移时间长一点），可能要花24小时。于是打算用前面黄大佬的牛B方案。

msck repair table分区慢的原因：

与当前分区目录下的文件大小无关，只与分区目录【数量】有关，分区目录越多，二级（或子级）目录越多，分区就越慢

Hive增量迁移：创建表结构+数据迁移(distcp)+修复分区

1）创建表结构读取cdh的建表语句，在tbds上创建表

2）数据迁移同distcp

3）分区数据 msck repair table XX（alter table XX recover partitions）修复太慢；改用查询元数据库，对比两边分区数据差异项，然后拼接成add partition语句，来执行。

例如之前修复一个1000个分区的表，需要8h（质疑？--我后面用了10T的表，测试了下200个一级分区也才3分钟修复）

hive:

一级分区：alter table XX add partition (etl_date=20240101);

alter table XX add partition (etl_date=20240101);

二级分区：alter table XX add partition (etl_yn=2024,etl_mn=01);

alter table XX add partition (etl_yn=2024,etl_mn=01);

改用add partition后，1000个分区的表，10min内

上面是他的方案，我实战测试下

实战测试

beeline -u 'xxxx'进入hive

show create table 表名

查看他的分区字段

这里我们能看到他就1个分区，而且字段是dt，接下来我们来查下dt有多少个

select distinct(dt) from xxx

查询这个表30T的表，大概花了110秒

我们能看到他是以日进行分区的。

并且有542行。我们先把这个复制出来，然后拼凑成sql。

alter table XX add partition (dt=20240101);

大概就处理成这样

测试：

在目标端，因为我们没有修复分区，所以这里迁移完数据和元数据后，他们是查不出来数据的。

beeline -u 'xxx'

select * from xxx limit 1;

没有数据

然后我们在执行一下查询

select * from xxx limit 1;

有数据了，手动修复成功，比hive MSCK REPAIR TABLE table_name分区命令快n倍。