Hadoop NameNode元資料相關檔案目錄解析
在第一次部署好Hadoop叢集的時候，我們需要在NameNode（NN）節點上格式化磁碟：
| 1 | [wyp@wyp hadoop-2.2.0]$ $HADOOP_HOME/bin/hdfs namenode -format |
格式化完成之後，將會在$dfs.namenode.name.dir/current目錄下如下的檔案結構
| 123456 | current/|-- VERSION|-- edits_*|-- fsimage_0000000000008547077|-- fsimage_0000000000008547077.md5`-- seen_txid |
其中的dfs.namenode.name.dir是在hdfs-site.xml檔案中配置的，預設值如下：
| 0102030405060708091011 | dfs.namenode.name.dirfile://${hadoop.tmp.dir}/dfs/namehadoop.tmp.dir是在core-site.xml中配置的，預設值如下hadoop.tmp.dir/tmp/hadoop-${user.name}A base for other temporary directories. |
dfs.namenode.name.dir屬性可以配置多個目錄，如/data1/dfs/name,/data2/dfs/name, /data3/dfs/name,….。各個目錄儲存的檔案結構和內容都完全一樣，相當於備份，這樣做的好處是當其中一個目錄損壞了，也不會影響到 Hadoop的元資料，特別是當其中一個目錄是NFS（網路檔案系統Network File System，NFS）之上，即使你這臺機器損壞了，元資料也得到儲存。
下面對$dfs.namenode.name.dir/current/目錄下的檔案進行解釋。
1、VERSION檔案是Java屬性檔案，內容大致如下：
| 1234567 | #Fri Nov 15 19:47:46 CST 2013namespaceID=934548976clusterID=CID-cdff7d73-93cd-4783-9399-0a22e6dce196cTime=0storageType=NAME_NODEblockpoolID=BP-893790215-192.168.24.72-1383809616115layoutVersion=-47 |
其中
（1）、namespaceID是檔案系統的唯一識別符號，在檔案系統首次格式化之後生成的；
（2）、storageType說明這個檔案儲存的是什麼程序的資料結構資訊（如果是DataNode，storageType=DATA_NODE）；
（3）、cTime表示NameNode儲存時間的建立時間，由於我的NameNode沒有更新過，所以這裡的記錄值為0，以後對NameNode升級之後，cTime將會記錄更新時間戳；
（4）、layoutVersion表示HDFS永久性資料結構的版本資訊， 只要資料結構變更，版本號也要遞減，此時的HDFS也需要升級，否則磁碟仍舊是使用舊版本的資料結構，這會導致新版本的NameNode無法使用；
（5）、clusterID是系統生成或手動指定的叢集ID，在-clusterid選項中可以使用它；如下說明
| 1 | $ $HADOOP_HOME/bin/hdfs namenode -format [-clusterId ] |
選擇一個唯一的cluster_id，並且這個cluster_id不能與環境中其他叢集有衝突。如果沒有提供cluster_id，則會自動生成一個唯一的ClusterID。
b、使用如下命令格式化其他Namenode：
| 1 | $ $HADOOP_HOME/bin/hdfs namenode -format -clusterId |
c、升級叢集至最新版本。在升級過程中需要提供一個ClusterID，例如：
| 12 | $ $HADOOP_PREFIX_HOME/bin/hdfs start namenode --config $HADOOP_CONF_DIR -upgrade -clusterId |
如果沒有提供ClusterID，則會自動生成一個ClusterID。
（6）、blockpoolID：是針對每一個Namespace所對應的blockpool的ID，上面的這個BP- 893790215-192.168.24.72-1383809616115就是在我的ns1的namespace下的儲存塊池的ID，這個ID包括了 其對應的NameNode節點的ip地址。
2、$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的資訊。
3、$dfs.namenode.name.dir/current目錄下在format的同時也會生成fsimage和edits檔案，及其 對應的md5校驗檔案。fsimage和edits是Hadoop元資料相關的重要檔案，我打算在下一篇文章中fsimage和edits儲存的內容和他 們之間的關係進行說明，請關注本部落格