本文已發(fā)表于InfoQ，下面的版本又經(jīng)過少量修訂。

一、背景

在Hadoop集群整個(gè)生命周期里，由于調(diào)整參數(shù)、Patch、升級(jí)等多種場景需要頻繁操作NameNode重啟，不論采用何種架構(gòu)，重啟期間集群整體存在可用性和可靠性的風(fēng)險(xiǎn)，所以優(yōu)化NameNode重啟非常關(guān)鍵。

本文基于Hadoop-2.x和HA with QJM社區(qū)架構(gòu)和系統(tǒng)設(shè)計(jì)（如圖1所示），通過梳理NameNode重啟流程，并在此基礎(chǔ)上，闡述對(duì)NameNode重啟優(yōu)化實(shí)踐。

圖1 HDFS HA with QJM架構(gòu)圖示

二、NameNode重啟流程

在HDFS的整個(gè)運(yùn)行期里，所有元數(shù)據(jù)均在NameNode的內(nèi)存集中管理，但是由于內(nèi)存易失特性，一旦出現(xiàn)進(jìn)程退出、宕機(jī)等異常情況，所有元數(shù)據(jù)都會(huì)丟失，給整個(gè)系統(tǒng)的數(shù)據(jù)安全會(huì)造成不可恢復(fù)的災(zāi)難。為了更好的容錯(cuò)能力，NameNode會(huì)周期進(jìn)行CheckPoint，將其中的一部分元數(shù)據(jù)（文件系統(tǒng)的目錄樹Namespace）刷到持久化設(shè)備上，即二進(jìn)制文件FSImage，這樣的話即使NameNode出現(xiàn)異常也能從持久化設(shè)備上恢復(fù)元數(shù)據(jù)，保證了數(shù)據(jù)的安全可靠。

但是僅周期進(jìn)行CheckPoint仍然無法保證所有數(shù)據(jù)的可靠，如前次CheckPoint之后寫入的數(shù)據(jù)依然存在丟失的問題，所以將兩次CheckPoint之間對(duì)Namespace寫操作實(shí)時(shí)寫入EditLog文件，通過這種方式可以保證HDFS元數(shù)據(jù)的絕對(duì)安全可靠。

事實(shí)上，除Namespace外，NameNode還管理非常重要的元數(shù)據(jù)BlocksMap，描述數(shù)據(jù)塊Block與DataNode節(jié)點(diǎn)之間的對(duì)應(yīng)關(guān)系。NameNode并沒有對(duì)這部分元數(shù)據(jù)同樣操作持久化，原因是每個(gè)DataNode已經(jīng)持有屬于自己管理的Block集合，將所有DataNode的Block集合匯總后即可構(gòu)造出完整BlocksMap。

HA with QJM架構(gòu)下，NameNode的整個(gè)重啟過程中始終以SBN（StandbyNameNode）角色完成。與前述流程對(duì)應(yīng)，啟動(dòng)過程分以下幾個(gè)階段：
1. 加載FSImage； 2. 回放EditLog；
3. 執(zhí)行CheckPoint（非必須步驟，結(jié)合實(shí)際情況和參數(shù)確定，后續(xù)詳述）； 4. 收集所有DataNode的注冊(cè)和數(shù)據(jù)塊匯報(bào)。

默認(rèn)情況下，NameNode會(huì)保存兩個(gè)FSImage文件，與此對(duì)應(yīng)，也會(huì)保存對(duì)應(yīng)兩次CheckPoint之后的所有EditLog文件。一般來說，NameNode重啟后，通過對(duì)FSImage文件名稱判斷，選擇加載最新的FSImage文件及回放該CheckPoint之后生成的所有EditLog，完成后根據(jù)加載的EditLog中操作條目數(shù)及距上次CheckPoint時(shí)間間隔（后續(xù)詳述）確定是否需要執(zhí)行CheckPoint，之后進(jìn)入等待所有DataNode注冊(cè)和元數(shù)據(jù)匯報(bào)階段，當(dāng)這部分?jǐn)?shù)據(jù)收集完成后，NameNode的重啟流程結(jié)束。

從線上NameNode歷次重啟時(shí)間數(shù)據(jù)看，各階段耗時(shí)占比基本接近如圖2所示。

圖2 NameNode重啟各階段耗時(shí)占比

經(jīng)過優(yōu)化，在元數(shù)據(jù)總量540M（目錄樹240M，數(shù)據(jù)塊300M），超過4K規(guī)模的集群上重啟NameNode總時(shí)間~35min，其中加載FSImage耗時(shí)~15min，秒級(jí)回放EditLog，數(shù)據(jù)塊匯報(bào)耗時(shí)~20min，基本能夠滿足生產(chǎn)環(huán)境的需求。

2.1 加載FSImage

如前述，FSImage文件記錄了HDFS整個(gè)目錄樹Namespace相關(guān)的元數(shù)據(jù)。從Hadoop-2.4.0起，FSImage開始采用Google Protobuf編碼格式描述（HDFS-5698），詳細(xì)描述文件見fsimage.proto。根據(jù)描述文件和實(shí)現(xiàn)邏輯，FSImage文件格式如圖3所示。

圖3 FSImage文件格式

從fsimage.proto和FSImage文件存儲(chǔ)格式容易看到，除了必要的文件頭部校驗(yàn)（MAGIC）和尾部文件索引（FILESUMMARY）外，主要包含以下核心數(shù)據(jù)：

NS_INFO（NameSystemSection）：記錄HDFS文件系統(tǒng)的全局信息，包括NameSystem的ID，當(dāng)前已經(jīng)分配出去的最大Block ID以及Transaction ID等信息；

INODE（INodeSection）：整個(gè)目錄樹所有節(jié)點(diǎn)數(shù)據(jù)，包括INodeFile/INodeDirectory/INodeSymlink等所有類型節(jié)點(diǎn)的屬性數(shù)據(jù)，其中記錄了如節(jié)點(diǎn)ID，節(jié)點(diǎn)名稱，訪問權(quán)限，創(chuàng)建和訪問時(shí)間等等信息；

INODE_DIR（INodeDirectorySection）：整個(gè)目錄樹中所有節(jié)點(diǎn)之間的父子關(guān)系，配合INODE可構(gòu)建完整的目錄樹；

FILES_UNDERCONSTRUCTION（FilesUnderConstructionSection）：尚未完成寫入的文件集合，主要為重啟時(shí)重建Lease集合；

SNAPSHOT（SnapshotSection）：記錄Snapshot數(shù)據(jù)，快照是Hadoop 2.1.0引入的新特性，用于數(shù)據(jù)備份、回滾，以防止因用戶誤操作導(dǎo)致集群出現(xiàn)數(shù)據(jù)問題；

SNAPSHOT_DIFF（SnapshotDiffSection）：執(zhí)行快照操作的目錄/文件的Diff集合數(shù)據(jù)，與SNAPSHOT一起構(gòu)建較完整的快照管理能力；

SECRET_MANAGER（SecretManagerSection）：記錄DelegationKey和DelegationToken數(shù)據(jù)，根據(jù)DelegationKey及由DelegationToken構(gòu)造出的DelegationTokenIdentifier方便進(jìn)一步計(jì)算密碼，以上數(shù)據(jù)可以完善所有合法Token集合；

CACHE_MANAGER（CacheManagerSection）：集中式緩存特性全局信息，集中式緩存特性是Hadoop-2.3.0為提升數(shù)據(jù)讀性能引入的新特性；

STRING_TABLE（StringTableSection）：字符串到ID的映射表，維護(hù)目錄/文件的Permission字符到ID的映射，節(jié)省存儲(chǔ)空間。

NameNode執(zhí)行CheckPoint時(shí)，遵循Protobuf定義及上述文件格式描述，重啟加載FSImage時(shí)，同樣按照Protobuf定義的格式從文件流中讀出相應(yīng)數(shù)據(jù)構(gòu)建整個(gè)目錄樹Namespace及其他元數(shù)據(jù)。將FSImage文件從持久化設(shè)備加載到內(nèi)存并構(gòu)建出目錄樹結(jié)構(gòu)后，實(shí)際上并沒有完全恢復(fù)元數(shù)據(jù)到最新狀態(tài)，因?yàn)槊看蜟heckPoint之后還可能存在大量HDFS寫操作。

2.2 回放EditLog

NameNode在響應(yīng)客戶端的寫請(qǐng)求前，會(huì)首先更新內(nèi)存相關(guān)元數(shù)據(jù)，然后再把這些操作記錄在EditLog文件中，可以看到內(nèi)存狀態(tài)實(shí)際上要比EditLog數(shù)據(jù)更及時(shí)。

記錄在EditLog之中的每個(gè)操作又稱為一個(gè)事務(wù)，對(duì)應(yīng)一個(gè)整數(shù)形式的事務(wù)編號(hào)。在當(dāng)前實(shí)現(xiàn)中多個(gè)事務(wù)組成一個(gè)Segment，生成獨(dú)立的EditLog文件，其中文件名稱標(biāo)記了起止的事務(wù)編號(hào)，正在寫入的EditLog文件僅標(biāo)記起始事務(wù)編號(hào)。EditLog文件的格式非常簡單，沒再通過Google Protobuf描述，文件格式如圖4所示。

圖4 EditLog文件格式

一個(gè)完整的EditLog文件包括四個(gè)部分內(nèi)容，分別是：
* LAYOUTVERSION：版本信息；
* OP_START_LOG_SEGMENT：標(biāo)識(shí)文件開始；
* RECORD：順序逐個(gè)記錄HDFS寫操作的事務(wù)內(nèi)容；
* OP_END_LOG_SEGMENT：標(biāo)記文件結(jié)束。

NameNode加載FSImage完成后，即開始對(duì)該FSImage文件之后（通過比較FSImage文件名稱中包含的事務(wù)編號(hào)與EditLog文件名稱的起始事務(wù)編號(hào)大小確定）生成的所有EditLog嚴(yán)格按照事務(wù)編號(hào)從小到大逐個(gè)遵循上述的格式進(jìn)行每一個(gè)HDFS寫操作事務(wù)回放。

NameNode加載完所有必需的EditLog文件數(shù)據(jù)后，內(nèi)存中的目錄樹即恢復(fù)到了最新狀態(tài)。

2.3 DataNode注冊(cè)匯報(bào)

經(jīng)過前面兩個(gè)步驟，主要的元數(shù)據(jù)被構(gòu)建，HDFS的整個(gè)目錄樹被完整建立，但是并沒有掌握數(shù)據(jù)塊Block與DataNode之間的對(duì)應(yīng)關(guān)系BlocksMap，甚至對(duì)DataNode的情況都不掌握，所以需要等待DataNode注冊(cè)，并完成對(duì)從DataNode匯報(bào)上來的數(shù)據(jù)塊匯總。待匯總的數(shù)據(jù)量達(dá)到預(yù)設(shè)比例（dfs.namenode.safemode.threshold-pct）后退出Safemode。

NameNode重啟經(jīng)過加載FSImage和回放EditLog后，所有DataNode不管進(jìn)程是否發(fā)生過重啟，都必須經(jīng)過以下兩個(gè)步驟： 1. DataNode重新注冊(cè)RegisterDataNode；
2. DataNode匯報(bào)所有數(shù)據(jù)塊BlockReport。

對(duì)于節(jié)點(diǎn)規(guī)模較大和元數(shù)據(jù)量較大的集群，這個(gè)階段的耗時(shí)會(huì)非常可觀。主要有三點(diǎn)原因：
1. 處理BlockReport的邏輯比較復(fù)雜，相對(duì)其他RPC操作耗時(shí)較長。圖5對(duì)比了BlockReport和AddBlock兩種不同RPC的處理時(shí)間，盡管AddBlock操作也相對(duì)復(fù)雜，但是對(duì)比來看，BlockReport的處理時(shí)間顯著高于AddBlock處理時(shí)間；
2. NameNode對(duì)每一個(gè)BlockReport的RPC請(qǐng)求處理都需要持有全局鎖，也就是說對(duì)于BlockReport類型RPC請(qǐng)求實(shí)際上是串行處理；
3. NameNode重啟時(shí)所有DataNode集中在同一時(shí)間段進(jìn)行BlockReport請(qǐng)求。

圖5 BlockReport和AddBlock兩個(gè)RPC處理時(shí)間對(duì)比

之前我們?cè)贜ameNode內(nèi)存全景一文中詳細(xì)描述過Block在NameNode元數(shù)據(jù)中的關(guān)鍵作用及與Namespace/DataNode/BlocksMap的復(fù)雜關(guān)系，從中也可以看出，每個(gè)新增Block需要維護(hù)多個(gè)關(guān)系，更何況重啟過程中所有Block都需要建立同樣復(fù)雜關(guān)系，所以耗時(shí)相對(duì)較高。

三、重啟優(yōu)化

根據(jù)前面對(duì)NameNode重啟過程的簡單梳理，在各個(gè)階段可以適當(dāng)?shù)膶?shí)施優(yōu)化以加快NameNode重啟過程。

HDFS-7097 解決重啟過程中SBN執(zhí)行CheckPoint時(shí)不能處理BlockReport請(qǐng)求的問題

Fix：2.7.0

Hadoop-2.7.0版本前，SBN（StandbyNameNode）在執(zhí)行CheckPoint操作前會(huì)先獲得全局讀寫鎖fsLock，在此期間，BlockReport請(qǐng)求由于不能獲得全局寫鎖會(huì)持續(xù)處于等待狀態(tài)，直到CheckPoint完成后釋放了fsLock鎖后才能繼續(xù)。NameNode重啟的第三個(gè)階段，同樣存在這種情況。而且對(duì)于規(guī)模較大的集群，每次CheckPoint時(shí)間在分鐘級(jí)別，對(duì)整個(gè)重啟過程影響非常大。實(shí)際上，CheckPoint是對(duì)目錄樹的持久化操作，并不涉及BlocksMap數(shù)據(jù)結(jié)構(gòu)，所以CheckPoint期間是可以讓BlockReport請(qǐng)求直接通過，這樣可以節(jié)省期間BlockReport排隊(duì)等待帶來的時(shí)間開銷，HDFS-7097正是將鎖粒度放小解決了CheckPoint過程不能處理BlockReport類型RPC請(qǐng)求的問題。

與HDFS-7097相對(duì)，另一種思路也值得借鑒，就是重啟過程盡可能避免出現(xiàn)CheckPoint。觸發(fā)CheckPoint有兩種情況：時(shí)間周期或HDFS寫操作事務(wù)數(shù)，分別通過參數(shù)dfs.namenode.checkpoint.period和dfs.namenode.checkpoint.txns控制，默認(rèn)值分別是3600s和1,000,000，即默認(rèn)情況下一個(gè)小時(shí)或者寫操作的事務(wù)數(shù)超過1,000,000觸發(fā)一次CheckPoint。為了避免在重啟過程中頻繁執(zhí)行CheckPoint，可以適當(dāng)調(diào)大dfs.namenode.checkpoint.txns，建議值10,000,000 ~ 20,000,000，帶來的影響是EditLog文件累計(jì)的個(gè)數(shù)會(huì)稍有增加。從實(shí)踐經(jīng)驗(yàn)上看，對(duì)一個(gè)有億級(jí)別元數(shù)據(jù)量的NameNode，回放一個(gè)EditLog文件（默認(rèn)1,000,000寫操作事務(wù)）時(shí)間在秒級(jí)，但是執(zhí)行一次CheckPoint時(shí)間通常在分鐘級(jí)別，綜合權(quán)衡減少CheckPoint次數(shù)和增加EditLog文件數(shù)收益比較明顯。

HDFS-6763 解決SBN每間隔1min全局計(jì)算和驗(yàn)證Quota值導(dǎo)致進(jìn)程Hang住數(shù)秒的問題

Fix：2.8.0

ANN（ActiveNameNode）將HDFS寫操作實(shí)時(shí)寫入JN的EditLog文件，為同步數(shù)據(jù)，SBN默認(rèn)間隔1min從JN拉取一次EditLog文件并進(jìn)行回放，完成后執(zhí)行全局Quota檢查和計(jì)算，當(dāng)Namespace規(guī)模變大后，全局計(jì)算和檢查Quota會(huì)非常耗時(shí)，在此期間，整個(gè)SBN的Namenode進(jìn)程會(huì)被Hang住，以至于包括DN心跳和BlockReport在內(nèi)的所有RPC請(qǐng)求都不能及時(shí)處理。NameNode重啟過程中這個(gè)問題影響突出。

實(shí)際上，SBN在EditLog Tailer階段計(jì)算和檢查Quota完全沒有必要，HDFS-6763將這段處理邏輯后移到主從切換時(shí)進(jìn)行，解決SBN進(jìn)程間隔1min被Hang住的問題。

從優(yōu)化效果上看，對(duì)一個(gè)擁有接近五億元數(shù)據(jù)量，其中兩億數(shù)據(jù)塊的NameNode，優(yōu)化前數(shù)據(jù)塊匯報(bào)階段耗時(shí)~30min，其中觸發(fā)超過20次由于計(jì)算和檢查Quota導(dǎo)致進(jìn)程Hang住~20s的情況，整個(gè)BlockReport階段存在超過5min無效時(shí)間開銷，優(yōu)化后可到~25min。

HDFS-7980 簡化首次BlockReport處理邏輯優(yōu)化重啟時(shí)間

Fix：2.7.1

NameNode加載完元數(shù)據(jù)后，所有DataNode嘗試開始進(jìn)行數(shù)據(jù)塊匯報(bào)，如果匯報(bào)的數(shù)據(jù)塊相關(guān)元數(shù)據(jù)還沒有加載，先暫存消息隊(duì)列，當(dāng)NameNode完成加載相關(guān)元數(shù)據(jù)后，再處理該消息隊(duì)列。對(duì)第一次塊匯報(bào)的處理比較特別（NameNode重啟后，所有DataNode的BlockReport都會(huì)被標(biāo)記成首次數(shù)據(jù)塊匯報(bào)），為提高處理速度，僅驗(yàn)證塊是否損壞，之后判斷塊狀態(tài)是否為FINALIZED，若是建立數(shù)據(jù)塊與DataNode的映射關(guān)系，建立與目錄樹中文件的關(guān)聯(lián)關(guān)系，其他信息一概暫不處理。對(duì)于非初次數(shù)據(jù)塊匯報(bào)，處理邏輯要復(fù)雜很多，對(duì)報(bào)告的每個(gè)數(shù)據(jù)塊，不僅檢查是否損壞，是否為FINALIZED狀態(tài)，還會(huì)檢查是否無效，是否需要?jiǎng)h除，是否為UC狀態(tài)等等；驗(yàn)證通過后建立數(shù)據(jù)塊與DataNode的映射關(guān)系，建立與目錄樹中文件的關(guān)聯(lián)關(guān)系。

初次數(shù)據(jù)塊匯報(bào)的處理邏輯獨(dú)立出來，主要原因有兩方面：
* 加快NameNode的啟動(dòng)時(shí)間；測試數(shù)據(jù)顯示含~500M元數(shù)據(jù)的NameNode在處理800K個(gè)數(shù)據(jù)塊的初次塊匯報(bào)的處理時(shí)間比正常塊匯報(bào)的處理時(shí)間可降低一個(gè)數(shù)量級(jí)； * 啟動(dòng)過程中，不提供正常讀寫服務(wù)，所以只要確保正常數(shù)據(jù)（整個(gè)Namespace和所有FINALIZED狀態(tài)Blocks）無誤，無效和冗余數(shù)據(jù)處理完全可以延后到IBR（IncrementalBlockReport）或下次BR（BlockReport）。

這本來是非常合理和正常的設(shè)計(jì)邏輯，但是實(shí)現(xiàn)時(shí)NameNode在判斷是否為首次數(shù)據(jù)塊塊匯報(bào)的邏輯一直存在問題，導(dǎo)致這段非常好的改進(jìn)點(diǎn)邏輯實(shí)際上長期并未真正執(zhí)行到，直到HDFS-7980在Hadoop-2.7.1修復(fù)該問題。HDFS-7980的優(yōu)化效果非常明顯，測試顯示，對(duì)含80K Blocks的BlockReport RPC請(qǐng)求的處理時(shí)間從~500ms可優(yōu)化到~100ms，從重啟期整個(gè)BlockReport階段看，在超過600M元數(shù)據(jù)，其中300M數(shù)據(jù)塊的NameNode顯示該階段從~50min優(yōu)化到~25min。

HDFS-7503 解決重啟前大刪除操作會(huì)造成重啟后鎖內(nèi)寫日志降低處理能力

Fix：2.7.0

若NameNode重啟前產(chǎn)生過大刪除操作，當(dāng)NameNode加載完FSImage并回放了所有EditLog構(gòu)建起最新目錄樹結(jié)構(gòu)后，在處理DataNode的BlockReport時(shí)，會(huì)發(fā)現(xiàn)有大量Block不屬于任何文件，Hadoop-2.7.0版本前，對(duì)于這類情況的輸出日志邏輯在全局鎖內(nèi)，由于存在大量IO操作的耗時(shí)，會(huì)嚴(yán)重拉長處理BlockReport的處理時(shí)間，影響NameNode重啟時(shí)間。HDFS-7503的解決辦法非常簡單，把日志輸出邏輯移出全局鎖外。線上效果上看對(duì)同類場景優(yōu)化比較明顯，不過如果重啟前不觸發(fā)大的刪除操作影響不大。

防止熱備節(jié)點(diǎn)SBN（StandbyNameNode）/冷備節(jié)點(diǎn)SNN（SecondaryNameNode）長時(shí)間未正常運(yùn)行堆積大量Editlog拖慢NameNode重啟時(shí)間

選擇HA熱備方案SBN（StandbyNameNode）還是冷備方案SNN（SecondaryNameNode）架構(gòu)，執(zhí)行CheckPoint的邏輯幾乎一致，如圖6所示。如果SBN/SNN服務(wù)長時(shí)間未正常運(yùn)行，CheckPoint不能按照預(yù)期執(zhí)行，這樣會(huì)積壓大量EditLog。積壓的EditLog文件越多，重啟NameNode需要加載EditLog時(shí)間越長。所以盡可能避免出現(xiàn)SNN/SBN長時(shí)間未正常服務(wù)的狀態(tài)。

圖6 CheckPoint流程

在一個(gè)有500M元數(shù)據(jù)的NameNode上測試加載一個(gè)200K次HDFS事務(wù)操作的EditLog文件耗時(shí)~5s，按照默認(rèn)2min的EditLog滾動(dòng)周期，如果一周時(shí)間SBN/SNN未能正常工作，則會(huì)累積~5K個(gè)EditLog文件，此后一旦發(fā)生NameNode重啟，僅加載EditLog文件的時(shí)間就需要~7h，也就是整個(gè)集群存在超過7h不可用風(fēng)險(xiǎn)，所以切記要保證SBN/SNN不能長時(shí)間故障。

HDFS-6425 HDFS-6772 NameNode重啟后DataNode快速退出blockContentsStale狀態(tài)防止PostponedMisreplicatedBlocks過大影響對(duì)其他RPC請(qǐng)求的處理能力

Fix: 2.6.0， 2.7.0

當(dāng)集群中大量數(shù)據(jù)塊的實(shí)際存儲(chǔ)副本個(gè)數(shù)超過副本數(shù)時(shí)（跨機(jī)房架構(gòu)下這種情況比較常見），NameNode重啟后會(huì)迅速填充到PostponedMisreplicatedBlocks，直到相關(guān)數(shù)據(jù)塊所在的所有DataNode匯報(bào)完成且退出Stale狀態(tài)后才能被清理。如果PostponedMisreplicatedBlocks數(shù)據(jù)量較大，每次全遍歷需要消耗大量時(shí)間，且整個(gè)過程也要持有全局鎖，嚴(yán)重影響處理BlockReport的性能，HDFS-6425和HDFS-6772分別將可能在BlockReport邏輯內(nèi)部遍歷非常大的數(shù)據(jù)結(jié)構(gòu)PostponedMisreplicatedBlocks優(yōu)化到異步執(zhí)行，并在NameNode重啟后讓DataNode快速退出blockContentsStale狀態(tài)避免PostponedMisreplicatedBlocks過大入手優(yōu)化重啟效率。

降低BlockReport時(shí)數(shù)據(jù)規(guī)模

NameNode處理BlockReport的效率低主要原因還是每次BlockReport所帶的Block規(guī)模過大造成，所以可以通過調(diào)整Block數(shù)量閾值，將一次BlockReport分成多盤分別匯報(bào)，以提高NameNode對(duì)BlockReport的處理效率。可參考的參數(shù)為：dfs.blockreport.split.threshold，默認(rèn)值1,000,000，即當(dāng)DataNode本地的Block個(gè)數(shù)超過1,000,000時(shí)才會(huì)分盤進(jìn)行匯報(bào)，建議將該參數(shù)適當(dāng)調(diào)小，具體數(shù)值可結(jié)合NameNode的處理BlockReport時(shí)間及集群中所有DataNode管理的Block量分布確定。

重啟完成后對(duì)比檢查數(shù)據(jù)塊上報(bào)情況

前面提到NameNode匯總DataNode上報(bào)的數(shù)據(jù)塊量達(dá)到預(yù)設(shè)比例（dfs.namenode.safemode.threshold-pct）后就會(huì)退出Safemode，一般情況下，當(dāng)NameNode退出Safemode后，我們認(rèn)為已經(jīng)具備提供正常服務(wù)的條件。但是對(duì)規(guī)模較大的集群，按照這種默認(rèn)策略及時(shí)執(zhí)行主從切換后，容易出現(xiàn)短時(shí)間丟塊的問題。考慮在200M數(shù)據(jù)塊的集群，默認(rèn)配置項(xiàng)dfs.namenode.safemode.threshold-pct=0.999，也就是當(dāng)NameNode收集到200M*0.999=199.8M數(shù)據(jù)塊后即可退出Safemode，此時(shí)實(shí)際上還有200K數(shù)據(jù)塊沒有上報(bào)，如果強(qiáng)行執(zhí)行主從切換，會(huì)出現(xiàn)大量的丟塊問題，直到數(shù)據(jù)塊匯報(bào)完成。應(yīng)對(duì)的辦法比較簡單，嘗試調(diào)大dfs.namenode.safemode.threshold-pct到1，這樣只有所有數(shù)據(jù)塊上報(bào)后才會(huì)退出Safemode。但是這種辦法一樣不能保證萬無一失，如果啟動(dòng)過程中有DataNode匯報(bào)完數(shù)據(jù)塊后進(jìn)程掛掉，同樣存在短時(shí)間丟失數(shù)據(jù)的問題，因?yàn)镹ameNode匯總上報(bào)數(shù)據(jù)塊時(shí)并不檢查副本數(shù)，所以更穩(wěn)妥的解決辦法是利用主從NameNode的JMX數(shù)據(jù)對(duì)比所有DataNode當(dāng)前匯報(bào)數(shù)據(jù)塊量的差異，當(dāng)差異都較小后再執(zhí)行主從切換可以保證不發(fā)生上述問題。

其他

除了優(yōu)化NameNode重啟時(shí)間，實(shí)際運(yùn)維中還會(huì)遇到需要滾動(dòng)重啟集群所有節(jié)點(diǎn)或者一次性重啟整集群的情況，不恰當(dāng)?shù)闹貑⒎绞揭矔?huì)嚴(yán)重影響服務(wù)的恢復(fù)時(shí)間，所以合理控制重啟的節(jié)奏或選擇合適的重啟方式尤為關(guān)鍵，HDFS集群啟動(dòng)方式分析一文對(duì)集群重啟方式進(jìn)行了詳細(xì)的闡述，這里就不再展開。

經(jīng)過多次優(yōu)化調(diào)整，從線上NameNode歷次的重啟時(shí)間監(jiān)控指標(biāo)上看，收益非常明顯，圖7截取了其中幾次NameNode重啟時(shí)元數(shù)據(jù)量及重啟時(shí)間開銷對(duì)比，圖中直觀顯示在500M元數(shù)據(jù)量級(jí)下，重啟時(shí)間從~4000s優(yōu)化到~2000s。

圖7 NameNode重啟時(shí)間對(duì)比

這里羅列了一小部分實(shí)踐過程中可以有效優(yōu)化重啟NameNode時(shí)間或者重啟全集群的點(diǎn)，其中包括了社區(qū)成熟Patch和相關(guān)參數(shù)優(yōu)化，雖然實(shí)現(xiàn)邏輯都很小，但是實(shí)踐收益非常明顯。當(dāng)然除了上述提到，NameNode重啟還有很多可以優(yōu)化的地方，比如優(yōu)化FSImage格式，并行加載等等，社區(qū)也在持續(xù)關(guān)注和優(yōu)化，部分討論的思路也值得關(guān)注、借鑒和參考。

四、總結(jié)

NameNode重啟甚至全集群重啟在整個(gè)Hadoop集群的生命周期內(nèi)是比較頻繁的運(yùn)維操作，優(yōu)化重啟時(shí)間可以極大提升運(yùn)維效率，避免可能存在的風(fēng)險(xiǎn)。本文通過分析NameNode啟動(dòng)流程，并結(jié)合實(shí)踐過程簡單羅列了幾個(gè)供參考的有效優(yōu)化點(diǎn)，借此希望能給實(shí)踐過程提供可優(yōu)化的方向和思路。

五、參考文獻(xiàn)

• NameNode內(nèi)存全景
• NameNode內(nèi)存詳解
• Apache Hadoop
• Hadoop Source
• HDFS Issues
• Cloudera Blog

作者簡介

小橋，美團(tuán)點(diǎn)評(píng)技術(shù)工程部數(shù)據(jù)平臺(tái)研發(fā)工程師。2012年北京航空航天大學(xué)畢業(yè)，2015年初加入美團(tuán)點(diǎn)評(píng)，關(guān)注Hadoop生態(tài)存儲(chǔ)方向，致力于為美團(tuán)點(diǎn)評(píng)提供穩(wěn)定、高效、易用的離線數(shù)據(jù)存儲(chǔ)服務(wù)。

總結(jié)

以上是生活随笔為你收集整理的HDFS NameNode重启优化的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。