TFS集群間資料遷移任務總結

來自：

最近幾天在做乙個集群間資料遷移的任務，要做的事很簡單，就是給定乙個任務檔案，檔案中每一行對應乙個source:dest形式的遷移任務（source和dest均為檔名），任務數在千萬級別。要做的事情其實很簡單，讀取每一行，解析出source和dest，並根據給定的集群資訊從源集群讀取source，並寫到目標集群的dest。

經歷了寫程式、執行任務、分析日誌、改程式、再執行子任務...等多次折磨之後，發現自己在處理任務的過程中走了很多彎路，原因是剛開始沒有意識到問題的複雜性，處理的方式太過簡單，這裡說下我對這種大批量任務處理的一些心得。

大批量任務處理主要從以下兩個方面來考慮：效能和正確性。

效能主要通過任務執行的時間來衡量，主要是通過優化每條任務的執行時間和並行處理實現。本次資料遷移的任務，每次遷移需要從源集群讀取檔案，並且寫到目標集群，由於讀寫都是通過客戶端介面實現，故能優化的地方僅僅是在讀的時候合理的利用好客戶端cache；檔案名字空間是扁平化的，檔案之間看不出任何的聯絡，也無法通過重新組織任務順序的方式來進行優化。由於子任務之間沒有任何依賴和聯絡，遷移任務是非常適合採用多程序或多執行緒的方式並行處理的，1000w條任務，每秒大約能處理30個任務（可理解為一次隨機讀和一次隨機寫的時間），單程序（單執行緒）順序處理時間約為3.9天，如果10個程序（執行緒）同時處理，則處理時間約為10個小時。為了減少編碼工作量，我採用的方式是編寫乙個簡單的單執行緒讀寫程式，在外圍將待處理任務檔案分成10個子檔案，啟動10個程序分別處理各個子檔案。這裡劃分成10個任務的原因：（1）方便計算；（2）10個小時的處理時間能夠接受，剛好睡一覺程式就跑完了；（3）10個程序並行，網絡卡也快跑滿了。

接下來說說正確性，其實這塊是最不好處理的，每一條遷移任務執行失敗可能有很多原因，如任務描述不合法、讀取源（這裡又可細分為多個階段）失敗，寫目標失敗（這裡也可細分)，對於發生錯誤的情況，有些錯誤時必然錯誤，如給定的源或目標不符合規則、原始檔不存在等；有些錯誤可能只是偶然，如讀取某個檔案，只成功讀到一部分，這種錯誤通過重新執行任務可以避免；還有些錯誤可能是由於程式（工具程式、甚至是客戶端庫）的bug造成，通過修改程式可避免這類錯誤。

通過日誌的方式可以區分以上提到的不同情況，這幾天發現列印日誌其實是很需要技巧的，並不是隨便輸出點資訊就叫打了日誌（這裡不討論日誌分級別列印的情況，只討論日誌內容輸出的技巧）。

首先對於描述錯誤資訊的日誌，必須能從日誌中迅速定位出錯誤位置及原因，在日誌內容上的描述上，日誌內容需要能很方便餵給grep、awk等工具分析，從而避免再去寫日誌分析工具。另外日誌中最好詳盡的描述錯誤的任務資訊，這樣再二次處理的時候就不用再去從任務檔案中分析出錯誤的任務，我剛開始寫遷移程式的時候，在讀不到source的時候，只列印了source的資訊，結果要二次處理這些任務項時，還另外寫了乙個python指令碼，把這些項從任務檔案分析出來，而如果把source:dest，只需awk下就能從日誌中得到錯誤的任務，重新處理。

對於本文提到的資料遷移任務，我總結了一套行之有效的日誌列印方法：

1.區分錯誤日誌和結果日誌，錯誤日誌記錄發生錯誤時的具體資訊，結果日誌為任務執行的具體結果（成功還是失敗）。處理乙個任務可能對應很多條（包括使用到的庫列印的錯誤日誌），但每個任務只對乙個一條結果日誌，結果日誌最好包含任務描述的所有資訊；

2. 將任務劃分成多個階段，該資訊在任務處理過程中不斷更新，如果某個任務出錯，在結果日誌中列印任務執行到的階段和錯誤資訊（錯誤碼），通過階段資訊快速定位錯誤位置，通過錯誤描述資訊（錯誤碼）進行錯誤分類。

3. 將錯誤日誌和結果日誌輸出到不同的位置，簡單的實現可將錯誤和結果日誌分別輸出到stderr和stdout，並將stderr和stdour重定向到不同的檔案。

通過結果日誌，可以將執行完的任務按照錯誤資訊快速分類（grep），對不同的錯誤情況進行不同的處理；而當需要確切知道出錯的具體原因時，則可分析錯誤日誌。

最後，如果對遷移後的資料正確性要求很高，可在遷移過程中做下crc或md5檢查，或是編寫額外的check工具進行全面的檢查工作，而這個工作的性質與遷移的工作非常類似。

TFS集群間資料遷移任務總結

Elasticsearch集群間資料遷移

hive集群間資料遷移，export import

集群之間資料的遷移

TFS集群間資料遷移任務總結

Elasticsearch集群間資料遷移

hive集群間資料遷移，export import

集群之間資料的遷移

相關推薦