## 媒介
截取常識星球的分享出來，也是對之前的 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個副本時會優先把副本儲備在運彩 nba 玩法差異的機架上，這是為了防範顯露一個機架斷電的場合，假如副本也儲備在同機架上的差異辦事器上，這時候數據就可能丟失了。
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 打交道，而不是和 folloer。不過你要知道，正常的實現數據的上傳下載的性能的確是走的 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 不能用，此時客戶端的讀寫操縱就不會再轉達到該 D運彩 讓分意思ataNode 上
安全模式
3.hadoop 集群剛開端發動時會進入安全模式（99.99），就用到了心跳機制，實在即是在集群剛發動的時候，每一個 DataNode 城市向 NameNode 發送 block 匯報，NameNode 會統計它們上報的總block數，除以一開端知道的總個數total，當 blocktotal 99.99 時，會引發安全模式，安全模式下客戶端就沒法向HDFS寫數據，只能進行讀數據。 並且增補一點，Namenode感知Datanode掉線滅亡時間的算計公式為： timeout = 2 * heartbeat.r台灣彩券 世足echeck.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 -setBalancerBandth nebandth nebandth 的默認單元是字節，所以這個物品個人依據需要調換即可。默認是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的原子廣播協議是徹底可以做到的。
[](suser-gold-cdn.xitu.io2024731731463f9eded92e?=787h=678f=pngs=69453) 此時在Zookeeper中創造一個鎖的目次，然后NameNode發動的時候城市已往搶占鎖，兩個NameNode誰先搶到，誰即是active狀態。並且每一個NameNode上還有一個ZKFC的辦事，連續監聽NameNode的康健狀態，假如active NameNode顯露疑問，ZKFC將會匯報給Zookeeper，然后Zookeeper會將鎖分發給standby的NameNode上。使其主動切換為active狀態。此時即是HDFS2的條理了。 #### JournalNode提名 由於實在JournalNode的工作并不重，所以不需求太過于巨大的集群 200個節點以下 — 3個
200~2024個節點 — 5個
#### 聯邦解決內存受限疑問
如上圖，即是等于一個橫豎開拓的方式，既然一個Namenode會撐爆，那麼多個Namenode，擔當儲備差異的元數據信息即可。
這就譬如我們的C,D,E,F盤，C盤是寄存體制的一些物品，D盤拿來裝軟件，E盤拿來放影戲是一個道理。並且聯邦機制，HDFS 主動路由。用戶不必關懷是具體是哪個 namenode 去進行儲備了
此時作一個小結算，active+standby 的Namenode形成一組，目標是做高可用，防範單點故障。而多組active+standby形成聯邦，目標是解決單組內存不夠的疑問。
#### HDFS如何控制元數據
還記得我們搭建集群的時候，在發動集群之前需求做一步形式化Namenode的操縱嗎？這一步的目標即是在磁盤上生成fsimage，也即是我們的元數據目次信息。此時再把這個元數據加載到內存。
[](suser-gold-cdn.xitu.io2024731731467460c189a8?=772h=598f=pngs=54508)
如下圖，此時如果客戶端要上傳文件，它就會和內存中的fsimage進行交互，提升一條元數據信息，這個操縱就會寫入到一份 edit log 中去，顧名思義即是編制日志。而磁盤中的fsimage此時還是最一開端的那份，不像內存中的fsimage是隨時在變動的。此時
內存fsimage = 磁盤fsimage + edit log
此時假如我休止了辦事，內存中的fsimage被燒毀，此時我只需求將edit log中的紀實回放，刷寫成新的一份fsimage，此時集群再次發動，再加載到內存中，就覆原成為我們休止辦事前的狀態了。
此時引入SecondaryNamenode，它的作用即是提高Namenode的覆原速度，大要對操縱程序進行一個論述：
1. SecondaryNameNode 會通過 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會給每一個元數據信息的改動賦予一個事情號，擔保操縱都是有序的。這也是出于數據的安全斟酌。這樣整個體制要求的內存會極度大，所以這關乎一個hadoop的優化疑問，在之后將會提及。
