柚子快報邀請碼778899分享：hadoop HDFS學習筆記

http://yzkb.51969.com/

HDFS1.0

1 什么是HDFS？

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

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

HDFS 由三個組件構成：NameNode（NN）、DataNode（DN）、SecondaryNameNode（SNN）

2 系統(tǒng)架構

HDFS 是一個主/從（Master/Slave）體系架構，由于分布式存儲的性質，集群擁有兩類節(jié)點 NameNode 和 DataNode。

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

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

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

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

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

Heartbeat：NameNode與DataNode之間存在心跳連接，DataNode每隔一段一時間就主動向NameNode匯報消息Balance：當一個datanode掛了，為了達到平衡block，內部數(shù)據(jù)會被平均分配到其他datanode上

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

因為hadoop1.0是在zookeeper誕生之前，沒有滿足高可用的工具。

3 關于NameNode

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

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

文件名目錄名及它們之間的層級關系文件目錄的所有者及其權限每個文件塊的名及文件有哪些塊組成

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

NameNode元信息并不包含每個塊的位置信息（每個塊的信息存儲在block中，block存儲在datanode中）

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

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

(5) 元信息持久化

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

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

4 Hadoop更傾向存儲大文件原因：

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

5 關于DataNode

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

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

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

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

6 關于block

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

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

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

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

(5) 數(shù)據(jù)塊過大也不好，因為一個MapReduce通常以一個塊作為輸入，塊過大會導致整體任務數(shù)量過小，降低作業(yè)處理速度。

7 關于SecondaryNameNode

(1) 兩個文件：

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

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

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

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

(3) SecondNameNode作用

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

(4) SecondNamenode存在意義？

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

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

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

內存->editlog(磁盤)-> fsimage

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

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

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

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

namenode：

1、文件名---》block

2、block---》datanode

datanode：

block---》path

9 防止單點故障

兩個方案：

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

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

10 副本機制

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

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

第二個副本，放在不同機架（隨機選擇）的節(jié)點；

第三個副本，放在與第二個副本同機架但是不同節(jié)點上；

所有有關塊復制的決策統(tǒng)一由NameNode負責，NameNode 會周期性地接受集群中數(shù)據(jù)節(jié)點 DataNode 的心跳和塊報告。一個心跳的到達表示這個數(shù)據(jù)節(jié)點是正常的。一個塊報告包括該數(shù)據(jù)節(jié)點上所有塊的列表。

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

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

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

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

需要校驗兩次：

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

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

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

12 容錯-可靠性措施

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

(1) 心跳：DN-NN

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

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

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

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

(6) 快照

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

13 HDFS特點

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

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

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

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

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

(3) 運行在普通廉價的機器上

Hadoop 的設計對硬件要求低，無需昂貴的高可用性機器上，因為在HDFS設計中充分考慮到了數(shù)據(jù)的可靠性、安全性和高可用性。

14 不適用于HDFS的場景

(1) 低延遲

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

(2) 大量小文件

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

(3) 多用戶更新

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

(4) 結構化數(shù)據(jù)

HDFS 適合存儲半結構化和非結構化數(shù)據(jù)，若有嚴格的結構化數(shù)據(jù)存儲場景，也可以考慮采用 Hbase 的方案。

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

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

15 HDFS寫流程

1）寫流程

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

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

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

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

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

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

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

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

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

16 HDFS讀取流程

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

Clinet讀流程總結：

(1) 客戶端發(fā)送請求，調用DistributedFileSystemAPI的open方法發(fā)送請求到Namenode，獲得block的位置信息，因為真正的block是存在Datanode節(jié)點上的，而namenode里存放了block位置信息的元數(shù)據(jù)。

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

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

(4) datanode返回給客戶端。

17 同步和異步

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

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

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

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

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

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

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

18 HDFS&MapReduce本地模式

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

mapreduce有map階段和reduce階段，本地化原則針對map階段，因為reduce階段有遠程partition，不能保證是同一機器。

HDFS2.0

HDFS2.0相對HDFS1.0有幾個新特性

1 NameNode HA

1.1 高可用方案

(1) 在Hadoop1.0中NameNode在整個HDFS中只有一個，存在單點故障風險，

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

1.0簡圖

2.0簡圖

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

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

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

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

1.2 高可用架構

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

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

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

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

? Hadoop自身提供了一個服務，叫做QJM

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

QJM：屬于應用軟件級別的配置----》JN

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

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

JN對應的映射關系：文件名->block

NN對應的映射關系：block->DN

總結以上：

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

(4) 命名空間保持同步

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

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

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

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

c. 每一個NN就需要一個ZKFC，Active NN對應Active ZKFC，Standby NN對應Standby ZKFC；

(6) 故障轉移

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

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

c. 如果當本地的namenode是健康的話，并且當前namenode也是剛好是active狀況，那么ZKFC就會持有一把鎖，這把鎖就是一個臨時節(jié)點，當本地的namenode失效了，這個節(jié)點也就失效了。

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

e. ZKFC進程，相當于對zookerper服務和NN服務進行了一定的隔離。

f. 以上就是ZK通過ZKFC進程來完全了整體的一個故障遷移。

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

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

(8) 關于JN

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

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

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

(9) 關于QJM

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

QJM本質也是一個小集群，好處：

a.不需要空間

b.無單點問題

c.不會因為個別機器延遲，影響整體性能

d.系統(tǒng)配置

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

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

第二：消除單點問題，

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

第四：JN不會因為其中一臺的延遲而影響整體的延遲，也不會因為JN的數(shù)量增多而影響------》為什么呢？

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

(11) 節(jié)點分配

a. NN和JN通常不在一個機器上

b. FC和NN在同一臺機器

c. RM（Yarn中的資源管理器，相當于1.0中Jobtracker部分功能）和NN在同一臺機器

d. NM（Yarn中從節(jié)點）和DN在同一個機器上

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

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

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é)點故障還有一個問題，內存空間有限，因為只有一個Namenode，它保持了整個HDFS所有的元數(shù)據(jù)，創(chuàng)建一個文件，就必然在內存里面占用一定的空間，影響整個HDFS的擴展，所以為什么之前說HDFS不利于過多的保存小文件，因為也就是在這里。

(2) Federation

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

(3) 聯(lián)邦架構

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

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

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

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

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

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

減輕單一NN壓力，將一部分文件轉移到其他NN上管理,如果集群中某一個目錄比較大，建議用單獨的NN維護起來,命名空間精簡，橫向擴展，真正突破單臺NN的限制

b. 性能提升

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

c. 資源的隔離(跟具體應用有關)

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

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

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

3 HDFS快照

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

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

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

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

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

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

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

(8) 快照會存儲在snapshottable的目錄下。

(9) HDFS快照是對目錄進行設定，是某個目錄的某一個時刻的鏡像

(10)對于一個snapshottable文件夾，“.snapshot”被用于進入他的快照 /foo 是一個snapshottable目錄，/foo/bar是一個/foo下面的文件目錄，/foo有一個快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)舉例

三個目錄是包含的關系，A最上層，B在A中，C在B中，當B做了個快照，這時C還能做快照嗎？不能，因為B做了快照，它下面的所有子目錄都包含了；這時候A也是不能做快照的，子目錄做了快照，父目錄也是不允許的。

4 HDFS緩存

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

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

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

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

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

自由控制緩存，提高緩存內存的可控性。

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

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

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

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

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

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

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

Namenode下的內容已經是在內存中的了，沒必要再做緩存了

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

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

5 HDFS ACL

(1) Hadoop從2.4.0開始支持ACL

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

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

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

柚子快報邀請碼778899分享：hadoop HDFS學習筆記

http://yzkb.51969.com/

推薦閱讀