:-:  hdfs組成架構 架構主要由四個部分組成，分別為 HDFS Client、NameNode、DataNode 和Secondary NameNode。 <br/> 結合前面安裝環境啟動的進程，HDSF 啟動的時候有 NameNode、DataNode 和 Secondary NameNode進程。 <br/> **1. Client**：就是客戶端，自己編寫的代碼+Hadoop API。其主要功能： （1）進行文件切分。文件上傳 HDFS 的時候，Client 將文件切分成一個一個的 Block，然后進行存儲。 （2）當我們要查詢一個文件時，與 NameNode 交互，獲取文件的位置信息。 （3）與 DataNode 交互，讀取或者寫入數據。 （4）Client 提供一些命令來管理 HDFS，比如啟動或者關閉 HDFS。 （5）Client 可以通過一些命令來訪問 HDFS。 <br/> **2. NameNode**：就是 Master，它是一個主管、管理者。也叫 HDFS 的元數據節點。集群中只能有一個活動的 NameNode 對外提供服務。 （1）管理 HDFS 的名稱空間（文件目錄樹）；HDFS 很方便的一點就是對于用戶來說很友好，用戶不考慮細節的話，看到的目錄結構和我們使用 Window 和Linux 文件系統很像。 （2）管理數據塊（Block）映射信息及副本信息；一個文件對應的塊的名字以及塊被存儲在哪里，以及每一個文件備份多少都是由 NameNode 來管理。 （3）處理客戶端讀寫請求。 <br/> **3. DataNode**：就是 Slave。實際存儲數據塊的節點，根據 NameNode 下達的命令，DataNode 執行實際的操作。 （1）存儲實際的數據塊。 （2）根據NameNode的命令執行數據塊的讀/寫操作。 <br/> **4. Secondary NameNode**：并非 NameNode 的熱備。當 NameNode 掛掉的時候，它并不能馬上替換 NameNode 并提供服務。它的功能如下： （1）輔助 NameNode，分擔其工作量。 （2）定期合并 Fsimage 和 Edits，并推送給 NameNode。 （3）在緊急情況下，可輔助恢復 NameNode。 Secondary NameNode 的工作與 HDFS 設計是相關的，主要針對元數據設計的。它維護了兩種文件 **Fsimage** 和 **Edits**。 <br/> Fsimage 鏡像文件，是元數據在某個時間段的快照，Edits 記錄了生成快照之后的一系列操作。<br/> HDFS 在最初格式化啟動時，創建 Edits 和 Fsimage 文件，并在內存中維護一版元數據信息，這時候，Fsimage 和內存中的元數據信息是相同的。后續每一次客戶端操作時，會先記錄客戶端執行的操作到 Edits 文件中，然后再更新內存中對應的目錄樹結構，比如用戶刪除一個文件，會先在 Edits 文件中記錄一個 delete 操作，然后在內存中真正刪除文件。<br/> 也就是說，內存中的元數據信息是完整的。前面生成的快照 Fsimage 只是元數據的一部分，執行完 Edits 文件中相關操作才能與內存中元數據相同。<br/> 為什么要這么設計呢？ 首先，為什么不直接更新Fsimage，而是要新添加Edits文件。這里就需要明確Fsimage里面存的是元數據目錄樹信息，其實是一個內存對象序列化后的內容。要更新這個文件，首先得反序列化對象加載到內存中，在實際工作，這個文件很大，序列化和反序列化過程會很繁重，速度會很慢。而 Edits 文件只需要 append操作記錄即可。這樣既保證了元數據不會丟失，也提高了性能。<br/> SecondaryNameNode 具體干什么事情？ 當 HDFS 運行一段時間后，需要重啟動時，<ins>需要將Fsimage加載到內存中，并把Eidts文件中的操作執行一遍，才是完整的元數據信息</ins>。假如操作記錄比較頻繁或者長時間沒有重啟過，Edits 文件會很大。重啟的時候合并Fsimage+Edits文件的操作也是很耗時的，增加了啟動時間。SecondaryNameNode就是解決這種問題的，它是一個獨立的進程，<ins>定期（滿足一定條件）會將 Fsimage+Edits 合并成一個新的 Fsimage，減少 HDFS 重啟時間</ins>。