我有1个30TB的分区表，客户给的带宽只有600MB，按照150%的耗时来算，大概要迁移17小时。
使用hive自带的修复分区命令（一般修复分区比迁移时间长一点），可能要花24小时。于是打算用前面黄大佬的牛B方案。

---

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

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

2）数据迁移 同distcp

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

例如之前修复一个1000个分区的表，需要8h

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倍。