從分佈式角度解讀HDFS運行機制和原理

引言：分佈式的一般設計

要想深入學習HDFS就要先了解其設計思想和架構，這樣才能繼續深入使用HDFS或者深入研究源代碼，先從一般的分佈式談起，在宏觀上逐步去探究HDFSDE設計思想和架構實現。

• 分佈式：

  分佈式是近幾年非常火的技術概念，無論是雲計算、大數據還是高併發的互聯網架構話題都會頻頻出現這個詞語，特別是這個大談“大規模”的時代，分佈式貌似成了高大上技術的代名詞。引的許多剛入行的技術人員趨之若鶩，其實世界上不會有憑空出現的事物，都是慢慢演化的，新事物一定可以找到舊事物的影子。

  那麼我們就先看看“一般的”分佈式系統需要解決那些問題、這些問題的通用解決方案和特性。

  分佈式的定義：

  分佈式系統會劃分成多個子系統或模塊，各自運行在不同的機器上，子系統或模塊之間通過網絡通信進行協作，實現最終的整體功能。比如分佈式操作系統、分佈式程序設計語言及其編譯(解釋)系統、分佈式文件系統和分佈式數據庫系統等。利用多個節點共同協作完成一項或多項具體業務功能的系統就是分佈式系統

• 問題及解決方案

  1:CAP的權衡

  分佈式領域有一個非常著名的CAP理論，是由 Eric Brewer 提出的分佈式系統中最爲重要的理論之一。其定義很好理解，CAP 三個字母分別代表了分佈式系統中三個相互矛盾的屬性。CAP分別代表Consistency、Availiablity、Tolerance to the partition of network即一致性、可用性、網絡分區容忍性。

一致性（Consistency）：在CAP理論中的一致性是強一致性，即每個節點上的數據時刻保持一致。

可用性（Availiablity）：是指分佈式系統在出現異常情況的時候的可用度。

分區容忍性（Tolerance…）：是指分佈式系統對網絡分區的容錯度。

CAP 理論指出：無法設計一種分佈式協議，使得同時完全具備 CAP 三個屬性，即該種協議下的副本始終是強一致性&服務始終是可用的&協議可以容忍任何網絡分區異常；分佈式系統協議只能在 CAP 這三者間所有折中。

CAP折中的實現可以體現在分佈式協議中：

a. Lease 機制犧牲了部分異常情況下的 A，從而獲得了完全的 C 與很好的 P。

b. Quorum 機制，即總共有 N 個副本，成功更新 W 個副本則算成功提交，讀取時讀 R 個副本。這種一般的 Quorum 機制，在 CAP 三大因素中都各做了折中，有一定的 C，有較好的 A，也有較好的 P，是一種較爲平衡的分佈式協議。

c. 兩階段提交系統具有完全的 C，很不好 A，很不好 P。

d. Paxos 協議具有完全的 C，較好的 A，較好的 P。

2：負載均衡

在某些有多個節點的分佈式系統中需要對服務請求進行負載均衡，根據業務需求的不同也可以使用不同的負載均衡算法，例如一致性Hash

3：高併發

有些分佈式系統對併發性有很高的要求，通常是使用MVCC:Multiversion concurrency control，多版本併發控制技術。本質是使用COW+Version+CAS這個技術組合來提升系統併發性

1：HDFS的基本知識

最近重新整理關於HDFS的知識點，深入瞭解它的應用場景和通用的分佈式架構，更重要的是理解步驟的原理和實現細節。

1.1 ：HDFS的來源

HDFS 源於 Google 在2003年10月份發表的GFS（Google File System） 論文。 它其實就是 GFS 的一個克隆版本

1.2：HDFS的特點

選擇HDFS存儲數據，是因爲HDFS擁有衆多優點：

（1）：高容錯性

• 數據自動保存多個副本。它通過增加副本的形式，提高容錯性
• 某一個副本丟失以後，它可以自動恢復

（2）：適合批處理

• 通過移動計算而不是移動數據

• 把數據位置暴露給計算框架

（3）: 適合大數據處理

• 處理數據達到 GB、TB、甚至PB級別的數據
• 能夠處理百萬規模以上的文件數量
• 能夠處理10K節點的規模

（4）: 流式文件訪問

• 一次寫入，多次讀取。文件一旦寫入不能修改，只能追加
• 它能保證數據的一致性

（5）搭建在廉價的機器上

• 通過副本機制，提高可靠性
• 提供容錯和恢復機制，當數據丟失時，可通過副本恢復

當然，HDFS也有缺點，導致它並不適合一些特定的場景：

（1）：低延時數據訪問

• 它適合高吞吐率的場景，就是在某一時間內寫入大量的數據。但是它在低延時的情況下是不行的，比如毫秒級以內讀取數據，這樣它是很難做到的

（2）：小文件存儲

• 存儲大量小文件(這裏的小文件是指小於HDFS系統的Block大小的文件（hadoop2.x默認128M）)的話，它會佔用 NameNode大量的內存來存儲文件、目錄和塊信息。這樣是不可取的，因爲NameNode的內存總是有限的。
• 小文件存儲的尋道時間會超過讀取時間，它違反了HDFS的設計目標

（3）併發寫入、文件隨機修改

• 一個文件只能有一個寫，不允許多個線程同時寫
• 僅支持數據 append（追加），不支持文件的隨機修改

1.3：HDFS的一般特性

• HDFS是一個文件系統，用戶存儲和管理文件，通過統一的命名空間（類似於本地文件系統的目錄樹），其特點是分佈式的，服務器中的每個節點都有自己的角色和職責。
• HDFS的文件在物理邏輯上是分塊存儲的——block，塊的大小可以通過配置參數dfs.blocksize指定，默認大小在hadoop2.x版本中是128M，之前的版本中是64M。
• HDFS文件系統會給客戶端提高一個統一的抽象目錄樹，客戶端通過路徑來訪問文件：hdfs://namenode:port/dir-a/dir-b/dir-c/file.data
• 目錄結構及文件分塊位置信息（元數據）的管理由namenode節點承擔，namenode是HDFS集羣主節點，負責維護整個HDFS的目錄樹，以及每一個路徑（文件）所對應的數據塊信息（blockid及所在的datanode服務器）。
• DataNode會定期向NameNode回報自身所保存的文件block信息，而Namenode會負責保持文件的副本數量，HDFS內部工作機制對客戶端保持透明，客戶端請求訪問HDFS都是通過向NameNode申請來進行的。
• HDFS適應一次寫入，多次讀取的場景，不支持文件的修改。因爲需要頻繁的RPC交互，所以寫入性能不好。

1.4 : HDFS的高級特性

• 安全模式 safe mode

  注意：HDFS正常運行的時候，安全模式一定是off（關閉狀態）， 是HDFS的一種自我保護，作用：檢查數據塊的副本率，HDFS處於安全模式，是隻讀的狀態

• 快照：是一種備份，默認：HDFS快照是關閉

  命令：管理命令

  [-allowSnapshot ]

  [-disallowSnapshot ]

  命令：操作命令

  -createSnapshot 目錄 快照名稱

  舉例：啓用目錄的快照功能
  hdfs dfsadmin -allowSnapshot /input

  創建快照：
  hdfs dfs -createSnapshot /input backup_input_20180905_01
  快照本質：Created snapshot /input/.snapshot/backup_input_20180905_01

  hdfs dfs -put student0*.txt /input
  重新創建快照
  hdfs dfs -createSnapshot /input backup_input_20180905_0

• 配額：Quota

• （1）名稱配額: 限定HDFS目錄下，存放文件（目錄）的個數
  [-setQuota …]

  [-clrQuota …]

  舉例：

  hdfs dfs -mkdir /myquota1
  規定這個最多存放3個文件（實際：N-1）
  hdfs dfsadmin -setQuota 3 /myquota1

  （2）空間配額：限定HDFS目錄下，文件的大小 —> 值必須大於數據塊大小（128M）

  [-setSpaceQuota [-storageType ] …]

  [-clrSpaceQuota [-storageType ] …]

  舉例：

  hdfs dfs -mkdir /myquota2

  規定該目錄下的文件空間配額是2M

  hdfs dfsadmin -setSpaceQuota 2M /myquota2

• 回收站：默認HDFS的回收站禁用

  -rm：刪除
  參數： -rmr 表示刪除目錄和子目錄
  hdfs dfs -rmr /output
  日誌：Deleted /output
  注意：如果啓用回收站，觀察日誌

  （*）補充一個知識：Oracle數據庫也有回收站
  通過閃回進行恢復（flashback）
  Oracle有7中類型的閃回

2：HDFS架構及原理

2.1：HDFS架構

HDFS 是一個能夠面向大規模數據使用的，可進行擴展的文件存儲與傳遞系統。是一種允許文件通過網絡在多臺主機上分享的文件系統，可讓多機器上的多用戶分享文件和 存儲空間。讓實際上是通過網絡來訪問文件的動作，由程序與用戶看來，就像是訪問本地的磁盤一般。即使系統中有某些節點脫機，整體來說系統仍然可以持續運作 而不會有數據損失。

HDFS存儲數據架構圖：

HDFS採用的是master/slave的主從架構來存儲數據，這種架構主要分成4個部分，分別是HDFS client，NameNode，DataNode和SecondaryNode。

1. Client：就是客戶端

   客戶端的主要工作：

   • 文件切分。文件上傳到HDFS的時候，Client將文件切分成一個個小的block，然後進行存儲。
   • 與NameNode進行交互，獲取文件位置
   • 與DataNode進行交互，讀取或寫入數據
   • 提供一些命令來管理HDFS，比如一鍵關閉或啓動HDFS，還有訪問HDFS等。

2. NameNode：也就是master，是一個管理者

   • 管理HDFS的名稱空間
   • 管理數據塊block的映射空間
   • 配置副本策略
   • 處理客戶端的讀寫請求

3. DataNode：也就是slave，負責存儲數據

   • 存儲實際的數據塊
   • 執行數據塊的讀/寫操作

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

   • 輔助 NameNode，分擔其工作量

   • 定期合併 fsimage和fsedits，並推送給NameNode

   • 在緊急情況下，可輔助恢復 NameNode

     ---

2.2：HDFS寫數據過程

• 概述：

客戶端要向HDFS中寫數據，首先要跟NameNode通信以確認可以寫文件並獲得接收文件block的DataNode，然後客戶端按順序將文件逐個block傳遞給相應的DataNode，並由接收到block的DataNode負責向其他 DataNode複製block的副本。

• 寫入數據的詳細步驟：

1. 客戶端想NameNode發送上傳文件請求，NameNode要對上傳目錄和文件進行檢查，判斷是否可以上傳，並向客戶端返回檢車結果；

2. 客戶端得到上傳文件允許之後讀取客戶端配置，如果沒有指定配置則會讀取默認配置，如副本數默認爲3，block大小默認爲128M，副本是由客戶端決定。向NameNode請求上傳一個數據塊；

3. NameNode會根據客戶端的配置來查詢DataNode信息 ,如果使用默認配置，那麼最終結果會返回同一個機架上的兩個datanode和另一個機架上的DataNode，這種機制稱爲“機架感知”；

4. 客戶端在開始傳輸數據塊之前會把數據緩存在本地，當緩存大小超過了一個數據塊的大小，客戶端就會從namenode獲取要上傳的datanode列表。之後會在客戶端和第一個datanode建立連接開始流式的傳輸數據，這個datanode會一小部分一小部分（4K）的接收數據然後寫入本地倉庫，同時會把這些數據傳輸到第二個datanode，第二個datanode也同樣一小部分一小部分的接收數據並寫入本地倉庫，同時傳輸給第三個datanode，依次類推。這樣逐級調用和返回之後，待這個數據塊傳輸完成客戶端後告訴namenode數據塊傳輸完成，這時候namenode纔會更新元數據信息記錄操作日誌；

5. 第一個數據塊傳輸完成後會使用同樣的方式傳輸下面的數據塊直到整個文件上傳完成。

細節：

• 請求和應答是使用RPC的方式，客戶端通過ClientProtocol與NameNode通信，NameNode與DataNode之間使用DataNodeProtocol交互，在設計上，NameNode不會主動發起RPC，而是響應來自客戶端的DataNode的RPC請求，客戶端與DataNode之間是使用socket進行數據傳輸，與NameNode之間的交互採用的nio封裝的RPC。
• HDFS有自己的序列化協議
• 在數據塊傳輸成功後但客戶端沒有告訴namenode之前如果namenode宕機那麼這個數據塊就會丟失
• 在流式複製時，逐級傳輸和響應採用響應隊列來等待傳輸結果。隊列響應完成後返回給客戶端
• 在流式複製時如果有一臺或兩臺（不是全部）沒有複製成功，不影響最後結果，只不過datanode會定期向namenode彙報自身信息。如果發現異常namenode會指揮datanode刪除殘餘數據和完善副本。如果副本數量少於某個最小值就會進入安全模式。

關於RPC和安全模式：

1. RPC通信：

2. 安全模式：

   安全模式：Namenode啓動後會進入一個稱爲安全模式的特殊狀態。處於安全模式的Namenode是不會進行數據塊的複製的。Namenode從所有的 Datanode接收心跳信號和塊狀態報告。塊狀態報告包括了某個Datanode所有的數據塊列表。每個數據塊都有一個指定的最小副本數。當Namenode檢測確認某個數據塊的副本數目達到這個最小值，那麼該數據塊就會被認爲是副本安全(safely replicated)的；在一定百分比（這個參數可配置）的數據塊被Namenode檢測確認是安全之後（加上一個額外的30秒等待時間），Namenode將退出安全模式狀態。接下來它會確定還有哪些數據塊的副本沒有達到指定數目，並將這些數據塊複製到其他Datanode上。

   ---

2.3：HDFS讀數據過程

• 概述：

  客戶端將要讀取的文件路徑發送給namenode，namenode獲取文件的元信息（主要是block的存放位置信息）返回給客戶端，客戶端根據返回的信息找到相應datanode逐個獲取文件的block並在客戶端本地進行數據追加合併從而獲得整個文件。

• 讀取數據的詳細步驟：

1. 客戶端向NameNode發起RPC請求，請求讀取文件數據

2. NameNode檢查文件是否存在，如果存在文件的元信息（blockid以及對應的DataNode列表）

3. 客戶端收到元信息後選取一個網絡距離最近的datanode，依次請求讀取每個數據塊。客戶端首先要校檢文件是否損壞，如果損壞，客戶端會選取另外的datanode請求

4. datanode與客戶端建立socket連接，傳輸對應的數據塊，客戶端收到數據緩存到本地，之後寫入文件

5. 依次傳輸剩下的數據塊，直到整個文件合併完成

細節：

從某個Datanode獲取的數據塊有可能是損壞的，損壞可能是由Datanode的存儲設備錯誤、網絡錯誤或者軟件bug造成的。HDFS客戶端軟件實現了對HDFS文件內容的校驗和(checksum)檢查。當客戶端創建一個新的HDFS文件，會計算這個文件每個數據塊的校驗和，並將校驗和作爲一個單獨的隱藏文件保存在同一個HDFS名字空間下。當客戶端獲取文件內容後，它會檢驗從Datanode獲取的數據跟相應的校驗和文件中的校驗和是否匹配，如果不匹配，客戶端可以選擇從其他Datanode獲取該數據塊的副本。

2.4：HDFS刪除數據分析

HDFS刪除數據比較流程相對簡單，只列出詳細步驟

1. 客戶端向NameNode發起RPC調用，請求刪除文件。NameNode檢查合法性
2. NameNode查詢文件相關元信息，向存儲文件數據塊的DataNode發出刪除請求
3. DataNode刪除相關數據塊。返回結果
4. NameNode返回結果給客戶端

細節：

當用戶或應用程序刪除某個文件時，這個文件並沒有立刻從HDFS中刪除。實際上，HDFS會將這個文件重命名轉移到/trash目錄。只要文件還在/trash目錄中，該文件就可以被迅速地恢復。文件在/trash中保存的時間是可配置的，當超過這個時間時，Namenode就會將該文件從名字空間中刪除。刪除文件會使得該文件相關的數據塊被釋放。注意，從用戶刪除文件到HDFS空閒空間的增加之間會有一定時間的延遲。只要被刪除的文件還在/trash目錄中，用戶就可以恢復這個文件。如果用戶想恢復被刪除的文件，他/她可以瀏覽/trash目錄找回該文件。/trash目錄僅僅保存被刪除文件的最後副本。/trash目錄與其他的目錄沒有什麼區別，除了一點：在該目錄上HDFS會應用一個特殊策略來自動刪除文件。目前的默認策略是刪除/trash中保留時間超過6小時的文件。將來，這個策略可以通過一個被良好定義的接口配置。

當一個文件的副本系數被減小後，Namenode會選擇過剩的副本刪除。下次心跳檢測時會將該信息傳遞給Datanode。Datanode遂即移除相應的數據塊，集羣中的空閒空間加大。同樣，在調用setReplication API結束和集羣中空閒空間增加間會有一定的延遲。

2.5：NameNode元數據管理原理分析

• 概述：

  NameNode職責：響應客戶端請求、管理元數據。

  NameNode對元數據有三種存儲方式：

  1. 內存元數據(NameSystem)
  2. 磁盤元數據鏡像文件
  3. 數據操作日誌文件（可通過日誌運算出元數據）

  細節：

  HDFS不適合存儲小文件的原因，每個文件都會產生元信息，當小文件多了之後元信息也就多了，對NameNode會造成壓力。

• 對以上三種存儲機制的進一步解釋

  1. 內存元數據就是當前namenode正在使用的元數據，是存儲在內存中的

  2. 磁盤元數據鏡像文件是內存元數據的鏡像，保存在namenode工作目錄中，它是一個準元數據，作用是在namenode宕機時能夠快速較準確的恢復元數據。稱爲fsimage

  3. 數據操作日誌文件是用來記錄元數據操作的，在每次改動元數據時都會追加日誌記錄，如果有完整的日誌就可以還原完整的元數據。主要作用是用來完善fsimage，減少fsimage和內存元數據的差距。稱爲editslog

• checkpoint機制分析

  因爲namenode本身的任務就非常重要，爲了不再給namenode壓力，日誌合併到fsimage就引入了另一個角色secondarynamenode。secondarynamenode負責定期把editslog合併到fsimage，“定期”是namenode向secondarynamenode發送RPC請求的，是按時間或者日誌記錄條數爲“間隔”的，這樣即不會浪費合併操作又不會造成fsimage和內存元數據有很大的差距。因爲元數據的改變頻率是不固定的。

  每隔一段時間，會由secondary namenode將namenode上積累的所有edits和一個最新的fsimage下載到本地，並加載到內存進行merge（這個過程稱爲checkpoint）。

細節：

• namenode向secondarynamenode發送RPC請求，請求合併editslog到fsimage

• secondarynamenode收到請求後從namenode上讀取（通過http服務）editslog（多個，滾動日誌文件）和fsimage文件

• secondarynamenode會根據拿到的editslog合併到fsimage。形成最新的fsimage文件。（中間有很多步驟，把文件加載到內存，還原成元數據結構，合併，再生成文件，新生成的文件名爲fsimage.checkpoint）。

• secondarynamenode通過http服務把fsimage.checkpoint文件上傳到namenode，並且通過RPC調用把文件改名爲fsimage。

namenode和secondary namenode的工作目錄存儲結構完全相同，所以，當namenode故障退出需要重新恢復時，可以從secondary namenode的工作目錄中將fsimage拷貝到namenode的工作目錄，以恢復namenode的元數據

參考資料：
1：初步掌握HDFS的架構及原理：https://www.cnblogs.com/codeOfLife/p/5375120.html
2：深刻理解HDFS工作機制：https://www.cnblogs.com/wxisme/p/6270860.html