柚子快報(bào)邀請碼778899分享：hadoop HDFS學(xué)習(xí)筆記

http://yzkb.51969.com/

HDFS1.0

1 什么是HDFS？

HDFS的全稱是：Hadoop DistributeFiles System，分布式文件系統(tǒng)。

在整個(gè)Hadoop技術(shù)體系中，HDFS提供了數(shù)據(jù)分布式存儲(chǔ)的底層技術(shù)支持。

HDFS 由三個(gè)組件構(gòu)成：NameNode（NN）、DataNode（DN）、SecondaryNameNode（SNN）

2 系統(tǒng)架構(gòu)

HDFS 是一個(gè)主/從（Master/Slave）體系架構(gòu)，由于分布式存儲(chǔ)的性質(zhì)，集群擁有兩類節(jié)點(diǎn) NameNode 和 DataNode。

(1) Client：客戶端，是應(yīng)用程序可通過該模塊與 NameNode 和DataNode 進(jìn)行交互，進(jìn)行文件的讀寫操作；

(2) NameNode：主節(jié)點(diǎn)、名字節(jié)點(diǎn)、Master（進(jìn)程），一個(gè)hadoop集群只有一個(gè)，管理存儲(chǔ)和檢索多個(gè) DataNode 的實(shí)際數(shù)據(jù)所需的所有元數(shù)據(jù)；

(3) DataNode：從節(jié)點(diǎn)、數(shù)據(jù)節(jié)點(diǎn)、Worker（進(jìn)程）,一個(gè)hadoop集群可以有多個(gè)，是文件系統(tǒng)中真正存儲(chǔ)數(shù)據(jù)的地方，在NameNode 統(tǒng)一調(diào)度下進(jìn)行數(shù)據(jù)塊的創(chuàng)建、刪除和復(fù)制；

(4) SecondaryNameNode不是第二主節(jié)點(diǎn)，是助手節(jié)點(diǎn)，也可以理解為鏡像文件，或者是數(shù)據(jù)備份；

(5) NameNode與DataNode的聯(lián)系

Heartbeat：NameNode與DataNode之間存在心跳連接，DataNode每隔一段一時(shí)間就主動(dòng)向NameNode匯報(bào)消息Balance：當(dāng)一個(gè)datanode掛了，為了達(dá)到平衡block，內(nèi)部數(shù)據(jù)會(huì)被平均分配到其他datanode上

(6) 為什么1.0里只有一個(gè)NameNode？

因?yàn)閔adoop1.0是在zookeeper誕生之前，沒有滿足高可用的工具。

3 關(guān)于NameNode

(1) 管理著文件系統(tǒng)命名空間：維護(hù)著文件系統(tǒng)樹及樹中的所有文件和目錄

(2) 存儲(chǔ)元數(shù)據(jù)：NameNode保存元信息的種類有：

文件名目錄名及它們之間的層級關(guān)系文件目錄的所有者及其權(quán)限每個(gè)文件塊的名及文件有哪些塊組成

(3) 元數(shù)據(jù)保存在內(nèi)存中

NameNode元信息并不包含每個(gè)塊的位置信息（每個(gè)塊的信息存儲(chǔ)在block中，block存儲(chǔ)在datanode中）

(4) 保存文件，block，datanode之間的映射關(guān)系，有2種映射關(guān)系數(shù)據(jù)

文件名->blockid list列表block數(shù)據(jù)塊->datanode節(jié)點(diǎn)地址（數(shù)據(jù)是通過DN->NN發(fā)送心跳組織起來的）

(5) 元信息持久化

在NameNode中存放元信息的文件是 fsimage。在系統(tǒng)運(yùn)行期間所有對元信息的操作都保存在內(nèi)存中并被持久化到另一個(gè)文件edits中。并且edits文件和fsimage文件會(huì)被SecondaryNameNode周期性的合并。

(6) 運(yùn)行NameNode會(huì)占用大量內(nèi)存和I/O資源，一般NameNode不會(huì)存儲(chǔ)用戶數(shù)據(jù)或執(zhí)行MapReduce任務(wù)。

4 Hadoop更傾向存儲(chǔ)大文件原因：

一般來說，一條元信息記錄會(huì)占用200byte內(nèi)存空間。假設(shè)塊大小為64MB，備份數(shù)量是3，那么一個(gè)1GB大小的文件將占用16*3=48個(gè)文件塊。如果現(xiàn)在有1000個(gè)1MB大小的文件，則會(huì)占用1000*3=3000個(gè)文件塊（多個(gè)文件不能放到一個(gè)塊中）。我們可以發(fā)現(xiàn)，如果文件越小，存儲(chǔ)同等大小文件所需要的元信息就越多，所以Hadoop更喜歡大文件。

5 關(guān)于DataNode

(1) 負(fù)責(zé)存儲(chǔ)數(shù)據(jù)塊，負(fù)責(zé)為系統(tǒng)客戶端提供數(shù)據(jù)塊的讀寫服務(wù)；

(2) 根據(jù)NameNode的指示進(jìn)行創(chuàng)建、刪除和復(fù)制等操作；

(3) 心跳機(jī)制，定期向NameNode報(bào)告文件塊列表信息；

(4) DataNode之間進(jìn)行通信，塊的副本處理。

6 關(guān)于block

(1) 數(shù)據(jù)塊，磁盤讀寫的基本單位；

(2) Hadoop1.0默認(rèn)數(shù)據(jù)塊大小64MB，Hadoop2.0默認(rèn)是128M；

(3) 磁盤塊一般為512B；

(4) 塊增大可以減少尋址時(shí)間，降低尋址時(shí)間/文件傳輸時(shí)間，若尋址時(shí)間為10ms，磁盤傳輸速率為100MB/s，那么該比例僅為1%；

(5) 數(shù)據(jù)塊過大也不好，因?yàn)橐粋€(gè)MapReduce通常以一個(gè)塊作為輸入，塊過大會(huì)導(dǎo)致整體任務(wù)數(shù)量過小，降低作業(yè)處理速度。

7 關(guān)于SecondaryNameNode

(1) 兩個(gè)文件：

fsimage：它是在NameNode啟動(dòng)時(shí)對整個(gè)文件系統(tǒng)的快照（鏡像文件）edit logs：它是在NameNode啟動(dòng)后，對文件系統(tǒng)的改動(dòng)序列（存在磁盤中）

(2) 兩個(gè)文件狀態(tài)：數(shù)據(jù)是不斷增加的，而NameNode是很少重啟的，所以edit log是不斷增大的，而fsimage是比較舊的，永遠(yuǎn)也趕不上edit log文件，所以需要借助別的東西來更新fsimage文件

解析：NameNode重啟那一瞬間，內(nèi)存數(shù)據(jù)是空白的，那么NameNod在重啟的時(shí)候就需要把還原出內(nèi)存的元數(shù)據(jù)狀態(tài)，這些狀態(tài)數(shù)據(jù)是來自fsimage的；

NameNode重啟之后會(huì)先讀fsimage，再讀eidt，兩者合并才能得到完整數(shù)據(jù)，這時(shí)edit log數(shù)據(jù)會(huì)比fsimage大很多，合并需要很長時(shí)間，這時(shí)就需要一個(gè)機(jī)制，盡可能想辦法怎樣減小你的eidt，并且讓fsimage這個(gè)文件能夠盡可能的保持最新的數(shù)據(jù)狀態(tài)，這樣的話NameNode重啟的話就不需要受合并的影響了，它就可以從fsimage直接讀數(shù)據(jù)然后啟動(dòng)。所以，這個(gè)事情就由SecondNameNode來干的。

(3) SecondNameNode作用

用來保存HDFS的元數(shù)據(jù)信息，比如命名空間信息、塊信息等，由于這些信息是在內(nèi)存的，SecondNameNode是為了考慮持久化到磁盤；定時(shí)到NameNode去獲取edit logs，并更新到fsimage[Secondary NameNode自己的fsimage]；一旦它有了新的fsimage文件，它將其拷貝回NameNode中。（這時(shí)有兩個(gè)數(shù)據(jù)一樣的fsimage）；NameNode在下次重啟時(shí)會(huì)使用這個(gè)新的fsimage文件，從而減少重啟的時(shí)間；Secondary NameNode所做的不過是在文件系統(tǒng)中設(shè)置一個(gè)檢查點(diǎn)來幫助NameNode更好的工作。它不是要取代掉NameNode也不是NameNode的備份。

(4) SecondNamenode存在意義？

備份：是為了數(shù)據(jù)不丟失數(shù)據(jù)恢復(fù)：是數(shù)據(jù)找回

(5) NameNode把每一次改動(dòng)都會(huì)存在editlog中，但是整個(gè)事件是由誰來觸發(fā)的？是由DataNode觸發(fā)的

(6) 元數(shù)據(jù)持久化的過程（SNN來完成）：

內(nèi)存->editlog(磁盤)-> fsimage

(7) fsimage多久加載一次：重啟才會(huì)加載。

8 Client訪問數(shù)據(jù)流程

Client訪問數(shù)據(jù)流程：（先簡單梳理）

Client先是訪問NameNode，從NameNode中得知文件的block，從block中得知數(shù)據(jù)存儲(chǔ)的path，也就是數(shù)據(jù)存儲(chǔ)在哪個(gè)datanode上，之后client就直接到該datanode上讀取數(shù)據(jù)。

namenode：

1、文件名---》block

2、block---》datanode

datanode：

block---》path

9 防止單點(diǎn)故障

兩個(gè)方案：

(1) NFS：將hadoop元數(shù)據(jù)寫入到本地文件系統(tǒng)的同時(shí)再實(shí)時(shí)同步到一個(gè)遠(yuǎn)程掛載的網(wǎng)絡(luò)文件系統(tǒng)；

(2) secondary NameNode：它的作用是與NameNode進(jìn)行交互，定期通過編輯日志文件合并命名空間鏡像，當(dāng)NameNode發(fā)生故障時(shí)它會(huì)通過自己合并的命名空間鏡像副本來恢復(fù)。需要注意的是secondaryNameNode保存的狀態(tài)總是滯后于NameNode，所以這種方式難免會(huì)導(dǎo)致丟失部分?jǐn)?shù)據(jù)。

10 副本機(jī)制

為了系統(tǒng)容錯(cuò)，文件系統(tǒng)會(huì)對所有數(shù)據(jù)塊進(jìn)行副本復(fù)制多份，Hadoop 是默認(rèn) 3 副本管理：

第一個(gè)副本，在客戶端相同的節(jié)點(diǎn)（如果客戶端是集群外的一臺(tái)機(jī)器，就隨機(jī)算節(jié)點(diǎn)，但是系統(tǒng)會(huì)避免挑選太滿或者太忙的節(jié)點(diǎn)）；

第二個(gè)副本，放在不同機(jī)架（隨機(jī)選擇）的節(jié)點(diǎn)；

第三個(gè)副本，放在與第二個(gè)副本同機(jī)架但是不同節(jié)點(diǎn)上；

所有有關(guān)塊復(fù)制的決策統(tǒng)一由NameNode負(fù)責(zé)，NameNode 會(huì)周期性地接受集群中數(shù)據(jù)節(jié)點(diǎn) DataNode 的心跳和塊報(bào)告。一個(gè)心跳的到達(dá)表示這個(gè)數(shù)據(jù)節(jié)點(diǎn)是正常的。一個(gè)塊報(bào)告包括該數(shù)據(jù)節(jié)點(diǎn)上所有塊的列表。

特殊情況：比如我目前的集群環(huán)境（1個(gè)master、2個(gè)slaves），此時(shí)并不是3個(gè)副本而是2個(gè)，因?yàn)閐atanode數(shù)量就只有2個(gè)。

11 數(shù)據(jù)完整性校驗(yàn)

不希望存儲(chǔ)和處理數(shù)據(jù)時(shí)丟失或損失數(shù)據(jù)，HDFS會(huì)對寫入的數(shù)據(jù)計(jì)算檢驗(yàn)和，并在讀取數(shù)據(jù)時(shí)驗(yàn)證校驗(yàn)和。

(1) 校驗(yàn)和（傳輸檢測---csc32）

需要校驗(yàn)兩次：

a) client向DataNode寫數(shù)據(jù)的時(shí)候，要針對所寫的數(shù)據(jù)每個(gè)檢查單位（512字節(jié)）創(chuàng)建一個(gè)單獨(dú)的校驗(yàn)和，將該校驗(yàn)碼和數(shù)據(jù)本身一起傳送給DataNode；b) DataNode接收的時(shí)候，也要?jiǎng)?chuàng)建校驗(yàn)和進(jìn)行校驗(yàn)，新生成的校驗(yàn)和原始的校驗(yàn)和不完全匹配，那么數(shù)據(jù)就會(huì)被認(rèn)為是被損壞的。

(2) 數(shù)據(jù)塊檢測程序DataBlockScanner（本地檢測）

在DataNode節(jié)點(diǎn)上開啟一個(gè)后臺(tái)線程，來定期驗(yàn)證存儲(chǔ)在它上面的所有塊，這個(gè)是防止物理介質(zhì)出現(xiàn)損減情況而造成的數(shù)據(jù)損壞。

12 容錯(cuò)-可靠性措施

HDFS有一套可靠性保證（保證數(shù)據(jù)完整性）

(1) 心跳：DN-NN

(2) 副本：通過數(shù)據(jù)冗余保證高可用

(3) 數(shù)據(jù)完整性：crc32

(4) SNN，保證元數(shù)據(jù)避免一定程度上不丟失（日記文件、鏡像文件）

(5) 空間回收：回收站（.Trash目錄，在有效時(shí)間內(nèi)，可以把誤刪數(shù)據(jù)恢復(fù)回來）

(6) 快照

(7) 報(bào)告：快報(bào)告 ./hdfs fsck /passwd -files -blocks -locations

13 HDFS特點(diǎn)

HDFS 專為解決大數(shù)據(jù)存儲(chǔ)問題而產(chǎn)生的，其具備了以下特點(diǎn)：

(1) HDFS 文件系統(tǒng)可存儲(chǔ)超大文件

每個(gè)磁盤都有默認(rèn)的數(shù)據(jù)塊大小，這是磁盤在對數(shù)據(jù)進(jìn)行讀和寫時(shí)要求的最小單位，文件系統(tǒng)是要構(gòu)建于磁盤上的，文件系統(tǒng)的也有塊的邏輯概念，通常是磁盤塊的數(shù)倍;通常文件系統(tǒng)為幾千個(gè)字節(jié)，而磁盤塊一般為 512 個(gè)字節(jié);HDFS 是一種文件系統(tǒng)，自身也有塊（block）的概念，其文件塊要比普通單一磁盤上文件系統(tǒng)大的多，默認(rèn)是 64MB;HDFS 上的塊之所以設(shè)計(jì)的如此之大，其目的是為了最小化尋址開銷;HDFS 文件的大小可以大于網(wǎng)絡(luò)中任意一個(gè)磁盤的容量，文件的所有塊并不需要存儲(chǔ)在一個(gè)磁盤上，因此可以利用集群上任意一個(gè)磁盤進(jìn)行存儲(chǔ)，由于具備這種分式存儲(chǔ)的邏輯，所以可以存儲(chǔ)超大的文件，通常 G、T、P 級別。

(2) 一次寫入，多次讀?。╳rite-once-read-many）

一個(gè)文件經(jīng)過創(chuàng)建、寫入和關(guān)閉之后就不需要改變，這個(gè)假設(shè)簡化了數(shù)據(jù)一致性的問題，同時(shí)提高數(shù)據(jù)訪問的吞吐量。保證系統(tǒng)性能和穩(wěn)定。

(3) 運(yùn)行在普通廉價(jià)的機(jī)器上

Hadoop 的設(shè)計(jì)對硬件要求低，無需昂貴的高可用性機(jī)器上，因?yàn)樵贖DFS設(shè)計(jì)中充分考慮到了數(shù)據(jù)的可靠性、安全性和高可用性。

14 不適用于HDFS的場景

(1) 低延遲

HDFS 不適用于實(shí)時(shí)查詢這種對延遲要求高的場景，例如：股票實(shí)盤。往往應(yīng)對低延遲數(shù)據(jù)訪問場景需要通過數(shù)據(jù)庫訪問索引的方案來解決，Hadoop 生態(tài)圈中的Hbase 具有這種隨機(jī)讀、低延遲等特點(diǎn)。

(2) 大量小文件

對于 Hadoop 系統(tǒng)，小文件通常定義為遠(yuǎn)小于 HDFS 的 block size（默認(rèn) 64MB）的文件，由于每個(gè)文件都會(huì)產(chǎn)生各自的 MetaData 元數(shù)據(jù)，Hadoop 通過 Namenode來存儲(chǔ)這些信息，若小文件過多，容易導(dǎo)致 Namenode 存儲(chǔ)出現(xiàn)瓶頸。

(3) 多用戶更新

為了保證并發(fā)性，HDFS 需要一次寫入多次讀取，目前不支持多用戶寫入，若要修改，也是通過追加的方式添加到文件的末尾處，出現(xiàn)太多文件需要更新的情況Hadoop是不支持的。針對有多人寫入數(shù)據(jù)的場景，可以考慮采用 Hbase 的方案。

(4) 結(jié)構(gòu)化數(shù)據(jù)

HDFS 適合存儲(chǔ)半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)，若有嚴(yán)格的結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)場景，也可以考慮采用 Hbase 的方案。

(5) 數(shù)據(jù)量并不大

通常 Hadoop 適用于 TB、PB 數(shù)據(jù)，若待處理的數(shù)據(jù)只有幾十 GB 的話，不建議使用 Hadoop，因?yàn)闆]有任何好處。

15 HDFS寫流程

1）寫流程

客戶端調(diào)用 create()來創(chuàng)建文件，Distributed File System 用 RPC 調(diào)用 NameNode節(jié)點(diǎn)，在文件系統(tǒng)的命名空間中創(chuàng)建一個(gè)新的文件。NameNode 節(jié)點(diǎn)首先確定文件原來不存在，并且客戶端有創(chuàng)建文件的權(quán)限，然后創(chuàng)建新文件。Distributed File System 返回 FSDOutputStream，客戶端用于寫數(shù)據(jù)?？蛻舳碎_始寫入數(shù)據(jù)，F(xiàn)SDOutputStream 將數(shù)據(jù)分成塊，寫入 Data Queue。Data Queue 由 DataStreamer 讀取，并通知 NameNode 節(jié)點(diǎn)分配數(shù)據(jù)節(jié)點(diǎn)，用來存儲(chǔ)數(shù)據(jù)塊(每塊默認(rèn)復(fù)制 3塊)。分配的數(shù)據(jù)節(jié)點(diǎn)放在一個(gè) Pipeline 里。Data Streamer 將數(shù)據(jù)塊寫入 Pipeline 中的第一個(gè)數(shù)據(jù)節(jié)點(diǎn)。第一個(gè)數(shù)據(jù)節(jié)點(diǎn)將數(shù)據(jù)塊發(fā)送給第二個(gè)數(shù)據(jù)節(jié)點(diǎn)。第二個(gè)數(shù)據(jù)節(jié)點(diǎn)將數(shù)據(jù)發(fā)送給第三個(gè)數(shù)據(jù)節(jié)點(diǎn)。DFSOutputStream 為發(fā)出去的數(shù)據(jù)塊保存了 Ack Queue，等待 Pipeline 中的數(shù)據(jù)節(jié)點(diǎn)告知數(shù)據(jù)已經(jīng)寫入成功。寫入一個(gè)datanode都說明寫入數(shù)據(jù)成功，內(nèi)部datanode會(huì)數(shù)據(jù)冗余。

Client寫數(shù)據(jù)流程總結(jié)：

(1) client通過java類DistibutedFileSystem向NameNode發(fā)送creat請求）

(2) NameNode借助DistributedFileSystem來返回一個(gè)對象類FSDataOutputStream

(3) Client通過FSDataOutputStream往datanode里寫數(shù)據(jù)

(4) OutputStream會(huì)把寫入的文件切分成一個(gè)一個(gè)的數(shù)據(jù)塊，這時(shí)候還是在client上的

(5) Data Stream通過一個(gè)分發(fā)機(jī)制分別把數(shù)據(jù)塊寫入到datanode中

(6) 第一個(gè)datanode寫成功后，就會(huì)返回一個(gè)ack packet包給FSDataOutputStream

(7) 內(nèi)部副本數(shù)據(jù)冗余

16 HDFS讀取流程

首先 Client 通過 File System 的 Open 函數(shù)打開文件，Distributed File System 用 RPC調(diào)用 NameNode 節(jié)點(diǎn)，得到文件的數(shù)據(jù)塊信息。對于每一個(gè)數(shù)據(jù)塊，NameNode 節(jié)點(diǎn)返回保存數(shù)據(jù)塊的數(shù)據(jù)節(jié)點(diǎn)的地址。Distributed File System 返回 FSDataInputStream 給客戶端，用來讀取數(shù)據(jù)?？蛻舳苏{(diào)用 stream的 read()函數(shù)開始讀取數(shù)據(jù)。FSDInputStream連接保存此文件第一個(gè)數(shù)據(jù)塊的最近的數(shù)據(jù)節(jié)點(diǎn)。DataNode 從數(shù)據(jù)節(jié)點(diǎn)讀到客戶端(client)，當(dāng)此數(shù)據(jù)塊讀取完畢時(shí)，F(xiàn)SDInputStream 關(guān)閉和此數(shù)據(jù)節(jié)點(diǎn)的連接，然后連接此文件下一個(gè)數(shù)據(jù)塊的最近的數(shù)據(jù)節(jié)點(diǎn)。當(dāng)客戶端讀取完畢數(shù)據(jù)的時(shí)候，調(diào)用FSDataInputStream 的 close 函數(shù)。在讀取數(shù)據(jù)的過程中，如果客戶端在與數(shù)據(jù)節(jié)點(diǎn)通信出現(xiàn)錯(cuò)誤，則嘗試連接包含此數(shù)據(jù)塊的下一個(gè)數(shù)據(jù)節(jié)點(diǎn)。失敗的數(shù)據(jù)節(jié)點(diǎn)將被記錄，以后不再連接。

Clinet讀流程總結(jié)：

(1) 客戶端發(fā)送請求，調(diào)用DistributedFileSystemAPI的open方法發(fā)送請求到Namenode，獲得block的位置信息，因?yàn)檎嬲腷lock是存在Datanode節(jié)點(diǎn)上的，而namenode里存放了block位置信息的元數(shù)據(jù)。

(2) Namenode返回所有block的位置信息，并將這些信息返回給客戶端。

(3) 客戶端拿到block的位置信息后調(diào)用FSDataInputStreamAPI的read方法并行的讀取block信息，圖中4和5流程是并發(fā)的，block默認(rèn)有3個(gè)副本，所以每一個(gè)block只需要從一個(gè)副本讀取就可以。

(4) datanode返回給客戶端。

17 同步和異步

同步：保證數(shù)據(jù)一致性，問題慢

異步：速度快，不能保證數(shù)據(jù)強(qiáng)一致

同步是指：發(fā)送方發(fā)出數(shù)據(jù)后，等接收方發(fā)回響應(yīng)以后才發(fā)下一個(gè)數(shù)據(jù)包的通訊方式。

異步是指：發(fā)送方發(fā)出數(shù)據(jù)后，不等接收方發(fā)回響應(yīng)，接著發(fā)送下個(gè)數(shù)據(jù)包的通訊方式。

同步就是你叫我去吃飯，我聽到了就和你去吃飯；如果沒有聽到，你就不停的叫，直到我告訴你聽到了，才一起去吃飯。

異步就是你叫我，然后自己去吃飯，我得到消息后可能立即走，也可能等到下班才去吃飯。

所以，要我請你吃飯就用同步的方法，要請我吃飯就用異步的方法，這樣你可以省錢。

18 HDFS&MapReduce本地模式

本地模式：保證計(jì)算框架和任務(wù)調(diào)度管理部署在同一臺(tái)機(jī)器上，體現(xiàn)本地化原則，盡量減少數(shù)據(jù)移動(dòng)開銷。

mapreduce有map階段和reduce階段，本地化原則針對map階段，因?yàn)閞educe階段有遠(yuǎn)程partition，不能保證是同一機(jī)器。

HDFS2.0

HDFS2.0相對HDFS1.0有幾個(gè)新特性

1 NameNode HA

1.1 高可用方案

(1) 在Hadoop1.0中NameNode在整個(gè)HDFS中只有一個(gè)，存在單點(diǎn)故障風(fēng)險(xiǎn)，

一旦NameNode掛掉，整個(gè)集群無法使用，雖然有SNN，但還是不可靠；在Hadoop2.0中，就針對NameNode提供了一個(gè)高可用方案。

1.0簡圖

2.0簡圖

(2) HDFS的高可用性將通過在同一個(gè)集群中運(yùn)行兩個(gè)NameNode （active NameNode & standby NameNode）來解決；

(3) 在任何時(shí)間，只有一臺(tái)機(jī)器處于Active狀態(tài)；另一臺(tái)機(jī)器是處于Standby狀態(tài)；

(4) Active NN負(fù)責(zé)集群中所有客戶端的操作；

(5) Standby NN主要用于備用，它主要維持足夠的狀態(tài)，如果必要，可以提供快速的故障恢復(fù)。

1.2 高可用架構(gòu)

(1) 不管2.0還是1.0，底層都是datanode，2.0有兩個(gè)NN，一個(gè)是Active狀態(tài)，一個(gè)是Standby狀態(tài)，datanode中的block一旦發(fā)生了修過，就同時(shí)通過心跳的方式通知兩個(gè)NN，NN中的元數(shù)據(jù)就隨即更新。

(2) 為了保證兩個(gè)NN數(shù)據(jù)一致性，必須滿足兩個(gè)條件：

數(shù)據(jù)同步：要保證數(shù)據(jù)同步，DataNode要對兩個(gè)NN同時(shí)發(fā)送心跳命名空間同步（namespace/文件目錄樹），有以下兩種方法：

? 借助NFS文件系統(tǒng)，network File system

? Hadoop自身提供了一個(gè)服務(wù)，叫做QJM

NFS：屬于操作系統(tǒng)支持的配置---》鏡像文件和編制日記文件

QJM：屬于應(yīng)用軟件級別的配置----》JN

(3) DataNode要對兩個(gè)NN同時(shí)發(fā)送心跳，為了保證數(shù)據(jù)一致性，為什么還需要JN？

原因：兩者同步的數(shù)據(jù)不同，之前說過Namenode中有兩種不同類型的映射數(shù)據(jù)

JN對應(yīng)的映射關(guān)系：文件名->block

NN對應(yīng)的映射關(guān)系：block->DN

總結(jié)以上：

完成數(shù)據(jù)一致性要保證這兩個(gè)之間數(shù)據(jù)完全一致就需要兩個(gè)一致：一個(gè)是數(shù)據(jù)（通過數(shù)據(jù)管理部保證），一個(gè)是命名空間（通過JN（QJM起來的進(jìn)程）來保證的），一個(gè)集群中，最少要運(yùn)行3個(gè)JN系統(tǒng)，使得系統(tǒng)有一定的容錯(cuò)能力

(4) 命名空間保持同步

當(dāng)Active NameNode的命名空間發(fā)生變化的時(shí)候，它會(huì)把這個(gè)變化通知所有JN，有的JN收到信息，有的JN是沒有收到信息的，如果大部分JN進(jìn)程接到信息，就認(rèn)為這個(gè)事件是可信的，如果少數(shù)的JN接到信息，就認(rèn)為這個(gè)信息是錯(cuò)誤的，是屏蔽的，對于可信的信息，standby Namenode才會(huì)去同步過來，通過JN這種方式，才能保證Standby Namenode和Active Namenode之間有效信息的一個(gè)同步。

(5) NN與FailoverController、ZK的聯(lián)系

a. FailoverController進(jìn)程（ZKFC）主要是用來協(xié)助故障轉(zhuǎn)移用的，是部署在NN上的，對NN進(jìn)行健康狀態(tài)檢查；

b. ZK是用來用來完成故障轉(zhuǎn)移的，ZK不會(huì)與NN建立直接關(guān)系，ZKFC是ZK集群的客戶端，通過ZKFC用來監(jiān)控NN的狀態(tài)信息，ZKFC在ZK上創(chuàng)建節(jié)點(diǎn)（刪除節(jié)點(diǎn)、臨時(shí)節(jié)點(diǎn)、順序節(jié)點(diǎn)等），與NN保持心跳；

c. 每一個(gè)NN就需要一個(gè)ZKFC，Active NN對應(yīng)Active ZKFC，Standby NN對應(yīng)Standby ZKFC；

(6) 故障轉(zhuǎn)移

a. 什么叫故障轉(zhuǎn)移：就是說當(dāng)active突然掛掉了，standby立馬就把狀態(tài)變成active狀態(tài)，就是起到這么一個(gè)作用。

b. ZKFC對自己負(fù)責(zé)的NN進(jìn)行健康檢查，ZKFC是和NN部署在同節(jié)點(diǎn)上的，是時(shí)時(shí)健康檢查的，ZKFC與zookeeper通過心跳檢測連接，ZKFC會(huì)在ZK上注冊一個(gè)臨時(shí)節(jié)點(diǎn)（要監(jiān)控，必須要臨時(shí)節(jié)點(diǎn)），目的用于監(jiān)控NN，ZK通過一些監(jiān)控的命令不斷的去檢查NN進(jìn)程，如果NN失效，相應(yīng)的臨時(shí)節(jié)點(diǎn)消失，接下來的動(dòng)作類似于選主（或者申請鎖）的流程。

c. 如果當(dāng)本地的namenode是健康的話，并且當(dāng)前namenode也是剛好是active狀況，那么ZKFC就會(huì)持有一把鎖，這把鎖就是一個(gè)臨時(shí)節(jié)點(diǎn)，當(dāng)本地的namenode失效了，這個(gè)節(jié)點(diǎn)也就失效了。

d. 還有另外一種情況，NN是健康的，但是，不是Active狀態(tài)而是Standby狀態(tài)，這個(gè)時(shí)間ZKFC進(jìn)程就會(huì)去幫我檢查，ZZ中有沒有這個(gè)臨時(shí)節(jié)點(diǎn)，如果沒有的話，就去創(chuàng)建一個(gè)，如果創(chuàng)建不了，那么說明當(dāng)前集群里面有一個(gè)NN是處于active狀態(tài)。

e. ZKFC進(jìn)程，相當(dāng)于對zookerper服務(wù)和NN服務(wù)進(jìn)行了一定的隔離。

f. 以上就是ZK通過ZKFC進(jìn)程來完全了整體的一個(gè)故障遷移。

(7) 為什么只能有一個(gè)Active Namenode

對于HA集群來說，同一時(shí)刻一定要確保只有一個(gè)namenode的狀態(tài)active，如果有兩個(gè)active的話，這兩個(gè)active會(huì)互相爭奪信息，會(huì)出現(xiàn)丟數(shù)據(jù)，會(huì)導(dǎo)致集群不可靠，發(fā)現(xiàn)錯(cuò)誤的結(jié)果。

(8) 關(guān)于JN

JN目的：讓StandbyNN和ActiveNN保持?jǐn)?shù)據(jù)同步（文件名->block）

JN通常有兩種選擇：一種是NFS（需要額外的磁盤空間），另外一種QJM（不需要空間）

JN通常要配置成奇數(shù)個(gè)（2n+1），如果n+1個(gè)數(shù)據(jù)是一致的，數(shù)據(jù)就確定下來，也就是說能最大允許出錯(cuò)的JN個(gè)數(shù)是n個(gè)。

(9) 關(guān)于QJM

QJM：最低法定人數(shù)管理機(jī)制，原理：用2n+1臺(tái)JN機(jī)器存儲(chǔ)editlog，每次寫數(shù)據(jù)操作屬于大多數(shù)(>=n+1)的時(shí)候，返回成功（認(rèn)為當(dāng)前寫成功），保證高可用

QJM本質(zhì)也是一個(gè)小集群，好處：

a.不需要空間

b.無單點(diǎn)問題

c.不會(huì)因?yàn)閭€(gè)別機(jī)器延遲，影響整體性能

d.系統(tǒng)配置

(10)為什么用QJM來實(shí)現(xiàn)HA？

第一：不需要配置額外的共享存儲(chǔ)（相比NFS來說的）

第二：消除單點(diǎn)問題，

第三：可配置，使得系統(tǒng)更加魯棒

第四：JN不會(huì)因?yàn)槠渲幸慌_(tái)的延遲而影響整體的延遲，也不會(huì)因?yàn)镴N的數(shù)量增多而影響------》為什么呢？

因?yàn)閍vtive namenode一旦里面命名空間發(fā)生數(shù)據(jù)變化，它會(huì)把這個(gè)數(shù)據(jù)同步的寫到JN上，它是并行發(fā)送的狀態(tài)，不管是部署少也好，多也好，它都是并行發(fā)出的

(11) 節(jié)點(diǎn)分配

a. NN和JN通常不在一個(gè)機(jī)器上

b. FC和NN在同一臺(tái)機(jī)器

c. RM（Yarn中的資源管理器，相當(dāng)于1.0中Jobtracker部分功能）和NN在同一臺(tái)機(jī)器

d. NM（Yarn中從節(jié)點(diǎn)）和DN在同一個(gè)機(jī)器上

e. 通常工業(yè)界，Zookeeper是單獨(dú)維護(hù)的獨(dú)立集群

=================================

HA集群：

【192.168.1.1】master1：NN，ZKFC，RM

【192.168.1.2】master2：NN，ZKFC，RM

【192.168.1.3】slave1：DN，NM，ZK，JN

【192.168.1.4】slave2：DN，NM，ZK，JN

【192.168.1.5】slave3：DN，NM

【192.168.1.6】slave4：DN，NM，ZK，JN

2 聯(lián)邦

(1) 1.0中除了單節(jié)點(diǎn)故障還有一個(gè)問題，內(nèi)存空間有限，因?yàn)橹挥幸粋€(gè)Namenode，它保持了整個(gè)HDFS所有的元數(shù)據(jù)，創(chuàng)建一個(gè)文件，就必然在內(nèi)存里面占用一定的空間，影響整個(gè)HDFS的擴(kuò)展，所以為什么之前說HDFS不利于過多的保存小文件，因?yàn)橐簿褪窃谶@里。

(2) Federation

聯(lián)邦，主要是針對namenode來說的，所以也叫namenode Federation，是有多個(gè)namenode條件下才建立起來的一個(gè)機(jī)制，有多個(gè)namenode就意味著有多套的命名空間（namespace），一個(gè)namenode負(fù)責(zé)一個(gè)命名空間，一個(gè)命名空間對應(yīng)一個(gè)block pool（是同一個(gè)namespace下的所有block集合，就是一個(gè)namenode只對應(yīng)自己管理的文件目錄，目錄里面就是文件數(shù)據(jù)，也就是block）

(3) 聯(lián)邦架構(gòu)

Federation意味著集群里面有多個(gè)block pool，上圖中，底層是一個(gè)datanode存儲(chǔ)，上層是命名空間，每一個(gè)命名空間都維護(hù)著自己的文件目錄樹，文件目錄樹下面都存在著一些文件和數(shù)據(jù)，這些數(shù)據(jù)都是由block組成的，block都是由datanode通過心跳數(shù)據(jù)同步更新過來的。

(4) 數(shù)據(jù)同步

datanode會(huì)先把數(shù)據(jù)存到各自各自pool里，也就是緩沖區(qū)里，然后由namenode管理起來，不管是1.0也好，2.0也好，在整個(gè)集群里面，所有的文件，就是整體空間的全集，把所有pool里的信息加起來就是一個(gè)整體概念，那這個(gè)時(shí)候呢，因?yàn)橐M成一個(gè)聯(lián)邦，每個(gè)namenode要管理自己的空間，要把每一個(gè)pool分開，每一個(gè)namenode來維護(hù)自己的一個(gè)pool，每一個(gè)節(jié)點(diǎn)都是這樣的，好比這個(gè)集群里面有三個(gè)namenode，每個(gè)namenode都要去維護(hù)自己的pool，維護(hù)自己的那一套緩存，而且兩兩之間的內(nèi)部緩存信息都是不一樣的，因?yàn)槲募?nèi)部的邏輯概念不一樣。

所以這就是聯(lián)邦解決內(nèi)部空間不足的一個(gè)解決方案。

(5) 聯(lián)邦優(yōu)勢：

a. 命名空間可以橫向擴(kuò)展，使得Hadoop集群的規(guī)?？梢赃_(dá)到上萬臺(tái)

減輕單一NN壓力，將一部分文件轉(zhuǎn)移到其他NN上管理,如果集群中某一個(gè)目錄比較大，建議用單獨(dú)的NN維護(hù)起來,命名空間精簡，橫向擴(kuò)展，真正突破單臺(tái)NN的限制

b. 性能提升

就是說當(dāng)namenode持有的數(shù)據(jù)達(dá)到一個(gè)非常大規(guī)模量級時(shí)候，比如說集群里面有十億個(gè)文件，這個(gè)時(shí)候呢，namenode處理效率可以會(huì)受到一點(diǎn)影響，但是呢，它可以會(huì)容易陷入到一個(gè)比較繁難的狀態(tài)，而且整個(gè)集群會(huì)受限于單個(gè)namenode來處理的這個(gè)效率，從而影響整個(gè)集群的吞吐量，這個(gè)時(shí)候呢，你如果用聯(lián)邦這種方式，顯然可以提高性能，原來一個(gè)namenode它承載了外部所有的請求，現(xiàn)在不是了，現(xiàn)在是把這個(gè)請求給分流了，性能也會(huì)提升的

c. 資源的隔離(跟具體應(yīng)用有關(guān))

通過多個(gè)命名空間，可以將關(guān)鍵文件移動(dòng)到不同的namenode上，那些相對不關(guān)鍵的數(shù)據(jù)修改，一旦發(fā)生了問題，至少不影響關(guān)鍵數(shù)據(jù)的破壞就相當(dāng)于每一個(gè)namenode維護(hù)的空間可以按部門去分，也可以看重要程度去分

每個(gè)NN共享所有的DN數(shù)據(jù)，一個(gè)命名空間對應(yīng)一個(gè)塊池（是同一個(gè)命名空間下的所有塊集合）

(6) 聯(lián)邦的本質(zhì)：將一部分文件遷移到其他NN進(jìn)行管理，讓元數(shù)據(jù)管理（NN）和存儲(chǔ)（DN）進(jìn)行解耦（分開），但是真實(shí)的數(shù)據(jù)存儲(chǔ)還是共享的。

3 HDFS快照

(1) 概念：在某一時(shí)刻給當(dāng)前的文件系統(tǒng)照一個(gè)照片，這一照片就是當(dāng)前時(shí)刻，整個(gè)集群的數(shù)據(jù)狀態(tài)

(2) 作用：主要用來做數(shù)據(jù)備份、災(zāi)備、快速恢復(fù)

(3) 本質(zhì)：只記錄了block列表和文件大小，但不會(huì)出現(xiàn)數(shù)據(jù)的復(fù)制

(4) 快照也是數(shù)據(jù)，也會(huì)占空間，但不是占特別大的空間（有些可以忽略不計(jì)）

(5) 假設(shè)：一個(gè)集群，如果全部備份，可能還需要另外一個(gè)集群，操作很麻煩，成本還特高，快照的創(chuàng)建時(shí)瞬間完成的，高效！

(6) 并不會(huì)影響HDFS 的正常操作：修改會(huì)按照時(shí)間的反序記錄，這樣可以直接讀取到最新的數(shù)據(jù)。

(7) 快照數(shù)據(jù)是當(dāng)前數(shù)據(jù)減去修改的部分計(jì)算出來的。

(8) 快照會(huì)存儲(chǔ)在snapshottable的目錄下。

(9) HDFS快照是對目錄進(jìn)行設(shè)定，是某個(gè)目錄的某一個(gè)時(shí)刻的鏡像

(10)對于一個(gè)snapshottable文件夾，“.snapshot”被用于進(jìn)入他的快照 /foo 是一個(gè)snapshottable目錄，/foo/bar是一個(gè)/foo下面的文件目錄，/foo有一個(gè)快s0，那么路徑就是：/foo/.snapshot/s0/bar

(11)操作命令

? hdfs dfsadmin-allowSnapshot /user/spark

? hdfs dfs-createSnapshot /user/spark s0

? hdfs dfs-renameSnapshot /user/spark s0 s_init

? hdfs dfs-deleteSnapshot /user/spark s_init

? hdfsdfsadmin -disallowSnapshot /user/spark

(12)舉例

三個(gè)目錄是包含的關(guān)系，A最上層，B在A中，C在B中，當(dāng)B做了個(gè)快照，這時(shí)C還能做快照嗎？不能，因?yàn)锽做了快照，它下面的所有子目錄都包含了；這時(shí)候A也是不能做快照的，子目錄做了快照，父目錄也是不允許的。

4 HDFS緩存

HDFS1.0中也講過類似緩存的情況，就是當(dāng)客戶端去讀這個(gè)DN的時(shí)候，如果這個(gè)數(shù)據(jù)被頻繁讀取，在操作系統(tǒng)級別會(huì)有一個(gè)預(yù)讀取，這個(gè)數(shù)據(jù)讀了，會(huì)把未來的數(shù)據(jù)會(huì)提前加載到一個(gè)系統(tǒng)級別緩存里面去，這樣會(huì)加快數(shù)據(jù)訪問。

把HDFS1.0中的緩存叫做是依賴于操作系統(tǒng)本身的緩存機(jī)制。這種緩存機(jī)制是不能被系統(tǒng)管理員或者中央節(jié)點(diǎn)所管理的，這些緩存都是在datanode上的，由datanode自身操作系統(tǒng)來決定的，那對于想在namenode或者master控制整個(gè)路徑緩存的話是不行的。2.0針對這種情況做了升級。

在HDFS2.0中，叫做是集中式緩存（不局限在具體的機(jī)器cpu和操作系統(tǒng)層面上的優(yōu)化），即是由Namenode集中式管理的，可以提高對于緩存內(nèi)存的可性。

集中式緩存作用或者優(yōu)點(diǎn)：

（1）允許用戶指定要緩存的HDFS路徑

自由控制緩存，提高緩存內(nèi)存的可控性。

（2）明確的鎖定可以阻止頻繁使用的數(shù)據(jù)被從內(nèi)存中清除

對于頻繁讀取的數(shù)據(jù)，一旦明確了存儲(chǔ)路徑，就會(huì)告知系統(tǒng)，這個(gè)數(shù)據(jù)是要頻繁讀取的，讓內(nèi)存清緩存的機(jī)制不清除這些數(shù)據(jù)。

（3）集中化緩存管理對于重復(fù)訪問的文件很有用

（4）可以換成目錄或文件，但目錄是非遞歸的

集中式緩存只能對文件和目錄操作，目錄是非遞歸的，只能緩存當(dāng)前目錄

就比如下圖，對目錄B做了緩存，那C是不受影響的，也沒有緩存C中的數(shù)據(jù)，C還可以再做緩存

非遞歸這是集中式緩存的特點(diǎn)，但是不能說是優(yōu)點(diǎn)

Namenode下的內(nèi)容已經(jīng)是在內(nèi)存中的了，沒必要再做緩存了

主要問題是緩存數(shù)據(jù)還是緩存映射關(guān)系？

是緩存數(shù)據(jù)的，加快讀取速度

5 HDFS ACL

(1) Hadoop從2.4.0開始支持ACL

(2) 目前HDFS的權(quán)限控制與Linux一致，包括用戶、用戶組、其他用戶組三類權(quán)限，這種方式有很大局限性

(3) 首先參數(shù)上要開啟基本權(quán)限和訪問控制列表功能

dfs.permissions.enabled

dfs.namenode.acls.enabled

(4) 常用命令：

hadoop fs-getfacl /input/acl

hdfs dfs-setfacl -m user:mapred:r-- /input/acl

hdfs dfs-setfacl -x user:mapred /input/acl

柚子快報(bào)邀請碼778899分享：hadoop HDFS學(xué)習(xí)筆記

http://yzkb.51969.com/

推薦閱讀