HDFS檔案目錄結構詳解
HDFS metadata以樹狀結構儲存整個HDFS上的檔案和目錄，以及相應的許可權、配額和副本因子（replication factor）等。本文基於Hadoop2.6版本介紹HDFS Namenode本地目錄的儲存結構和Datanode資料塊儲存目錄結構，也就是hdfs-site.xml中配置的dfs.namenode.name.dir和dfs.datanode.data.dir。
一、NameNode
HDFS metadata主要儲存兩種型別的檔案
1、fsimage
記錄某一永久性檢查點（Checkpoint）時整個HDFS的元資訊
2、edits
所有對HDFS的寫操作都會記錄在此檔案中
Checkpoint介紹
HDFS會定期（dfs.namenode.checkpoint.period，預設3600秒）的對最近的fsimage和一批新edits檔案進行Checkpoint（也可以手工命令方式），Checkpoint發生後會將前一次Checkpoint後的所有edits檔案合併到新的fsimage中，HDFS會儲存最近兩次checkpoint的fsimage。Namenode啟動時會把最新的fsimage載入到記憶體中。
下面是一個標準的dfs.namenode.name.dir目錄結構，注意edits和fsimage也可以通過配置放到不同目錄中
├── current
│ ├── VERSION
│ ├── edits_0000000000000000001-0000000000000000007
│ ├── edits_0000000000000000008-0000000000000000015
│ ├── edits_0000000000000000016-0000000000000000022
│ ├── edits_0000000000000000023-0000000000000000029
│ ├── edits_0000000000000000030-0000000000000000030
│ ├── edits_0000000000000000031-0000000000000000031
│ ├── edits_inprogress_0000000000000000032
│ ├── fsimage_0000000000000000030
│ ├── fsimage_0000000000000000030.md5
│ ├── fsimage_0000000000000000031
│ ├── fsimage_0000000000000000031.md5
│ └── seen_txid
└── in_use.lock
1、VERSION
#Thu May 19 10:13:22 CST 2016 namespaceID=1242163293 clusterID=CID-124668a8-9b25-4ca7-97bf-5dd5c25041a9 cTime=1455091012961 storageType=NAME_NODE blockpoolID=BP-180412957-192.168.1.8-1419305031110 layoutVersion=-60
- layoutVersion - HDFS metadata版本號，通常只有HDFS增加新特性時才會更新這個版本號
- namespaceID/clusterID/blockpoolID - 這三個ID在整個HDFS叢集全域性唯一，作用是引導Datanode加入同一個叢集。在HDFS Federation機制下，會有多個Namenode，所以不同Namenode直接namespaceID是不同的，分別管理一組blockpoolID，但是整個叢集中，clusterID是唯一的，每次format namenode會生成一個新的，也可以使用-clusterid手工指定ID
- storageType - 有兩種取值NAME_NODE /JOURNAL_NODE，對於JournalNode的引數dfs.journalnode.edits.dir，其下的VERSION檔案顯示的是JOURNAL_NODE
- cTime - HDFS建立時間，在升級後會更新該值
2、edits_start transaction ID-end transaction ID
finalized edit log segments，在HA環境中，Standby Namenode只能讀取finalized log segments，
3、edits_inprogress__start transaction ID
當前正在被追加的edit log，HDFS預設會為該檔案提前申請1MB空間以提升效能
4、fsimage_end transaction ID
每次checkpoing（合併所有edits到一個fsimage的過程）產生的最終的fsimage，同時會生成一個.md5的檔案用來對檔案做完整性校驗
5、seen_txid
儲存最近一次fsimage或者edits_inprogress的transaction ID。需要注意的是，這並不是Namenode當前最新的transaction ID，該檔案只有在checkpoing(merge of edits into a fsimage)或者edit log roll(finalization of current edits_inprogress and creation of a new one)時才會被更新。
這個檔案的目的在於判斷在Namenode啟動過程中是否有丟失的edits，由於edits和fsimage可以配置在不同目錄，如果edits目錄被意外刪除了，最近一次checkpoint後的所有edits也就丟失了，導致Namenode狀態並不是最新的，為了防止這種情況發生，Namenode啟動時會檢查seen_txid，如果無法載入到最新的transactions，Namenode程序將不會完成啟動以保護資料一致性。
6、in_use.lock
防止一臺機器同時啟動多個Namenode程序導致目錄資料不一致
二、Datanode
Datanode主要儲存資料，下面是一個標準的dfs.datanode.data.dir目錄結構
├── current
│ ├── BP-1079595417-192.168.2.45-1412613236271
│ │ ├── current
│ │ │ ├── VERSION
│ │ │ ├── finalized
│ │ │ │ └── subdir0
│ │ │ │ └── subdir1
│ │ │ │ ├── blk_1073741825
│ │ │ │ └── blk_1073741825_1001.meta
│ │ │ │── lazyPersist
│ │ │ └── rbw
│ │ ├── dncp_block_verification.log.curr
│ │ ├── dncp_block_verification.log.prev
│ │ └── tmp
│ └── VERSION
└── in_use.lock
1、BP-random integer-NameNode-IP address-creation time
BP代表BlockPool的意思，就是上面Namenode的VERSION中的叢集唯一blockpoolID，如果是Federation HDFS，則該目錄下有兩個BP開頭的目錄，IP部分和時間戳代表建立該BP的NameNode的IP地址和建立時間戳
2、VERSION
與Namenode類似，其中storageType是DATA_NODE
#Wed Feb 10 16:00:18 CST 2016
storageID=DS-2e165f84-68b1-40c9-b501-b6b08fcb09ee
clusterID=CID-124668a8-9b25-4ca7-97bf-5dd5c25041a9
cTime=0
datanodeUuid=cb9fead7-cd64-4507-affd-c06f083708b5
storageType=DATA_NODE
layoutVersion=-56
3、finalized/rbw目錄
這兩個目錄都是用於實際儲存HDFS BLOCK的資料，裡面包含許多block_xx檔案以及相應的.meta檔案，.meta檔案包含了checksum資訊。
rbw是“replica being written”的意思，該目錄用於儲存使用者當前正在寫入的資料。
4、dncp_block_verification.log
該檔案用於追蹤每個block最後修改後的checksum值，該檔案會定期滾動，滾動後會移到.prev檔案
5、in_use.lock
防止一臺機器同時啟動多個Datanode程序導致目錄資料不一致
--------------------- 本文來自 opensure 的CSDN 部落格 ，全文地址請點選：https://blog.csdn.net/opensure/article/details/51452058?utm_source=copy