轉：【HDFS基礎】HDFS檔案目錄詳解
版權宣告：本文為博主原創文章，若轉載，請註明出處，謝謝！ https://blog.csdn.net/baiye_xing/article/details/76268495
HDFS的檔案目錄圖
分析：從上圖可以看出，HDFS的檔案目錄主要由NameNode、SecondaryNameNode和DataNode組成，而NameNode和DataNode之間由心跳機制通訊。
注：
HDFS(Hadoop Distributed File System)預設的儲存單位是128M的資料塊。
可以執行命令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）：當客戶端執行寫操作時，首先NameNode會在編輯日誌中寫下記錄，並在記憶體中儲存一個檔案系統元資料，這個描述符會在編輯日誌改動之後更新。
edits_start transaction ID-end transaction ID
finalized edit log segments，在HA（高可用）環境中，Standby Namenode只能讀取finalized log segments，
edits_inprogress__start transaction ID
當前正在被追加的edit log，HDFS預設會為該檔案提前申請1MB空間以提升效能
3.fsimage
檔案系統映象（fsimage）:檔案系統元資料的持久檢查點，包含以序列化格式（從Hadoop-2.4.0起，FSImage開始採用Google Protobuf編碼格式）儲存的檔案系統目錄和檔案inodes，每個inodes表徵一個檔案或目錄的元資料資訊以及檔案的副本數、修改和訪問時間等資訊。
fsimage_end transaction ID
每次checkpoing（合併所有edits到一個fsimage的過程）產生的最終的fsimage，同時會生成一個.md5的檔案用來對檔案做完整性校驗（詳細過程見下文）。
4.seen_txid
seen_txid是存放transactionId的檔案，format之後是0，它代表的是namenode裡面的edits_*檔案的尾數，namenode重啟的時候，會按照seen_txid的數字，循序從頭跑edits_0000001~到seen_txid的數字。
當hdfs發生異常重啟的時候，一定要比對seen_txid內的數字是不是你edits最後的尾數，不然會發生建置namenode時metaData的資料有缺少，導致誤刪Datanode上多餘Block的資訊。
5.VERSION
VERSION檔案是java屬性檔案，儲存了HDFS的版本號。
• namespaceID是檔案系統的唯一識別符號，是在檔案系統初次格式化時生成的。
• clusterID是系統生成或手動指定的叢集ID
• cTime表示NameNode儲存時間的建立時間，升級後會更新該值。
• storageType表示此資料夾中儲存的是元資料節點的資料結構。
• blockpoolID：針對每一個Namespace所對應blockpool的ID,該ID包括了其對應的NameNode節點的ip地址。
• layoutVersion是一個負整數，儲存了HDFS的持續化在硬碟上的資料結構的格式版本號。
6.in_use.lock
防止一臺機器同時啟動多個Namenode程序導致目錄資料不一致
SecondaryNameNode
1.SecondaryNameNode的檔案結構
分析：從上圖可以看出，SecondaryNameNode主要包括edits、fsimage、VERSION
2.edits
從NameNode複製的日誌檔案
3.fsimage
從NameNode複製的映象檔案
4.VERSION
注：SecondaryNameNode和NameNode的VERSION系相同，不再贅述。
5.in_use.lock
防止一臺機器同時啟動多個SecondaryNameNode程序導致目錄資料不一致
check point 過程
1.圖例：檢查點處理過程
2.過程分析
1）Secondary NameNode首先請求原NameNode進行edits的滾動，這樣新的編輯操作就能夠進入新的檔案中。
2）Secondary NameNode通過HTTP方式讀取原NameNode中的fsimage及edits。
3）Secondary NameNode讀取fsimage到記憶體中，然後執行edits中的每個操作，並建立一個新的統一的fsimage檔案。
4）Secondary NameNode通過HTTP方式將新的fsimage傳送到原NameNode。
5）原NameNode用新的fsimage替換舊的fsimage，舊的edits檔案用步驟1）中的edits進行替換（將edits.new改名為edits）。同時系統會更新fsimage檔案到記錄檢查點的時間。
這個過程結束後，NameNode就有了最新的fsimage檔案和更小的edits檔案
注：可執行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部分和時間戳代表建立該BP的NameNode的IP地址和建立時間戳
3.finalized/rbw
這兩個目錄都是用於實際儲存HDFS BLOCK的資料，裡面包含許多block_xx檔案以及相應的.meta檔案，.meta檔案包含了checksum資訊。
rbw是“replica being written”的意思，該目錄用於儲存使用者當前正在寫入的資料。
4.blk_字首檔案
HDFS中的檔案塊本身，儲存的是原始檔案內容。
塊的元資料資訊（使用.meta字尾標識）。一個檔案塊由儲存的原始檔案位元組組成，元資料檔案由一個包含版本和型別資訊的標頭檔案和一系列塊的區域校驗和組成。
注：當目錄中儲存的塊資料量增加到一定規模時，DataNode會建立一個新的目錄，用於儲存新的塊及元資料。當目錄中的塊資料量達到64（可由dfs.DataNode.numblocks屬性確定）時，便會新建一個子目錄，這樣就會形成一個更寬的檔案樹結構，避免了由於儲存大量資料塊而導致目錄很深，使檢索效能免受影響。通過這樣的措施，資料節點可以確保每個目錄中的檔案塊都可控的，也避免了一個目錄中存在過多檔案。
5.VERSION
• storageID相對於DataNode來說是唯一的，用於在NameNode處標識DataNode
• clusterID是系統生成或手動指定的叢集ID
• cTime表示NameNode儲存時間的建立時間
• datanodeUuid表示DataNode的ID號
• storageType將這個目錄標誌位DataNode資料儲存目錄。
• layoutVersion是一個負整數，儲存了HDFS的持續化在硬碟上的資料結構的格式版本號。
6.in_use.lock
防止一臺機器同時啟動多個Datanode程序導致目錄資料不一致
本人才疏學淺，若有錯，請指出，謝謝！
如果你有更好的建議，可以留言我們一起討論，共同進步！
衷心的感謝您能耐心的讀完本篇博文！
參考連結： Secondary NameNode:它究竟有什麼作用？
---------------------
作者：白夜行515
來源：CSDN
原文：https://blog.csdn.net/baiye_xing/article/details/76268495
版權宣告：本文為博主原創文章，轉載請附上博文連結！