Tech

導讀

為了實現(xiàn)降本增效，京東HDFS 團隊在 EC 功能的移植、測試與上線過程中，基于自身現(xiàn)狀采取的一些措施并最終實現(xiàn)平滑上線。同時自研了一套數(shù)據(jù)生命周期管理系統(tǒng)，對熱溫冷數(shù)據(jù)進行自動化管理。在研發(fā)落地過程中還構建了三維一體的數(shù)據(jù)校驗機制，為 EC 數(shù)據(jù)的正確性提供了強有力的技術保障。

本文詳細介紹在研發(fā)一個復雜系統(tǒng)時，如何基于實際情況進行取舍，并確立行動準則。在功能上線過程中，要保持對線上系統(tǒng)的敬畏，確保上線與回滾不會導致元數(shù)據(jù)損壞。此外，要深刻認識系統(tǒng)的核心職責，對于存儲系統(tǒng)務必加強技術保障，確保數(shù)據(jù)的安全與可靠，不能丟不能錯。

數(shù)據(jù)作為京東數(shù)智戰(zhàn)略的重要資產(chǎn)，隨著業(yè)務的持續(xù)增長，大數(shù)據(jù)平臺存儲的數(shù)據(jù)量已突破 EB 級別，并且還在以每天將近 PB 的速度持續(xù)增長。傳統(tǒng)的方法是分析數(shù)據(jù)的使用頻率，把數(shù)據(jù)分為熱溫冷三類數(shù)據(jù)。對于溫冷數(shù)據(jù)，使用壓縮率更高的算法，來降低存儲成本。但是無法突破三副本存儲策略的固有屬性：需要存儲三份完整的數(shù)據(jù)塊。

EC 數(shù)據(jù)相比副本模式如何提升存儲效能

Hadoop 分布式存儲引擎（HDFS）在 3.0 版本中發(fā)布了 EC inside HDFS 重要特性。該 EC（Erasure Coding）是一種可通過計算降存儲的技術。下面我以 HDFS 支持的一種 EC 存儲策略 RS-3-2-1024k 為例簡單介紹其原理。對于一個 200MB 的文件，會把數(shù)據(jù)按 1MB(1024KB) 一個條帶（striped）進行切分，每切分出 3 個 1MB 的數(shù)據(jù)塊條帶（data striped，記為 d1-1,d2-1,d3-1），就用這 3 個數(shù)據(jù)塊條帶計算出兩個 1MB 的校驗塊條帶(parity striped，記為 p1-1, p2-1)，依次循環(huán)處理，最后的 2MB 數(shù)據(jù)只能構成 2 個數(shù)據(jù)塊條帶（d1-67,d2-67），EC 算法會構建一個全零的假數(shù)據(jù)塊（d3-67）計算出最后兩個校驗塊條帶（p1-67,p2-67）。實際存儲在 DN 上的 5（3 個數(shù)據(jù)塊加 2 個校驗塊）個 EC 數(shù)據(jù)塊分別由（d1-1..d1-67, d2-1..d2-67, d3-1..d3-66, p1-1..p1-67, p2-1..p2-67）組合成的數(shù)據(jù)塊。如果丟失其中任意兩個數(shù)據(jù)塊，都可以使用剩下的 3 個塊算出丟失的兩個塊。

一個 200MB 的文件按三副本方式存儲，需要在不同 DN 上存放 3 份完整的數(shù)據(jù)塊，消耗600MB的存儲空間。而 RS-3-2-1024k只需要 334MB的存儲空間，就能保證數(shù)據(jù)的冗余度，并且存儲空間降低了 45%。因此，我們可以借助 EC inside HDFS 技術進一步降低數(shù)據(jù)存儲成本，提高存儲效率。

要把 EC 技術應用到生產(chǎn)環(huán)境，需要對我們的生產(chǎn)系統(tǒng)進行改造升級。首先，需要讓生產(chǎn)代碼支持EC 功能，我將在第一部分分析我們采用升級還是移植的權衡，以及遵循的原則。然后，介紹我們在改造過程中，通過哪些方法和技術來保障項目質(zhì)量的。改造過程中涉及元數(shù)據(jù)方面的改動，因此上線需要格外注意，否則會導致數(shù)據(jù)難以恢復，在第三部分我會介紹線上系統(tǒng)的平滑升級方法與回滾的可行性。

我們運用 EC 的目的是存儲溫冷數(shù)據(jù)。對于熱溫冷數(shù)據(jù)，我們需要一套方案讓數(shù)據(jù)在這三種場景中流轉(zhuǎn)。我會在第四部分解密我們的數(shù)據(jù)生命周期管理系統(tǒng)。

作為數(shù)據(jù)存儲平臺，我們的首要職責是保證數(shù)據(jù)的安全可靠性，不能把用戶的數(shù)據(jù)弄丟了，也不能把數(shù)據(jù)存錯了。特別是 EC 這種基于計算的存儲技術，尤為需要注意數(shù)據(jù)的完整性。在最后一部分會闡述我們在 EC 數(shù)據(jù)完整性方面所做的努力。

升級 or 移植

我們從 2015 年開始基于社區(qū) 2.7.1 版本，構建京東大數(shù)據(jù)生態(tài)系統(tǒng)，作為大數(shù)據(jù)平臺的最底層基礎系統(tǒng)，服務著成百上千個業(yè)務。

HDFS EC 是 3.0 版本正式發(fā)布的一個重要特性，為了支持 EC 做了大量的修改，接口也發(fā)生了較大變化。此外 3.0+ 版本還在一直迭代，存在不少缺陷，正式上線前還需要解決一些額外的接口兼容問題，會影響項目進度。再加上這幾年我們基于 2.7.1 版本，做了大量的功能開發(fā)與性能優(yōu)化，才能支持當前單集群萬臺規(guī)模的存儲集群。因此我們采用移植 EC的方案。

社區(qū)EC相關的兩個父任務：HDFS-7285、HDFS-8031 以及相關的 bugfix，加起來差不多300多個patch。同時，我們的移植目標版本是2.7.1，而patch是相對3.0的。如果圍繞patch進行移植，我們要把3.0 相對2.7.1相關的前驅(qū)patch先移植過來，而這帶來的工作量是巨大并且無法估量的。

面對如此復雜的存儲系統(tǒng)，在開始移植前，需要確立一套移植方案和移植原則：

按功能模塊移植代碼。
移植過程中，盡可能的保持社區(qū)代碼原有樣式，以便于后續(xù)apply patch。
對移植過程沒有任何幫助的代碼，不移植。
對于接口，優(yōu)先移植，而且與社區(qū)保持一致。
測試用例必須移植并跑通。
對于目前不移植或者為了簡化移植工作而去掉的代碼，一定不能影響現(xiàn)有場景的功能，并用TODO標識未來會修改。

參與移植工作的開發(fā)人員都是非常有經(jīng)驗的，對HDFS的整體架構比較清楚，才能保證移植的效率。經(jīng)過一個多月的努力，完成了移植工作并跑通所有HDFS相關測試用例。

項目質(zhì)量保障

這么龐大的工程，如果僅靠單元測試來驗證，顯然大家是不放心的，所以在啟動 EC 項目時，QA 團隊就參加進來，展開了自動化集成測試工作，主要目的是保證：

移植工作不能改變原有接口和命令行語義，甚至接口和命令行的返回信息也要確保與 2.7.1 版本一致。
一般的集群運維操作能夠正常進行，比如 DN 節(jié)點上下線，NN 升級與回退。
在破壞性測試中，集群的健壯性不受影響，比如磁盤故障，網(wǎng)絡異常，數(shù)據(jù)損壞。
驗證集群兼容性，NN/DN/JN 逐步升級和回退不能影響集群的服務能力。
校驗數(shù)據(jù)正確性，在測試過程中要保證 EC 數(shù)據(jù)沒有被損壞，丟塊后重建的數(shù)據(jù)是正確的。
性能對比測試，引入 EC 功能后，通過壓測對比，確保集群，特別是 NN，性能不受影響。

為了適應千變?nèi)f化的測試需求，我們定制了一套自動化測試系統(tǒng)。運用 ansible 編寫了集群搭建系統(tǒng)，實現(xiàn)組件（NN/DN/JN），操作（安裝、卸載、啟動、停止、配置、切換、初始化），安裝包，主機，配置修改等的參數(shù)化。測試人員能夠靈活組合各種參數(shù)操作測試集群，實現(xiàn)測試目的。

在功能冒煙測試和回歸測試中，使用 pytest 編寫了 HDFS 測試框架和接口用例，以及數(shù)據(jù)校驗用例等。方便構建測試數(shù)據(jù)集，按需執(zhí)行測試用例，搜集測試用例的輸出并對比歷史數(shù)據(jù)，獲取集群 JMX 指標驗證正確性。

通過集成 Jenkins/Docker/makefile 等工具，貫通從開發(fā)人員提交代碼，到自動化編譯，到部署測試集群，再到冒煙測試并返回測試結果，一套完整的自動化測試流程。

升級與回滾

完成功能開發(fā)，測試也做的差不多之后，接下來就該上線了。但是上線不是換個包重啟下就完事了，否則集群很可能由于一些故障和兼容性問題，導致數(shù)據(jù)損壞。因此上線要支持回退，還要在升級YARN、客戶端等生態(tài)系統(tǒng)后，能寫EC文件，同時集群還能像以前一樣工作，盡可能不影響用戶的使用習慣。下面我詳細介紹一下 NameNode(NN) 和 DataNode(DN) 的升級過程。

為了支撐不停服務升級，就需要依賴 HDFS 集群的高可用（HA）特性。在兩臺 NN(Active/Standby) 滾動升級或回滾過程中，首先需要識別出 Active/Standby間的元數(shù)據(jù)兼容問題，然后逐個進行兼容性改造。

如 Editlog文件和 AddCloseOp方法中為表示當前版本支持 EC, LayoutVersion 被設置為 -64。如果使用 -64 寫 Editlog會導致 NN回滾后不認識 -64 而起不來。我們的處理辦法是在升級完成前，把LayoutVersion設置為老版本-63，但是內(nèi)部代碼可以識別 EC 元數(shù)據(jù)。還有 FsImage 文件中新增了ErasureCodingSection，需要先改造原有的老版本，保證老版本能處理新版本回傳的 FsImage 文件，否則會導致 NPE 異常。

INode整體格式?jīng)]有太大變化，只是重新定義了表示 replication的12bit字段。replication字段的高位為1時后邊的11位表示EcPolicyId。而高位為0，后續(xù)的11位表示副本。這個變化其實沒有修改布局，因此無需特殊處理。

平滑升級示意圖

通過一些兼容性改造，我們發(fā)布了一個過渡性質(zhì)的兼容性版本，可以識別 EC 相關元數(shù)據(jù)，但是不支持讀寫 EC 文件。這樣可以確保每次上線都是可以回滾到前一個版本，但不要求能回滾到之前的歷史版本。具體升級流程：

1. 第一次使用兼容版本升級一臺standby狀態(tài)的NN(LayoutVersion=-63)，并切換為active，測試運行一段時間，驗證該節(jié)點服務正常。如果服務有預料之外的問題，或者性能有所下降，都可以隨時進行 Active/Standby切換，并將Standby 節(jié)點回滾為老版本。

2. 第二次直接將standby節(jié)點的老版本升級到支持EC功能的新版(LayoutVersion=-64，也就是支持寫EC文件），并切換為active。如果出現(xiàn)問題，都可以隨時進行 Active/Standby切換，使用到第 1步中已經(jīng)穩(wěn)定運行一段時間的 NN(LayoutVersion=-63) 作為 Active 節(jié)點。

3. 第三次使用支持EC功能的新版替換第 1 步中升級的 NN。

至此，線上的服務就平滑由2.7.1升級為支持EC的HDFS了。整個過程經(jīng)歷3次升級，對外沒有中止服務，外界無感知，并且整個過程是支持逐步回退。因此這個升級過程可以應用到生產(chǎn)環(huán)境。

滾動升級 DN 示意圖

說完NN上線，接下來再討論一下DN滾動上線。首先，解釋下為什么要滾動升級DN(支持讀寫 EC塊，記為 DN(EC))。第一個很顯然的原因是為了保證 HDFS的可用性，不影響用戶讀寫副本文件；另外一個很重要的原因是想在線上驗證 EC 功能的同時限制 EC 的故障域。

客戶端調(diào)用addBlock選擇DN去寫塊時，現(xiàn)有的選塊策略無法給用戶返回DN(EC)，因此會出現(xiàn)寫失敗。通過在NN上新增ECClusterMap，構建一棵由 DN(EC) 組成的拓撲樹。經(jīng)過改造后，當客戶端想要寫 EC 文件，選塊策略會從ECClusterMap中選取目標節(jié)點，就可以解決DN滾動升級過程中不支持 EC 寫入的兼容性問題，同時也可以在線上環(huán)境中小范圍驗證 DN 中 EC 功能的穩(wěn)定性。

數(shù)據(jù)生命周期管理

業(yè)界使用 DistCp或用 Hive 創(chuàng)建新表的方式把數(shù)據(jù)轉(zhuǎn)換為 EC 存儲。這個方案需要分別運維一套 YARN 集群和任務調(diào)度系統(tǒng)，并存在一些不足：

在不修改 NN的前提下，任務調(diào)度系統(tǒng)無法實時轉(zhuǎn)換新增數(shù)據(jù)。
如果在數(shù)據(jù)拷貝過程中發(fā)生錯誤，只能重頭開始轉(zhuǎn)換。
如果要對數(shù)據(jù)進行過濾，只支持對文件路徑的過濾。
如果把轉(zhuǎn)換后的數(shù)據(jù)移到源目錄時，沒法進行原子交換，用戶程序會在此間隙拋出找不到文件的異常。
此外，HDFS 為目錄和文件設置了用戶組權限以及時間戳，對所有數(shù)據(jù)進行拷貝時，需要給拷貝程序賦超級權限，會引入一定的安全風險，現(xiàn)有方案也不能保證轉(zhuǎn)換后的文件和原始文件屬性保持一致。

我們實現(xiàn)了一套基于數(shù)據(jù)生命周期的溫冷數(shù)據(jù)轉(zhuǎn)存管理系統(tǒng), 來解決現(xiàn)有方案的不足。在 NN 內(nèi)部啟動一個數(shù)據(jù)轉(zhuǎn)換管理器，周期掃描待轉(zhuǎn)換文件, 把轉(zhuǎn)換任務封裝成 FileConvertCommand，然后借助轉(zhuǎn)換任務均衡器（ConvertTaskBalancer）選擇一個 DN, 把FileConvertCommand加入到這個 DN 的待轉(zhuǎn)換隊列中。當 DN心跳過來時，會從待轉(zhuǎn)換隊列中領取一定數(shù)量的任務回去處理。詳見下圖。

EC 數(shù)據(jù)轉(zhuǎn)換流程圖

無論轉(zhuǎn)換任務是否成功，DN都會通過心跳告知 NN 處理結果。當收到文件轉(zhuǎn)換成功的響應，NN 讀取原始文件的屬性，包括用戶組、時間戳、擴展屬性等，設置轉(zhuǎn)換后的 EC 文件。然后借助一個臨時目錄，對原始副本文件加讀鎖，并移動到臨時目錄，然后再把轉(zhuǎn)換后的 EC 文件移動到原副本文件目錄，實現(xiàn)副本文件和 EC 文件的原子性交換。如果這個過程沒有異常發(fā)生，會在 checkpoint 中加一條操作日志。如果發(fā)生異常，把原始副本文件移回原目錄，然后把該任務加入到待轉(zhuǎn)換隊列進行重做。

在轉(zhuǎn)換執(zhí)行過程中，允許人為中斷。在轉(zhuǎn)換功能異常的情況下，要確保文件不能被損壞，服務不能中斷。NN 側(cè)通過 checkpoint記錄操作日志，并存放在 HDFS 系統(tǒng)中，確保轉(zhuǎn)換過程的冪等性。通過轉(zhuǎn)換任務均衡器把轉(zhuǎn)換任務均勻的分布到不同的 DN，避免熱節(jié)點導致集群性能下降。DN 側(cè)通過超時機制快速終止異常轉(zhuǎn)換任務，釋放資源處理下一個轉(zhuǎn)換任務。

通過以上手段，我們可以讓 HDFS 集群不依賴任何其它系統(tǒng)獨立完成數(shù)據(jù)轉(zhuǎn)換，并能對新增數(shù)據(jù)進行實時轉(zhuǎn)換，利用容錯機制確保數(shù)據(jù)不會被重復轉(zhuǎn)換或漏轉(zhuǎn)，提供了豐富的策略對待轉(zhuǎn)換數(shù)據(jù)進行過濾，使用原子性操作為用戶提供不間斷服務，不修改轉(zhuǎn)后的文件屬性確保轉(zhuǎn)換對于用戶是透明的。

后來，我們對這套數(shù)據(jù)生命周期管理系統(tǒng)進行了抽象擴展，相當于在 HDFS 內(nèi)部構建了一套調(diào)度系統(tǒng)。除了可以支持溫冷數(shù)據(jù)轉(zhuǎn)換，還可以對數(shù)據(jù)進行比對校驗，甚至連數(shù)據(jù)清理工作也可以由這套系統(tǒng)進行調(diào)度。

全方位的數(shù)據(jù)完整性保障

HDFS-14768, HDFS-15186 還有 HDFS-15240是同行和我們在使用 EC 過程中發(fā)現(xiàn)導致數(shù)據(jù)損壞的情況，可見使用新興的 EC 存在極大的數(shù)據(jù)損壞風險。正因如此，我們設計了文件級別和數(shù)據(jù)塊級別的多重校驗機制。

對于文件，在轉(zhuǎn)換初期，我們使用 EC 與副本混合存儲的策略，周期性的比對并恢復數(shù)據(jù)塊，保障數(shù)據(jù)的完整性。通過在數(shù)據(jù)生命周期管理服務中，擴充 FileConvertCommand，支持數(shù)據(jù)驗證模式。在上文提到的數(shù)據(jù)轉(zhuǎn)換過程中，把副本文件轉(zhuǎn)換為 EC 存儲后，會立即使用 md5sum比對副本和 EC 文件內(nèi)容，確保轉(zhuǎn)換的正確性。

EC 文件的數(shù)據(jù)塊組分為數(shù)據(jù)塊與校驗塊兩部分?？蛻舳俗x取 EC 文件時，一般情況下只需要讀取數(shù)據(jù)塊部分。因此，在比對副本文件與 EC文件時，無法校驗 EC 文件的校驗塊部分。為此，我們在文件內(nèi)容比對過程中，還加入了數(shù)據(jù)塊級別的驗證。調(diào)用 BlockReaderFactory 獲取 EC(RS-6-3-1024k) 塊組中的數(shù)據(jù)塊（d1-d6）與校驗塊(p1-p3)內(nèi)容，再使用 EC 工具庫中的 CodecUtil.createRawDecoder 隨機選取 EC 塊組中（d1,d2,d4,d5,p1,p3）計算其它塊(d3’,d6’,p2’)，再與前面讀取到的（d3,d6,p2）塊內(nèi)容比對。

三階段 EC 數(shù)據(jù)塊校驗

經(jīng)過以上兩輪比對，數(shù)據(jù)轉(zhuǎn)換的結果可以保證完全無誤。但是這種數(shù)據(jù)校驗成本很高，我們不可能在很短的周期內(nèi)，重新校驗所有的數(shù)據(jù)文件。另外，副本文件不可能一直存留在集群中，否則使用EC 降存的意義也就不存在了。

為此，我們基于流式計算構建了一套實時的數(shù)據(jù)塊級別的檢測機制。具體流程是檢測到數(shù)據(jù)塊在節(jié)點間發(fā)生遷移（塊重建，復制或是 balancer 都會導致塊在節(jié)點間遷移），會計算新數(shù)據(jù)塊的 md5sum, 并與舊數(shù)據(jù)塊 md5sum 進行比對，當數(shù)據(jù)塊 md5sum 發(fā)生變化后，通知集群維護人員進行處理。這套實時數(shù)據(jù)檢測機制減少了數(shù)據(jù)校驗成本，同時提高了時效性。

在這三維一體的數(shù)據(jù)校驗與檢測機制的保駕護航下，我們的 EC 功能成功上線到生產(chǎn)環(huán)境。經(jīng)歷了機房遷移、數(shù)據(jù)節(jié)點升級、618 和雙十一的考驗。到目前為止運用 EC 存儲了上百PB 溫冷數(shù)據(jù)，為公司節(jié)省上千臺服務器成本。

總結與展望

在如此龐大的生產(chǎn)系統(tǒng)改造工程中，我們踩了不少坑。例如，HDFS 命令行輸出發(fā)生變更，導致用戶程序無法識別新增內(nèi)容報錯；修改Hadoop版本號后，一些 Hive 應用使用正則表達式解析 Hadoop版本號報錯；由于接口變化導致 TeraSort 無法運行；要先改造老版本 NN，增加 BlockReportLeaseManager，否則新版本的 DN 無法向老版本的 NN 進行全量塊匯報。這是我們趟過的比較典型的坑，主要是代碼兼容，Hadoop 生態(tài)兼容的一些事項。

在實踐過程中，我們還有一些很好的經(jīng)驗總結和大家分享下。移植代碼時，一定要移植單元測試用例，可以幫助我們避免在移植過程中的疏忽導致代碼少移漏移；另外，為了與社區(qū)代碼的兼容，盡量使用一些設計模式，如裝飾器、工廠模式、組合模式，進行代碼的改造，方便日后引入社區(qū)新功能；還有一點非常重要，在改造 RPC 接口時，務必要保證 ProtoBuf 協(xié)議的兼容性，我們在新增自定義的字段時，會預留一部分坑位應對社區(qū)代碼的擴展；對于存儲系統(tǒng)，最重要的事情莫過于數(shù)據(jù)的完整性，大家可以參考上面第五部分內(nèi)容，結合自己的場景進行優(yōu)化。

Hadoop 社區(qū)為我們創(chuàng)造了優(yōu)秀的存儲系統(tǒng)。本著人人為我，我為人人的開源精神，在項目改造過程中，

我們向社區(qū)回饋了數(shù)十個 patch。比較典型的改進如下：

HDFS-14171，影響 NN 啟動速度。
HDFS-14353, 修復 xmitsInProgress 指標異常。
HDFS-14523, 去除 NetworkTopology 多余鎖。
HDFS-14849, DN 下線導致 EC 塊無限復制。
HDFS-15240, 修復臟緩存導致數(shù)據(jù)重建錯誤。

接下來，為了讓 EC 突破溫冷數(shù)據(jù)的使用場景。我們準備在生產(chǎn)環(huán)境使用 native 方法加速 EC 數(shù)據(jù)的編解碼效率，驗證功能的穩(wěn)定性，并向社區(qū)回饋我們的改造。目前的 EC inside HDFS 功能已經(jīng)比較穩(wěn)定了，但是問題還是存在的，我們將與社區(qū)一起努力建設更加穩(wěn)定的 HDFS 存儲系統(tǒng)。

京東零售-黃濤

推薦閱讀

HDFS 實踐 | 京東 HDFS EC 應用解密

Tech

京東零售-黃濤

揭秘| 大數(shù)據(jù)計算引擎性能及穩(wěn)定性提升神器！

"多模態(tài)數(shù)字內(nèi)容生成"的技術探索與應用實踐

AI新生：破解人機共存密碼 | 每月一書（福利送書）

一圖看懂未來科技趨勢

HDFS 實踐 | 京東 HDFS EC 應用解密

Tech

京東零售-黃濤

揭秘| 大數(shù)據(jù)計算引擎性能及穩(wěn)定性提升神器！

"多模態(tài)數(shù)字內(nèi)容生成"的技術探索與應用實踐

AI新生：破解人機共存密碼 | 每月一書（福利送書）

一圖看懂未來科技趨勢

揭秘| 大數(shù)據(jù)計算引擎性能及穩(wěn)定性提升神器！