一、背景
隨著同程旅行業務和資料規模越來越大，原有的機房不足以支撐未來幾年的擴容需求，同時老機房的保障優先順序也低於新機房，為了不受限於機房的壓力，公司決定進行機房遷移，為了儘快完成遷移，需要1個月內完成上百PB資料量的叢集遷移，遷移過程不允許停止服務。
目前HADOOP叢集主要有多個2。X叢集版本，2019年升級到聯邦模式，目前有近幾十個namespace，80%的業務都與HDFS相關，資源排程層主要依賴YARN叢集，上游支撐數倉建設、演算法分析、機器學習等多個業務板塊。
二、遷移方案
目前同程旅行有多套HDFS叢集，在新機房搭建多套HDFS叢集成本和資料同步都是不小的工作量，所以這個方案剛開始就被PASS，總體遷移方案規劃是單叢集擴縮容的方式進行遷移。
關於資料遷移有下面2個實現方案：
機房感知策略
副本選擇節點策略
A：增加機房感知策略
透過修改namenode核心程式碼，支援儲存的多機房感知，增加節點的機房屬性。
針對指定遷移的租戶/目錄做任務隔離搭建獨立的yarn，遷移過程中充分利用HDFS本地性和減少跨機房產生的網路頻寬。
按照目錄/租戶的方式進行遷移，方便控制進度和觀察跨機房網路的穩定性
優點
：可以細粒度的進行遷移；過程可控。
缺點
：修改namenode核心程式碼，需要有一定時間來測試再上線；遷移週期相對比較久
B：支援副本策略資料優先寫入新機房
透過策略控制新寫入的資料寫到使用率比較低的DN節點（新機房節點），從生產源頭進行資料轉移，對於歷史的資料可以透過balance指定Iplist和叢集遷移的方式來加快遷移
優點
：可以不依賴具體的目錄/租戶來遷移，可以按照機架來遷移。
缺點
：新的策略對於磁碟使用過低的datanode還是可能會出現一些熱點問題，需要進行改進；balance速度比較慢，滿足不了快速遷移需求；會產生大量的頻寬壓力，高峰期可能會叢集造成額外的RPC壓力。
最後我們選擇方案B，理由是：我們需要儘快完成遷移，而且B方案遷移流程相對比較簡單，不過需要對副本選擇策略做原始碼改造，解決datanode的熱點問題，同時對於balance可以進一步做效能最佳化，解決可能的RPC問題。
三、經驗和教訓
1、DN下線過慢
剛開始datanode下線的時候發現一組機架decommssion結束需要6H+，這個相對比較容易解決，需要做下引數最佳化，提高資料replication的速度，最後實現了一組機架下線時間從6個多小時到1個多小時，滿足了遷移的需求。
2、DN資料嚴重不均衡
採取擴縮容策略來進行遷移不可避免的會遇到DN節點下線後，儲存壓力會平攤到剩下的DN節點上，繼而可能出現其他問題，下面是我們遇到的幾個典型的問題。
1）新寫入的資料仍然會選擇DN使用率比較高的節點
目前同程旅行的大資料服務基本都是標準部署模式，DN服務基本和NM服務進行了同節點部署，如果新寫入的資料寫到了使用率比較高的DN上，可能會引發下面兩個問題。
①產生DN熱點，可能影響任務的讀寫
我們的磁碟SKU相差不大，使用率比較高的節點一般會有更多的資料，可能會有更多IO操作，導致硬體出現效能瓶頸，影響到資料的正常讀寫。
②NodeManager無法透過健康檢測，會進入unhealthy狀態
NM有磁碟空間檢測項，一旦無法完成健康檢測，服務將進入到UnHealthy狀態，從可用服務列表中剔除，計算資源相應會減少。
為了解決這個問題，我們在hadoop2。5支援了基於空間策略的副本，這個策略的作用是讓HDFS副本選擇的時候優先考慮DN使用率比較低的DN節點（大多是新機房新上線的節點），這樣資料在寫入的時候就會寫到新機房，減少了後續的遷移壓力，不過低版本的策略有缺陷，存在出現空指標的場景，需要修復後才可以上線，同時我們也改進了原始碼中部分邏輯，並已貢獻到hadoop社群，以便更合理的使用這個策略。
同時我們還透過資料遷移工具來加快遷移歷史資料、透過優先下線高水位節點等手段有效控制了高水位節點的比例。
2）新寫入的資料會大量選擇DN使用率比較低的節點
支援可用空間策略後，可以減少使用率過高的DN被寫入，不過假設大量副本如果都選擇到較低使用的DN，該DN有可能會成為新的“熱點”，為此我們繼續在原始碼上優化了此策略，副本選擇的時候會參考DN的心跳彙報情況和執行緒數的情況，如果該DN過於繁忙，將不會被選擇，基於新最佳化的可用空間策略既解決了資料過多寫入到使用率比較高的DN上，也解決了資料過多寫入到使用率過低的DN上引起的熱點問題。
3）對於本地短路讀的最佳化
短路讀的開啟充分利用了客戶端和DN節點在同一個節點的優勢，如果首選節點和客戶端在同一個機器，那麼pipeline很大可能會選擇這個節點作為pipeline的第一個，資料寫完本地後，然後按照副本選擇策略去選擇剩下的副本，我們在原始碼中改造了這塊邏輯，在首選DN節點壓力比較大時，可以不選擇該DN節點，去選擇更優的DN節點。
3、balance是把雙刃劍
1）封裝balance程式
Balance程式預設會把所有節點納入balance list，然後進行節點篩選，對不滿足threshold的DN做balance，但是實際上我們更期望把一些使用率比較高的DN作為source，使用率比較低的DN作為destination，所以我們重新封裝了Balance程式，支援按照指定IP的方式進行資料均衡，減少“無效”節點參與均衡佔用寶貴的執行緒資源和RPC。
2）balance程式支援按照檔案大小執行
同時過程中我們發現即使很少的檔案都要佔用一個執行緒和RPC去操作，這些比較小的檔案對整體資料遷移起的作用不大，所以支援Balance過程中指定需要均衡的檔案大小，最佳化後balance效率提升一倍，社群也在討論預設balance的時候支援這種場景。
3）對balance進行監控
Balance是個好工具，不過同時也會產生大量的RPC請求，在夜間ETL壓力比較大的時候，如果balance沒有正常關閉的話可能會對ETL造成很大的影響，所以我們開發了一個監控小程式來24H監控balance是執行情況，保證balance在凌晨ETL時關閉，白天正常狀態的時候開啟。
4、叢集整體監控
另外我們對DN執行情況、網路頻寬、RPC等也進行了監控，每天會分析下是否有指標是否達到效能瓶頸，同時給予告警。
四、跨叢集遷移工具改造
Hadoop原生提供一個比較好用的跨叢集遷移工具distcp，在叢集遷移過程中為了進一步加快遷移速度，我們也在同步的做跨叢集遷移，進一步減少需要遷移的資料，不過這個工具有下面幾個使用限制：
1、使用限制
1）
這是個客戶端命令
，需要有個客戶端才好進行操作，不具有普遍操作性，放開使用有一定的許可權風險。
2）
併發執行性不友好
，如果同時需要遷移100個大目錄，需要額外的開發來滿足併發的需求。
3）
狀態管控不友好
，客戶端執行命令後需要單線回收對應的結果，每次命令執行結束後需要單線等待結束狀態。
4）
缺少資料最終一致性校驗
，如果遷移過程中原始資料變更後，仍然可能會認為遷移成功，但是前後兩個目錄的大小等屬性可能已經不一致。
5）
許可權不一致問題
，distcp程式會保證遷移的最終檔案的屬性等保持一致，但是無法保證上層多級資料夾的許可權，從而可能會導致後續寫入許可權的問題，需要人肉介入每次遷移進行檢查。
6）
不支援黑名單遷移
，對於一些實時在變更的資料遷移場景可能會遷移失敗，這類場景需要針對性的對於實時變更的目錄做黑名單處理。
7）
對於超大目錄的遷移不友好
，超大目錄遷移需要更多的資源，不過程式只會起一個application，可能導致遷移失敗，過大的目錄需要在客戶端也需要額外的MR引數調優才能夠執行起來。
對此我們對distcp對了封裝和改造，增加了如下的功能。
2、增加的功能
1）支援多人併發提交遷移job
可以多人24H隨時選擇遷移，不需要叢集負責人配合執行遷移任務
2）多Job狀態管理
多個任務並行執行，平臺會記錄每個Job的各個狀態，方面掌握自己的遷移情況。
3）資料一致性校驗
任務執行前後對會遷移的目錄做資料統計，對於遷移前後資料不一致情況進行告警，及時關注資料情況。
4）目錄許可權智慧匹配
目前既可以滿足遷移前後許可權等屬性保持不變，也可以讓遷移後的目錄許可權繼承目標目錄的父目錄，特別是對於遷移叢集同時進行租戶梳理來說，這些都比較重要。
5）多Job進度管理
我們會定時自動重新整理job的進度，透過平臺可以看到遷移的進度。
6）模糊匹配
模糊匹配的功能可以用於多個層級，方面選擇有一定特徵的路徑一起遷移，減少重複操作，比如可以按照庫或者某個主體屬性等一起遷移。
7）黑名單遷移
黑名單策略主要是應對部分實時資料變更的場景，資料遷移時可以自動過濾掉指定目錄，減少實時資料和離線資料一起搬運，最後出現數據校驗不一致的問題。
8）定時排程&宏變數遷移
對於一些每天都是變更的資料，可以透過排程指定宏變數來遷移指定日期的資料，不需要每天手動操作。
9）特殊檔案自動處理
對於一些特殊檔案，比如隱藏檔案，本身檔案之前是存在問題的，遷移過程中，我們也對這些可能有問題的檔案進行自動處理，修復潛在的問題。
10）大任務智慧拆解
對於一些單次搬運資料量比較大的任務，可以透過指定方式搬運，job會自動拆解為多個job，提高整個搬運的效率。
11）元資料一鍵更新
目前絕大多數的hdfs資料都有hive元資料，我們也支援了一鍵修改hive分割槽等元資料，方面資料和元資料一起完成遷移。
透過上述功能點的改造，基本滿足了跨叢集的各種資料遷移工作。
五、總結和未來展望
總結一下，本文主要介紹了同程旅行Hadoop叢集跨機房的遷移實踐，主要改造和最佳化如下：
支援並最佳化可用空間策略
針對短路讀功能最佳化
針對DN熱點的策略最佳化
叢集遷移工具的功能加強
實現叢集遷移多維度監控
後續我們期望對hadoop版本做下升級，統一目前的多版本現狀，同時高版本的EC特性等可以很好的減少冷資料的儲存成本，進一步實現降本增效。
>>>>
參考資料
https：//issues。apache。org/jira/browse/HDFS-8824
https：//issues。apache。org/jira/browse/HDFS-9412
https：//issues。apache。org/jira/browse/HDFS-13222
https：//issues。apache。org/jira/browse/HDFS-13356
https：//issues。apache。org/jira/browse/HDFS-10715
https：//issues。apache。org/jira/browse/HDFS-14578
https：//issues。apache。org/jira/browse/HDFS-8131
作者丨郭飛
dbaplus社群歡迎廣大技術人員投稿，投稿郵箱：editor@dbaplus。cn
關注公眾號【dbaplus社群】，獲取更多原創技術文章和精選工具下載
