NameNode
學習目標
理解 namenode 的工作機制尤其是元數據管理機制，以增強對 HDFS 工作原理的 理解，及培養 hadoop 集羣運營中“性能調優”、“namenode”故障問題的分析解決能力
問題場景
1、Namenode 服務器的磁盤故障導致 namenode 宕機，如何挽救集羣及數據？
2、Namenode 是否可以有多個？namenode 內存要配置多大？namenode 跟集羣數據存儲能 力有關係嗎？
3、文件的 blocksize 究竟調大好還是調小好？結合 mapreduce
NameNode的職責
1、負責客戶端請求（讀寫數據 請求 ）的響應
2、維護目錄樹結構（ 元數據的管理： 查詢，修改 ）
3、配置和應用副本存放策略
4、管理集羣數據塊負載均衡問題
NameNode元數據的管理
WAL（Write ahead Log）: 預寫日誌系統
在計算機科學中，預寫式日誌（Write-ahead logging，縮寫 WAL）是關係數據庫系統中 用於提供原子性和持久性（ACID 屬性中的兩個）的一系列技術。在使用 WAL 的系統中，所 有的修改在提交之前都要先寫入 log 文件中。
Log 文件中通常包括 redo 和 undo 信息。這樣做的目的可以通過一個例子來說明。假設 一個程序在執行某些操作的過程中機器掉電了。在重新啓動時，程序可能需要知道當時執行 的操作是成功了還是部分成功或者是失敗了。如果使用了 WAL，程序就可以檢查 log 文件， 並對突然掉電時計劃執行的操作內容跟實際上執行的操作內容進行比較。在這個比較的基礎 上，程序就可以決定是撤銷已做的操作還是繼續完成已做的操作，或者是保持原樣。
WAL 允許用 in-place 方式更新數據庫。另一種用來實現原子更新的方法是 shadow paging， 它並不是 in-place 方式。用 in-place 方式做更新的主要優點是減少索引和塊列表的修改。ARIES 是 WAL 系列技術常用的算法。在文件系統中，WAL 通常稱爲 journaling。PostgreSQL 也是用 WAL 來提供 point-in-time 恢復和數據庫複製特性。
NameNode 對數據的管理採用了兩種存儲形式：內存和磁盤
首先是內存中存儲了一份完整的元數據，包括目錄樹結構，以及文件和數據塊和副本存儲地 的映射關係；
1、內存元數據 metadata（全部存在內存中），其次是在磁盤中也存儲了一份完整的元數據。
2、磁盤元數據鏡像文件 fsimage_0000000000000000555
fsimage_0000000000000000555 等價於
edits_0000000000000000001-0000000000000000018
……
edits_0000000000000000444-0000000000000000555
合併之和
3、數據歷史操作日誌文件 edits：edits_0000000000000000001-0000000000000000018 （可通過日誌運算出元數據，全部存在磁盤中）
4、數據預寫操作日誌文件 edits_inprogress_0000000000000000556 （存儲在磁盤中）
metadata = 最新 fsimage_0000000000000000555 + edits_inprogress_0000000000000000556
metadata = 所有的 edits 之和（edits_001_002 + …… + edits_444_555 + edits_inprogress_556）
VERSION（存放 hdfs 集羣的版本信息）文件解析：
#Sun Jan 06 20:12:30 CST 2017 ## 集羣啓動時間
namespaceID=844434736 ## 文件系統唯一標識符
clusterID=CID-5b7b7321-e43f-456e-bf41-18e77c5e5a40 ## 集羣唯一標識符
cTime=0 ## fsimage 創建的時間，初始爲 0，隨 layoutVersion 更新
storageType=NAME_NODE ##節點類型
blockpoolID=BP-265332847-192.168.123.202-1483581570658 ## 數據塊池 ID，可以有多個
layoutVersion=-60 ## hdfs 持久化數據結構的版本號
查看 edits 文件信息：
hdfs oev -i edits_0000000000000000482-0000000000000000483 -o edits.xml
cat edits.xml
查看 fsimage 鏡像文件信息：
hdfs oiv -i fsimage_0000000000000000348 -p XML -o fsimage.xml
cat fsimage.xml
NameNode 元數據存儲機制
A、內存中有一份完整的元數據(內存 metadata)
B、磁盤有一個“準完整”的元數據鏡像（fsimage）文件(在 namenode 的工作目錄中)
C、用於銜接內存 metadata 和持久化元數據鏡像 fsimage 之間的操作日誌（edits 文件）
（PS：當客戶端對 hdfs 中的文件進行新增或者修改操作，操作記錄首先被記入 edits 日誌 文件中，當客戶端操作成功後，相應的元數據會更新到內存 metadata 中）
DataNode
問題場景
1、集羣容量不夠，怎麼擴容？
2、如果有一些 datanode 宕機，該怎麼辦？
3、datanode 明明已啓動，但是集羣中的可用 datanode 列表中就是沒有，怎麼辦？
Datanode 工作職責
1、存儲管理用戶的文件塊數據
2、定期向 namenode 彙報自身所持有的 block 信息（通過心跳信息上報）
（PS：這點很重要，因爲，當集羣中發生某些 block 副本失效時，集羣如何恢復 block 初始 副本數量的問題）
<property>
<!—HDFS 集羣數據冗餘塊的自動刪除時長，單位 ms，默認一個小時 -->
<name>dfs.blockreport.intervalMsec</name>
<value>3600000</value>
<description>Determines block reporting interval in milliseconds.</description>
</property>
Datanode 掉線判斷時限參數
datanode 進程死亡或者網絡故障造成 datanode 無法與 namenode 通信，namenode 不會立即 把該節點判定爲死亡，要經過一段時間，這段時間暫稱作超時時長。HDFS 默認的超時時長 爲 10 分鐘+30 秒。如果定義超時時間爲 timeout，則超時時長的計算公式爲： t
imeout = 2 * heartbeat.recheck.interval + 10 * dfs.heartbeat.interval
而默認的 heartbeat.recheck.interval 大小爲 5 分鐘，dfs.heartbeat.interval 默認爲 3 秒。 需要注意的是 hdfs-site.xml 配置文件中的 heartbeat.recheck.interval 的單位爲毫秒， dfs.heartbeat.interval 的單位爲秒。 所以，舉個例子，如果 heartbeat.recheck.interval 設置爲 5000（毫秒），dfs.heartbeat.interval 設置爲 3（秒，默認），則總的超時時間爲 40 秒。
<property>
<name>heartbeat.recheck.interval</name>
<value>5000</value>
</property>
<property>
<name>dfs.heartbeat.interval</name>
<value>3</value>
</property>
SecondaryNameNode
SecondaryNamenode 工作機制
SecondaryNamenode 的作用就是分擔 namenode 的合併元數據的壓力。所以在配置 SecondaryNamenode 的工作節點時，一定切記，不要和 namenode 處於同一節點。但事實上， 只有在普通的僞分佈式集羣和分佈式集羣中才有會 SecondaryNamenode 這個角色，在 HA 或 者聯邦集羣中都不再出現該角色。在 HA 和聯邦集羣中，都是有 standby namenode 承擔。
元數據的 CheckPoint
每隔一段時間，會由 secondary namenode 將 namenode 上積累的所有 edits 和一個最新的 fsimage 下載到本地，並加載到內存進行 merge（這個過程稱爲 checkpoint） CheckPoint 詳細過程圖解：
CheckPoint 觸發配置
dfs.namenode.checkpoint.check.period=60 ##檢查觸發條件是否滿足的頻率，60 秒
dfs.namenode.checkpoint.dir=file://${hadoop.tmp.dir}/dfs/namesecondary
##以上兩個參數做 checkpoint 操作時，secondary namenode 的本地工作目錄
dfs.namenode.checkpoint.edits.dir=${dfs.namenode.checkpoint.dir}
dfs.namenode.checkpoint.max-retries=3 ##最大重試次數
dfs.namenode.checkpoint.period=3600 ##兩次 checkpoint 之間的時間間隔 3600 秒
dfs.namenode.checkpoint.txns=1000000 ##兩次 checkpoint 之間最大的操作記錄
CheckPoint 附帶作用
Namenode 和 SecondaryNamenode 的工作目錄存儲結構完全相同，所以，當 Namenode 故障 退出需要重新恢復時，可以從SecondaryNamenode的工作目錄中將fsimage拷貝到Namenode 的工作目錄，以恢復 namenode 的元數據
原文鏈接： https://www.cnblogs.com/frankdeng/p/9311434.html