一、目標

HDFS 全稱 hadoop 分散式檔案系統，其最主要的作用是作為 Hadoop 生態中各系統的儲存服務。

面對大規模的資料，HDFS 在設計上滿足了以下目標：

高度容錯性：HDFS 可能由成百上千的伺服器構成，任何一個元件都可能失效，因此錯誤檢測和快速、自動的恢復時 HDFS 最核心的架構目標。

支援大規模資料集：執行在 HDFS 應用具有很大的資料集，它應該能提供整體上高的資料傳輸頻寬，並能支撐數以千萬計的檔案。

支援流式讀取資料：HDFS 的設計更多的考慮到了資料批處理，而不是使用者互動處理，比之資料訪問延遲的問題，更關鍵的是資料訪問的高吞吐量。

簡單的一致性模型：“一次寫入多次讀取”的檔案訪問模型簡化了資料一致性的問題，並且是高吞吐量稱為可能。

移動計算而非移動資料：一個應用的請求，離它操作的資料越近就越高效，HDFS 提供了將它們自己移動到資料附近的介面。

異構軟硬體平臺間的可移植性：平臺的可移植性，方便使用者也方便 HDFS 作為大規模資料應用平臺的推廣。

那麼通過以上目標，HDFS 被設計成了什麼樣的架構呢？

二、架構與原理

1. HDFS 服務

根據 Cloudera Manager 安裝 hadoop 2.6.0-cdh5.8.3 版本後，得到如下的 HDFS 服務：

如上圖所示，HDFS 使用單一的 NameNode 節點簡化了整體的設計，同時使用 Master-Slave 模式，防止 NameNode 成為單點故障，Failover Controller（故障切換器）的工作便是負責監控 NameNode 的狀態與切換主從伺服器。與此同時，為了能夠快速從故障中恢復，每一次的資料讀寫刪操作都會記錄在 NameNode 上的 EditLog 中並同步到每個 JournalNode 節點。而 DataNode 節點則負責儲存物理資料，為了應對不確定的故障，每一份資料預設被儲存為 3 份，並分散在不同的 DataNode 中，而通過 Balancer 則可以平衡叢集之間各節點的磁碟利用率，以防止某一個 DataNode 節點儲存已滿但是其它 DataNode 節點卻可能為空的情況。

最後為了方便使用者操作，HDFS 提供了 HttpFS 服務，用以通過 HTTP 方式訪問 HDFS 服務的功能。預設的，你可以通過 http://[master namenode host]:50070/ 訪問這個功能。

總的來說，HDFS 主要包含了 6 個服務，它們主要的功能如下：

NameNode：負責管理檔案系統的 namespace 以及客戶端對檔案的訪問；

DataNode：用於管理它所在節點上的儲存；

FailoverController：故障切換控制器，負責監控與切換 Namenode 服務；

JournalNode：用於儲存 EditLog；

Balancer：用於平衡叢集之間各節點的磁碟利用率；

HttpFS：提供 HTTP 方式訪問 HDFS 的功能。

通常而言，在關注 HDFS 架構時，總是關注 Namenode 和 Datanode 的架構，因為它們是 HDFS 的核心，也是客戶端操作資料需要依賴的兩個服務，所以再來看看 Namenode & Datanode 的架構吧。

2. NameNode & DataNode

在 HDFS 中，Namenode 是 HDFS 中的主節點，用於維護和管理 Datanode 上存在的 block。它是一個高度可用的伺服器，用於管理檔案的 namespace 並控制客戶端對檔案的訪問。HDFS 體系的構建方式是，使用者資料永遠不會駐留在 Namenode 上，資料只會駐留在 Datanode 上。

Namenode 的功能：

它是維護和管理 Datanode 的主守護程序；

它記錄儲存在叢集中的所有檔案的元資料，例如 block 的位置、檔案大小、許可權、層次結構等。有兩個檔案與元資料關聯：

FsImage：它包含自 Namenode 開始以來檔案的 namespace 的完整狀態；

EditLogs：它包含最近對檔案系統進行的與最新 FsImage 相關的所有修改。

它記錄了發生在檔案系統元資料上的每個更改。例如，如果一個檔案在 HDFS 中被刪除，Namenode 會立即在 EditLog 中記錄這個操作。

它定期從叢集中的所有 Datanode 接收心跳資訊和 block 報告，以確保 Datanode 處於活動狀態；

它保留了 HDFS 中所有 block 的記錄以及這些 block 所在的節點；

它負責管理所有 block 的複製；

在 Datanode 失敗的情況下，Namenode 會為副本選擇新的 Datanode，平衡磁碟使用並管理到 Datanode 的通訊流量。

Datanode 則是 HDFS 中的從節點，與 Namenode 不同的是，Datanode 是一種商品硬體，它並不具有高質量或高可用性。Datanode 是一個將資料儲存在本地檔案 ext3 或 ext4 中的 block 伺服器。

Datanode 功能：

這些是叢屬守護進行或在每臺從屬機器上執行的程序；

實際的資料儲存在 Datanode 上；

執行檔案系統客戶端底層的讀寫請求；

定期向 Namenode 傳送心跳報告 HDFS 的整體健康狀況，預設頻率為 3 秒。

上面提到 HDFS 中的資料是以 block 的形式分散在 DataNode 中，那什麼是 block ，它是如何形成的呢？

3. 資料塊（Block）

通常，在任何檔案系統中，都將資料儲存為 block 的集合。block 是硬碟上儲存資料的最不連續的位置。在 hadoop 叢集中，每個 block 的預設大小為 128M（此處指 hadoop 2.x 版本，hadoop 1.x 版本為 64M），您也可以通過如下配置配置 block 的大小：

dfs.block.size或 dfs.blocksize =64M

HDFS 不會將每個檔案儲存在配置的 block 大小的確切倍數中，比如一個 514M 的檔案 example.txt，如果上圖所示，假設 block 大小為預設的 128M，那麼將會建立 5 個block，前 4 個 block 大小為 128M，但是最後一個 block 的大小則僅為 2M。

那麼，為何需要將 block 的大小設定為如此大，比如 128M，而不是更小呢？

通常我們在談論 HDFS 的作用的時，都會談論到巨大的資料集，即 Terabytes 和 PB 資料，所以如果我們的 block 大小僅為 4KB，那麼將會產生太多的 block，間接導致產生太多的元資料，從而使管理這些 block 和 元資料會產生巨大的開銷，這樣無疑會增加 Namenode 和 Datanode 的負載，尤其 Namenode 是一箇中心伺服器，所以這並不會是我們想要的。

4. 資料複製

HDFS 提供了一種將大資料作為資料塊儲存在分散式環境中的可靠方法，即將這些 block 複製以容錯。預設的複製因子是 3，您也可以通過如下配置配置複製因子：

fs.replication = 3

因此，如下圖所示，每個 block 被複制 3 次儲存在不同的 Datanode 中。

所以，如果使用預設配置在 HDFS 中儲存 128M 的檔案，則最終將佔用 384M （3 * 128M）的空間，因為這些 block 將被複制 3 次，並且每個副本將駐留在不同的 Datanode 中。

注意：Namenode 會定期的 從 Datanode 中收集 block 報告以維護複製因子。因此，無論何時 block 被過度複製或複製不足，Namenode 都會根據需要刪除或新增副本。

5. 元資料

我們知道，Namenode 對我們來說相當的重要，如果它失敗了，我們註定要失敗。不過 HDFS 有對它做高可用的解決方案，高可用的方案中，如何同步狀態是一個關鍵，所以這裡再介紹一下那些儲存在 Namenode 上的元資料。

注：以下元資料同步的方式使用的是通過JournalNode 節點同步的方式。

NameNode 將整個 namespace ，包括 block 到檔案的對映、檔案的屬性等，都儲存在一個稱為 FsImage 的檔案中，它被存放在記憶體以及本地檔案系統中。而任何對於 namespace 元資料產生修改的操作，NameNode 都會使用一種稱為 EditLog 的事務日誌記錄下來。例如在 HDFS 中建立一個檔案，NameNode 就會在 EditLog 中插入一條記錄來表示；同樣的，修改檔案的副本系數也將往 EditLog 插入一條記錄。主 NameNode 會在本地檔案系統中儲存這個 EditLog，並同步到各個 JournalNode 節點上，而從 NameNode 則通過在 JournalNode 節點中讀取 EditLog 來完成同步。

當 NameNode 啟動時，它會從硬碟中讀取 EditLog 和 FsImage，將所有 EditLog 中的事務作用在記憶體中的 FsImage 上，並將這個新版本的 FsImage 從記憶體中儲存到本地磁碟上，然後刪除舊的 EditLog，這個過程也被稱為一個 checkpoint。

那麼通過 NameNode 上的元資料可以確定 block 到具體 DataNode 節點的一個對映，所以客戶端在讀取或者寫入資料到 HDFS 時，都是先到 NameNode 上獲取元資料，然後根據元資料中的地址直接與 DataNode 互動，與此同時，客戶端會快取一段時間的元資料，從而減少與 NameNode 的互動。

那麼一個完整的讀取和寫入流程是怎樣的呢？

6. 資料寫入原理

假如 HDFS 客戶端想要寫入一個名為 “example.txt” 的大小為 128MB 的檔案。

假定系統 block 的配置大小為 128MB（預設），那麼客戶端將把檔案 “example.txt” 分成 2 個 block - 128 MB（block A） + 128MB（block B）。

接下來，每當客戶端將資料寫入 HDFS 時，將遵循以下協議：

首先，HDFS 客戶端將與 NameNode 聯絡以獲得針對兩個 block（例如 block A 和 block B）的寫入請求；

然後，NameNode 將授予客戶端寫入許可權，並將提供最終將複製檔案的 DataNode 的 IP 地址。

根據 HDFS 的可用性，複製因素和機架感知，DataNode IP 地址的選擇純碎是隨機的。

假設複製因子被設定成預設值 3，那麼對於每個 block，NameNode 將向客戶端提供 3 個 DataNode 的 IP 地址列表。該列表對於每個 block 都是唯一的。假設分配結果如下：

對於 block A，列表 A = { DN 1 IP， DN 4 IP, DN 6 IP }

對於 block B，列表 B =｛DN 3 IP， DN 7 IP, DN 9 IP｝

每個 block 將被複制到 3 個不同的 DataNode 中，以保持整個叢集中複製因子的一致。

接下來，整個資料的複製將分為 3 個階段進行： 1) 管道設定 2) 資料流和複製 3) 管道關閉與確認階段

1) 管道設定

在寫入 block 之前，客戶端確認每個 IP 列表中的 DataNode 是否準備好接受資料，這樣做時，客戶端會通過連線該 block 列表中的各個 DataNode，為每個 block 建立一個管道。比如 block A，它提供的 DataNode 列表是： 列表 A = { DN 1 IP， DN 4 IP, DN 6 IP }

因此，對於 block A，客戶端將建立以下步驟來建立管道：

客戶端將選擇列表中的第一個 DataNode （DN1）並建立 TCP/IP 連線；

客戶端將通知 DN 1 準備好接收該 block，它還會將下兩個 DataNode（DN 4, 6）的 IP 地址提供給 DN 1；

DN 1 將連線 DN 4，並通知 DN 4 準備好接受該 block，同時將 DN 6 的 IP 地址告知給 DN 4。然後 DN 4 將告訴 DN 6 準備好接受資料；

接下來，準備就緒的確認將遵循相反的順序，即從 DN 6 -> DB 4 -> DN 1；

最後 DN 1 將通知客戶端所有的 DataNode 都以準備就緒，並且將在 DataNode 1，4 和 6 之間形成管道；

現在，管道設定完成，客戶端將最終的資料以流式方式處理。

2) 資料流

由於管道已經建立，客戶端會將資料推送到管道中。不過不要忘記，在 HDFS 中，資料是基於複製因子進行復制的，所以，在假設複製因子為 3 時，block A 將儲存到 3 個 DataNode 中。移動到最前的，客戶端僅僅是將 block A 複製到 DN1。複製總是按照順序進行的。

因此，在複製過程中將執行以下的步驟：

一旦該 block 被客戶端寫入 DN 1，DN 1 將連線到 DN 4；

然後，DN 1 將推送管道中的 block，資料將被複制到 DN 4；

同樣的 DN 4 將連線到 DN 6 並將 block 複製為最後一個副本。

3) 管道關閉與確認階段

一旦 block 被複制到所有的 3 個 DataNode 中，就會發生一系列的確認操作，以確保客戶端和 NameNode 確信資料已經寫入成功。然後客戶端將最終關閉管道以結束 TCP 會話。

如下圖所示，確認以相反的順序發生，即從 DN 6 到 DN 4，再到 DN 1。最後，DN 1 將把 3 個確認（包括它自己的）推送到流水線中併發送給客戶端，客戶端將通知 NameNode 資料已經成功寫入。此時，NameNode 將更新元資料，客戶端將關閉管道。

類似的，block B 也將被複制到與 block B 並行的 DataNode 中，因此，這裡需要注意一下幾點：

客戶端將同時將 block A 和 block B 複製到第一個 DataNode 上；

因此，在這個示例下，將為兩個 block 形成兩條管道，上述所有過程將在這兩天管道中並行發生；

客戶端將該 block 寫入第一個 DataNode，然後 DataNode 將順序複製該 block

如上圖所示，客戶端為兩個 block 一共建立了兩個管道，以下是各個管道中每個 block 正在進行的操作流程：

block A 的管道：1A -> 2A -> 3A -> 4A

block B 的管道：1B -> 2B -> 3B -> 4B -> 5B -> 6B

7. 資料寫入實現

寫入資料的詳細流程： 1) 客戶端通過在 DistributedFileSystem 上呼叫 create() 方法來建立檔案（步驟1）；

2) DistributedFileSystem 對 NameNode 進行 RPC 呼叫，以在檔案系統的 namespace 中建立一個新的檔案，此時沒有與之關聯的 block（步驟2）（NameNode 會執行各種檢查以確保檔案不存在，並且確保客戶端具有建立檔案的正確許可權。只有通過了這些檢查，才會建立新檔案成功，否則客戶端丟擲 IOException）

3) DistributedFileSystem 返回一個 FSDataOutputStream 物件以開始寫入資料。與讀取資料一樣，FSDataOutputStream 封裝了一個 DFSOutputStream 物件，它處理與DataNode 和 NameNode 的通訊。當客戶端開始寫入資料（步驟3）時，DFSOutputStream 將其拆分成資料包（packet），寫入內部的資料佇列，資料佇列由 DataStreamer 使用，它通過選擇合適的 DataNode 列表來儲存副本，從而要求 NameNode 分配新的 block。DataNode列表會形成一個管道（假設副本數為3），其中包含3個節點。

4) DataStreamer 將資料包以流式傳輸的方式傳輸到流水線中的第一個 DataNode，該資料流將資料包儲存到第一個 DataNode 中並將其轉發到流水線中的第二個 DataNode。類似地，第二個 DataNode 節點會將資料包轉發到流水線中的第三個 DataNode 節點（步驟4）；

5) DFSOutputStream 還維護了一個正在等待的資料包的內部的 ack 佇列，由 DataNode 確認。只有在流水線中的書友 DataNode 節點都確認了資料包（步驟5）後才會將資料包從 ack 佇列中刪除；

6) 如果資料在寫入過程中發生故障，那麼：(1) 首先關閉管道，並將 ack 佇列中的所有資料包新增到資料佇列的前端，以便故障節點下游的 DataNode 不會錯過任何資料包。(2) 正常狀態的 DataNode 上的 block 會被賦予一個新的標識，以便如果失敗的 DataNode 稍後恢復後，刪除發生故障的 DataNode 上的部分 block。(3) 然後將失敗的 DataNode 從流水線中移除，並將該 block 的其餘資料寫入流水線中的兩個良好的 DataNode。(4) 當 NameNode 注意到該 block 被複制不足時，會安排它在另外一個節點上建立另一個副本。

如果多個 DataNode 在寫入 block 發生故障，那麼只要寫入 dfs.replication.min 最小副本數，寫入操作也會成功，該 block 將非同步複製，知道其目標複製因子達到 dfs.replication 指定的數量。

7) 當客戶端完成寫入資料後，它會在流上呼叫 close() 方法（步驟6）。

8) close() 操作會將所有剩餘的資料包重新整理到 DataNode 管道，並聯系 NameNode 以表示檔案以傳輸完成（步驟7），並等待確認。

9) NameNode 已經知道該檔案由哪些 block 組成（因為通過 DataStreamer 分配的 block），所以它只需要等待 block 最小程度（dfs.replication.min）的被複制，便可以返回成功，也是此時，NameNode 才會將檔案建立操作提交到 EditLog 中。

8. 資料讀取原理

HDFS 讀取原理比較簡單，參考上面的例子，假如 HDFS 客戶端現在想要讀取“example.txt“。

現在，讀取資料將發生以下步驟：

客戶端將與 NameNode 聯絡，詢問檔案”example.txt“的 block 元資料；

NameNode 返回儲存的每個塊（block A 和 block B）的 DataNode 列表；

然後，客戶端將連線到列表中最近的 DataNode；

客戶端開始從 DataNode 並行讀取資料（DN 1 的 block A 和 DN 3 的 block B）

一旦客戶端獲得了所有必須的 block，它就會將這些 block 組合起來形成一個檔案。

在提供給客戶端讀取請求時，HDFS 選擇最接近客戶端的副本，這減少了讀取延遲和頻寬消耗。因此，如果可能，會選擇與閱讀節點位於同一個機架上的副本。

9. 資料讀取實現

讀取資料的詳細流程：

1) 客戶端通過呼叫 FileSystem 物件的 open() 方法來開啟它希望讀取的檔案，其實就是建立了一個 DistributedFileSystem 物件（步驟1）；

2) DistributedFileSystem 使用 RPC 呼叫 NameNode 來確定檔案中前幾個 block 的位置，同時對於每個 block，NameNode 返回具有該 block 副本的 DataNode 的地址，此外，DataNode 根據它們與客戶端的接近程度進行排序（根據叢集網路的拓撲結構），如果客戶端本身就是一個 DataNode，那麼它將從本地直接讀取（步驟2）。

3) DistributedFileSystem 返回一個 FSDataInputStream（支援檔案搜尋的輸入流）給客戶端，供其從中讀取資料；

4) FSDataInputStream 依次包裝一個 DFSInputStream，它們用於管理 DataNode 和 NameNode 的 I/O 讀寫；

5) 客戶端呼叫 stream 上的 read() 方法（步驟3）；

6) DFSInputStream 中儲存了檔案中前幾個 block 所在 DataNode 的地址，根據這些資訊連線到檔案中離 block 的最近的DataNode。資料從 DataNode 返回至客戶端，客戶端在資料流上重複呼叫 read() 方法（不同 block 並行讀取）（步驟4，5）；

7) 當 block 全部傳輸完成後，DFSInputStream 將關閉與 DataNode 的連線；

8) 當客戶端完成資料讀取後，呼叫 FSDataInputStream 上 close() 方法以關閉流（步驟6）；

心跳檢測、block 狀態報告與資料重新複製

檔案以 block 形式寫入 DataNode 後，其副本數必須滿足系統配置的數量（dfs.replication），即使是在之後 DataNode 發生了故障，比如磁碟錯誤或者宕機，HDFS 都應該有能力來處理這樣的情況。所以這裡就涉及到了幾個問題：

1) HDFS 如果確定 Datanode 的狀態

2) 如何確定哪些 block 出現了丟失

3) Datanode 發生故障後，如何保障資料的安全

在 HDFS 中，Datanode 以及 block 的元資訊都通過 Namenode 來管理。Namenode 會週期性地從叢集中的每個 Datanode 接收心跳訊號和 block 狀態報告（Blockreport）。接收到心跳訊號意味著該 Datanode 節點工作正常，而 block 狀態報告則包含了一個該 Datanode 上所有 block 的列表。

那麼根據心跳訊號以及 block 狀態報告，Namenode 可以知道每一個 Datanode 是否正常工作，以及哪些 block 被損壞了。如果一個 Datanode 宕機了，那麼任何儲存在它之上的所有 block 將不再有效。Namenode 不斷地檢測這些 block 是否滿足副本系數，一旦發現某個 block 的副本系數低於指定值，就會啟動複製操作。可能需要重新複製的操作有：某個 Datanode 節點失效、某個副本遭到破壞、Datanode 上的磁碟錯誤、或者檔案的副本系數變大。

10. 儲存空間回收

檔案的刪除和恢復

當用戶或應用程式刪除某個檔案時，這個檔案並沒有立刻從 HDFS 中刪除。實際上 HDFS 會將這個檔案重新命名並轉移到 /trash 目錄，所以只要該檔案在 /trash 目錄中，就可以被迅速恢復。檔案在 /trash 中儲存的時間通過 fs.trash.interval 配置，當超過這個時間時，Namenode 就會將檔案從 namespace 中刪除。刪除檔案會使得該檔案的 block 被釋放。

Namenode 在做類似的常規掃描時，Namenode 找點孤兒 block（不被任何檔案包含的 block）並刪除它們的元資料。然後 Datanode 在和 Namenode 互動心跳資訊中，報告它所擁有的 block 子集的資訊，Namenode 回覆 Datanode 哪些 block 在元資料中已經不存在了，Datanode 便可以任意刪除這些 block 副本了。

減少副本系數

同樣的，當一個檔案的副本系數被減小後，Namenode 會選擇過剩的副本刪除。其原理與上面的類似。

想學習大資料或者想學習大資料的朋友，我整理了一套大資料的學習視訊免費分享給大家，從入門到實戰都有，大家可以加微信：Lxiao_28獲取，還可以入微信群交流！（備註領取資料，真實有效哦）。