HDFS在B站的探索和實踐

HDFS離線存儲平臺是Hadoop大數(shù)據(jù)計算的底層架構(gòu)，在B站應(yīng)用已經(jīng)超過5年的時間。經(jīng)過多年的發(fā)展，HDFS存儲平臺目前已經(jīng)發(fā)展成為總存儲數(shù)據(jù)量近EB級，元數(shù)據(jù)總量近百億級，NameSpace 數(shù)量近20組，節(jié)點數(shù)量近萬臺，日均吞吐幾十PB數(shù)據(jù)量的大型分布式文件存儲系統(tǒng)。

首先我們來介紹一下B站的HDFS離線存儲平臺的總體架構(gòu)。

圖 1-1 HDFS 總體架構(gòu)

HDFS離線存儲平臺之前主要有元數(shù)據(jù)層和數(shù)據(jù)層，近年來我們引入了HDFS Router 擴展了接入層，形成當(dāng)前的三層架構(gòu)，如圖1-1所示。

• 接入層，主要以HDFS Router為主，HDFS Router提供了HDFS的統(tǒng)一元數(shù)據(jù)視圖，以掛載點的方式，記錄路徑與集群的映射關(guān)系，將用戶對路徑的請求轉(zhuǎn)發(fā)到不同的NameSpace中。

• 元數(shù)據(jù)層，主要記錄文件元數(shù)據(jù)信息，管理文件讀寫操作，是整個HDFS存儲系統(tǒng)的心臟。

• 數(shù)據(jù)層，以存儲節(jié)點DataNode為主，用于存儲真實的數(shù)據(jù)。

接下來將介紹我們在接入層、元數(shù)據(jù)層、數(shù)據(jù)層的探索與實踐。

（一）基于MergeFs的元數(shù)據(jù)快速擴展

由于HDFS集群存儲數(shù)據(jù)量的迅猛增長，單個NameSpace已經(jīng)無法滿足元數(shù)據(jù)量的快速增長，我們在經(jīng)歷了HDFS 聯(lián)邦機制后擴展成多NameSpace，滿足了一段時間的需求。但是隨著集群元數(shù)據(jù)量的指數(shù)級增長，特別是小文件數(shù)量的猛增，HDFS 聯(lián)邦機制逐漸無法滿足當(dāng)時的需求。

為了能夠快速新增NameSpace以及讓新增的NameSpace迅速接入已有的集群，負載新增的元數(shù)據(jù)，現(xiàn)有的聯(lián)邦機制和社區(qū)版本的RBF也無法滿足當(dāng)前的要求，我們決定在RBF的基礎(chǔ)上，深度定制開發(fā)，來解決主節(jié)點擴展性問題。

當(dāng)時元數(shù)據(jù)層的壓力主要來源于3個方面：

• 存量元數(shù)據(jù)數(shù)據(jù)量大，新增文件數(shù)量增長迅猛。

• 新增NameSpace無法快速進行遷移，遷移效率不足。

• 大量目錄存在實時寫入，歷史的遷移方式需要停止寫入。

  
  

為了解決元數(shù)據(jù)層擴展能力不足的問題，經(jīng)過調(diào)研社區(qū)3.0的HDFS Router和業(yè)界相關(guān)方案后，我們決定在社區(qū)3.3版本的HDFS Router 的基礎(chǔ)上，進行定制開發(fā)MergeFs來解決集群元數(shù)據(jù)層擴展性能問題，整體架構(gòu)如圖2-1所示：

圖 2-1 HDFS MergeFS 整體架構(gòu)

• 在社區(qū)版本的HDFS Router 基礎(chǔ)上，定制化開發(fā)MergeFS支持元數(shù)據(jù)遷移，MergeFS 支持按一個掛載點配置2個NameSpace，新寫入數(shù)據(jù)會按規(guī)則路由到新增的NameSpace中，但歷史數(shù)據(jù)仍然可見，通過這種方式，我們能迅速擴張新的NameSpace，緩解老NameSpace的寫入壓力。

• 建設(shè)了NameSpace Balancer工具，能在業(yè)務(wù)低峰時期自動化的異步遷移老NameSpace的歷史數(shù)據(jù)到新擴容的NameSpace中，遷移完成后收歸掉掛載點，最終實現(xiàn)路徑完全遷移到新的NameSpace中。

• 基于HDFS元倉，不斷分析出增長較快的目錄，用于指導(dǎo)哪些數(shù)據(jù)需要遷移。

  
  

在支持了接入層的MergeFS后，元數(shù)據(jù)擴張不再成為瓶頸，我們擴容了14組NameSpace，支持了90億左右的元數(shù)據(jù)總量，遷移了54億左右的元數(shù)據(jù)。與此同時，整個集群的元數(shù)據(jù)層QPS得到了極大的提升，整體QPS從50K/s上漲到177.8K/s，整個數(shù)據(jù)遷移工作對上層數(shù)據(jù)計算任務(wù)透明，極大的減少了遷移的工作量，遷移工作量從1人/week，下降到0.1人/week。

（二）接入層限流策略

隨著集群規(guī)模的日益增長，集群任務(wù)的讀寫數(shù)據(jù)量也有數(shù)量級的上漲，對集群元數(shù)據(jù)層的請求如果不加以限制，往往會造成熱點NameSpace，針對HDFS存儲這種多租戶場景，往往會影響高優(yōu)先級任務(wù)的運行，因此我們對接入層Router和元數(shù)據(jù)層NameNode都做了限流策略，來保障資源向高優(yōu)先級任務(wù)傾斜，如圖2-2所示：

• 我們在計算引擎?zhèn)群虷DFS Client段通過CallerContext透傳了user和Jobid信息，首先在Router層基于用戶，JobId，Optype，NameSpace permit負載判斷，對于需要進行限流的請求，會對Client返回StanbyException，客戶端通過指數(shù)回退策略在等待一定時間后再進行重試，最大重試次數(shù)為30次。
  

• 在NameNode上基于客戶端透傳的Job和User信息配置優(yōu)先級，我們啟用了FairCallQueue進行限流，同時采用基于Job信息的Job-Based Cost Provider取代了默認的User-Based Cost Provider，實現(xiàn)了實現(xiàn)作業(yè)粒度的RPC限流。

圖 2-2 HDFS 流量限制

通過上述的限流策略，我們對Hive，Spark計算引擎的動態(tài)分區(qū)任務(wù)等這類短時間大量讀寫請求的任務(wù)有了很大的防御能力，從監(jiān)控上看，Router上單個NameSpace的Permit耗盡的情況出現(xiàn)的概率大大下降。

（三）接入層Quota 策略

存儲數(shù)據(jù)的迅猛增長，以及數(shù)據(jù)治理推動耗時耗力，對租戶數(shù)據(jù)進行Quota限制也是急需解決的問題。由于之前為了提升NameNode RPC性能，我們在NameNode上進行改造跳過了部分Quota計算的邏輯，極大的降低了NameNode在處理存在大量文件目錄時的持鎖時間。我們設(shè)計了基于接入層Router的quota機制如圖2-3所示，將NameNode中Quota計算和校驗的邏輯前置到Router中。Router中緩存了來源于HDFS元倉的路徑Quota信息，目前是T+1更新，實效性不高，因此我們也正在開發(fā)基于NameNode Observer節(jié)點的準實時Quota功能，如圖2-4所示。

• 改造NameNode Observer節(jié)點，支持無鎖版本的getQuotaUsage接口，獲取路徑Quota信息對NameNode整體讀寫無影響；

• Quota Service 聚合分散在多個NameSpace中的路徑，實現(xiàn)分鐘級Quota計算；

• HDFS Router訪問Quota Service獲取路徑使用的Quota信息，進行Quota校驗；

• Quota Service相關(guān)數(shù)據(jù)提供上層數(shù)據(jù)平臺進行資產(chǎn)管理使用。

圖 2-3 基于HDFS元倉的Quota機制

圖 2-4 近實時的Quota計算服務(wù)

（四）基于Router的Staging目錄分流

由于業(yè)務(wù)的擴張，集群上并行的任務(wù)數(shù)量也迅猛增長，各種任務(wù)運行的臨時文件目錄如：Yarn Staing路徑、Spark Staing路徑、Hive scratchdir路徑、Yarn Logs路徑的QPS請求非常大，需要多組NameSpace進行分擔(dān)才能承載，我們通過對這些路徑配置HASH_ALL掛載點。

通過一致性HASH實現(xiàn)多組NameSpace之間的QPS負載均衡，將這些目錄隔離在單獨的NameSpace中，減少主集群NameNode的讀寫壓力。

（一）基于RBF的Observer NameNode策略

HDFS 架構(gòu)中元數(shù)據(jù)節(jié)點NameNode 的實現(xiàn)中存在針對目錄樹的全局鎖，很容易就達到讀寫請求處理瓶頸。社區(qū)3.0版本中提出了一個Observer Read架構(gòu)，通過讀寫分離的架構(gòu)，嘗試提升單個NameService的處理能力。為了提升NameNode請求處理能力，我們在社區(qū)版本的Observer機制的基礎(chǔ)上也經(jīng)過了定制化開發(fā)，基于最新的RBF框架，實現(xiàn)動態(tài)負載讀請求路由，提升NameNode讀寫效率，如圖3-1所示：

• 基于RBF的Observer 架構(gòu)，對于HDFS Client和計算引擎完全透明，無需變更Client配置；

• 計算引擎可以通過callerContext 透傳是否進行Observer讀請求，適配不同的業(yè)務(wù)；

• HDFS Router 判斷是否需要進行Observer Read和msync請求，依據(jù)具體情況進行Observer Read。

圖 3-1 Observer NameNode 基礎(chǔ)架構(gòu)

在Observer NameNode功能落地過程中，我們做了許多的工作：

• 由于主集群是2.8.4 版本，而Observer功能在3.X版本才開啟，因此我們合并了大量Hadoop 3.x版本中Observer相關(guān)的代碼到當(dāng)前版本；

• 為提升MSync RPC穩(wěn)定性，我們在NameNode上開啟新的9020端口，用于專門處理Msync請求；

• 新增RequeueRpcCalls監(jiān)控項，監(jiān)控NameNode Observer節(jié)點請求re-queue情況；

• 在RBF上支持根據(jù)用戶Client透傳的Callercontext信息判斷是否使用Observer NameNode，便于不同業(yè)務(wù)劃分。

通過Observer NameNode的擴容，單個NameSpace的處理能力迅速上漲，由于當(dāng)前只有部分Adhoc查詢接入Observer節(jié)點，單組NameSpace Observer節(jié)點增加平均4.5k/s左右QPS，Active NameNode 峰值QPS下降40k/s，此外Active NameNode QueueTime 峰值和平均值均有所下降，均值從23ms下降到11ms ，如圖3-2，圖3-3 所示：

圖 3-2 Observer NameNode 發(fā)布前Active NameNode QueueTime

圖 3-3 Observer NameNode 發(fā)布后Active NameNode QueueTime

（二）NameNode動態(tài)負載均衡策略

當(dāng)前集群由于DataNode節(jié)點和NodeManager節(jié)點混合部署，而NodeManager上運行的任務(wù)對節(jié)點負載造成的影響大小不一，HDFS文件的讀寫受到DataNode節(jié)點的負載影響較大，常常有慢讀慢寫的情況發(fā)生。為提高HDFS系統(tǒng)的穩(wěn)定性，我們在NameNode端加以改造，實現(xiàn)動態(tài)的負載均衡策略，如圖 3-4所示：

• 在DataNode端按照固定的時間窗口采集節(jié)點負載信息，包括IO，Load，帶寬，磁盤使用率信息，通過滑動時間窗口，獲取當(dāng)前一段時間內(nèi)負載均值信息。

• 依托 DataNode 心跳上報到NameNode節(jié)點相關(guān)負載信息，NameNode節(jié)點按照設(shè)定的權(quán)重進行匯總打分。

• 當(dāng)Client請求NameNode新增Block時，NameNode每次選擇DataNode時會隨機選出2個DataNode節(jié)點，根據(jù)之前匯總的分數(shù)，選擇負載較低的節(jié)點。

圖 3-4 NameNode 負載均衡策略

（三）NameNode 刪除保護策略

在管理數(shù)據(jù)的過程中，由于多次出現(xiàn)數(shù)據(jù)誤刪的操作，HDFS原生的回收站功能不足，且事后恢復(fù)數(shù)據(jù)的工作非常困難，我們針對刪除操作進行了限制，用于保護集群中存儲的數(shù)據(jù)，主要有以下幾點：

• 在NameNode端配置能刪除的最小層級，如配置為2，則只能刪除目錄層級在2級以上的目錄；

• 配置可動態(tài)刷新的保護目錄列表，若被刪除的目錄包含在該列表中或是列表中某個目錄的父祖目錄，則禁止刪除；

• 所有RPC調(diào)用的刪除操作轉(zhuǎn)化為移動到回收站操作，且需要經(jīng)過上述最小層級驗證和保護目錄驗證；

• 針對回收站的清理操作，只允許超級管理員用戶和NameNode自動觸發(fā)的回收站清理；

• 回收站清理操作在業(yè)務(wù)低峰時間進行，并對刪除操作進行限流，保護刪除對NameNode RPC耗時影響。

（四）NameNode 大刪除優(yōu)化策略

由于集群文件大小不一，存在部分目錄文件數(shù)量較多，同時開啟了上述介紹的刪除保護策略，每日回收站清理時會有大量的刪除操作。刪除操作持寫鎖時間長，特別是刪除存在大量文件的目錄時，可能持寫鎖達到分鐘級，造成NameNode無法處理其他讀寫請求，因此我們參照社區(qū)實現(xiàn)了大刪除異步化策略。從圖3-5的火焰圖中可以看出，刪除操作持鎖時間主要由removeBlocks占據(jù)，因此我們做了如下優(yōu)化措施：

• 執(zhí)行刪除操作時，同步從父目錄中刪除，并收集該目錄的block信息；

• 異步向DataNode發(fā)送刪除數(shù)據(jù)的指令，即使NameNode在該過程中意外終止，數(shù)據(jù)會在下次DataNode塊匯報時刪除。

通過上述方式，有效的減少了大量文件目錄刪除時持鎖時間，耗時從分鐘級下降到了秒級。

圖 3-5 NameNode delete操作火焰圖

（五）NameNode FsImage并行加載

由于HDFS單NameSpace的元數(shù)據(jù)總量上升，我們發(fā)現(xiàn)生產(chǎn)環(huán)境中NameNode節(jié)點啟動時間過長（最長約80min），不僅影響運維效率， 還增加了運維重啟過程中的單點風(fēng)險， 一旦出現(xiàn)宕機等異常情況，服務(wù)將長時間不可用。因此，如何加快NameNode重啟速度是我們亟待解決的問題。

經(jīng)分析發(fā)現(xiàn)，NameNode啟動信息主要包括以下四個階段：

1. Loading fsimage：加載fsimage，并構(gòu)建目錄樹，耗時較長。

2. Loading edits：回放EditLog，耗時一般在亞秒級，對于長達小時級的重啟時間來說，該階段可能忽略不計。

3. Saving checkpoint：Checkpoint在HDFS-7097 優(yōu)化了鎖粒度后，可以與Reporting blocks階段并行，且耗時遠小于Reporting blocks階段，因此，該階段不是NameNode重啟的瓶頸， 亦可忽略。

4. Reporting blocks：隱含DataNode registering過程，并接受DataNode BlockReport匯報，耗時最長。

圖 3-6 NameNode Fsimage 構(gòu)成圖

由于DataNode BlockReport存在一些方法可以進行加速匯報，我們當(dāng)前只做了加載fsimage的優(yōu)化加速。我們對fsimage中占比最大（90%以上）的部分為INodeSection / INodeDirectorySection進行并行（多線程）加載改造，如上圖3-6所示：

• 將Section拆分為多個小Sub-Section，然后更新FileSummary Section，記錄各SubSecton的信息詳情；

• 加載時，依據(jù)索引啟動并行的任務(wù)，去加載SubSection對應(yīng)的區(qū)間數(shù)據(jù)，來達到并行加載的目的，縮短加載時長。

通過采用FSimage并行加載機制，NameNode啟動時間有了明顯的下降，從大約80min下降到了50min 左右，后續(xù)我們也會繼續(xù)優(yōu)化BlockReport時間，進一步降低啟動耗時。

（六）HDFS數(shù)據(jù)元倉

HDFS元倉是HDFS所有文件路徑的大小信息，讀寫信息和對應(yīng)表信息的匯總，基于每日凌晨產(chǎn)出的HDFS文件鏡像和HDFS 審計日志以及Hive元數(shù)據(jù)信息，通過一系列ETL任務(wù)，生成HDFS 文件信息寬表，積累一定時間段數(shù)據(jù)后，我們可以獲取目錄文件增長，文件訪問信息等數(shù)據(jù)，用于指導(dǎo)數(shù)據(jù)治理和數(shù)據(jù)冷存等業(yè)務(wù)的開展，具體架構(gòu)如圖3-7所示：

圖 3-7 HDFS 元倉模型架構(gòu)

用數(shù)據(jù)思維指導(dǎo)數(shù)據(jù)治理，在HDFS元倉搭建完成后，我們和公司內(nèi)數(shù)倉數(shù)據(jù)治理團隊，SRE團隊一起，多次推動數(shù)據(jù)治理，建設(shè)HDFS水位預(yù)警機制，輸出數(shù)據(jù)使用報表，推動用戶數(shù)據(jù)自治。

（七）Smart Storage Manager 管理工具

Smart Storage Manager是Intel開源的智能存儲管理系統(tǒng)，可以智能的管理HDFS上的數(shù)據(jù)，包括自動化使用異構(gòu)存儲，HDFS Cache，小文件合并，塊級別的EC和數(shù)據(jù)壓縮等，主要架構(gòu)如圖3-6所示。我們引入了SSM服務(wù)結(jié)合HDFS元倉建設(shè)了B站自己的HDFS數(shù)據(jù)管理服務(wù)，當(dāng)前主要用于冷存數(shù)據(jù)轉(zhuǎn)換服務(wù)。

• 基于元倉信息，分析HDFS路徑一定周期內(nèi)的訪問次數(shù)來判斷是否需要冷存，生成相應(yīng)的SSM規(guī)則。

• SSM Server 根據(jù)上述元倉產(chǎn)生的規(guī)則自動化進行數(shù)據(jù)冷備。

• 后續(xù)我們將不斷拓展SSM服務(wù)，支持對用戶透明的數(shù)據(jù)EC策略的等優(yōu)化措施。

圖 3-8 HDFS Smart Storage Manager 架構(gòu)

HDFS 數(shù)據(jù)層的問題主要是Client寫入的問題，在一個復(fù)雜的分布式系統(tǒng)中，熱點的存在始終無法避免，我們所做的就是盡力保障整個HDFS讀寫的穩(wěn)定性。

（一）HDFS Client寫入慢節(jié)點處理策略

HDFS是一個復(fù)雜的分布式存儲系統(tǒng)，其中各個節(jié)點負載不一，寫入非常容易遇到慢節(jié)點問題。為解決此類問題，我們陸續(xù)推出了Pipline Recovery策略和FastFailover策略提升寫入的效率。

• HDFS Client 統(tǒng)計寫入單個packet耗時，同時判斷寫入一個Block數(shù)據(jù)量，如果寫入Block的數(shù)據(jù)量低于50%的Block Size，且寫入Packet的耗時超出設(shè)定的閾值，則剔除導(dǎo)致寫入慢的DataNode節(jié)點

• HDFS Client 進入 Pipline Recovery 狀態(tài)，重新向NameNode申請新的DataNode ，重建pipline，恢復(fù)寫入流，如圖4-1所示。

• 如果寫入Block的數(shù)據(jù)量高于50%的Block Size時，且寫入Packet的耗時超出設(shè)定的閾值，則提前結(jié)束當(dāng)前block，開啟新的block進行寫入，如圖4-2所示。

圖 4-1 HDFS Client Pipeline Recovery 策略

圖 4-2 HDFS Client FastFailover 策略

通過上述的Pipeline Recovery策略和FastFailover策略，HDFS客戶端的讀寫能力有了很大的提升。寫入packet長尾時間從分鐘級下降到秒級，平均耗時（遇到慢節(jié)點的情況）從秒級下降到毫秒級如圖4-3、圖4-4所示。目前Pipline Recovery策略觸發(fā)次數(shù)大約在50次/s，觸發(fā)FastFailover策略大約在100次/24H。

圖 4-3 未進行優(yōu)化措施

圖 4-4 支持Pipeline Recovery策略和FastFailover策略后

（二）HDFS Client FastSwitchRead功能

客戶端訪問HDFS存儲系統(tǒng)讀取文件時，會訪問NameNode獲取文件的全部或者部分block列表，每個block上帶有按距離排好序的datanode地址，客戶端拿到block的位置信息后，對于每個block，選擇距離客戶端最近的datanode，建立連接來讀取當(dāng)前block的數(shù)據(jù)。如果連接的DataNode正好屬于慢節(jié)點，則極有可能導(dǎo)致讀取文件速度變慢。因此我們采用以下兩種方式優(yōu)化HDFS Client讀取數(shù)據(jù)。

• 基于時間窗口吞吐量的慢節(jié)點切換

每個block包含多個packet，hdfs client在讀取數(shù)據(jù)的時候，是按照packet來讀取的，因此，我們假設(shè)block-1有d1,d2兩個副本，n個packet，同時，我們設(shè)定時間窗口為64ms(即當(dāng)時間窗口超過64ms計算一次吞吐量)，初始吞吐量的閾值為4474bytes/ms，如下圖所示：

圖 4-5 基于時間窗口吞吐量的慢節(jié)點切換

• 基于動態(tài)調(diào)整超時時間的慢節(jié)點切換

從上述基于時間窗口吞吐量避免慢節(jié)點可知，計算吞吐量有個前提是，當(dāng)前packet必須讀取完成，而通常會有在一個慢節(jié)點上讀一個packet耗時較長（如讀一個packet耗時超過1分鐘）的現(xiàn)象，為了避免這樣情況發(fā)生，保證遇到慢節(jié)點時切換足夠敏感，我們通過動態(tài)調(diào)整客戶端與DataNode的 read socket timeout超時參數(shù)，來實現(xiàn)慢節(jié)點的切換，我們從一個較小的超時時間（128ms）開始配置，每次切換后超時時間*2，最大時間不超過30s。

圖 4-6 基于動態(tài)調(diào)整超時時間的慢節(jié)點切換

（三）DataNode拆鎖優(yōu)化

• DataNode offerService線程同時負責(zé)heartbeat/fbr/ibr多種工作，經(jīng)過分析Top20慢DataNode日志發(fā)現(xiàn)，部分時段processCommand耗時可達分鐘級, 該操作會阻塞其會阻塞ibr過程，導(dǎo)致block匯報延遲，影響close效率，為解決該問題，對processCommand操作進行異步化處理；

• DataNode 鎖優(yōu)化：DataNode Server端數(shù)據(jù)處理使用的是排它鎖，當(dāng)存在IO打滿、Load高等情況時，單操作持鎖時間變長，將影響RPC吞吐；為解決該問題， 將排它鎖轉(zhuǎn)換為讀寫鎖，讓讀操作并行起來，減少整體的持鎖時間， 增加RPC吞吐；

如下圖所示，經(jīng)過拆鎖優(yōu)化后，WriteBlockAvgTime 有了很大的提升。

圖 4-7 升級前DataNode RPC處理均值

圖 4-8 升級后DataNode RPC處理均值

隨著集群規(guī)模的不斷擴大，同時由于單個機房機位達到機房上限無法提供更多的機位用于部署HDFS存儲節(jié)點，而單純在異地機房部署DataNode節(jié)點會帶來無法預(yù)計的帶寬問題。因此為了集群的持續(xù)發(fā)展，以及跨機房網(wǎng)絡(luò)的帶寬瓶頸和網(wǎng)絡(luò)抖動問題，我們設(shè)計并建設(shè)了HDFS多機房體系。

• 在異地機房部署相同的HDFS和YARN集群。

• 通過Router掛載點信息確定數(shù)據(jù)存儲機房。

• 在任務(wù)調(diào)度服務(wù)上配置DataManager服務(wù)，用于判斷任務(wù)調(diào)度機房信息。

• 任務(wù)統(tǒng)一提交到RMProxy根據(jù)任務(wù)/用戶/隊列等mapping關(guān)系自動路由到相應(yīng)機房的Yarn集群。

• 公共依賴數(shù)據(jù)由Transfer服務(wù)拷貝鏡像數(shù)據(jù)到異地機房，并做TTL管理。

• 任務(wù)跨機房數(shù)據(jù)讀寫統(tǒng)一接入限流服務(wù)，保障跨機房帶寬。

圖 5-1 多機房體系架構(gòu)

整個跨機房體系聯(lián)動了許多部門，整體架構(gòu)較復(fù)雜，涉及到調(diào)度，存儲，計算引擎和工具側(cè)改造，在這就不多做贅述了，后續(xù)我們會針對跨機房項目單獨分享一篇文章介紹。

（一）對用戶透明的EC策略

由于總體數(shù)據(jù)量的膨脹，對總體儲存的消耗也與日俱增，為了響應(yīng)公司整體降本增效的戰(zhàn)略，我們準備對大量數(shù)據(jù)進行EC處理。EC即ErasureCoding，通過對存儲數(shù)據(jù)進行編碼，能有效降低總存儲量，提升存儲的穩(wěn)健性。為了盡快開展EC工作，并且做到對各種用戶的讀寫方式透明，我們預(yù)期做到以下幾點：

• 開發(fā)EC Data Proxy Sever(Datanode端實現(xiàn)) 兼容老版本客戶端讀EC數(shù)據(jù)。

• 合并 EC相關(guān)Patch 到當(dāng)前使用的HDFS 客戶端。

• 單獨部署3.x版本HDFS集群存儲EC數(shù)據(jù)。

• HDFS Router研發(fā)支持EC掛載點，EC數(shù)據(jù)讀寫對用戶透明。

• 開發(fā)對用戶透明的自動化EC轉(zhuǎn)換工具，數(shù)據(jù)校驗工具。

（二）冷熱溫三級數(shù)據(jù)路由策略

由于數(shù)據(jù)熱點的存在（如部分公共Hive維表等）經(jīng)常導(dǎo)致DataNode節(jié)點整體IO打高，影響該DataNode上其他的數(shù)據(jù)讀寫受阻，我們計劃引入Alluxio組件，支持熱點數(shù)據(jù)緩存，在Router改造掛載點，使其支持掛載點冷熱溫三級數(shù)據(jù)類型，自動化路由到對應(yīng)的目錄。同時支持HDFS元倉自動化分析數(shù)據(jù)訪問熱度，數(shù)據(jù)按訪問熱度自動降級為冷存或EC數(shù)據(jù)。

（三）NameNode拆鎖

隨著元數(shù)據(jù)層的擴展，我們當(dāng)前已經(jīng)擴展到十幾組的規(guī)模。但元數(shù)據(jù)層的擴容不可能是無限制的，同時各組NameNode的qps請求不均衡，非常出現(xiàn)熱點NameSpace的存在，因此對NameNode進行優(yōu)化的工作也是必不可少的?？紤]到NameNode鎖機制，寫操作會鎖住整個目錄樹，我們計劃對NameNode目錄鎖進行優(yōu)化，提升NameNode讀寫能力。

（四）Hadoop 3.x版本升級

為了支持HDFS的EC策略，我們計劃新建3.x版本HDFS集群，用于存儲EC數(shù)據(jù)，由于3.x版本集成了很多HDFS相關(guān)優(yōu)化，在讀寫兼容的情況下，我們計劃用3.x版本慢慢替換掉現(xiàn)有的2.x版本的HDFS集群。