桔妹導讀：Hadoop 3的第一個穩定版本在2017年底就已經發布了，有了很多重大的改進。在HDFS方面，支持了Erasure Coding、More than 2 NameNodes、Router-Based Federation、Intra-datanode balancer 等功能，大家可能對這些功能很感興趣，打算將叢集升級到HDFS 3.x 版本。本篇文章會介紹我們是如何將 HDFS 從2.7滾動升級到3.2版本的，在升級中會遇到哪些問題以及我們是如何解決掉的。HDFS 升級過程漫長，但是收益是非常多的。在此基礎上，我們可以繼續做非常有意義的工作，持續在穩定性、效能、成本等多個方面深入探索，使用技術為公司創造可見的價值。

1.為什麼要升級

在2017年底， Hadoop3.0 釋出了，到目前為止， Hadoop 釋出的最新版本為3.2.1。在 Hadoop3 中有很多有用的新特性出現，如支援 ErasureCoding、多 NameNode、Standby NameNode read、DataNode Disk Balance、HDFS RBF 等等。除此之外，還有很多效能最佳化以及 BUG 修復。

其中最吸引我們的就是 ErasureCoding 特性，資料可靠性保持不變的情況下可以降低資料的儲存副本數量，結合公司的降成本目標以及使用者的痛點，我們對此做了深入的調研。同時，在實際工作中我們發現，我們遇到的一些 BUG 以及想做的一些最佳化點，社群早已經修復或者實現。內部使用的 Hadoop 版本對應社群的2.7.2，由於社群很多 BUG 修復是不會移植到太低版本的，我們解決問題時花費了較多精力在移植與測試驗證中。

如果升級到 HDFS3.2 版本，可以站在巨人肩膀上繼續工作，做一些更有意義的事情。

2.調研升級方案

升級方式有兩種：Express 和 Rolling，Express 升級過程是停止現有服務，然後使用新版本啟動服務；Rolling 升級過程是滾動升級，不停服務，對使用者無感知。對於公司來說，當然滾動升級是最好的方案，離線叢集使用者非常之多，影響面非常之大。

目前業界還沒有滾動升級的方案從2.x 版本升級到3.x 版本，Cloudera 和 Hontonworks 公司（目前兩個公司已合併）給出的推薦方案仍然是 Express 升級，例如 Hontonworks 的文件中描述，目前滾動升級存在一些問題尚未解決，推薦使用者做 Express 升級。

當前滾動升級存在的問題記錄在 Apache Hadoop Wiki 中，主要問題是 Edit Log 不相容，無法進行滾動升級。調研之後，我們對整個升級方案有了一個初步掌握，開始著手解決這些問題。

HDFS 整體架構圖（網路上獲取）如下所示，我們準備對服務端進行升級，包括 JournalNode，NameNode，ZKFC，DataNode 元件。Client 端受到 Spark，Hive，Flink 等等很多元件依賴，目前這些元件還不支援 Hadoop3，因此 Client 版本暫時保持不變。

HDFS3.2升級在滴滴的實踐

3.解決滾動升級中遇到的問題

滾動升級的操作流程在 Hadoop 官方升級文件中有介紹，概括起來大致步驟如下：

1.JournalNode 升級，使用新版本依次重啟 JournalNode

2. NameNode 升級

2.1升級準備，生成 fallback fsimage 檔案

2. 2使用新版本 Hadoop 重啟 Standby NameNode，重啟 ZKFC

2.3做 failover，使升級後的 NameNode 變成 Active 節點

2.4使用新版本 Hadoop 重啟另一個 NameNode，重啟 ZKFC

3.升級 DataNode，使用新版本 Hadoop 重啟所有 DataNode 節點

4.做 Finalize，確認叢集變更到3.2

在測試環境驗證 HDFS 滾動升級方案時，升級和降級過程中都遇到了一些問題。

在滾動升級中，當 Active NameNode 為3.2版本，Standby NameNode 為2.7版本時，會出現 EditLog 不相容問題。此時，Active NameNode 寫 EditLog 時會將 EC 相關的結構寫入到 EditLog 當中，當 Standby NameNode 讀取 EditLog 時，會出現識別不了的情況，導致 Standby NameNode 直接 Shutdown。我們的解決方案是，考慮當前有效版本是否支援 EC，如果支援 EC 則會寫入 EC 資訊到 EditLog，否則不會寫入。而在升級過程中，有效版本實際上還是2.7，是不支援 EC 的，這個時候忽略 EC 即可，這樣 Standby NameNode 讀取 EditLog 做合併時，不會出現 EC 相關資訊，可正常工作。解決問題的 ISSUE 為 HDFS-13596。

在滾動降級中，當3.2版本的 NameNode 使用3.2版本 Hadoop 重啟時，如果當前最新的 Fsimage 是3.2版本 NameNode 產生的，則2.7版本 Hadoop 重啟 NameNode 會直接 Shutdown，原因是，3.2版本 Haodop 產生的 Fsimage 檔案，2.7版本的 Hadoop 無法進行載入，這將導致如果升級中遇到問題想回滾的話，無法完成回滾操作。經過深入分析，我們發現有兩個問題會導致這種情況出現。

第一個問題，Fsimage 的不相容是由於3.2版本的 NameNode 將 EC 資訊寫入到了 Fsimage 當中，2.7版本的 Hadoop 無法識別 EC 資訊，導致失敗。解決方案與上面類似，在儲存 Fsimage 時考慮當前的有效版本，如果不支援 EC 則不會將 EC 資訊寫入到 Fsimage 檔案中。解決問題的 ISSUE 為 HDFS-14396。

第二個問題，由於 NameNode 對 StringTable 的修改導致了 Fsimage 的不相容，目前該問題可以透過回滾 commit 進行解決，社群反饋修復也不是很必要，可以透過先升級到無該 commit 的版本，滾動升級穩定後，直接進行小版本升級，跨過這個不相容特性。記錄 ISSUE 為 HDFS-14831。

由於滴滴使用的是內部的使用者名稱密碼認證機制，社群出現的一個問題我們沒有遇到， ISSUE 為 HDFS-14509 ，升級過程中 NameNode 和 DataNode 由於資料結構的變化，生成了不同的 password，導致無法認證，讀寫資料會失敗。該 ISSUE 記錄了這個問題，需要先升級到 2.x 的最新版本進行過度，之後才能滾動升級到 3.x 版本。

總結起來，需要做 HDFS2.x 到 3.x 的滾動升級，需要關注這些 ISSUE，HDFS-13596，HDFS-14396，HDFS-14831，HDFS-14509。

4.測試與上線

從19年初開始關注 HDFS 滾動升級，在解決遇到的已知問題之後，開發與測試不斷討論升級方案，將可能遇到的風險進行總結。

在這個過程中，我們詳細閱讀分析了滾動升級的原始碼，確定升級中 NameNode，DataNode 會做哪些動作，以明確風險點。同時我們還分析了從2.7到3.2版本引入的關於 HDFS 的4000左右的 Patch ，找出可能存在相容性問題的點，進行深入地分析。同時我們對3.2中新引入的 Feature 也進行了分析，以確保新功能對升級沒有影響。種種總結、分析、測試相關的工作，我們寫了四五十篇的 WIKI 文件進行記錄。在測試環境中升級步驟進行了數次演練，確認沒問題之後，我們開始了升級之路。相關的具體里程碑上線過程如下：

1.19年5月左右，升級演練多次，準備全量 Hadoop、Hive、Spark Case 進行測試，確定方案沒有問題

2.19年7月左右，離線小叢集1（百臺）升級到3.2版本，使用者未受到影響。

3.19年10月左右，離線小叢集2（數百臺）升級到3.2版本，使用者未受到影響。

4.19年11月底，離線大叢集（數千臺）升級到3.2版本，使用者未受到影響.

升級過程中，DataNode 在刪除 Block 時，是不會真的將 Block 刪除的，而是先將Block 檔案放到一個 Trash 目錄中，為了能夠使用原來的 FallBack Fsimage 恢復以前的資料。當升級週期比較長時，Trash 中的資料就會很多，例如我們這邊大叢集升級週期就有3周之長。升級操作在短時間之內，是可以確定是否有問題的，並且三週之後也不可能真的回滾到以前的資料，倘若真的遇到問題，是需要及時修復的。我們開發了額外的工具，對 Trash 中的 Block 檔案進行按天歸檔，設定好保留時間，例如設定1天。我們會每天例行將1天之前的資料進行刪除，這樣可以大大減少 DataNode 上磁碟的儲存壓力。

升級之後，我們對各個叢集進行都進行自己觀察，目前服務一切正常。

5.總結

非常高興在如此大規模的叢集上完成從2.7到3.2的滾動升級，走在了行業的前列。HDFS 升級過程漫長，但是收益是非常多的。在此基礎上，我們可以繼續做非常有意義的工作，持續在穩定性、效能、成本等多個方面深入探索，使用技術為公司創造可見的價值。

本文作者▬費輝

滴滴 | 大資料架構技術專家

滴滴出行大資料架構技術專家，負責離線儲存。在加入滴滴之前，曾在阿里巴巴參與過JVM和EMR產品的開發。開源大資料愛好者，積極參與社群的交流討論，Hadoop/Hive/Tez 社群貢獻者。