1. 程式人生 > >NameNode啟動過程詳細剖析

NameNode啟動過程詳細剖析

前面涉及了namenode中的相關類,下面轉載一下儲存結構

NameNode中幾個關鍵的資料結構
1、FSImage
Namenode會將HDFS的檔案和目錄元資料儲存在一個叫fsimage的二進位制檔案中,每次儲存fsimage之後到下次儲存之間的所有hdfs操作,將會記錄在editlog檔案中,當editlog達到一定的大小(bytes,由fs.checkpoint.size引數定義)或從上次儲存過後一定時間段過後(sec,由fs.checkpoint.period引數定義),namenode會重新將記憶體中對整個HDFS的目錄樹和檔案元資料刷到fsimage檔案中。Namenode就是通過這種方式來保證HDFS中元資料資訊的安全性。

Fsimage是一個二進位制檔案,當中記錄了HDFS中所有檔案和目錄的元資料資訊,在我的Hadoop的HDFS版中,該檔案的中儲存檔案和目錄的格式如下:

 ss

 當namenode重啟載入fsimage時,就是按照如下格式協議從檔案流中載入元資料資訊。從fsimag的儲存格式可以看出,fsimage儲存有如下資訊:

1.         首先是一個image head,其中包含:

a)         imgVersion(int):當前image的版本資訊

b)        namespaceID(int):用來確保別的HDFS instance中的datanode不會誤連上當前NN。

c)         numFiles(long):整個檔案系統中包含有多少檔案和目錄

d)        genStamp(long):生成該image時的時間戳資訊。

2.         接下來便是對每個檔案或目錄的源資料資訊,如果是目錄,則包含以下資訊:

a)         path(String):該目錄的路徑,如”/user/build/build-index”

b)        replications(short):副本數(目錄雖然沒有副本,但這裡記錄的目錄副本數也為3)

c)         mtime(long):該目錄的修改時間的時間戳資訊

d)        atime(long):該目錄的訪問時間的時間戳資訊

e)         blocksize(long):目錄的blocksize都為0

f)         numBlocks(int):實際有多少個檔案塊,目錄的該值都為-1,表示該item為目錄

g)        nsQuota(long):namespace Quota值,若沒加Quota限制則為-1

h)        dsQuota(long):disk Quota值,若沒加限制則也為-1

i)          username(String):該目錄的所屬使用者名稱

j)          group(String):該目錄的所屬組

k)        permission(short):該目錄的permission資訊,如644等,有一個short來記錄。

3.         若從fsimage中讀到的item是一個檔案,則還會額外包含如下資訊:

a)         blockid(long):屬於該檔案的block的blockid,

b)        numBytes(long):該block的大小

c)         genStamp(long):該block的時間戳

當該檔案對應的numBlocks數不為1,而是大於1時,表示該檔案對應有多個block資訊,此時緊接在該fsimage之後的就會有多個blockid,numBytes和genStamp資訊。

因此,在namenode啟動時,就需要對fsimage按照如下格式進行順序的載入,以將fsimage中記錄的HDFS元資料資訊載入到記憶體中。

2、BlockMap
從以上fsimage中載入如namenode記憶體中的資訊中可以很明顯的看出,在fsimage中,並沒有記錄每一個block對應到哪幾個datanodes的對應表資訊,而只是儲存了所有的關於namespace的相關資訊。而真正每個block對應到datanodes列表的資訊在hadoop中並沒有進行持久化儲存,而是在所有datanode啟動時,每個datanode對本地磁碟進行掃描,將本datanode上儲存的block資訊彙報給namenode,namenode在接收到每個datanode的塊資訊彙報後,將接收到的塊資訊,以及其所在的datanode資訊等儲存在記憶體中。HDFS就是通過這種塊資訊彙報的方式來完成 block -> datanodes list的對應表構建。Datanode向namenode彙報塊資訊的過程叫做blockReport,而namenode將block -> datanodes list的對應表資訊儲存在一個叫BlocksMap的資料結構中。

BlocksMap的內部資料結構如下:   

ss

如上圖顯示,BlocksMap實際上就是一個Block物件對BlockInfo物件的一個Map表,其中Block物件中只記錄了blockid,block大小以及時間戳資訊,這些資訊在fsimage中都有記錄。而BlockInfo是從Block物件繼承而來,因此除了Block物件中儲存的資訊外,還包括代表該block所屬的HDFS檔案的INodeFile物件引用以及該block所屬datanodes列表的資訊(即上圖中的DN1,DN2,DN3,該資料結構會在下文詳述)。

因此在namenode啟動並載入fsimage完成之後,實際上BlocksMap中的key,也就是Block物件都已經載入到BlocksMap中,每個key對應的value(BlockInfo)中,除了表示其所屬的datanodes列表的陣列為空外,其他資訊也都已經成功載入。所以可以說:fsimage載入完畢後,BlocksMap中僅缺少每個塊對應到其所屬的datanodes list的對應關係資訊。所缺這些資訊,就是通過上文提到的從各datanode接收blockReport來構建。當所有的datanode彙報給namenode的blockReport處理完畢後,BlocksMap整個結構也就構建完成。

BlockMap中datanode列表資料結構
在BlockInfo中,將該block所屬的datanodes列表儲存在一個Object[]陣列中,但該陣列不僅僅儲存了datanodes列表,還包含了額外的資訊。實際上該陣列儲存瞭如下資訊:

ss

上圖表示一個block包含有三個副本,分別放置在DN1,DN2和DN3三個datanode上,每個datanode對應一個三元組,該三元組中的第二個元素,即上圖中prev block所指的是該block在該datanode上的前一個BlockInfo引用。第三個元素,也就是上圖中next Block所指的是該block在該datanode上的下一個BlockInfo引用。每個block有多少個副本,其對應的BlockInfo物件中就會有多少個這種三元組。

       Namenode採用這種結構來儲存block->datanode list的目的在於節約namenode記憶體。由於namenode將block->datanodes的對應關係儲存在了記憶體當中,隨著HDFS中檔案數的增加,block數也會相應的增加,namenode為了儲存block->datanodes的資訊已經耗費了相當多的記憶體,如果還像這種方式一樣的儲存datanode->block list的對應表,勢必耗費更多的記憶體,而且在實際應用中,要查一個datanode上儲存的block list的應用實際上非常的少,大部分情況下是要根據block來查datanode列表,所以namenode中通過上圖的方式來儲存block->datanode list的對應關係,當需要查詢datanode->block list的對應關係時,只需要沿著該資料結構中next Block的指向關係,就能得出結果,而又無需儲存datanode->block list在記憶體中。

NameNode啟動過程
fsimage載入過程
Fsimage載入過程完成的操作主要是為了:

1.         從fsimage中讀取該HDFS中儲存的每一個目錄和每一個檔案

2.         初始化每個目錄和檔案的元資料資訊

3.         根據目錄和檔案的路徑,構造出整個namespace在記憶體中的映象

4.         如果是檔案,則讀取出該檔案包含的所有blockid,並插入到BlocksMap中。

整個載入流程如下圖所示:

 ww

如上圖所示,namenode在載入fsimage過程其實非常簡單,就是從fsimage中不停的順序讀取檔案和目錄的元資料資訊,並在記憶體中構建整個namespace,同時將每個檔案對應的blockid儲存入BlocksMap中,此時BlocksMap中每個block對應的datanodes列表暫時為空。當fsimage載入完畢後,整個HDFS的目錄結構在記憶體中就已經初始化完畢,所缺的就是每個檔案對應的block對應的datanode列表資訊。這些資訊需要從datanode的blockReport中獲取,所以載入fsimage完畢後,namenode程序進入rpc等待狀態,等待所有的datanodes傳送blockReports。

blockReport階段
每個datanode在啟動時都會掃描其機器上對應儲存hdfs block的目錄下(dfs.data.dir)所儲存的所有檔案塊,然後通過namenode的rpc呼叫將這些block資訊以一個long陣列的方式傳送給namenode,namenode在接收到一個datanode的blockReport rpc呼叫後,從rpc中解析出block陣列,並將這些接收到的blocks插入到BlocksMap表中,由於此時BlocksMap缺少的僅僅是每個block對應的datanode資訊,而namenoe能從report中獲知當前report上來的是哪個datanode的塊資訊,所以,blockReport過程實際上就是namenode在接收到塊資訊彙報後,填充BlocksMap中每個block對應的datanodes列表的三元組資訊的過程。其流程如下圖所示:

 ss

當所有的datanode彙報完block,namenode針對每個datanode的彙報進行過處理後,namenode的啟動過程到此結束。此時BlocksMap中block->datanodes的對應關係已經初始化完畢。如果此時已經達到安全模式的推出閾值,則hdfs主動退出安全模式,開始提供服務。

啟動過程資料採集和瓶頸分析
對namenode的整個啟動過程有了詳細瞭解之後,就可以對其啟動過程中各階段各函式的呼叫耗時進行profiling的採集,資料的profiling仍然分為兩個階段,即fsimage載入階段和blockReport階段。

fsimage載入階段效能資料採集和瓶頸分析
以下是對建庫叢集真實的fsimage載入過程的的效能採集資料:

從上圖可以看出,fsimage的載入過程那個中,主要耗時的操作分別分佈在FSDirectory.addToParent,FSImage.readString,以及PermissionStatus.read三個操作,這三個操作分別佔用了載入過程的73%,15%以及8%,加起來總共消耗了整個載入過程的96%。而其中FSImage.readString和PermissionStatus.read操作都是從fsimage的檔案流中讀取資料(分別是讀取String和short)的操作,這種操作優化的空間不大,但是通過調整該檔案流的Buffer大小來提高少許效能。而FSDirectory.addToParent的呼叫卻佔用了整個載入過程的73%,所以該呼叫中的優化空間比較大。

       以下是addToParent呼叫中的profiling資料:

從以上資料可以看出addToParent呼叫佔用的73%的耗時中,有66%都耗在了INode.getPathComponents呼叫上,而這66%分別有36%消耗在INode.getPathNames呼叫,30%消耗在INode.getPathComponents呼叫。這兩個耗時操作的具體分佈如以下資料所示:

可以看出,消耗了36%的處理時間的INode.getPathNames操作,全部都是在通過String.split函式呼叫來對檔案或目錄路徑進行切分。另外消耗了30%左右的處理時間在INode.getPathComponents中,該函式中最終耗時都耗在獲取字串的byte陣列的java原生操作中。

blockReport階段效能資料採集和瓶頸分析
由於blockReport的呼叫是通過datanode呼叫namenode的rpc呼叫,所以在namenode進入到等待blockreport階段後,會分別開啟rpc呼叫的監聽執行緒和rpc呼叫的處理執行緒。其中rpc處理和rpc鑑定的呼叫耗時分佈如下圖所示:

而其中rpc的監聽執行緒的優化是另外一個話題,在其他的issue中再詳細討論,且由於blockReport的操作實際上是觸發的rpc處理執行緒,所以這裡只關心rpc處理執行緒的效能資料。

       在namenode處理blockReport過程中的呼叫耗時效能資料如下:

 

可以看出,在namenode啟動階段,處理從各個datanode彙報上來的blockReport耗費了整個rpc處理過程中的絕大部分時間(48/49),blockReport處理邏輯中的耗時分佈如下圖:

 

從上圖資料中可以發現,blockReport階段中耗時分佈主要耗時在FSNamesystem.addStoredBlock呼叫以及DatanodeDescriptor.reportDiff過程中,分別耗時37/48和10/48,其中FSNamesystem.addStoredBlock所進行的操作時對每一個彙報上來的block,將其於彙報上來的datanode的對應關係初始化到namenode記憶體中的BlocksMap表中。所以對於每一個block就會呼叫一次該方法。所以可以看到該方法在整個過程中呼叫了774819次,而另一個耗時的操作,即DatanodeDescriptor.reportDiff,該操作的過程在上文中有詳細介紹,主要是為了將該datanode彙報上來的blocks跟namenode記憶體中的BlocksMap中進行對比,以決定那個哪些是需要新增到BlocksMap中的block,哪些是需要新增到toRemove佇列中的block,以及哪些是新增到toValidate佇列中的block。由於這個操作需要針對每一個彙報上來的block去查詢BlocksMap,以及namenode中的其他幾個map,所以該過程也非常的耗時。而且從呼叫次數上可以看出,reportDiff呼叫在啟動過程中僅呼叫了14次(有14個datanode進行塊彙報),卻耗費了10/48的時間。所以reportDiff也是整個blockReport過程中非常耗時的瓶頸所在。

       同時可以看到,出了reportDiff,addStoredBlock的呼叫耗費了37%的時間,也就是耗費了整個blockReport時間的37/48,該方法的呼叫目的是為了將從datanode彙報上來的每一個block插入到BlocksMap中的操作。從該方法呼叫的執行資料如下圖所示:

從上圖可以看出,addStoredBlock中,主要耗時的兩個階段分別是FSNamesystem.countNode和DatanodeDescriptor.addBlock,後者是java中的插表操作,而FSNamesystem.countNode呼叫的目的是為了統計在BlocksMap中,每一個block對應的各副本中,有幾個是live狀態,幾個是decommission狀態,幾個是Corrupt狀態。而在namenode的啟動初始化階段,用來儲存corrput狀態和decommission狀態的block的map都還是空狀態,並且程式邏輯中要得到的僅僅是出於live狀態的block數,所以,這裡的countNoes呼叫在namenode啟動初始化階段並無需統計每個block對應的副本中的corrrput數和decommission數,而僅僅需要統計live狀態的block副本數即可,這樣countNodes能夠在namenode啟動階段變得更輕量,以節省啟動時間。

2.3 瓶頸分析總結
從profiling資料和瓶頸分歧情況來看,fsimage載入階段的瓶頸除了在分切路徑的過程中不夠優以外,其他耗時的地方几乎都是在java原生介面的呼叫中,如從位元組流讀資料,以及從String物件中獲取byte[]陣列的操作。

       而blockReport階段的耗時其實很大的原因是跟當前的namenode設計以及記憶體結構有關,比較明顯的不優之處就是在namenode啟動階段的countNode和reportDiff的必要性,這兩處在namenode初始化時的blockReport階段有一些不必要的操作浪費了時間。可以針對namenode啟動階段將必要的操作抽取出來,定製成namenode啟動階段才呼叫的方式,以優化namenode啟動效能。