1. 元數據管理概述

　　HDFS元數據，按類型分，主要包括以下幾個部分：

　　1、文件、目錄自身的屬性信息，例如文件名，目錄名，修改信息等。

　　2、文件記錄的信息的存儲相關的信息，例如存儲塊信息，分塊情況，副本個數等。

　　3、記錄HDFS的Datanode的信息，用于DataNode的管理。

　　按形式分為內存元數據和元數據文件兩種，分別存在內存和磁盤上。

　　HDFS磁盤上元數據文件分為兩類，用于持久化存儲：

　　fsimage 鏡像文件：是元數據的一個持久化的檢查點，包含Hadoop文件系統中的所有目錄和文件元數據信息，但不包含文件塊位置的信息。文件塊位置信息只存儲在內存中，是在 datanode加入集群的時候，namenode詢問datanode得到的，并且間斷的更新。

　　Edits 編輯日志：存放的是Hadoop文件系統的所有更改操作(文件創建，刪除或修改)的日志，文件系統客戶端執行的更改操作首先會被記錄到edits文件中。

　　fsimage和edits文件都是經過序列化的，在NameNode啟動的時候，它會將fsimage文件中的內容加載到內存中，之后再執行edits文件中的各項操作，使得內存中的元數據和實際的同步，存在內存中的元數據支持客戶端的讀操作，也是最完整的元數據。

　　當客戶端對HDFS中的文件進行新增或者修改操作，操作記錄首先被記入edits日志文件中，當客戶端操作成功后，相應的元數據會更新到內存元數據中。因為fsimage文件一般都很大(GB級別的很常見)，如果所有的更新操作都往fsimage文件中添加，這樣會導致系統運行的十分緩慢。

　　HDFS這種設計實現著手于：一是內存中數據更新、查詢快，極大縮短了操作響應時間;二是內存中元數據丟失風險頗高(斷電等)，因此輔佐元數據鏡像文件(fsimage)+編輯日志文件(edits)的備份機制進行確保元數據的安全。

　　NameNode維護整個文件系統元數據。因此，元數據的準確管理，影響著HDFS提供文件存儲服務的能力。

　　2. 元數據目錄相關文件

　　在Hadoop的HDFS首次部署好配置文件之后，并不能馬上啟動使用，而是先要對文件系統進行格式化。需要在NameNode(NN)節點上進行如下的操作：

　　$HADOOP_HOME/bin/hdfs namenode –format

　　在這里要注意兩個概念，一個是文件系統，此時的文件系統在物理上還不存在;二就是此處的格式化并不是指傳統意義上的本地磁盤格式化，而是一些清除與準備工作。

　　格式化完成之后，將會在$dfs.namenode.name.dir/current目錄下創建如下的文件結構，這個目錄也正是namenode元數據相關的文件目錄：

　　其中的dfs.namenode.name.dir是在hdfs-site.xml文件中配置的，默認值如下：

　　dfs.namenode.name.dir屬性可以配置多個目錄，各個目錄存儲的文件結構和內容都完全一樣，相當于備份，這樣做的好處是當其中一個目錄損壞了，也不會影響到Hadoop的元數據，特別是當其中一個目錄是NFS(網絡文件系統Network File System，NFS)之上，即使你這臺機器損壞了，元數據也得到保存。

　　下面對$dfs.namenode.name.dir/current/目錄下的文件進行解釋。

　　VERSION

　　namespaceID=934548976

　　clusterID=CID-cdff7d73-93cd-4783-9399-0a22e6dce196

　　cTime=0

　　storageType=NAME_NODE

　　blockpoolID=BP-893790215-192.168.24.72-1383809616115

　　layoutVersion=-47

　　namespaceID/clusterID/blockpoolID 這些都是HDFS集群的唯一標識符。標識符被用來防止DataNodes意外注冊到另一個集群中的namenode上。這些標識在聯邦(federation)部署中特別重要。聯邦模式下，會有多個NameNode獨立工作。每個的NameNode提供唯一的命名空間(namespaceID)，并管理一組唯一的文件塊池(blockpoolID)。clusterID將整個集群結合在一起作為單個邏輯單元，在集群中的所有節點上都是一樣的。

　　storageType說明這個文件存儲的是什么進程的數據結構信息(如果是DataNode，storageType=DATA_NODE);

　　cTime NameNode存儲系統創建時間，首次格式化文件系統這個屬性是0，當文件系統升級之后，該值會更新到升級之后的時間戳;

　　layoutVersion表示HDFS永久性數據結構的版本信息，是一個負整數。

　　補充說明：

　　格式化集群的時候，可以指定集群的cluster_id，但是不能與環境中其他集群有沖突。如果沒有提供cluster_id，則會自動生成一個唯一的ClusterID。

　　$HADOOP_HOME/bin/hdfs namenode -format -clusterId

　　seen_txid

　　$dfs.namenode.name.dir/current/seen_txid非常重要，是存放transactionId的文件，format之后是0，它代表的是namenode里面的edits_*文件的尾數，namenode重啟的時候，會按照seen_txid的數字，循序從頭跑edits_0000001~到seen_txid的數字。所以當你的hdfs發生異常重啟的時候，一定要比對seen_txid內的數字是不是你edits最后的尾數。

　　Fsimage & edits

　　$dfs.namenode.name.dir/current目錄下在format的同時也會生成fsimage和edits文件，及其對應的md5校驗文件。

　　3. secondary namenode

　　NameNode職責是管理元數據信息，DataNode的職責是負責數據具體存儲，那么SecondaryNameNode的作用是什么?對很多初學者來說是非常迷惑的。它為什么會出現在HDFS中。從它的名字上看，它給人的感覺就像是NameNode的備份。但它實際上卻不是。

　　大家猜想一下，當HDFS集群運行一段事件后，就會出現下面一些問題：

　　l edit logs文件會變的很大，怎么去管理這個文件是一個挑戰。

　　l NameNode重啟會花費很長時間，因為有很多改動要合并到fsimage文件上。

　　l 如果NameNode掛掉了，那就丟失了一些改動。因為此時的fsimage文件非常舊。

　　因此為了克服這個問題，我們需要一個易于管理的機制來幫助我們減小edit logs文件的大小和得到一個最新的fsimage文件，這樣也會減小在NameNode上的壓力。這跟Windows的恢復點是非常像的，Windows的恢復點機制允許我們對OS進行快照，這樣當系統發生問題時，我們能夠回滾到最新的一次恢復點上。

　　SecondaryNameNode就是來幫助解決上述問題的，它的職責是合并NameNode的edit logs到fsimage文件中。

　　4. Checkpoint

　　每達到觸發條件，會由secondary namenode將namenode上積累的所有edits和一個最新的fsimage下載到本地，并加載到內存進行merge(這個過程稱為checkpoint)，如下圖所示：

　　4.1. Checkpoint詳細步驟

　　l NameNode管理著元數據信息，其中有兩類持久化元數據文件：edits操作日志文件和fsimage元數據鏡像文件。新的操作日志不會立即與fsimage進行合并，也不會刷到NameNode的內存中，而是會先寫到edits中(因為合并需要消耗大量的資源)，操作成功之后更新至內存。

　　l 有dfs.namenode.checkpoint.period和dfs.namenode.checkpoint.txns 兩個配置，只要達到這兩個條件任何一個，secondarynamenode就會執行checkpoint的操作。

　　l 當觸發checkpoint操作時，NameNode會生成一個新的edits即上圖中的edits.new文件，同時SecondaryNameNode會將edits文件和fsimage復制到本地(HTTP GET方式)。

　　l secondarynamenode將下載下來的fsimage載入到內存，然后一條一條地執行edits文件中的各項更新操作，使得內存中的fsimage保存最新，這個過程就是edits和fsimage文件合并，生成一個新的fsimage文件即上圖中的Fsimage.ckpt文件。

　　l secondarynamenode將新生成的Fsimage.ckpt文件復制到NameNode節點。

　　l 在NameNode節點的edits.new文件和Fsimage.ckpt文件會替換掉原來的edits文件和fsimage文件，至此剛好是一個輪回，即在NameNode中又是edits和fsimage文件。

　　l 等待下一次checkpoint觸發SecondaryNameNode進行工作，一直這樣循環操作。

　　4.2. Checkpoint觸發條件

　　Checkpoint操作受兩個參數控制，可以通過core-site.xml進行配置：

　　dfs.namenode.checkpoint.period

　　3600

　　兩次連續的checkpoint之間的時間間隔。默認1小時

　　dfs.namenode.checkpoint.txns

　　1000000

　　最大的沒有執行checkpoint事務的數量，滿足將強制執行緊急checkpoint，即使尚未達到檢查點周期。默認設置為100萬。

　　從上面的描述我們可以看出，SecondaryNamenode根本就不是Namenode的一個熱備，其只是將fsimage和edits合并。其擁有的fsimage不是最新的，因為在他從NameNode下載fsimage和edits文件時候，新的更新操作已經寫到edit.new文件中去了。而這些更新在SecondaryNamenode是沒有同步到的!當然，如果NameNode中的fsimage真的出問題了，還是可以用SecondaryNamenode中的fsimage替換一下NameNode上的fsimage，雖然已經不是最新的fsimage，但是我們可以將損失減小到最少!

作者 ：黑馬程序員大數據培訓學院
首發：http://cloud.itheima.com