前言
在目前單一大HDFS集羣越來越無法支撐我們的業務場景時，越來越多的公司開始考慮採用HDFS federation方案來做。這裏就自然會衍生出一個問題：新federation出來的Namespace，我如何將數據從原集羣（NameNode）同步出來呢？而且在這個過程中，還會有每天增量數據的寫入在老集羣內。假若只是靜態的數據，我們啓動一個distcp任務就可以做這部分跨namespace的數據的同步了，但是有了增量數據這個影響因素，這個事情就稍微會變得複雜一點了。最近Hadoop社區在做關於這塊的實現和討論，也實現了一個初始的HDFS federation間的balance工具。本文來聊聊此工具內部的實現細節，相信這個工具在我們實際的生成環境下還是十分有用處的。
粗粒度的federation Balance方案
關於federation Balance的使用場景，主要來源於下面兩種情況：
- 純粹爲了平衡各個federation NN上的數據，防止一個集羣下的數據量過多進而出現性能瓶頸問題，這種情況在已經使用多集羣管理方案下(HDFS RBF或者ViewFs)是比較常見的，
- 新增federation namespace時，從原有的namespace下拆離出數據到新的namespace，這時我們也有着方面的數據同步的需求。
關於上面提到的第二點，筆者在之前寫過一篇基於initial distcp + 多次snapshot diff ditcp的方案，不過那套方案執行起來比較的粗粒度，還不是特別的完善，需要額外大量的手工重複的命令的執行。與此粗粒度federation Balance方案的細節可參閱筆者之前寫的文章：HDFS數據遷移解決方案之DistCp工具的巧妙使用。
系統化的federation Balance工具方案
本文筆者所要闡述的是上述粗粒度federation Balance方案的完善版本，即工具化的完整實現方案，目前社區已經有對應的實現在討論了。
工具化實現方案和上面談論的粗粒度的Balance方案在本質原理上是一樣的，分兩階段執行：
1）第一階段，執行首次distcp數據拷貝。
2）第二階段，執行後續diff的distcp來做拷貝，基於目錄的snapshot來做，每次執行完一次diff的distcp，隨後比較一次此時快照和當前文件目錄最新的狀態，如果還是有updated的change diff，再執行diff的distcp拷貝直到數據完全無差異爲止。
同步原理如下圖所示：
相比較於純手工觸發執行distcp去做初始和diff的拷貝，federation balance方案還考慮了額外以下幾點：
- ditcp任務的schedul執行管理，這樣用戶只需命令提交一次Balance任務，後續的distcp任務會在Job裏面被調度起來。
- BalanceJob的信息持久化，這裏持久化的外部存儲爲HDFS，這是爲了防止BalanceJob一旦沒有執行完畢，下次可從HDFS數據中恢復這些未執行的Job。
- 源端文件目錄的自動清理，這個發生在BalanceJob執行完畢的收尾階段，當我們完全將數據從源集羣拷貝到目標集羣后，我們就可以從原集羣中把這部分數據給清理掉了。
多了上述的細節完善，這樣使得整個工具能夠更爲方便的給admin來使用，減少了很多額外人工的數據同步操作的處理。
在federation Balance內部工具方案的實現中，它的原理過程如下圖所示：
對應上述步驟的過程：
- 1，2）命令行入口，提交的主程序入口，提交一個新的BalanceJob或者從HDFS上讀取BalanceJob ，恢復上次失敗的未執行Job，然後提交到以個JobQueue內。
- 3）WorkThread工作線程從JobQueue內拉取BalanceJob來執行。
- 4）WorkThread開始調度執行BalanceJob時，將Job信息持久化到HDFS裏去，爲了做Job失敗的recovery。
- 5）BalanceJob結束了，WorkThread從HDFS中將之前寫入的BalanceJob信息進行移除。
整個過程不是特別的複雜。
上述federation balance工具化方案整體來看，實現比較清晰，而且沒有在HDFS內部通過鎖目錄的方式來做數據的精準同步，巧妙利用distcp支持的diff拷貝來做增量同步，這個應該是目前來看是造成user impact比較小的方案了。上面所有的實現細節來自於社區JIRA HDFS-15294：RBF: Balance data across federation namespaces with DistCp and snapshot diff，感興趣的同學可閱讀其具體代碼實現。
引用
[1].https://issues.apache.org/jira/browse/HDFS-15294