HDFS知識點整理
優缺點
優點
-
高容錯性：多副本，自動恢復
-
處理的數據規模大：可處理PB級別的文件，可支持百萬級數量的文件
缺點
- 不適合低延遲的數據訪問
- 無法高效存儲小文件
- 文件元數據過多，耗盡NameNode內存
- 小文件尋址超過文件讀取時間，違背HDFS設計初衷
- 不支持併發文件寫入
- 僅支持數據追加，不支持文件隨機寫
組成架構
NameNode
文件系統的管理者：
- 管理HDFS命名空間
- 配置副本策略
- 維護數據塊映射
- 處理客戶端讀寫請求（控制流）
DataNode
數據存儲節點：
- 存儲數據塊
- 執行數據塊讀寫（數據流）
Client
客戶端：
- 通過API或shell執行命令
- 按數據塊大小切分文件
Secondary NameNode
- 並非NameNode熱備份，當NameNode宕機，不能馬上替代NameNode對外提供服務
- 分擔NameNode一部分工作，例如Edits和FsImage操作
- 當NameNode宕機時輔助NameNode恢復
HDFS數據塊大小
- Hadoop2中默認的數據塊（
dfs.blocksize）大小爲128M：取決於磁盤傳輸速率 - 原則：尋址時間爲傳輸時間的1%, HDFS中尋址時間平均爲10ms, 因此比較好的傳輸時間爲1s
- 磁盤的傳輸速率普遍爲100MB/s，決定了一個HDFS數據塊的大小在100MB左右
- HDFS數據塊太小，元數據增加，尋址時間增加
- HDFS數據塊太大，MapReduce任務的一個map處理的數據過多，處理時間過長，不符合MapReduce設計原則
HDFS讀寫數據
寫數據流程
流程圖來自《Hadoop權威指南_第四版》，幾個注意點：
- 在一個副本（該數量由
dfs.namenode.replication.min設定）寫入成功後，寫操作就會返回成功 - 客戶端會根據NameNode的返回信息，向網絡拓撲上最近的DataNode寫入，副本的寫入由DataNode按照最短路原則接力寫入，即DataNode1調用DataNode2，DataNode2調用DataNode3
- 如果需要寫入多個block，寫入一個block完成之後，Client會向NameNode請求下一個block的地址
- 一個block分成固定大小的package（默認64k）傳輸
網絡拓撲的節點距離
節點距離：在網絡拓撲樹上，兩個節點到最近的公共祖先的距離和
- 同一節點上的不同進程距離爲0
- 同一機架的不同節點距離爲2
- 同一數據中心的不同機架距離爲4
- 不同數據中心的距離爲6
副本存儲策略
詳見官方文檔（以Hadoop2.7.2版本爲例）
- 當副本數爲3時，在Client所在的本地機架放置一個副本（如果Client不在HDFS集羣的機器上，則隨機選一個集羣節點），在本地機架的另一個節點放置一個副本，在不同機架放置一個副本
- IO效率和可用性之間的平衡
讀數據流程
流程圖來自《Hadoop權威指南_第四版》，注意：對於需要讀取的每一個block，總是讀距離最近的DataNode
NameNode與Secondary NameNode
- NameNode元數據存儲在內存中（爲了提高效率）
- 元數據的磁盤備份：FsImage，保障NameNode元數據斷電後可恢復
- 更新內存元數據的同時，如果更新FsImage，仍然是低效的
- 磁盤上的Edits文件，類似於元數據更新日誌，記錄元數據的修改
- FsImage和Edits合併可以得到此刻內存元數據一致的結果
- 如果Edits過長，從FsImage和Edits恢復元數據的時間過長，因此需要定期合併Edits更新FsImage，該操作由Secondary NameNode完成
- 定時時間（默認1小時）到或Edits中數據滿（默認100萬），則Secondary NameNode向NameNode請求執行Checkpoint，NameNode備份當前Edits（之後的Client請求全部寫入新的Edits），將FsImage和老的Edits文件發給Secondary NameNode，Secondary NameNode在內存中對FsImage和Edits進行合併，生成新的FsImage，發送給NameNode替換老的FsImage
DataNode
數據完整性
- 當DataNode讀取Block時，會計算CheckSum
- 如果計算的CheckSum與Block創建時值不一樣，說明Block已損壞
- Client會讀取其他DataNode上該Block的副本