1. 程式人生 > >Hadoop HDFS本地存儲目錄結構解析

Hadoop HDFS本地存儲目錄結構解析

XML -i 類型 情況 block eno 文件合並 配額 種類型

轉自:https://blog.csdn.net/superman_xxx/article/details/51689398

HDFS metadata以樹狀結構存儲整個HDFS上的文件和目錄,以及相應的權限、配額和副本因子(replication factor)等。本文基於Hadoop2.6版本介紹HDFS Namenode本地目錄的存儲結構和Datanode數據塊存儲目錄結構,也就是hdfs-site.xml中配置的dfs.namenode.name.dir和dfs.namenode.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進程導致目錄數據不一致

Hadoop HDFS本地存儲目錄結構解析