HDFS簡介

HDFS 源於 Google 在2003年10月份發表的GFS（Google File System） 論文。 是 GFS 的一個克隆版本
HDFS（Hadoop Distributed File System）是Hadoop專案的核心子專案，是分散式計算中資料儲存管理的基礎，是基於流資料模式訪問和處理超大檔案的需求而開發的，可以運行於廉價的商用伺服器上。它所具有的高容錯、高可靠性、高可擴充套件性、高獲得性、高吞吐率等特徵為海量資料提供了不怕故障的儲存，為超大資料集（Large Data Set）的應用處理帶來了很多便利。

HDFS儲存資料的優缺點

HDFS的優點

1. 高容錯性

• 資料自動儲存多個副本。通過增加副本的形式，提高容錯性。
• 某一個副本丟失以後，可以自動恢復，這是由 HDFS 內部機制實現的，我們不必關心。

2. 適合批處理

• 通過移動計算而不是移動資料。
• 它會把資料位置暴露給計算框架。

3. 適合大資料處理

• 處理資料達到 GB、TB、甚至PB級別的資料。
• 能夠處理百萬規模以上的檔案數量，數量相當之大。
• 能夠處理10K節點的規模。

4. 流式檔案訪問

• 一次寫入，多次讀取。
• 檔案一旦寫入不能修改，只能追加。
• 能保證資料的一致性。

5. 可構建在廉價機器上

• 通過多副本機制，提高可靠性。
• 提供了容錯和恢復機制。比如某一個副本丟失，可以通過其它副本來恢復。

HDFS的缺點

1. 無法低延時資料訪問

• 無法毫秒級的來儲存資料。
• 適合高吞吐率的場景，就是在某一時間內寫入大量的資料。但是它在低延時的情況下是不行的，比如毫秒級以內讀取資料

2. 不適合小檔案儲存

• 儲存大量小檔案(這裡的小檔案是指小於HDFS系統的Block大小的檔案（預設64M）)的話，它會佔用 NameNode大量的記憶體來儲存檔案、目錄和塊資訊。這樣是不可取的，因為NameNode的記憶體總是有限的。
• 小檔案儲存的尋道時間會超過讀取時間，它違反了HDFS的設計目標。

3. 不支援併發寫入、檔案隨機修改

• 一個檔案只能有一個寫，不允許多個執行緒同時寫。
• 僅支援資料 append（追加），不支援檔案的隨機修改

以上內容來自：https://www.cnblogs.com/codeOfLife/p/5375120.html

HDFS架構

叢集架構

HDFS 採用Master/Slave的架構來儲存資料，這種架構主要由四個部分組成，分別為HDFS Client、NameNode、DataNode和Secondary NameNode。這裡重點介紹Secondary NameNode，其他架構部分參考下文高可用叢集架構

Secondary NameNode

並非 NameNode 的熱備。當NameNode 掛掉的時候，它並不能馬上替換 NameNode 並提供服務

SecondaryNameNode的工作情況：

1. SecondaryNameNode會定期和NameNode通訊，請求其停止使用EditLog檔案，暫時將新的寫操作寫到一個新的檔案edit.new上來，這個操作是瞬間完成，上層寫日誌的函式完全感覺不到差別；

2. SecondaryNameNode通過HTTP GET方式從NameNode上獲取到FsImage和EditLog檔案，並下載到本地的相應目錄下；

3. SecondaryNameNode將下載下來的FsImage載入到記憶體，然後一條一條地執行EditLog檔案中的各項更新操作，使得記憶體中的FsImage保持最新；這個過程就是EditLog和FsImage檔案合併；

4. SecondaryNameNode執行完（3）操作之後，會通過post方式將新的FsImage檔案傳送到NameNode節點上

5. NameNode將從SecondaryNameNode接收到的新的FsImage替換舊的FsImage檔案，同時將edit.new替換EditLog檔案，通過這個過程EditLog就變小了
   此處內容來自:https://blog.csdn.net/xjz729827161/article/details/79463140

高可用叢集架構

• HDFS HA（High Availability）是為了解決單點故障問題
• HA叢集設定兩個名稱節點，“活躍（Active）”和“待命（Standby）”
• 兩種名稱節點的狀態同步，可以藉助於一個共享儲存系統來實現
• 一旦活躍名稱節點出現故障，就可以立即切換到待命名稱節點
• Zookeeper確保一個名稱節點在對外服務
• 名稱節點維護對映資訊，資料節點同時向兩個名稱節點彙報資訊

1. 主Master，整個Hadoop叢集只能有一個

• 管理HDFS檔案系統的名稱空間

• 維護元資料資訊

• 管理副本的配置和資訊（預設三個副本）

• 處理客戶端讀寫請求

2. Standby Name Node

• Active Name Node的熱備節點

• Active Name Node故障時可快速切換成新的Active Name Node

• 週期性同步edits編輯日誌，定期合併fsimage與edits到本地磁碟

3. Journal Node

• 可以被Active Name Node和StandBy Name Node同時訪問，用以支援Active Name Node高可用

• Active Name Node在檔案系統被修改時，會向Journal Node寫入操作日誌（edits）

• Standby Name Node同步Journal Node edits日誌，使叢集中的更新操作可以被共享和同步。

4. Data Node

• Slave 工作節點，叢集一般會啟動多個

• 負責儲存資料塊和資料塊校驗

• 執行客戶端的讀寫請求

• 通過心跳機制定期向NameNode彙報執行狀態和本地所有塊的列表資訊

• 在叢集啟動時DataNode項NameNode提供儲存Block塊的列表資訊

5. Block資料塊

• HDSF固定的最小的儲存單元（預設128M，可配置修改）

• 寫入到HDFS的檔案會被切分成Block資料塊（若檔案大小小於資料塊大小，則不會佔用整個資料塊）

• 預設配置下，每個block有三個副本

6. Client

• 與Name Node互動獲取檔案的元資料資訊

• 與Data Node，讀取或者寫入資料

• 通過客戶端可以管理HDFS

更多詳情見：https://blog.csdn.net/u010993514/article/details/83009822

HDFS副本存放策略

namenode如何選擇在哪個datanode 儲存副本（replication）？這裡需要對可靠性、寫入頻寬和讀取頻寬進行權衡。Hadoop對datanode儲存副本有自己的副本策略，在其發展過程中一共有兩個版本的副本策略，分別如下所示

此處內容來自：https://www.cnblogs.com/codeOfLife/p/5375120.html

Hadoop2.x新特性

• 引入了NameNode Federation，解決了橫向記憶體擴充套件
• 引入了Namenode HA，解決了namenode單點故障
• 引入了YARN，負責資源管理和排程
• 增加了ResourceManager HA解決了ResourceManager單點故障

更多詳細資訊：https://www.cnblogs.com/codeOfLife/p/5375120.html