我有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内
上面是他的方案，我实战测试下
实战测试
1、先查询指定库的分区有几个（源端查）
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);
2、然后打开notepad++，用ctrl + f 正则处理一下
大概就处理成这样
测试：
在目标端，因为我们没有修复分区，所以这里迁移完数据和元数据后，他们是查不出来数据的。
beeline -u 'xxx'
select * from xxx limit 1;
没有数据
3、接下来我们将500多条语句丢进Hive执行一下（手动分区修复）。
然后我们在执行一下查询
select * from xxx limit 1;
有数据了，手动修复成功，比hive MSCK REPAIR TABLE table_name分区命令快n倍。
