## 前言 截取知識星球的分享出來，也是對之前的 HDFS 進行一個補充，順帶讓大家復習一下 前面兩篇 HDFS 在這里： [帶你入坑大數據（一） --- HDFS基礎概念篇] [帶你入坑大數據（二） --- HDFS的讀寫流程和一些重要策略] ## Coutent ### 分散存儲，冗余存儲 這兩點我可以展開說明一下，首先我們要清楚，HDFS里面的數據，分為**真實數據**和**元數據**兩種，當然這里面元數據是在 Namenode 里面的，而真實數據是存儲在 Datanode 里面的。 比如我們現在要存儲一個大文件，分散存儲的意思就是，會將這個文件拆分成一個個的數據塊block，分別獨立存放在某個 Datanode 中。那此時問題就來了，你怎么知道哪個文件是由哪些數據塊組成呢？而且這些數據塊又分別存在哪些 Datanode 上呢？

這就是元數據所起到的作用。 元數據存儲其實是在內存和磁盤都存儲了一份的，存儲在內存的考量主要就是提高響應速度，而存磁盤是為了保證元數據的安全。而這樣導致的問題就是：如何保證內存和磁盤的數據一致性問題？這塊可以去學習一下 Redis 的做法，既保證效率又保證安全。 而且為什么說HDFS不適合存儲小文件，甚至說我們會有很多小文件的合并機制，那是因為元數據并不是一個文件一條元數據，而是每一個數據塊都會對應有一個相關的元數據描述，而每個數據塊的元數據大小將近150字節，這好比說我們往HDFS存一個100M的視頻，對應一條150byte的元數據，如果存100張1M的圖片，就會有對應100條150byte的元數據，所以這個資源的浪費是十分可怕的。

 而冗余存儲就是我們的block會有副本機制，這個副本的存儲套路是機架存儲策略 ### 機架存儲策略 實際機房中，會有機架，每個機架上會有若干臺服務器。一般來說我們會把一個block的3個副本分別按照下述方法進行存儲： 

1. 第一個副本就存儲在一個機架A上 第二個副本存儲在和這個block塊不同機架（比如機架B）的一個服務器上

 2. 存儲第2個副本時會優先把副本存儲在不同的機架上，這是為了防止出現一個機架斷電的情況，如果副本也存儲在同機架上的不同服務器上，這時候數據就可能丟失了。 

3. 第三個副本存儲在機架B的另外一個服務器上（注意副本2,3都存儲在了機架B） 為什么會這么選擇，因為如果我們把副本3也放在另外一個機架C上，副本2和副本3之間的通信就需要副本2通過它的交換機去聯系總交換機，然后總交換機去聯系機架C的交換機，需要走的路線非常長，而且機房中的帶寬資源非常寶貴，如果處于高并發的情況，很容易就把機房的帶寬打滿，此時整一個集群的響應速度會急劇下降，這時候服務就會出現問題了。 當然我們的副本數也是可以手動通過命令增加的，在客戶端訪問量多的時候，可以適當分配一下壓力 $ hadoop fs -setrep -R 

4 path + FileName setrep的意思其實就是set replication，設置副本數的縮寫，上面命令就是將副本數設置成4份了，后面跟著文件路徑和文件名即可 客戶端的交互全部都是和 Namenode 打交道的，這點和 Kafka 一樣，永遠都是和 leader 打交道，而不是和 follower。但是你要知道，正常的實現數據的上傳下載的功能確實是走的 Datanode。 

 HDFS 的架構 HDFS的架構：主從架構，三大角色 

1. Namenode作為集群的老大，掌管HDFS文件系統的元數據，處理客戶端讀寫請求，HDFS的集群內部數據安全及負載均衡等 2. Datanode存儲整個集群的所有數據塊，處理真正的數據讀寫 

3. SecondaryNamenode嚴格意義上來說并不屬于namenode的備份節點，它主要起到的作用其實是替namenode分擔壓力，降低負載（元數據的編輯日志合并，也就是edits log）之用 

 心跳機制  心跳機制解決了HDFS集群間的通信問題，還是NameNode命令DataNode執行操作的途徑 1. master namenode啟動之后，會開一個ipc server 2. DataNode啟動，連接NameNode，每隔3s向NameNode發送一個心跳，并攜帶狀態信息 3. NameNode通過對這個心跳的返回值來給DataNode傳達任務指令 #### 心跳機制的作用： 1.NameNode 全權管理數據塊的復制，它周期性從集群中的每個 DataNode 接收心跳信號和 block 狀態報告，接收到心跳信號意味著該 DataNode 節點工作正常，塊狀態報告包含了該 DataNode 上所有數據塊的列表 2.DataNode啟動時向 NameNode 注冊，通過后周期性地向 NameNode 上報 block 報告，每3秒向 NameNode 發送一次心跳，NameNode 返回對該 DataNode 的指令，如將數據塊復制到另一臺機器，或刪除某個數據塊等···而當某一個 DataNode 超過10min還沒向 NameNode 發送心跳，此時 NameNode 就會判定該 DataNode 不可用，此時客戶端的讀寫操作就不會再傳達到該 DataNode 上

 安全模式 3.hadoop 集群剛開始啟動時會進入安全模式（99.99%），就用到了心跳機制，其實就是在集群剛啟動的時候，每一個 DataNode 都會向 NameNode 發送 block 報告，NameNode 會統計它們上報的總block數，除以一開始知道的總個數total，當 block/total < 99.99% 時，會觸發安全模式，安全模式下客戶端就沒法向HDFS寫數據，只能進行讀數據。 而且補充一點，Namenode感知Datanode掉線死亡時間的計算公式為： timeout = 2 * heartbeat.recheck.interval + 10 * dfs.heartbeat.interval HDFS默認超時時間為630秒，因為默認的 heartbeat.recheck.interval 為5分鐘，而 dfs.heartbeat.interval 默認為3秒，而這兩個參數理解起來也很簡單，一個是重新檢查的時間間隔，而另一個是每n秒發送一次心跳的參數，等待10次，不行拉倒。 

安全模式的補充 安全模式不僅僅是集群剛啟動時等所有的Datanode匯報這一種情況會進入安全模式的，還有就是HDFS數據塊丟失達到一個比例的時候，也會自動進入，當然我們也可以手動去進入安全模式。這個比例默認是0.1%，1000個塊丟1個已經很嚴重的事件了。 可以通過 start-balancer.sh 來讓HDFS做負載均衡，可是要注意，這個命令是存在一定的問題的，這和Java的垃圾回收機制中的 System.gc() 是一樣的。

我告訴你，現在要去進行垃圾回收了，可是 JVM 壓根就不理咱們，為啥呢？它只會在自己有空，合適的時間去做垃圾回收，而 start-balancer.sh 就也是一樣的套路，利用剩余的帶寬去做這個事情。 而這個操作也有一定的標準，根據一個數值n規定。每一個節點都計算出一個磁盤的占用量，占用量最大-占用量最小 = 這個標準數值n即可。默認是10%，這樣就很好理解了吧。而且這個負載均衡的操作是一定不能影響到客戶端的讀寫業務的，所以HDFS默認會不允許balance操作占用太多的帶寬。但是我們可以進行手動調整 hdfs dfs admin -setBalancerBandwidth newbandwidth newbandwidth 的默認單位是字節，所以這個東西自己根據需求調整即可。默認是1M每秒的。 

 HDFS的缺陷及演進 Hadoop1 版本剛出來的時候是為了解決兩個問題：一個是海量數據如何存儲的問題，一個是海量數據如何計算的問題 Namenode的工作： 

1. 管理集群元數據信息（文件目錄樹）: 可以簡單理解為，一個文件被分為了幾個block塊，而這些block塊又分別存儲在了哪些位置。

 2. Namenode為了快速響應用戶的操作請求，所以將元數據加載到了內存里面 Datanode的工作： 

1. 存儲數據，把上傳的數據劃分為固定大小的文件塊，hadoop1默認64，之后是128M 2. 為了保證數據安全，每個文件塊默認都有三個副本，這里的三個副本其實是總共3個的意思，而不是一份原始3個備份總數為4 #### HDFS1的架構缺陷 1. 單點故障問題：Namenode掛掉集群就廢了 

2. 內存受限問題：就是Namenode的元數據信息撐爆了內存的情況下，整個集群就癱瘓了 #### QJM方案解決單點故障問題 其實本身還存在一個多個Namenode共用一個共享目錄的解決方式，但是這樣也會存在共享目錄出現問題的情況，所以就無法滿足我們的要求 QJM方案如下：我們單獨建立一個JournalNode集群，然后由它們來解決單點故障的問題，JournalNode之間數據是一致的，我們的主Namenode，也就是active Namenode對元數據進行修改的時候，會對JournalNode進行寫入操作，然后再由Standby Namenode去進行同步以達到主從Namenode的數據一致。

  但是現在還是存在一個問題，就是我們需要手動將standby切換成active，所以此時我們就引入了Zookeeper來解決這個問題，其實存在一些企業會有直接不使用JournalNode而直接使用Zookeeper來代替的方案，因為JournalNode的任務就是保證這些節點的數據一致而已，這個特點通過Zookeeper的原子廣播協議是完全可以做到的。 

[](https://user-gold-cdn.xitu.io/2020/7/3/1731463f9eded92e?w=787&h=678&f=png&s=69453) 此時在Zookeeper中創建一個鎖的目錄，然后NameNode啟動的時候都會過去搶占鎖，兩個NameNode誰先搶到，誰就是active狀態。而且每一個NameNode上還有一個ZKFC的服務，持續監聽NameNode的健康狀態，如果active NameNode出現問題，ZKFC將會報告給Zookeeper，然后Zookeeper會將鎖分配給standby的NameNode上。使其自動切換為active狀態。此時就是HDFS2的架構了。 #### JournalNode推薦 因為其實JournalNode的任務并不重，所以不需要太過于龐大的集群 200個節點以下 ---> 3個 200~2000個節點 ---> 5個 #### 聯邦解決內存受限問題  如上圖，就是等于一個橫向擴展的方式，既然一個Namenode會撐爆，那么多個Namenode，負責存儲不同的元數據信息即可。

這就好比我們的C,D,E,F盤，C盤是存放系統的一些東西，D盤拿來裝軟件，E盤拿來放電影是一個道理。而且聯邦機制，HDFS 自動路由。用戶不用關心是具體是哪個 namenode 去進行存儲了 此時作一個小總結，active+standby 的Namenode形成一組，目的是做高可用，防止單點故障。而多組active+standby形成聯邦，目的是解決單組內存不夠的問題。 #### HDFS如何管理元數據 還記得我們搭建集群的時候，在啟動集群之前需要做一步“格式化Namenode”的操作嗎？這一步的目的就是在磁盤上生成fsimage，也就是我們的元數據目錄信息。此時再把這個元數據加載到內存。 

[](https://user-gold-cdn.xitu.io/2020/7/3/1731467460c189a8?w=772&h=598&f=png&s=54508) 如下圖，此時假如客戶端要上傳文件，它就會和內存中的fsimage進行交互，增加一條元數據信息，這個操作就會寫入到一份 edit log 中去，顧名思義就是編輯日志。而磁盤中的fsimage此時還是最一開始的那份，不像內存中的fsimage是隨時在變化的。此時 內存fsimage = 磁盤fsimage + edit log 此時如果我停止了服務，內存中的fsimage被銷毀，此時我只需要將edit log中的記錄回放，刷寫成新的一份fsimage，此時集群再次啟動，再加載到內存中，就恢復成為我們停止服務前的狀態了。  此時引入SecondaryNamenode，它的作用就是提高Namenode的恢復速度，大致對操作步驟進行一個闡述： 

1. SecondaryNameNode 會通過http get方式把edits log和fsimage的信息拉取過來 

2. 在SecondaryNameNode中把edits log和fsimage做一個合并，產生一個新的文件叫做 fsimage.ckpt 

3. 在SecondaryNameNode中合并完成之后，再回傳給NameNode里面 

4. 這時大概率會有客戶端還在對NameNode進行讀寫操作，也會產生新的日志，此時按照先前未引入SNN的套路繼續即可。 在HA方案中這個行為可以交給standby去完成。

雙緩沖機制 Namenode里面的元數據是以兩種狀態進行存儲的： 第一狀態即是存儲在內存里面，也就是剛剛所提到的目錄樹，它就是一個list，在內存里面更新元數據速度是很快的。但是如果僅僅只在內存里存放元數據，數據是不太安全的。 

所以我們在磁盤上也會存儲一份元數據，可是此時問題就出現了，我們需要把數據寫進磁盤，這個性能肯定是不太好的呀。可NameNode作為整個集群的老大，在hadoop上進行hive，HBASE，spark，flink等計算，這些數據都會不停給NameNode施壓寫元數據，一天下來一億條元數據都是可能的，所以NameNode的設計肯定是要支持超高并發的，可是寫磁盤這操作是非常非常慢的，一秒幾十或者最多幾百都已經封頂了，那現在咋辦？  首先我們的客戶端（這里指的是hive，hbase，spark···都沒關系）所產生的數據將會走兩個流程，第一個流程會向內存處寫入數據，這個過程非常快，也不難理解  這時候肯定就不能直接寫內存了，畢竟我們是明知道這東西非常慢的，真的要等它一條條數據寫到磁盤，那特么我們都可以雙手離開鼠標鍵盤下班走人了。

那NameNode一個東西不行就整個集群都不行了，那現在我們該如何解決？  雙緩沖機制就是指我們將會開辟兩份一模一樣的內存空間，一個為bufCurrent，產生的數據會直接寫入到這個bufCurrent，而另一個叫bufReady，在bufCurrent數據寫入（其實這里可能不止一條數據，等下會說明）后，兩片內存就會exchange（交換）。

然后之前的bufCurrent就負責往磁盤上寫入數據，之前的bufReady就繼續接收客戶端寫入的數據。其實就是將向磁盤寫數據的任務交給了后臺去做。這個做法，在JUC里面也有用到 而且在此基礎上，hadoop會給每一個元數據信息的修改賦予一個事務ID號，保證操作都是有序的。這也是出于數據的安全考慮。這樣整個系統要求的內存會非常大，所以這關乎一個hadoop的優化問題，在之后將會提及。