hadoop(NameNode和SecondaryNameNode)

NN和2NN工作機制

思考: NameNode中的元數據是存儲在哪裏的？
首先，我們做個假設：如果存儲在NameNode的磁盤中，因爲經常需要進行隨機訪問，還有相應客戶請求，必然是效率過低；因此，元數據需要存放在內存中，但是如果只存放在內存中，一旦斷電，內存中的元數據就會丟失，整個集羣就掛了。爲了解決這個問題，Hadoop中就產生了在磁盤中備份元數據的FSImage。
但是，這種解決方案又帶來了新的問題：當在內存中的元數據更新時，如果同時更新FSImage，就會導致效率過低；但如果不更新，就會出現一致性問題，一旦NameNode節點斷電，就會產生數據丟失。因此，又引入了Edits文件(只進行追加操作，效率很高)。每當元數據有更新或者添加元數據時，修改內存中的元數據並追加到Edits中。這樣，一旦NameNode節點斷電，可以通過FsImage和Edits的合併，合成元數據。
但是，如果長時間添加數據到Edits中，會導致該文件數據過大，效率降低，而且一旦斷電，會因爲Edits數據太多，導致元數據恢復需要的時間過長，因此，需要定期進行FSImage和Edits的合併，如果這個操作由NameNode節點自己完成，就會讓NameNode的執行效率降低。因此,引入一個新的節點SecondaryNameNode，專門用於FSImage和Edits的合併

NameNode工作機制

圖中黑色的步驟是第一階段，紫色的是第二階段

第一階段：NameNode啓動

第一次啓動NameNode格式化後，創建Fsimage和Edits文件。如果不是第一次啓動，直接加載編輯日誌(Edits)和鏡像文件(FSImage)到內存。

客戶端對元數據進行增刪改的請求。

NameNode記錄操作日誌，更新Edits。

NameNode在內存中對數據進行增刪改。

第二階段：Scondary NameNode工作

Secondary NameNode詢問NameNode是否需要CheckPoint。直接收到NameNode是否檢查的結果。

Secondary NameNode請求執行CheckPoint。

NameNode複製一份新的Edits文件；這樣就不會使得Edits文件因爲Secondary NameNode而有一段時間停止寫入

將舊的的編輯日誌和鏡像文件拷貝到Secondary NameNode。

Secondary NameNode模仿NameNode的啓動過程：加載編輯日誌和鏡像文件到自己的內存，併合並。

生成新的鏡像文件fsimage.chkpoint。

拷貝fsimage.chkpoint到NameNode。

NameNode將fsimage.chkpoint重新命名成fsimage。

ckeckpoint的條件

定時時間到

Edits文件滿了

剛啓動hadoop時

NN和2NN工作機制詳解

Fsimage： NameNode內存中元數據序列化後形成的文件。
Edits： 記錄客戶端更新元數據信息的每一步操作（可通過Edits運算出元數據）。

NameNode啓動時，先滾動Edits並生成一個空的edits.inprogress，然後加載Edits和Fsimage到內存中，此時NameNode內存就持有最新的元數據信息。Client開始對NameNode發送元數據的增刪改的請求，這些請求的操作首先會被記錄到edits.inprogress中（查詢元數據的操作不會被記錄在Edits中，因爲查詢操作不會更改元數據信息），如果此時NameNode掛掉，重啓後會從Edits中讀取元數據的信息。然後，NameNode會在內存中執行元數據的增刪改的操作。
由於Edits中記錄的操作會越來越多，Edits文件會越來越大，導致NameNode在啓動加載Edits時會很慢，所以需要對Edits和Fsimage進行合併（所謂合併，就是將Edits和Fsimage加載到內存中，照着Edits中的操作一步步執行，最終形成新的Fsimage）。SecondaryNameNode的作用就是幫助NameNode進行Edits和Fsimage的合併工作。
SecondaryNameNode首先會詢問NameNode是否需要CheckPoint（觸發CheckPoint需要滿足兩個條件中的任意一個，定時時間到和Edits中數據寫滿了）。直接帶回NameNode是否檢查結果。SecondaryNameNode執行CheckPoint操作，首先會讓NameNode滾動Edits並生成一個空的edits.inprogress，滾動Edits的目的是給Edits打個標記，以後所有新的操作都寫入edits.inprogress，其他未合併的Edits和Fsimage會拷貝到SecondaryNameNode的本地，然後將拷貝的Edits和Fsimage加載到內存中進行合併，生成fsimage.chkpoint，然後將fsimage.chkpoint拷貝給NameNode，重命名爲Fsimage後替換掉原來的Fsimage。NameNode在啓動時就只需要加載之前未合併的Edits和Fsimage即可，因爲合併過的Edits中的元數據信息已經被記錄在Fsimage中。

爲什麼2NN不能成爲NN的熱備？
答：按理2NN和NN的內存都是一樣的，因爲2NN都是copyNN的；但是最重要的是NN始終有未合併的Edits文件，這一部分始終是2NN所沒有的，所以2NN不能成爲NN的熱備份

FSImage和Edits解析

概念
NameNode被格式化之後，將在/opt/module/hadoop-2.7.2/data/tmp/dfs/name/current目錄中產生如下文件

Edits文件：

存放HDFS文件系統的所有更新操作的路徑，文件系統客戶端執行的所有寫操作首先會被記錄到Edits文件中。
Edits更新後舊的Edits不會被刪除,會一直存在

Fsimage文件：

HDFS文件系統元數據的一個永久性的檢查點，其中包含HDFS文件系統的所有目錄和文件inode的序列化信息。
默認存在兩個FSImage文件，一個最新的，一個是上一個舊的。

seen_txid：

seen_txid文件保存的是一個數字，就是最後一個edits_的數字

VERSION:

格式化HDFS產生的ID，如果NameNode的clusterID和DataNode的不同，就會出現DataNode不能加入集羣的情況

每次NameNode啓動的時候都會將Fsimage文件讀入內存，加載Edits裏面的更新操作，保證內存中的元數據信息是最新的、同步的，可以看成NameNode啓動的時候就將Fsimage和Edits文件進行了合併。

oiv查看FSImage文件

查看oiv和oev命令

基本語法

hdfs oiv -p 文件類型 -i 鏡像文件 -o 轉換後文件輸出路徑

實例實操

xml文件格式化後，部分顯示結果如下

思考： FSImage中沒有記錄塊所對應的DataNode，爲什麼？
答：在集羣啓動後，要求DataNode上報數據塊信息，並間隔一段時間再次上報

oev查看Edits文件
基本語法

hdfs oev -p 文件類型 -i編輯日誌 -o 轉換後文件輸出路徑

將顯示的xml格式化後部分顯示結果：