HDFS的文件目錄圖

分析：從上圖可以看出，HDFS的文件目錄主要由NameNode、SecondaryNameNode和DataNode組成，而NameNode和DataNode之間由心跳機制通信。

注：

• HDFS(Hadoop Distributed File System)默認的存儲單位是128M的數(shù)據(jù)塊。
  可以執(zhí)行命令vim /home/qingaolei/hadoop/hadoop-2.8.0/share/doc/hadoop/hadoop-project-dist/hadoop-hdfs/hdfs-default.xml查看

• 當然也可以通過修改配置文件進行修改，通過命令vim /home/qingaolei/hadoop/hadoop-2.8.0/etc/hadoop/hdfs-site.xml進入到配置文件進行修改。

NameNode

1.NameNode的文件結構

//中間省略很多行

分析：從上圖可以看出，NameNode的文件結構包含edits、fsimage、seen_txid、VERSION

2.edits

• 編輯日志（edit log）：當客戶端執(zhí)行寫操作時，首先NameNode會在編輯日志中寫下記錄，并在內(nèi)存中保存一個文件系統(tǒng)元數(shù)據(jù)，這個描述符會在編輯日志改動之后更新。

• edits_start transaction ID-end transaction ID
  finalized edit log segments，在HA（高可用）環(huán)境中，Standby Namenode只能讀取finalized log segments，

• edits_inprogress__start transaction ID
  當前正在被追加的edit log，HDFS默認會為該文件提前申請1MB空間以提升性能

3.fsimage

• 文件系統(tǒng)鏡像（fsimage）:文件系統(tǒng)元數(shù)據(jù)的持久檢查點，包含以序列化格式（從Hadoop-2.4.0起，F(xiàn)SImage開始采用Google Protobuf編碼格式）存儲的文件系統(tǒng)目錄和文件inodes，每個inodes表征一個文件或目錄的元數(shù)據(jù)信息以及文件的副本數(shù)、修改和訪問時間等信息。

• fsimage_end transaction ID
  每次checkpoing（合并所有edits到一個fsimage的過程）產(chǎn)生的最終的fsimage，同時會生成一個.md5的文件用來對文件做完整性校驗（詳細過程見下文）。

4.seen_txid

• seen_txid是存放transactionId的文件，format之后是0，它代表的是namenode里面的edits_*文件的尾數(shù)，namenode重啟的時候，會按照seen_txid的數(shù)字，循序從頭跑edits_0000001~到seen_txid的數(shù)字。

• 當hdfs發(fā)生異常重啟的時候，一定要比對seen_txid內(nèi)的數(shù)字是不是你edits最后的尾數(shù)，不然會發(fā)生建置namenode時metaData的資料有缺少，導致誤刪Datanode上多余Block的資訊。

5.VERSION

VERSION文件是java屬性文件，保存了HDFS的版本號。

· namespaceID是文件系統(tǒng)的唯一標識符，是在文件系統(tǒng)初次格式化時生成的。
· clusterID是系統(tǒng)生成或手動指定的集群ID
· cTime表示NameNode存儲時間的創(chuàng)建時間，升級后會更新該值。
· storageType表示此文件夾中保存的是元數(shù)據(jù)節(jié)點的數(shù)據(jù)結構。
· blockpoolID：針對每一個Namespace所對應blockpool的ID,該ID包括了其對應的NameNode節(jié)點的ip地址。
· layoutVersion是一個負整數(shù)，保存了HDFS的持續(xù)化在硬盤上的數(shù)據(jù)結構的格式版本號。

6.in_use.lock

防止一臺機器同時啟動多個Namenode進程導致目錄數(shù)據(jù)不一致

SecondaryNameNode

1.SecondaryNameNode的文件結構

分析：從上圖可以看出，SecondaryNameNode主要包括edits、fsimage、VERSION

2.edits

從NameNode復制的日志文件

3.fsimage

從NameNode復制的鏡像文件

4.VERSION

注：SecondaryNameNode和NameNode的VERSION系相同，不再贅述。

5.in_use.lock

防止一臺機器同時啟動多個SecondaryNameNode進程導致目錄數(shù)據(jù)不一致

check point 過程

1.圖例：檢查點處理過程

2.過程分析

1）Secondary NameNode首先請求原NameNode進行edits的滾動，這樣新的編輯操作就能夠進入新的文件中。

2）Secondary NameNode通過HTTP方式讀取原NameNode中的fsimage及edits。

3）Secondary NameNode讀取fsimage到內(nèi)存中，然后執(zhí)行edits中的每個操作，并創(chuàng)建一個新的統(tǒng)一的fsimage文件。

4）Secondary NameNode通過HTTP方式將新的fsimage發(fā)送到原NameNode。

5）原NameNode用新的fsimage替換舊的fsimage，舊的edits文件用步驟1）中的edits進行替換（將edits.new改名為edits）。同時系統(tǒng)會更新fsimage文件到記錄檢查點的時間。
這個過程結束后，NameNode就有了最新的fsimage文件和更小的edits文件

注：可執(zhí)行hadoop dfsadmin –saveNamespace命令運行上圖的過程Secondary NameNode（NameNode的冷備份）每隔一小時會插入一個檢查點，如果編輯日志達到64MB，則間隔時間更短，每隔5分鐘檢查一次。

DataNode

1.DataNode的文件結構

分析：從上圖可以看出，.DataNode的文件結構主要由blk_前綴文件、BP-random integer-NameNode-IP address-creation time和VERSION構成。

2.BP-random integer-NameNode-IP address-creation time

• BP代表BlockPool的，就是Namenode的VERSION中的集群唯一blockpoolID，

• 從上圖可以看出我的DataNode是兩個BP，這是因為我的HDFS是Federation HDFS，所以該目錄下有兩個BP開頭的目錄，IP部分和時間戳代表創(chuàng)建該BP的NameNode的IP地址和創(chuàng)建時間戳

3.finalized/rbw

• 這兩個目錄都是用于實際存儲HDFS BLOCK的數(shù)據(jù)，里面包含許多block_xx文件以及相應的.meta文件，.meta文件包含了checksum信息。

• rbw是“replica being written”的意思，該目錄用于存儲用戶當前正在寫入的數(shù)據(jù)。

4.blk_前綴文件

• HDFS中的文件塊本身，存儲的是原始文件內(nèi)容。

• 塊的元數(shù)據(jù)信息（使用.meta后綴標識）。一個文件塊由存儲的原始文件字節(jié)組成，元數(shù)據(jù)文件由一個包含版本和類型信息的頭文件和一系列塊的區(qū)域校驗和組成。

注：當目錄中存儲的塊數(shù)據(jù)量增加到一定規(guī)模時，DataNode會創(chuàng)建一個新的目錄，用于保存新的塊及元數(shù)據(jù)。當目錄中的塊數(shù)據(jù)量達到64（可由dfs.DataNode.numblocks屬性確定）時，便會新建一個子目錄，這樣就會形成一個更寬的文件樹結構，避免了由于存儲大量數(shù)據(jù)塊而導致目錄很深，使檢索性能免受影響。通過這樣的措施，數(shù)據(jù)節(jié)點可以確保每個目錄中的文件塊都可控的，也避免了一個目錄中存在過多文件。

5.VERSION

· storageID相對于DataNode來說是唯一的，用于在NameNode處標識DataNode
· clusterID是系統(tǒng)生成或手動指定的集群ID
· cTime表示NameNode存儲時間的創(chuàng)建時間
· datanodeUuid表示DataNode的ID號
· storageType將這個目錄標志位DataNode數(shù)據(jù)存儲目錄。
· layoutVersion是一個負整數(shù)，保存了HDFS的持續(xù)化在硬盤上的數(shù)據(jù)結構的格式版本號。

6.in_use.lock

防止一臺機器同時啟動多個Datanode進程導致目錄數(shù)據(jù)不一致