Tech

導(dǎo)讀

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

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

數(shù)據(jù)作為京東數(shù)智戰(zhàn)略的重要資產(chǎn)，隨著業(yè)務(wù)的持續(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）是一種可通過計算降存儲的技術(shù)。下面我以 HDFS 支持的一種 EC 存儲策略 RS-3-2-1024k 為例簡單介紹其原理。對于一個 200MB 的文件，會把數(shù)據(jù)按 1MB(1024KB) 一個條帶（striped）進(jìn)行切分，每切分出 3 個 1MB 的數(shù)據(jù)塊條帶（data striped，記為 d1-1,d2-1,d3-1），就用這 3 個數(shù)據(jù)塊條帶計算出兩個 1MB 的校驗(yàn)塊條帶(parity striped，記為 p1-1, p2-1)，依次循環(huán)處理，最后的 2MB 數(shù)據(jù)只能構(gòu)成 2 個數(shù)據(jù)塊條帶（d1-67,d2-67），EC 算法會構(gòu)建一個全零的假數(shù)據(jù)塊（d3-67）計算出最后兩個校驗(yàn)塊條帶（p1-67,p2-67）。實(shí)際存儲在 DN 上的 5（3 個數(shù)據(jù)塊加 2 個校驗(yàn)塊）個 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ìn)一步降低數(shù)據(jù)存儲成本，提高存儲效率。

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

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

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

升級 or 移植

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

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

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

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

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

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

項(xiàng)目質(zhì)量保障

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

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

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

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

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

升級與回滾

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

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

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

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

平滑升級示意圖

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

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

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

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

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

滾動升級 DN 示意圖

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)與展望

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

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

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

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

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

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

京東零售-黃濤

推薦閱讀

HDFS 實(shí)踐 | 京東 HDFS EC 應(yīng)用解密

Tech

京東零售-黃濤

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

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

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

一圖看懂未來科技趨勢

HDFS 實(shí)踐 | 京東 HDFS EC 應(yīng)用解密

Tech

京東零售-黃濤

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

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

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

一圖看懂未來科技趨勢

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