1. namenode介紹
namenode管理文件系統的命名空間。它維護着文件系統樹及整棵樹內所有的文件和目錄。這些信息以兩個文件形式永久保存在本地磁盤上：命名空間鏡像文件fsimage和編輯日志文件edits。NameNode也記錄着每個文件中各個塊所在的數據節點信息，但它並不永久保存塊的位置信息，因為這些信息在系統啟動時由數據節點重建。
namenode主要負責三個功能，分別是
管理元數據
維護目錄樹
響應客戶請求
2. namenode關鍵文件夾
位於/opt/software/hadoop277/tmp/dfs/name/current目錄中
（初次啟動之前需要對namenode目錄格式化：hadoop namenode -format）
seen_txid文件保存的是一個數字，就是最后一個edits_的數字
fsimage文件：HDFS文件系統元數據的一個永久性的檢查點，其中包含HDFS文件系統的所有目錄和文件idnode的序列化信息
edits文件：存放HDFS文件系統的所有更新操作的路徑，文件系統客戶端執行的所有寫操作首先會被記錄到edits文件中
version: 該文件為namenode中一些版本號的信息
3. 元數據
3.1元數據格式
/jdk/jdk18.zip, 3, {blk_1,blk_2}, [{blk_1:[dd1,dd2,dd4]}, {blk_2:[dd0,dd1,dd3]}]
/jdk/jdk18.zip：這個文件在hdfs文件系統中的路徑
3：這個文件的副本數（hdfs-site.xml可修改）
{blk_1,blk_2}：這個文件分成的塊（默認滿128M分成一個塊）
dd0,dd1...：datanode節點，比如blk_1的3個副本分別存儲在dd1，dd2，dd4中
3.2元數據的合並
3.2.1原因
1、隨着集群的運行，edit logs文件逐步增大，管理該文件需要消耗資源
2、Namenode合並fsimage文件需要消耗資源
3、Namenode宕機后，再次恢復時會丟失一部分操作
2.2.2解決辦法
使用secondarynamenode對元數據進行合並
2.2.3觸發條件（其中之一即可）
到達檢查點周期，默認1個小時。可通過 dfs.namenode.checkpoint.period屬性手動配置。
一分鍾檢查一次操作次數，到達設置事務數量，默認一百萬條。可通過dfs.namenode.checkpoint.txns屬性配置
2.2.3合並過程
1、secondarynamenode檢查當前集群狀態是否觸發checkpoint的合並條件
2、若未觸發則繼續運行，否則開始元數據合並
3、namenode停止向日志文件edits寫入數據，並生成一個新的edits文件用於存儲在合並期間產生的操作
4、secondarynamenode通過Http GET方式從namenode處下載edits文件和fsimage文件，並將fsimage文件載入內存
5、secondarynamenode逐條執行edits文件的更新操作，使內存中的fsimage文件保存最新的操作日志，結束后生成一個新fsimaget文件
6、secondarynamenode復制發送新fsimaget文件給namenode，然后刪除edits.new
7、兩個新文件替換前兩個舊文件，等待下一次合並