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