988
MaxCompute跨Region數據遷移指導手冊
概述
大數據計算服務（MaxCompute，原名ODPS）是一種快速、完全托管的 GB/TB/PB 級數據倉庫解決方案。MaxCompute 為用戶提供了完善的數據導入導出方案以及多種經典的分布式計算模型，能夠更快速的解決海量數據計算問題，有效降低企業成本，並保障數據安全。
隨著MaxCompute的多Region部署，一些用戶可能需要把MaxCompute的應用從老的Region上遷移到和自己的業務係統相同的Region上來，從而在數據傳輸上獲得更好的性能並減少數據傳輸費用。本指導手冊主要聚焦在數據遷移層麵上，目標在於指導客戶以最小業務影響的代價、簡單高效的方法將數據遷移到其他Region上來。
在數據遷移完成後，用戶可能需要做後續的諸如賬號權限的遷移、大數據開發套件的任務的遷移甚至更加上遊的產品遷移，本手冊暫時不涉及這些內容，需要用戶自行遷移。
本方案並非產品提供的標準服務範圍內，強烈建議用戶使用前先review源碼並做好測試。
MaxCompute數據遷移方案
遷移流程說明
整個遷移的任務，分為準備工作、數據遷移、以及最後的結果驗證。
圖2.1 遷移實施流程
數據遷移的過程已經基於MaxCompute的Java SDK實現了，用戶可以根據後麵的操作步驟進行操作即可完成。如果有一些預期外的報錯或者特殊需求無法實現的話，我們也提供了整個工程的打包，用戶可以把代碼進行修改後重新編譯執行。
準備工作
項目創建
本次遷移是針對同一個用戶下有多個Project的場景做的。假設用戶已經創建雲賬號、通過了實名認證並且已經創建好2個Project並且其中有一個待遷出的Project內有數據。
理論上本方案也支持跨賬戶間的不同的Project的遷移。不過由於時間比較倉促，並未對這些方麵進行完備測試，如用戶有這方麵的需求需要用戶自行調試。
環境搭建
首先用戶需要一台能連接到MaxCompute的服務器，可以是ECS雲服務器，也可以是有公網訪問能力的自己的電腦比如一台筆記本電腦。
需要參考文檔安裝MaxCompute的客戶端。具體可以參考https://help.aliyun.com/document_detail/27804.html。 需要注意的是MaxCompute客戶端需要JRE 1.7或以上版本。下載安裝完成後，需要配置客戶端的參數文件。用戶需要配置2個參數文件，分別對應嵌入的項目和遷出的項目，後續的說明裏，有數據待遷出的項目的參數文件是odps_config_from.ini，待遷入的項目的參數文件是odps_config_to.ini。
具體下載客戶端的操作步驟：
mkdir ~/maxcompute
cd ~/maxcompute/
wget https://repo.aliyun.com/download/odpscmd/latest/odpscmd_public.zip
unzip odpscmd_public.zip
cd ./conf
cp odps_config.ini odps_config_from.ini
填寫相關信息
cp odps_config_from.ini odps_config_to.ini
修改project信息
數據遷移
把打包出的jar包（或者直接使用附件提供的migrate.jar）傳到~/ maxcompute/ 這個路徑下。
java -classpath ./migrate.jar:./lib/* com.aliyun.maxcompute.Migrate /root/maxcompute/conf/odps_config_from.ini /root/maxcompute/conf/odps_config_to.ini
觀察裏麵的日誌，特別是WARNING和ERROR級別的日誌。
遷移的代碼會執行3個步驟：
1. 讀取配置文件，並通過show tables命令來校驗配置是否生效，是否能正常訪問數據庫。（會打印返回的第一張表的名字或者提示找到0張表）
2. 做表meta的遷移，把表結構拷貝過來。對於外部表不會遷移。如果是視圖會執行一次SQL，但是由於視圖涉及的表可能在排在這個視圖之後才導入，所以可能有一些視圖不會遷移成功（不成功的視圖有WARNING級別的日誌），需要用戶手工繼續遷移這些失敗的視圖。
3. 數據遷移，在技術選型上，有Tunnel和SQLTASK使用SQL拷貝數據兩種方案。對此做了對比，本文檔選擇使用SQLTASK作為數據遷移的方案。主要考慮到Tunnel方案相對比較複雜，而且數據要上傳下載對傳輸服務器的壓力較大，而且走公網可能會受到網絡的瓶頸。再者用Tunnel需要事先創建好分區，而目前創建表和分區的操作速度還不盡人意，如果有的用戶需要遷移的表或者分區特別多，這個時間無法忍受。
注意事項
首先本遷移方案使用SQL進行遷移，每個表的數據同步會對應到MaxComupute的一個SQL，因此可能會產生計算費用（體現在導入的project裏）。
瓶頸限製
本方案使用SQL進行數據同步，所以會受到MaxCompute關於SQL的各種限製。主要體現在分區表上。如果用戶的分區表的分區數量特別多，超過了一萬個，會導致報錯。屆時需要用戶自行對這個表做數據遷移。遷移方案是使用SQL，每次Insert的時候用Where條件過濾隻遷移部分的分區，把一張表通過多個SQL作業進行遷移。另外對於分區表的分區特別多的場景，動態分區的MergeTask可能會多消耗一些時間，這是符合預期的（這是目前針對分區表裏分區特別多的場景裏最快速的方案了）。
本作業會提交大量的SQL作業，從而對集群產生一定的壓力。目前MaxCompute對用戶提交的作業會進入排隊，並不會馬上執行。如果需要同步的表較多，可能排隊時間會比較長。特別是提現在導入項目是包年包月的項目，但是購買的CU較少的情況下。可以考慮購買更多的CU或者耐心等待。如果是按量付費的項目，由於集群的整體資源以及集群上的安全限製等原因，也可能會出現任務排隊的情況。這是符合遷移預期的。
驗證方法
- 查看日誌，是否有WARNING級別和ERROR級別的日誌，並根據錯誤的提示進行排查定位。
- 同步結束後，查看表的數量和表結構是否能對上。不過表的size字段無法作為數量的核對標準。數據在傳輸過程中可能會經過shuffle，再經過列式壓縮的時候，壓縮後的數據量可能會發生變化。當然如果有太明顯的變化比如為0那就是有問題的。校驗數據量可以用SQL來查詢一下裏麵的數據，看看統計結果是否能對上。而且MaxComute本身計算有校驗。MaxCompute SQL如果沒有報錯的話，數據的同步時候沒有問題的。
最後更新：2017-11-05 18:03:40