本文轉自 Hadoop NameNode元數據相關文件目錄解析
一. NameNode 元數據相關文件目錄架構
在第一次部署好 Hadoop 集羣的時候，我們需要在 NameNode（NN）節點上格式化磁盤：
$HADOOP_HOME/bin/hdfs namenode -format- 1
- 1
格式化完成之後，將會在 $dfs.namenode.name.dir/current 目錄下如下的文件結構
current/
|-- VERSION
|-- edits_*
|-- fsimage_0000000000008547077
|-- fsimage_0000000000008547077.md5
`-- seen_txid- 1
- 2
- 3
- 4
- 5
- 6
- 1
- 2
- 3
- 4
- 5
- 6
其中的 dfs.namenode.name.dir 是在 hdfs-site.xml 文件中配置的，默認值如下：
<property>
<name>dfs.namenode.name.dir</name>
<value>file://${hadoop.tmp.dir}/dfs/name</value>
</property>- 1
- 2
- 3
- 4
- 1
- 2
- 3
- 4
hadoop.tmp.dir 是在 core-site.xml 中配置的，默認值如下
<property>
<name>hadoop.tmp.dir</name>
<value>/tmp/hadoop-${user.name}</value>
<description>A base for other temporary directories.</description>
</property>- 1
- 2
- 3
- 4
- 5
- 1
- 2
- 3
- 4
- 5
dfs.namenode.name.dir 屬性可以配置多個目錄，如 /data1/dfs/name，/data2/dfs/name ，/data3/dfs/name 等。各個目錄存儲的文件結構和內容都完全一樣，相當於備份，這樣做的好處是當其中一個目錄損壞了，也不會影響到
Hadoop 的元數據，特別是當其中一個目錄是 NFS（網絡文件系統 Network File System，NFS）之上，即使你這臺機器損壞了，元數據也得到保存。
二. 元數據相關文件解析
下面對 $dfs.namenode.name.dir/current/ 目錄下的文件進行解釋
2.1 VERSION 文件
VERSION 文件是 Java 屬性文件，內容大致如下：
#Sun Dec 20 03:37:06 CST 2015
namespaceID=555938486
clusterID=CID-6d9c34e0-9d84-45be-8442-be73a03ddea8
cTime=0
storageType=NAME_NODE
blockpoolID=BP-391569129-10.6.3.43-1450226754562
layoutVersion=-59- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 1
- 2
- 3
- 4
- 5
- 6
- 7
其中
1. namespaceID ：是文件系統的唯一標識符，在文件系統首次格式化之後生成的
2. cTime ：表示 NameNode 存儲時間的創建時間，由於筆者我的 NameNode 沒有更新過，所以這裏的記錄值爲 0，以後對 NameNode 升級之後，cTime 將會記錄更新時間戳
3. storageType ：說明這個文件存儲的是什麼進程的數據結構信息（如果是 DataNode，storageType=DATA_NODE）
4. blockpoolID：是針對每一個 Namespace 所對應的 blockpool 的 ID，上面的這個 BP-391569129-10.6.3.43-1450226754562 就是在我的 nameserver1 的 namespace下的存儲塊池的 ID，這個 ID 包括了其對應的 NameNode 節點的 ip 地址。
5. layoutVersion ：表示 HDFS 永久性數據結構的版本信息， 只要數據結構變更，版本號也要遞減，此時的 HDFS 也需要升級，否則磁盤仍舊是使用舊版本的數據結構，這會導致新版本的 NameNode 無法使用
6. clusterID ：是系統生成或手動指定的集羣 ID，在 -clusterid 選項中可以使用它；如下說明
- 使用如下命令格式化一個 Namenode：
$HADOOP_HOME/bin/hdfs namenode -format [-clusterId <cluster_id>]- 1
- 1
選擇一個唯一的 cluster_id，並且這個 cluster_id 不能與環境中其他集羣有衝突。如果沒有提供 cluster_id，則會自動生成一個唯一的
ClusterID。
- 使用如下命令格式化其他 Namenode：
$HADOOP_HOME/bin/hdfs namenode -format -clusterId <cluster_id>- 1
- 1
- 升級集羣至最新版本。在升級過程中需要提供一個 ClusterID，例如：
$HADOOP_PREFIX_HOME/bin/hdfs start namenode --config $HADOOP_CONF_DIR -upgrade -clusterId <cluster_ID>- 1
- 1
如果沒有提供 ClusterID，則會自動生成一個 ClusterID。
2.2 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 最後的尾數，不然會發生建置 namenode 時 metaData 的資料有缺少，導致誤刪 Datanode 上多餘 Block 的資訊。
2.3 fsimage 和 edits 及 md5 校驗文件
$dfs.namenode.name.dir/current 目錄下在 format 的同時也會生成 fsimage 和 edits 文件，及其對應的 md5 校驗文件。fsimage 和 edits 是 Hadoop 元數據相關的重要文件。接下來將重點講解。
三. 文件系統元數據 fsimage 和編輯日誌 edits
其中存在大量的以 edits 開頭的文件和少量的以 fsimage 開頭的文件。那麼這兩種文件到底是什麼，有什麼用？下面對這兩中類型的文件進行詳解。在進入下面的主題之前先來搞清楚 edits 和 fsimage 文件的概念：
3.1 edits 和 fsimage 文件的概念
1. fsimage文件
fsimage 文件其實是 Hadoop 文件系統元數據的一個永久性的檢查點，其中包含 Hadoop 文件系統中的所有目錄和文件 idnode 的序列化信息；
2. edits文件
存放的是 Hadoop文件系統的所有更新操作的路徑，文件系統客戶端執行的所以寫操作首先會被記錄到 edits文件中。
3.2 fsimage 和 edits 的工作原理
fsimage 和 edits 文件都是經過序列化的，在 NameNode 啓動的時候，它會將 fsimage 文件中的內容加載到內存中，之後再執行 edits 文件中的各項操作，使得內存中的元數據和實際的同步，存在內存中的元數據支持客戶端的讀操作。
NameNode 起來之後，HDFS 中的更新操作會重新寫到 edits 文件中，因爲 fsimage 文件一般都很大（GB 級別的很常見），如果所有的更新操作都往 fsimage 文件中添加，這樣會導致系統運行的十分緩慢，但是如果往 edits 文件裏面寫就不會這樣，每次執行寫操作之後，且在向客戶端發送成功代碼之前，edits 文件都需要同步更新。如果一個文件比較大，使得寫操作需要向多臺機器進行操作，只有當所有的寫操作都執行完成之後，寫操作纔會返回成功，這樣的好處是任何的操作都不會因爲機器的故障而導致元數據的不同步。
fsimage 包含 Hadoop 文件系統中的所有目錄和文件 idnode 的序列化信息；
- 對於文件來說，包含的信息有修改時間、訪問時間、塊大小和組成一個文件塊信息等
- 對於目錄來說，包含的信息主要有修改時間、訪問控制權限等信息
fsimage 並不包含 DataNode 的信息，而是包含 DataNode 上塊的映射信息，並存放到內存中，當一個新的 DataNode 加入到集羣中，DataNode 都會向 NameNode 提供塊的信息，而 NameNode 會定期的“索取”塊的信息，以使得 NameNode 擁有最新的塊映射。因爲 fsimage 包含 Hadoop 文件系統中的所有目錄和文件 idnode 的序列化信息，所以如果 fsimage 丟失或者損壞了，那麼即使 DataNode 上有塊的數據，但是我們沒有文件到塊的映射關係，我們也無法用 DataNode 上的數據！所以定期及時的備份 fsimage 和 edits 文件非常重要！
在前面我們也提到，文件系統客戶端執行的所以寫操作首先會被記錄到 edits 文件中，那麼久而久之，edits 會非常的大，而 NameNode 在重啓的時候需要執行 edits 文件中的各項操作，那麼這樣會導致 NameNode 啓動的時候非常長！
其他信息
備用 NameNode
ameNode保存了文件系統的修改信息，並將其作爲一個本地的日誌文件edits。當NameNode啓動時，它從映像文件fsimage中讀取HDFS的狀態，並開始操作一個空的edits文件。由於NameNode僅在啓動時合併fsimage和各edits文件，所以日誌文件edits在一個很忙的集羣上會變得越來越大。大日誌文件edits另一個副作用是會使NameNode在下次啓動時變長。
備用NameNode週期性地合併fsimage和edits文件，將edits限制在一個範圍內，備用NameNode與主NameNode通常運行在不同的機器上，因爲備用NameNode與主NameNode有同樣的內存要求。
備用NameNode上檢查點進程的運行受兩個配置參數控制：
dfs.namenode.checkpoint.period，兩次連續的檢查點之間的最大的時間間隔，缺省值是1小時
dfs.namenode.checkpoint.txns，最大的沒有沒有執行檢查點的事務數目，即使執行檢查點的週期未到，也將執行一次緊急檢查點，缺省值是1百萬
備用NameNode存儲最新的檢查點，它目錄結構與主NameNode一致，所以這個備用的檢查點映像在主NameNode需要時，總是能訪問的。
Checkpoint節點
NameNode採用兩個文件來保存命名空間的信息：fsimage，它是最新的已執行檢查點的命名空間的信息；edits，它是執行檢查點後命名空間變化的日誌文件。當NameNode啓動時，fsimage和edits合併，提供一個最新的文件系統的metadata，然後NameNode將新的HDFS狀態寫入fasimage，並開始一個新的edits日誌。
Checkpoint節點週期性地創建命名空間的檢查點。它從NameNode下載fsimage和edits，在本地合併它們，並將其發回給活動的NameNode。Checkpoint節點通常與NameNode不在同一臺機器上，因爲它們有同樣的內存要求。Checkpoint節點由配置文件中的bin/hdfs namenode –checkpoint來啓動。
Checkpoint(或Backup)節點的位置以及附帶的web接口由dfs.namenode.backup.address anddfs.namenode.backup.http-address參數指定。
Checkpoint進程的運行受兩個配置參數控制：
dfs.namenode.checkpoint.period，兩次連續的檢查點之間的最大的時間間隔，缺省值是1小時
dfs.namenode.checkpoint.txns，最大的沒有沒有執行檢查點的事務數目，即使執行檢查點的週期未到，也將執行一次緊急檢查點，缺省值是1百萬
Checkpoint節點上保存的最新的檢查點，其目錄結構與NameNode上一樣，這樣，如果需要，NameNode總是可以讀取這上面的已執行檢查點的文件映像。參見“import checkpoint”。
多個Checkpoint節點可以在集羣的配置文件中指定。