.前期準(zhǔn)備工作
1：安裝protobuf（其版本只能是2.5，高了不行）
windows下
下載protobuf：https://github.com/google/protobuf/releases，選擇protoc-xxx-win32.zip下載
將解壓出來的protoc.exe放在一全英文路徑下，并把其路徑名放在windows環(huán)境變量下的path下
打開命令窗口，輸入protoc --version，若顯示出了protoc的版本號(hào)，則安裝成功。
Linux環(huán)境
下載protobuf：https://github.com/google/protobuf/releases，選擇Linux版本下載。
解壓安裝包，并將其路徑加入到環(huán)境變量，即/etc/profile文件中。
進(jìn)入protobuf目錄（我是將其解壓在/home/dev/目錄下的），依次執(zhí)行以下命令
./configure --prefix=/home/dev/protobuf-2.5.0
make
make check
make install
ldconfig
添加環(huán)境變量：vi /etc/profile，添加如下，
# (動(dòng)態(tài)庫搜索路徑) 程序加載運(yùn)行期間查找動(dòng)態(tài)鏈接庫時(shí)指定除了系統(tǒng)默認(rèn)路徑之外的其他路徑export
export PATH=$PATH:$PROTOCOL_HOME:/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/dev/protobuf-2.5.0/lib
export LIBRARY_PATH=$LIBRARY_PATH:/home/dev/protobuf-2.5.0/lib
source /etc/profile，使其生效，最后在終端輸入 protoc --version，此處與windows類似。
安裝成功會(huì)顯示版本號(hào)，如下圖（以windows為例）：
2.安裝maven
maven安裝方式可參照下面連接，方法也就是將其安裝路徑加入環(huán)境變量。
windows：https://jingyan.baidu.com/article/3065b3b6a00792becef8a46c.html
Linux：https://www.cnblogs.com/jimmy-muyuan/p/7895933.html
二：編譯
1.首先在Hadoop官網(wǎng)下載Hadoop源碼，然后將其解壓在一個(gè)全英文目錄。
2.修改項(xiàng)目根目錄（hadoop-3.0.0-src目錄）下的pom.xml文件，將snapshot依賴注釋或者刪除（在190行）。不然會(huì)導(dǎo)致在編譯過程中出現(xiàn)無法找到依賴而導(dǎo)致編譯失敗。
3.進(jìn)入到hadoop-maven-plugins目錄下，輸入mvn install，然后進(jìn)入hadoop-3.0.0-src目錄下，輸入mvn eclipse:eclipse –DskipTests，此過程會(huì)下載很多依賴，會(huì)很慢，若編譯成功出現(xiàn)如下。
四.將項(xiàng)目導(dǎo)入到Eclipse
打開Eclipse，按照下列步驟：import-->general-->Existing Projects into Workspace-->next-->select root directory-->選擇Hadoop-3.0.0-src文件-->finish即可。
不過導(dǎo)入進(jìn)來會(huì)有一些錯(cuò)誤，需要解決。。。
隨著全球經(jīng)濟(jì)的不斷發(fā)展，大數(shù)據(jù)時(shí)代早已悄悄到來，而Hadoop又是大數(shù)據(jù)環(huán)境的基礎(chǔ)，想入門大數(shù)據(jù)行業(yè)首先需要了解Hadoop的知識(shí)。2017年年初apache發(fā)行了Hadoop3.0，也意味著一直有一群人在對Hadoop不斷的做優(yōu)化，不僅如此，各個(gè)Hadoop的商業(yè)版本也有好多公司正在使用，這也印證了它的商業(yè)價(jià)值。
讀者可以通過閱讀“一文讀懂Hadoop”系列文章，對Hadoop技術(shù)有個(gè)全面的了解，它涵蓋了Hadoop官網(wǎng)的所有知識(shí)點(diǎn)，并且通俗易懂，英文不好的讀者完全可以通過閱讀此篇文章了解Hadoop。
本期獨(dú)家內(nèi)容“一文讀懂Hadoop”系列文章將根據(jù)先介紹Hadoop，繼而分別詳細(xì)介紹HDFS、MAPREDUCE、YARN的所有知識(shí)點(diǎn)的框架，分為四期內(nèi)容在近幾天推送。敬請關(guān)注后續(xù)內(nèi)容。
本期內(nèi)容為大家詳解HDFS，由于字?jǐn)?shù)限制，本文分為上下兩篇分別在頭條和二條推送。
1. HDFS優(yōu)缺點(diǎn)
1.1 優(yōu)點(diǎn)
1.1.1 高容錯(cuò)性
可以由數(shù)百或數(shù)千個(gè)服務(wù)器機(jī)器組成，每個(gè)服務(wù)器機(jī)器存儲(chǔ)文件系統(tǒng)數(shù)據(jù)的一部分；
數(shù)據(jù)自動(dòng)保存多個(gè)副本；
副本丟失后檢測故障快速，自動(dòng)恢復(fù)。
1.1.2 適合批處理
移動(dòng)計(jì)算而非數(shù)據(jù)；
數(shù)據(jù)位置暴露給計(jì)算框架；
數(shù)據(jù)訪問的高吞吐量；
運(yùn)行的應(yīng)用程序?qū)ζ鋽?shù)據(jù)集進(jìn)行流式訪問。
1.1.3 適合大數(shù)據(jù)處理
典型文件大小為千兆字節(jié)到太字節(jié)；
支持單個(gè)實(shí)例中的數(shù)千萬個(gè)文件；
10K+節(jié)點(diǎn)。
1.1.4 可構(gòu)建在廉價(jià)的機(jī)器上
通過多副本提高可靠性；
提供了容錯(cuò)與恢復(fù)機(jī)制。
1.1.5 跨異構(gòu)硬件和軟件平臺(tái)的可移植性強(qiáng)
輕松地從一個(gè)平臺(tái)移植到另一個(gè)平臺(tái)。
1.1.6 簡單一致性模型
應(yīng)用程序需要一次寫入多次讀取文件的訪問模型；
除了追加和截?cái)嘀猓恍枰囊褎?chuàng)建，寫入和關(guān)閉的文件；
簡化了數(shù)據(jù)一致性問題，并實(shí)現(xiàn)了高吞吐量數(shù)據(jù)訪問；
高度可配置，具有非常適合于許多安裝的默認(rèn)配置。大多數(shù)時(shí)候，只需要為非常大的集群調(diào)整配置。
1.2 缺點(diǎn)
1.2.1 不適合低延遲的數(shù)據(jù)訪問
HDFS設(shè)計(jì)更多的是批處理，而不是用戶交互使用。重點(diǎn)在于數(shù)據(jù)訪問的高吞吐量，而不是數(shù)據(jù)訪問的低延遲。
1.2.2 不適合小文件存取
占用NameNode大量內(nèi)存；
尋道時(shí)間超過讀取時(shí)間。
1.2.3 無法并發(fā)寫入、文件隨即修改
一個(gè)文件只能有一個(gè)寫者；
僅支持追加和截?cái)唷?/p>
2. 基本組成
2.1 Namenode
2.1.1 接受客戶端的讀寫服務(wù)
執(zhí)行文件系統(tǒng)命名空間操作，如打開，關(guān)閉和重命名文件和目錄。
2.1.2 管理文件系統(tǒng)命名空間
記錄對文件系統(tǒng)命名空間或其屬性的任何更改。
2.1.3 metadata組成
Metadata是存儲(chǔ)在Namenode上的元數(shù)據(jù)信息，它存儲(chǔ)到磁盤的文件名為：fsimage。并且有個(gè)叫edits的文件記錄對metadata的操作日志。總體來說，fsimage與edits文件記錄了Metadata中的權(quán)限信息和文件系統(tǒng)目錄樹、文件包含哪些塊、確定塊到DataNode的映射、Block存放在哪些DataNode上(由DataNode啟動(dòng)時(shí)上報(bào))。
NameNode將這些信息加載到內(nèi)存并進(jìn)行拼裝，就成為了一個(gè)完整的元數(shù)據(jù)信息。
2.1.4 文件系統(tǒng)命名空間
HDFS支持傳統(tǒng)的分層文件組織。用戶或應(yīng)用程序可以在這些目錄中創(chuàng)建目錄和存儲(chǔ)文件。文件系統(tǒng)命名空間層次結(jié)構(gòu)與大多數(shù)其他現(xiàn)有文件系統(tǒng)類似：可以創(chuàng)建和刪除文件，將文件從一個(gè)目錄移動(dòng)到另一個(gè)目錄，或重命名文件。HDFS支持用戶配額和訪問權(quán)限。但不支持硬鏈接或軟鏈接。
NameNode維護(hù)文件系統(tǒng)命名空間。對文件系統(tǒng)命名空間或其屬性的任何更改由NameNode記錄。應(yīng)用程序可以指定應(yīng)由HDFS維護(hù)的文件的副本數(shù)。文件的副本數(shù)稱為該文件的復(fù)制因子。此信息由NameNode存儲(chǔ)。
2.1.5 文件系統(tǒng)元數(shù)據(jù)的持久性
NameNode的metadata信息在啟動(dòng)后會(huì)加載到內(nèi)存，由于加載到內(nèi)存的數(shù)據(jù)很不安全，斷電后就沒有了，因此必須對內(nèi)存中存放的信息做持久化處理。
Namenode上保存著HDFS的命名空間。對于任何對文件系統(tǒng)元數(shù)據(jù)產(chǎn)生修改的操作，Namenode都會(huì)使用一種稱為Edits的事務(wù)日志記錄下來。例如，在HDFS中創(chuàng)建一個(gè)文件，Namenode就會(huì)在Edits中插入一條記錄來表示；同樣地，修改文件的副本系數(shù)也將往Edits插入一條記錄。Namenode在本地操作系統(tǒng)的文件系統(tǒng)中存儲(chǔ)這個(gè)Edits。整個(gè)文件系統(tǒng)的命名空間，包括數(shù)據(jù)塊到文件的映射、文件的屬性等，都存儲(chǔ)在一個(gè)稱為FsImage的文件中，這個(gè)文件也是放在Namenode所在的本地文件系統(tǒng)上。
Namenode在內(nèi)存中保存著整個(gè)文件系統(tǒng)的命名空間和文件數(shù)據(jù)塊映射(Blockmap)的映像。這個(gè)關(guān)鍵的元數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)得很緊湊，因而一個(gè)有4G內(nèi)存的Namenode足夠支撐大量的文件和目錄。當(dāng)Namenode啟動(dòng)時(shí)，它從硬盤中讀取Edits和FsImage，將所有Edits中的事務(wù)作用在內(nèi)存中的FsImage上，并將這個(gè)新版本的FsImage從內(nèi)存中保存到本地磁盤上，然后刪除舊的Edits，因?yàn)檫@個(gè)舊的Edits的事務(wù)都已經(jīng)作用在FsImage上了。這個(gè)過程稱為一個(gè)檢查點(diǎn)(checkpoint)。
Datanode將HDFS數(shù)據(jù)以文件的形式存儲(chǔ)在本地的文件系統(tǒng)中，它并不知道有關(guān)HDFS文件的信息。它把每個(gè)HDFS數(shù)據(jù)塊存儲(chǔ)在本地文件系統(tǒng)的一個(gè)單獨(dú)的文件中。Datanode并不在同一個(gè)目錄創(chuàng)建所有的文件，實(shí)際上，它用試探的方法來確定每個(gè)目錄的最佳文件數(shù)目，并且在適當(dāng)?shù)臅r(shí)候創(chuàng)建子目錄。在同一個(gè)目錄中創(chuàng)建所有的本地文件并不是最優(yōu)的選擇，這是因?yàn)楸镜匚募到y(tǒng)可能無法高效地在單個(gè)目錄中支持大量的文件。當(dāng)一個(gè)Datanode啟動(dòng)時(shí)，它會(huì)掃描本地文件系統(tǒng)，產(chǎn)生一個(gè)這些本地文件對應(yīng)的所有HDFS數(shù)據(jù)塊的列表，然后作為報(bào)告發(fā)送到Namenode，這個(gè)報(bào)告就是塊狀態(tài)報(bào)告。
2.2 SecondaryNameNode
它不是NameNode的備份，但可以作為NameNode的備份，當(dāng)因?yàn)閿嚯娀蚍?wù)器損壞的情況，可以用SecondNameNode中已合并的fsimage文件作為備份文件恢復(fù)到NameNode上，但是很有可能丟失掉在合并過程中新生成的edits信息。因此不是完全的備份。
由于NameNode僅在啟動(dòng)期間合并fsimage和edits文件，因此在繁忙的群集上，edits日志文件可能會(huì)隨時(shí)間變得非常大。較大編輯文件的另一個(gè)副作用是下一次重新啟動(dòng)NameNode需要更長時(shí)間。SecondNameNode的主要功能是幫助NameNode合并edits和fsimage文件，從而減少NameNode啟動(dòng)時(shí)間。
2.2.1 SNN執(zhí)行合并時(shí)機(jī)
根據(jù)配置文件配置的時(shí)間間隔fs.checkpoint.period默認(rèn)1小時(shí)；
dfs.namenode.checkpoint.txns，默認(rèn)設(shè)置為1百萬，也就是Edits中的事務(wù)條數(shù)達(dá)到1百萬就會(huì)觸發(fā)一次合并，即使未達(dá)到檢查點(diǎn)期間。
2.2.2 SNN合并流程
首先生成一個(gè)名叫edits.new的文件用于記錄合并過程中產(chǎn)生的日志信息；
當(dāng)觸發(fā)到某一時(shí)機(jī)時(shí)（時(shí)間間隔達(dá)到1小時(shí)或Edits中的事務(wù)條數(shù)達(dá)到1百萬）時(shí)SecondaryNamenode將edits文件、與fsimage文件從NameNode上讀取到SecondNamenode上；
將edits文件與fsimage進(jìn)行合并操作，合并成一個(gè)fsimage.ckpt文件；
將生成的合并后的文件fsimage.ckpt文件轉(zhuǎn)換到NameNode上；
將fsimage.ckpt在NameNode上變成fsimage文件替換NameNode上原有的fsimage文件，并將edits.new文件上變成edits文件替換NameNode上原有的edits文件。
SNN在hadoop2.x及以上版本在非高可用狀態(tài)時(shí)還存在，但是在hadoop2.x及以上版本高可用狀態(tài)下SNN就不存在了，在hadoop2.x及以上版本在高可用狀態(tài)下，處于standby狀態(tài)的NameNode來做合并操作。
2.3 DataNode
管理附加到它們運(yùn)行的節(jié)點(diǎn)的存儲(chǔ)，并允許用戶數(shù)據(jù)存儲(chǔ)在文件中；
在內(nèi)部，文件被分割成一個(gè)或多個(gè)塊（Block），并且這些塊被存儲(chǔ)在一組DataNode中；
負(fù)責(zé)提供來自文件系統(tǒng)客戶端的讀取和寫入請求；
執(zhí)行塊創(chuàng)建，刪除；
啟動(dòng)DN進(jìn)程的時(shí)候會(huì)向NN匯報(bào)Block信息；
通過向NN發(fā)送心跳保持與其聯(lián)系（3秒一次），如果NN10分鐘沒有收到DN的心跳，則認(rèn)為DN已經(jīng)丟失，并且復(fù)制其上的Block到其他的DN上。
2.3.1 HDFS存儲(chǔ)單元（block）
2.3.1.1文件被切分成固定大小的數(shù)據(jù)塊
默認(rèn)數(shù)據(jù)塊大小為64MB（hadoop1.x）、128MB（hadoop2.x）、256MB(hadoop3.x)，可配置；
若文件大小不到一個(gè)塊大小，則單獨(dú)存成一個(gè)block，block塊是一個(gè)邏輯意義上的概念。文件大小是多少，就占多少空間。
2.3.1.2 一個(gè)文件存儲(chǔ)方式
按大小被切分成不同的block，存儲(chǔ)到不同的節(jié)點(diǎn)上；
默認(rèn)情況下，每個(gè)block都有3個(gè)副本；
block大小與副本數(shù)通過client端上傳文件時(shí)設(shè)置，文件上傳成功后副本數(shù)可以變更，block size不可變更。
2.3.1.3 設(shè)計(jì)思想
將大文件拆分成256MB的block塊，每個(gè)block塊分別隨機(jī)存放在不同的節(jié)點(diǎn)上，從而避免了數(shù)據(jù)傾斜的問題，但是在開發(fā)過程中，如果算法、程序?qū)懙牟缓茫瑯右矔?huì)出現(xiàn)數(shù)據(jù)傾斜的問題。
2.3.2 數(shù)據(jù)復(fù)制
2.3.2.1 數(shù)據(jù)復(fù)制概述
HDFS被設(shè)計(jì)成能夠在一個(gè)大集群中跨機(jī)器可靠地存儲(chǔ)超大文件。它將每個(gè)文件存儲(chǔ)成一系列的數(shù)據(jù)塊，除了最后一個(gè)，所有的數(shù)據(jù)塊都是同樣大小的。為了容錯(cuò)，文件的所有數(shù)據(jù)塊都會(huì)有副本。每個(gè)文件的數(shù)據(jù)塊大小和副本系數(shù)都是可配置的。應(yīng)用程序可以指定某個(gè)文件的副本數(shù)目。副本系數(shù)可以在文件創(chuàng)建的時(shí)候指定，也可以在之后改變。HDFS中的文件都是一次性寫入的，并且嚴(yán)格要求在任何時(shí)候只能有一個(gè)寫入者。
Namenode全權(quán)管理數(shù)據(jù)塊的復(fù)制，它周期性地從集群中的每個(gè)Datanode接收心跳信號(hào)和塊狀態(tài)報(bào)告(Blockreport)。接收到心跳信號(hào)意味著該Datanode節(jié)點(diǎn)工作正常。塊狀態(tài)報(bào)告包含了一個(gè)該Datanode上所有數(shù)據(jù)塊的列表。
HDFS數(shù)據(jù)節(jié)點(diǎn)
2.3.2.2 Block的副本放置策略
副本的存放是HDFS可靠性和性能的關(guān)鍵。優(yōu)化的副本存放策略是HDFS區(qū)分于其他大部分分布式文件系統(tǒng)的重要特性。這種特性需要做大量的調(diào)優(yōu)，并需要經(jīng)驗(yàn)的積累。HDFS采用一種稱為機(jī)架感知(rack-aware)的策略來改進(jìn)數(shù)據(jù)的可靠性、可用性和網(wǎng)絡(luò)帶寬的利用率。目前實(shí)現(xiàn)的副本存放策略只是在這個(gè)方向上的第一步。實(shí)現(xiàn)這個(gè)策略的短期目標(biāo)是驗(yàn)證它在生產(chǎn)環(huán)境下的有效性，觀察它的行為，為實(shí)現(xiàn)更先進(jìn)的策略打下測試和研究的基礎(chǔ)。
大型HDFS實(shí)例一般運(yùn)行在跨越多個(gè)機(jī)架的計(jì)算機(jī)組成的集群上，不同機(jī)架上的兩臺(tái)機(jī)器之間的通訊需要經(jīng)過交換機(jī)。在大多數(shù)情況下，同一個(gè)機(jī)架內(nèi)的兩臺(tái)機(jī)器間的帶寬會(huì)比不同機(jī)架的兩臺(tái)機(jī)器間的帶寬大。
通過一個(gè)機(jī)架感知的過程，Namenode可以確定每個(gè)Datanode所屬的機(jī)架id。一個(gè)簡單但沒有優(yōu)化的策略就是將副本存放在不同的機(jī)架上。這樣可以有效防止當(dāng)整個(gè)機(jī)架失效時(shí)數(shù)據(jù)的丟失，并且允許讀數(shù)據(jù)的時(shí)候充分利用多個(gè)機(jī)架的帶寬。這種策略設(shè)置可以將副本均勻分布在集群中，有利于當(dāng)組件失效情況下的負(fù)載均衡。但是，因?yàn)檫@種策略的一個(gè)寫操作需要傳輸數(shù)據(jù)塊到多個(gè)機(jī)架，這增加了寫的代價(jià)。
在大多數(shù)情況下，副本系數(shù)是3，HDFS的存放策略是將一個(gè)副本存放在本地機(jī)架的節(jié)點(diǎn)上，一個(gè)副本放在同一機(jī)架的另一個(gè)節(jié)點(diǎn)上，最后一個(gè)副本放在不同機(jī)架的節(jié)點(diǎn)上。這種策略減少了機(jī)架間的數(shù)據(jù)傳輸，這就提高了寫操作的效率。機(jī)架的錯(cuò)誤遠(yuǎn)遠(yuǎn)比節(jié)點(diǎn)的錯(cuò)誤少，所以這個(gè)策略不會(huì)影響到數(shù)據(jù)的可靠性和可用性。于此同時(shí)，因?yàn)閿?shù)據(jù)塊只放在兩個(gè)（不是三個(gè)）不同的機(jī)架上，所以此策略減少了讀取數(shù)據(jù)時(shí)需要的網(wǎng)絡(luò)傳輸總帶寬。在這種策略下，副本并不是均勻分布在不同的機(jī)架上。三分之一的副本在一個(gè)節(jié)點(diǎn)上，三分之二的副本在一個(gè)機(jī)架上，其他副本均勻分布在剩下的機(jī)架中，這一策略在不損害數(shù)據(jù)可靠性和讀取性能的情況下改進(jìn)了寫的性能。
2.3.2.3 副本選擇
為了降低整體的帶寬消耗和讀取延時(shí)，HDFS會(huì)盡量讓讀取程序讀取離它最近的副本。如果在讀取程序的同一個(gè)機(jī)架上有一個(gè)副本，那么就讀取該副本。如果一個(gè)HDFS集群跨越多個(gè)數(shù)據(jù)中心，那么客戶端也將首先讀本地?cái)?shù)據(jù)中心的副本。
2.3.2.4 安全模式
NameNode在啟動(dòng)的時(shí)候會(huì)進(jìn)入一個(gè)稱為安全模式的特殊狀態(tài)，它首先將映像文件（fsimage）載入內(nèi)存，并執(zhí)行編輯日志（edits）中的各項(xiàng)操作；
一旦在內(nèi)存中成功建立文件系統(tǒng)元數(shù)據(jù)映射，則創(chuàng)建一個(gè)新的fsimage文件（這個(gè)操作不需要SecondNameNode來做）與一個(gè)空的編輯日志；
此刻namenode運(yùn)行在安全模式，即namenode的文件系統(tǒng)對于客戶端來說是只讀的，顯示目錄、顯示文件內(nèi)容等，寫、刪除、重命名都會(huì)失敗；
在此階段namenode搜集各個(gè)datanode的報(bào)告，當(dāng)數(shù)據(jù)塊達(dá)到最小副本數(shù)以上時(shí)，會(huì)被認(rèn)為是“安全”的，在一定比例的數(shù)據(jù)塊被認(rèn)為是安全的以后（可設(shè)置），再過若干時(shí)間，安全模式結(jié)束；
當(dāng)檢測到副本數(shù)不足數(shù)據(jù)塊時(shí)，該塊會(huì)被復(fù)制，直到達(dá)到最小副本數(shù)，系統(tǒng)中數(shù)據(jù)塊的位置并不是由namenode維護(hù)的，而是以塊列表形式存儲(chǔ)在datanode中。
2.4 數(shù)據(jù)組織
2.4.1 數(shù)據(jù)塊
HDFS被設(shè)計(jì)成支持大文件，適用HDFS的是那些需要處理大規(guī)模的數(shù)據(jù)集的應(yīng)用。這些應(yīng)用都是只寫入數(shù)據(jù)一次，但卻讀取一次或多次，并且讀取速度應(yīng)能滿足流式讀取的需要。HDFS支持文件的“一次寫入多次讀取”語義。一個(gè)典型的數(shù)據(jù)塊大小是256MB。因而，HDFS中的文件總是按照256M被切分成不同的塊，每個(gè)塊盡可能地存儲(chǔ)于不同的Datanode中。
2.4.2 分段
客戶端創(chuàng)建文件的請求其實(shí)并沒有立即發(fā)送給Namenode，事實(shí)上，在剛開始階段HDFS客戶端會(huì)先將文件數(shù)據(jù)緩存到本地的一個(gè)臨時(shí)文件。應(yīng)用程序的寫操作被透明地重定向到這個(gè)臨時(shí)文件。當(dāng)這個(gè)臨時(shí)文件累積的數(shù)據(jù)量超過一個(gè)數(shù)據(jù)塊的大小，客戶端才會(huì)聯(lián)系Namenode。Namenode將文件名插入文件系統(tǒng)的層次結(jié)構(gòu)中，并且分配一個(gè)數(shù)據(jù)塊給它。然后返回Datanode的標(biāo)識(shí)符和目標(biāo)數(shù)據(jù)塊給客戶端。接著客戶端將這塊數(shù)據(jù)從本地臨時(shí)文件上傳到指定的Datanode上。當(dāng)文件關(guān)閉時(shí)，在臨時(shí)文件中剩余的沒有上傳的數(shù)據(jù)也會(huì)傳輸?shù)街付ǖ腄atanode上。然后客戶端告訴Namenode文件已經(jīng)關(guān)閉。此時(shí)Namenode才將文件創(chuàng)建操作提交到日志里進(jìn)行存儲(chǔ)。如果Namenode在文件關(guān)閉前宕機(jī)了，則該文件將丟失。
上述方法是對在HDFS上運(yùn)行的目標(biāo)應(yīng)用進(jìn)行認(rèn)真考慮后得到的結(jié)果。這些應(yīng)用需要進(jìn)行文件的流式寫入。如果不采用客戶端緩存，由于網(wǎng)絡(luò)速度和網(wǎng)絡(luò)堵塞會(huì)對吞估量造成比較大的影響。這種方法并不是沒有先例的，早期的文件系統(tǒng)，比如AFS，就用客戶端緩存來提高性能。為了達(dá)到更高的數(shù)據(jù)上傳效率，已經(jīng)放松了POSIX標(biāo)準(zhǔn)的要求。
2.4.3 管道復(fù)制
當(dāng)客戶端向HDFS文件寫入數(shù)據(jù)的時(shí)候，一開始是寫到本地臨時(shí)文件中。假設(shè)該文件的副本系數(shù)設(shè)置為3，當(dāng)本地臨時(shí)文件累積到一個(gè)數(shù)據(jù)塊的大小時(shí)，客戶端會(huì)從Namenode獲取一個(gè)Datanode列表用于存放副本。然后客戶端開始向第一個(gè)Datanode傳輸數(shù)據(jù)，第一個(gè)Datanode一小部分一小部分(4 KB)地接收數(shù)據(jù)，將每一部分寫入本地倉庫，并同時(shí)傳輸該部分到列表中第二個(gè)Datanode節(jié)點(diǎn)。第二個(gè)Datanode也是這樣，一小部分一小部分地接收數(shù)據(jù)，寫入本地倉庫，并同時(shí)傳給第三個(gè)Datanode。最后，第三個(gè)Datanode接收數(shù)據(jù)并存儲(chǔ)在本地。因此，Datanode能流水線式地從前一個(gè)節(jié)點(diǎn)接收數(shù)據(jù)，并在同時(shí)轉(zhuǎn)發(fā)給下一個(gè)節(jié)點(diǎn)，數(shù)據(jù)以流水線的方式從前一個(gè)Datanode復(fù)制到下一個(gè)。
3. 讀寫流程
3.1 HDFS讀流程
首先HDFS的客戶端通過DistributedFileSystem；
通過DistributedFileSystem來對NameNode進(jìn)行請求，同時(shí)將用戶信息及文件名的信息等發(fā)送給NameNode，并返回給DistributedFileSystem該文件包含的block所在的DataNode位置；
HDFS客戶端通過FSDataInputStream按順序去讀取DataNode中的block信息（它會(huì)選擇負(fù)載最低的或離客戶端最近的一臺(tái)DataNode去讀block）；
FSDataInputStream按順序一個(gè)一個(gè)的讀，直到所有的block都讀取完畢；
當(dāng)讀取完畢后會(huì)將FSDataInputStream關(guān)閉。
3.2 HDFS寫流程
首先HDFS的客戶端通過Distributed FileSystem（HDFS中API里的一個(gè)對象）；
通過Distributed FileSystem發(fā)送客戶端的請求給NameNode（NameNode主要是接受客戶端請求）并且會(huì)帶著文件要保存的位置、文件名、操作的用戶名等信息一起發(fā)送給NameNode；
NameNode會(huì)給客戶端返回了一個(gè)FSDataOutputStream，同時(shí)也會(huì)返回文件要寫入哪些DataNode上（負(fù)載較低的）；
通過FSDataOutputStream進(jìn)行寫操作，在寫之前就做文件的拆分，將文件拆分成多個(gè)Block，第一個(gè)寫操作寫在負(fù)載比較低的DataNode上，并將這個(gè)block復(fù)制到其他的DataNode上；
當(dāng)所有的block副本復(fù)制完成后會(huì)反饋給FSDataOutputStream；
當(dāng)所有的block副本全都復(fù)制完成，就可以將FSDataOutputStream流關(guān)閉；
通過Distributed FileSystem更新NameNode中的源數(shù)據(jù)信息。
4. 架構(gòu)
4.1 NameNode和DataNode
HDFS采用master/worker架構(gòu)。一個(gè)HDFS集群是由一個(gè)Namenode和一定數(shù)目的Datanodes組成。Namenode是一個(gè)中心服務(wù)器，負(fù)責(zé)管理文件系統(tǒng)的命名空間(namespace)以及客戶端對文件的訪問。集群中的Datanode一般是一個(gè)節(jié)點(diǎn)一個(gè)，負(fù)責(zé)管理它所在節(jié)點(diǎn)上的存儲(chǔ)。HDFS暴露了文件系統(tǒng)的命名空間，用戶能夠以文件的形式在上面存儲(chǔ)數(shù)據(jù)。從內(nèi)部看，一個(gè)文件其實(shí)被分成一個(gè)或多個(gè)數(shù)據(jù)塊，這些塊存儲(chǔ)在一組Datanode上。Namenode執(zhí)行文件系統(tǒng)的命名空間操作，比如打開、關(guān)閉、重命名文件或目錄。它也負(fù)責(zé)確定數(shù)據(jù)塊到具體Datanode節(jié)點(diǎn)的映射。Datanode負(fù)責(zé)處理文件系統(tǒng)客戶端的讀寫請求。在Namenode的統(tǒng)一調(diào)度下進(jìn)行數(shù)據(jù)塊的創(chuàng)建、刪除和復(fù)制。
HDFS架構(gòu)
Namenode和Datanode被設(shè)計(jì)成可以在普通的商用機(jī)器上運(yùn)行。這些機(jī)器一般運(yùn)行著GNU/Linux操作系統(tǒng)(OS)。HDFS采用Java語言開發(fā)，因此任何支持Java的機(jī)器都可以部署Namenode或Datanode。由于采用了可移植性極強(qiáng)的Java語言，使得HDFS可以部署到多種類型的機(jī)器上。一個(gè)典型的部署場景是一臺(tái)機(jī)器上只運(yùn)行一個(gè)Namenode實(shí)例，而集群中的其它機(jī)器分別運(yùn)行一個(gè)Datanode實(shí)例。這種架構(gòu)也可以在一臺(tái)機(jī)器上運(yùn)行多個(gè)Datanode，但這樣的情況比較少見。
集群中單一Namenode的結(jié)構(gòu)大大簡化了系統(tǒng)的架構(gòu)。Namenode是所有HDFS元數(shù)據(jù)的管理者，用戶數(shù)據(jù)永遠(yuǎn)不會(huì)流過Namenode。
4.1.1 通信協(xié)議
所有的HDFS通訊協(xié)議都是建立在TCP/IP協(xié)議之上。客戶端通過一個(gè)可配置的TCP端口連接到Namenode，通過ClientProtocol協(xié)議與Namenode交互。而Datanode使用DatanodeProtocol協(xié)議與Namenode交互。一個(gè)遠(yuǎn)程過程調(diào)用(RPC)模型被抽象出來封裝ClientProtocol和Datanodeprotocol協(xié)議。在設(shè)計(jì)上，Namenode不會(huì)主動(dòng)發(fā)起RPC，而是響應(yīng)來自客戶端或 Datanode 的RPC請求。
4.2 基礎(chǔ)架構(gòu)
Hadoop分布式文件系統(tǒng)(HDFS)被設(shè)計(jì)成適合運(yùn)行在通用硬件上的分布式文件系統(tǒng)。它和現(xiàn)有的分布式文件系統(tǒng)有很多共同點(diǎn)。但同時(shí)，它和其他的分布式文件系統(tǒng)的區(qū)別也是很明顯的。HDFS是一個(gè)高度容錯(cuò)性的系統(tǒng)，適合部署在廉價(jià)的機(jī)器上。HDFS能提供高吞吐量的數(shù)據(jù)訪問，非常適合大規(guī)模數(shù)據(jù)集上的應(yīng)用。HDFS放寬了一部分POSIX約束，來實(shí)現(xiàn)流式讀取文件系統(tǒng)數(shù)據(jù)的目的。HDFS在最開始是作為Apache Nutch搜索引擎項(xiàng)目的基礎(chǔ)架構(gòu)而開發(fā)的。HDFS是Apache Hadoop Core項(xiàng)目的一部分。
客戶端的請求全部落到了NameNode上；
元數(shù)據(jù)信息存在NameNode；
在Hadoop集群中有且只有一個(gè)處于Active狀態(tài)的NameNode；
SecondaryNameNode不是NameNode的備份節(jié)點(diǎn)或從節(jié)點(diǎn)（確切的說它只能備份NameNode的部分內(nèi)容，而不是全部）；
NameNode與DataNode之間有心跳機(jī)制，從而NameNode可以知道DataNode的運(yùn)行情況與負(fù)載情況。
4.2.1 健壯性
HDFS的主要目標(biāo)就是即使在出錯(cuò)的情況下也要保證數(shù)據(jù)存儲(chǔ)的可靠性。常見的三種出錯(cuò)情況是：Namenode出錯(cuò), Datanode出錯(cuò)和網(wǎng)絡(luò)分區(qū)。
4.2.1.1 磁盤數(shù)據(jù)錯(cuò)誤，心跳檢測和重新復(fù)制
每個(gè)Datanode節(jié)點(diǎn)周期性地向Namenode發(fā)送心跳信號(hào)。網(wǎng)絡(luò)原因有可能導(dǎo)致一部分Datanode跟Namenode失去聯(lián)系。Namenode通過心跳信號(hào)的缺失來檢測這一情況，并將這些近期不再發(fā)送心跳信號(hào)的Datanode標(biāo)記為宕機(jī)，不會(huì)再將新的IO請求發(fā)給它們。任何存儲(chǔ)在宕機(jī)Datanode上的數(shù)據(jù)將不再有效。Datanode的宕機(jī)可能會(huì)引起一些數(shù)據(jù)塊的副本系數(shù)低于指定值，Namenode不斷地檢測這些需要復(fù)制的數(shù)據(jù)塊，一旦發(fā)現(xiàn)就啟動(dòng)復(fù)制操作。在下列情況下，可能需要重新復(fù)制：某個(gè)Datanode節(jié)點(diǎn)失效、某個(gè)副本遭到損壞、Datanode上的硬盤錯(cuò)誤或者文件的副本系數(shù)增大。
4.2.1.1.1 DataNode熱插拔驅(qū)動(dòng)器
Datanode支持熱插拔驅(qū)動(dòng)器。可以添加或替換HDFS數(shù)據(jù)卷，而不必不關(guān)閉DataNode。下面簡要介紹典型的熱插拔驅(qū)動(dòng)程序：
如果存在新的存儲(chǔ)目錄，則應(yīng)格式化它們并適當(dāng)?shù)匮b載它們；
將數(shù)據(jù)卷目錄更新到DataNode的配置dfs.datanode.data.dir中；
通過運(yùn)行dfsadmin -reconfig datanode HOST：PORT start來使我們配置的目錄生效，并且可以使用dfsadmin -reconfig datanode HOST：PORT status查詢重新配置任務(wù)的運(yùn)行狀態(tài)；
一旦重新配置任務(wù)完成，我們就可以安全地卸載、刪除數(shù)據(jù)卷目錄并物理刪除磁盤。
4.2.1.2 負(fù)載均衡
HDFS的架構(gòu)支持?jǐn)?shù)據(jù)均衡策略。如果某個(gè)Datanode節(jié)點(diǎn)上的空閑空間低于特定的臨界點(diǎn)，按照均衡策略系統(tǒng)就會(huì)自動(dòng)地將數(shù)據(jù)從這個(gè)Datanode移動(dòng)到其他空閑的Datanode。在對特定文件的突然高需求的情況下，此方案可以動(dòng)態(tài)地創(chuàng)建附加的副本并重新平衡群集中的其他數(shù)據(jù)。
4.2.1.2.1 平衡器
HDFS的數(shù)據(jù)也許并不是非常均勻的分布在各個(gè)DataNode中。一個(gè)常見的原因是在現(xiàn)有的集群上經(jīng)常會(huì)增添新的DataNode節(jié)點(diǎn)。當(dāng)新增一個(gè)數(shù)據(jù)塊（一個(gè)文件的數(shù)據(jù)被保存在一系列的塊中）時(shí)，NameNode在選擇DataNode接收這個(gè)數(shù)據(jù)塊之前，會(huì)考慮到很多因素。其中的一些考慮的是：
將數(shù)據(jù)塊的一個(gè)副本放在正在寫這個(gè)數(shù)據(jù)塊的節(jié)點(diǎn)上；
盡量將數(shù)據(jù)塊的不同副本分布在不同的機(jī)架上，這樣集群可在完全失去某一機(jī)架的情況下還能存活；
一個(gè)副本通常被放置在和寫文件的節(jié)點(diǎn)同一機(jī)架的某個(gè)節(jié)點(diǎn)上，這樣可以減少跨越機(jī)架的網(wǎng)絡(luò)I/O；
盡量均勻地將HDFS數(shù)據(jù)分布在集群的DataNode中。
4.2.1.2.2 磁盤平衡器
Diskbalancer是一個(gè)命令行工具，可以將數(shù)據(jù)均勻分布在數(shù)據(jù)節(jié)點(diǎn)的所有磁盤上。此工具不同于平衡器，它負(fù)責(zé)群集范圍的數(shù)據(jù)平衡。由于幾個(gè)原因，數(shù)據(jù)可能在節(jié)點(diǎn)上的磁盤之間具有不均勻分布。這可能是由于大量的寫入和刪除或由于更換磁盤而發(fā)生的。該工具針對給定的數(shù)據(jù)編碼進(jìn)行操作，并將塊從一個(gè)磁盤移動(dòng)到另一個(gè)磁盤。
4.2.1.2.2.1 架構(gòu)
磁盤平衡器通過創(chuàng)建計(jì)劃進(jìn)行操作，然后在數(shù)據(jù)節(jié)點(diǎn)上執(zhí)行該計(jì)劃。一個(gè)計(jì)劃是一組描述兩個(gè)磁盤之間移動(dòng)數(shù)據(jù)的語句。一個(gè)計(jì)劃由多個(gè)步驟組成。移動(dòng)步驟具有源磁盤，目標(biāo)磁盤和要移動(dòng)的字節(jié)數(shù)。可以針對操作數(shù)據(jù)節(jié)點(diǎn)執(zhí)行計(jì)劃。
一共包含3個(gè)階段,Discover(發(fā)現(xiàn))到Plan(計(jì)劃),再從Plan(計(jì)劃)到Execute(執(zhí)行):
4.2.1.2.2.1.1 Discover
發(fā)現(xiàn)階段做的事情實(shí)際上就是通過計(jì)算各個(gè)節(jié)點(diǎn)內(nèi)的磁盤使用情況,然后得出需要數(shù)據(jù)平衡的磁盤列表.這里會(huì)通過Volume Data Density磁盤使用密度的概念作為一個(gè)評判的標(biāo)準(zhǔn),這個(gè)標(biāo)準(zhǔn)值將會(huì)以節(jié)點(diǎn)總使用率作為比較值.舉個(gè)例子,如果一個(gè)節(jié)點(diǎn),總使用率為75%,就是0.75,其中A盤使用率0.5(50%),那么A盤的volumeDataDensity密度值就等于0.75-0.5=0.25.同理,如果超出的話,則密度值將會(huì)為負(fù)數(shù).于是我們可以用節(jié)點(diǎn)內(nèi)各個(gè)盤的volumeDataDensity的絕對值來判斷此節(jié)點(diǎn)內(nèi)磁盤間數(shù)據(jù)的平衡情況,如果總的絕對值的和越大,說明數(shù)據(jù)越不平衡,這有點(diǎn)類似于方差的概念.Discover階段將會(huì)用到如下的連接器對象:
DBNameNodeConnector
JsonConnector
NullConnector
其中第一個(gè)對象會(huì)調(diào)用到Balancer包下NameNodeConnector對象,以此來讀取集群節(jié)點(diǎn),磁盤數(shù)據(jù)情況。
4.2.1.2.2.1.2 Plan
拿到上一階段的匯報(bào)結(jié)果數(shù)據(jù)之后,將會(huì)進(jìn)行執(zhí)行計(jì)劃的生成.Plan并不是一個(gè)最小的執(zhí)行單元,它的內(nèi)部由各個(gè)Step組成.Step中會(huì)指定好源、目標(biāo)磁盤.這里的磁盤對象是一層經(jīng)過包裝的對象:DiskBalancerVolume,并不是原來的FsVolume.這里順便提一下DiskBalancer中對磁盤節(jié)點(diǎn)等概念的轉(zhuǎn)化:
DiskBalancerCluster.通過此對象可以讀取到集群中的節(jié)點(diǎn)信息,這里的節(jié)點(diǎn)信息以DiskBalancerDataNode的方式所呈現(xiàn)；
DiskBalancerDataNode.此對象代表的是一個(gè)包裝好后的DataNode；
DiskBalancerVolume和DiskBalancerVolumeSet.DataNode磁盤對象以及磁盤對象集合.DiskBalancerVolumeSet內(nèi)的磁盤存儲(chǔ)目錄類型需要是同種StorageType。
4.2.1.2.2.1.3 Execute
最后一部分是執(zhí)行階段,所有的plan計(jì)劃生成好了之后,就到了執(zhí)行階段.這些計(jì)劃會(huì)被提交到各自的DataNode上,然后在DiskBalancer類中進(jìn)行執(zhí)行.DiskBalancer類中有專門的類對象來做磁盤間數(shù)據(jù)平衡的工作,這個(gè)類名稱叫做DiskBalancerMover.在磁盤間數(shù)據(jù)平衡的過程中,高使用率的磁盤會(huì)移動(dòng)數(shù)據(jù)塊到相對低使用率的磁盤,等到滿足一定閾值關(guān)系的情況下時(shí),DiskBalancer會(huì)漸漸地退出.在DiskBalancer的執(zhí)行階段,有以下幾點(diǎn)需要注意：
帶寬的限制.DiskBalancer中同樣可以支持帶寬的限制,默認(rèn)是10M,通過配置dfs.disk.balancer.max.disk.throughputInMBperSec進(jìn)行控制；
失敗次數(shù)的限制.DiskBalancer中會(huì)存在失敗次數(shù)的控制.在拷貝block數(shù)據(jù)塊的時(shí)候,出現(xiàn)IOException異常,會(huì)進(jìn)行失敗次數(shù)的累加計(jì)數(shù),如果超出最大容忍值,DiskBalancer也會(huì)退出；
數(shù)據(jù)平衡閾值控制.DiskBalancer中可以提供一個(gè)磁盤間數(shù)據(jù)的平衡閾值,以此作為是否需要繼續(xù)平衡數(shù)據(jù)的標(biāo)準(zhǔn),配置項(xiàng)為dfs.disk.balancer.block.tolerance.percent。
4.2.1.3 數(shù)據(jù)完整性
從某個(gè)Datanode獲取的數(shù)據(jù)塊有可能是損壞的，損壞可能是由Datanode的存儲(chǔ)設(shè)備錯(cuò)誤、網(wǎng)絡(luò)錯(cuò)誤或者軟件bug造成的。HDFS客戶端軟件實(shí)現(xiàn)了對HDFS文件內(nèi)容的校驗(yàn)和(checksum)檢查。當(dāng)客戶端創(chuàng)建一個(gè)新的HDFS文件，會(huì)計(jì)算這個(gè)文件每個(gè)數(shù)據(jù)塊的校驗(yàn)和，并將校驗(yàn)和作為一個(gè)單獨(dú)的隱藏文件保存在同一個(gè)HDFS名字空間下。當(dāng)客戶端獲取文件內(nèi)容后，它會(huì)檢驗(yàn)從Datanode獲取的數(shù)據(jù)跟相應(yīng)的校驗(yàn)和文件中的校驗(yàn)和是否匹配，如果不匹配，客戶端可以選擇從其他Datanode獲取該數(shù)據(jù)塊的副本。
4.2.1.3.1 回收站機(jī)制
4.2.1.3.1.1 文件的刪除和恢復(fù)
如果啟用了回收站功能，F(xiàn)S Shell刪除的文件不會(huì)立即從HDFS中刪除。而是將其移動(dòng)到回收目錄（每個(gè)用戶在/user /<username>/.Trash下都有自己的回收目錄）。只要文件保留在回收站中，文件就可以快速恢復(fù)。
最近刪除的文件移動(dòng)到當(dāng)前回收目錄（/user/<username>/.Trash/Current），并在可配置的時(shí)間間隔內(nèi)，HDFS創(chuàng)建對/user/<username>/.Trash/<date>目錄下的一個(gè)檢查點(diǎn)，并在過期后刪除舊檢查點(diǎn)。
當(dāng)文件在回收站期滿之后，NameNode將從HDFS命名空間中刪除該文件。刪除文件會(huì)導(dǎo)致與該文件關(guān)聯(lián)的塊被釋放。需要說明的是，文件被用戶刪除的時(shí)間和對應(yīng)的釋放空間的時(shí)間之間有一個(gè)明顯的時(shí)間延遲。
4.2.1.3.1.2 減少副本
當(dāng)文件的副本因子減小時(shí)，NameNode選擇可以刪除的多余副本。下一個(gè)心跳將此信息傳輸?shù)紻ataNode。DataNode然后刪除相應(yīng)的塊并且釋放對應(yīng)的空間。同樣，在設(shè)置副本因子完成和集群中出現(xiàn)新的空間之間有個(gè)時(shí)間延遲。
4.2.1.4 元數(shù)據(jù)磁盤錯(cuò)誤
FsImage和Edits是HDFS的核心數(shù)據(jù)結(jié)構(gòu)。如果這些文件損壞了，整個(gè)HDFS實(shí)例都將失效。因而，Namenode可以配置成支持維護(hù)多個(gè)FsImage和Edits的副本。任何對FsImage或者Edits的修改，都將同步到它們的副本上。這種多副本的同步操作可能會(huì)降低Namenode每秒處理的命名空間事務(wù)數(shù)量。然而這個(gè)代價(jià)是可以接受的，因?yàn)榧词笻DFS的應(yīng)用是數(shù)據(jù)密集型的，它們的元數(shù)據(jù)信息的量也不會(huì)很大。當(dāng)Namenode重啟的時(shí)候，它會(huì)選取最近的完整的FsImage和Edits來使用。
4.2.1.4.1 檢查點(diǎn)節(jié)點(diǎn)
NameNode采用兩個(gè)文件來保存命名空間的信息：fsimage，它是最新的已執(zhí)行檢查點(diǎn)的命名空間的信息：edits，它是執(zhí)行檢查點(diǎn)后命名空間變化的日志文件。當(dāng)NameNode啟動(dòng)時(shí)，fsimage和edits合并，提供一個(gè)最新的文件系統(tǒng)的metadata，然后NameNode將新的HDFS狀態(tài)寫入fsimage，并開始一個(gè)新的edits日志。
Checkpoint節(jié)點(diǎn)周期性地創(chuàng)建命名空間的檢查點(diǎn)。它從NameNode下載fsimage和edits，在本地合并它們，并將其發(fā)回給活動(dòng)的NameNode。Checkpoint節(jié)點(diǎn)通常與NameNode不在同一臺(tái)機(jī)器上，因?yàn)樗鼈冇型瑯拥膬?nèi)存要求。Checkpoint節(jié)點(diǎn)由配置文件中的bin/hdfs namenode –checkpoint來啟動(dòng)。
Checkpoint(或Backup)節(jié)點(diǎn)的位置以及附帶的web接口由dfs.namenode.backup.address anddfs.namenode.backup.http-address參數(shù)指定。
Checkpoint進(jìn)程的運(yùn)行受兩個(gè)配置參數(shù)控制：
dfs.namenode.checkpoint.period，兩次連續(xù)的檢查點(diǎn)之間的最大的時(shí)間間隔，缺省值是1小時(shí)；
dfs.namenode.checkpoint.txns，最大的沒有執(zhí)行檢查點(diǎn)的事務(wù)數(shù)目，默認(rèn)設(shè)置為1百萬，也就是Edits中的事務(wù)條數(shù)達(dá)到1百萬就會(huì)觸發(fā)一次合并，即使未達(dá)到檢查點(diǎn)期間；
Checkpoint節(jié)點(diǎn)上保存的最新的檢查點(diǎn)，其目錄結(jié)構(gòu)與NameNode上一樣，這樣，如果需要，NameNode總是可以讀取這上面的已執(zhí)行檢查點(diǎn)的文件映像。多個(gè)Checkpoint節(jié)點(diǎn)可以在集群的配置文件中指定。
4.2.1.4.2 備份節(jié)點(diǎn)
Backup節(jié)點(diǎn)與Checkpoint節(jié)點(diǎn)提供同樣的執(zhí)行檢查點(diǎn)功能，只不過它還在內(nèi)存中保存一份最新的命名空間的的拷貝，該拷貝與NameNode中的保持同步。除了接收NameNode中發(fā)送的edits并把它保存到磁盤之外，Backup還將edits用到自己的內(nèi)存中，因而創(chuàng)建出一份命名空間的備份。
因?yàn)锽ackup節(jié)點(diǎn)在內(nèi)存中保持有最新的命名空間的狀態(tài)，因此它不需要從NameNode下載fsimage和edits文件來創(chuàng)建一個(gè)檢查點(diǎn)，而這是Checkpoint節(jié)點(diǎn)或備用NameNode所必需的步驟。Backup節(jié)點(diǎn)的檢查點(diǎn)進(jìn)程更高效，因?yàn)樗恍枰獙⒚臻g信息保存到本地的fsimage文件并重置edits就可以了。
由于Backup節(jié)點(diǎn)內(nèi)存中維護(hù)了一份命名空間的拷貝，它的內(nèi)存要求與NameNode一致。NameNode同一時(shí)刻只支持一個(gè)Backup節(jié)點(diǎn)。如果Backup在用，則不能注冊Checkpont節(jié)點(diǎn)。
Backup節(jié)點(diǎn)的配置與Checkpoint節(jié)點(diǎn)一樣，它采用bin/hdfs namenode –backup啟動(dòng)。Backup(或Checkup)節(jié)點(diǎn)的位置及其web接口由配置參數(shù)dfs.namenode.backup.address和 dfs.namenode.backup.http-address指定。
使用Backup節(jié)點(diǎn)，NameNode就可以選擇不進(jìn)行存儲(chǔ)，而將保持命名空間狀態(tài)的責(zé)任交給Backup節(jié)點(diǎn)。為此，在NameNode的配置中，采用選項(xiàng)-importCheckpoint來啟動(dòng)NameNode，并且不設(shè)置edits的存儲(chǔ)位置選項(xiàng)dfs.namenode.edits.dir。
4.2.1.4.3 導(dǎo)入檢查點(diǎn)
如果其它所有的映像文件和edits都丟失了，可以將最后的檢查點(diǎn)導(dǎo)入到NameNode，為此，需要以下步驟：
創(chuàng)建一個(gè)空目錄，在dfs.namenode.name.dir項(xiàng)中配置為該目錄；
設(shè)置dfs.namenode.checkpoint.dir為檢查點(diǎn)目錄；
采用-importCheckpoint選項(xiàng)來啟動(dòng)NameNode。
NameNode將從dfs.namenode.checkpoint.dir設(shè)置的目錄中上載檢查點(diǎn)，并將其保存在dfs.namenode.name.dir指定的目錄中。如果dfs.namenode.name.dir中存在一個(gè)映像文件，NameNode就會(huì)啟動(dòng)失敗，NameNode要驗(yàn)證dfs.namenode.checkpoint.dir中的映像文件是否有問題，但在任何情況下，都不會(huì)修改該文件。
4.2.1.4.4 恢復(fù)模式
通常，你要配置多個(gè)metadata存儲(chǔ)位置，當(dāng)一個(gè)存儲(chǔ)位置崩潰后，你可以從其它位置讀取到metadata。但是，如果僅有的一個(gè)存儲(chǔ)位置崩潰后怎么辦呢？在這種情況下，有一個(gè)特別的NameNode啟動(dòng)模式，叫恢復(fù)模式，允許你恢復(fù)大部分?jǐn)?shù)據(jù)。你可以像這樣啟動(dòng)恢復(fù)模式：namenode –recover，在恢復(fù)模式時(shí)，NameNode以命令行的方式與你交互，顯示你可能采取的恢復(fù)數(shù)據(jù)的措施。如果你不想采用交互模式，你可以加上選項(xiàng)-force，這個(gè)選項(xiàng)將強(qiáng)制選取第一個(gè)選擇恢復(fù)，通常，這是最合理的選擇。由于恢復(fù)模式可能使數(shù)據(jù)丟失，你應(yīng)該在使用它之前備份edits日志文件和fsimage。
4.2.1.4.5 離線Edits文件視圖
離線Edits文件視圖是解析Edits日志文件的工具。當(dāng)前處理器主要用于不同格式之間的轉(zhuǎn)換，包括可讀且比本地二進(jìn)制格式更容易編輯的XML。該工具可以解析Edits日志文件格式（大致Hadoop 0.19）和更高版本。該工具僅對文件操作，它不需要運(yùn)行Hadoop集群。
支持的輸入格式：
binary：Hadoop在內(nèi)部使用的本地二進(jìn)制格式；
xml：XML格式，由xml處理器生成，如果filename具有.xml（不區(qū)分大小寫）擴(kuò)展名，則使用。
離線Edits文件視圖提供了多個(gè)輸出處理器（除非另有說明，否則處理器的輸出可以轉(zhuǎn)換回原始Edits日志文件）：
binary：Hadoop在內(nèi)部使用的本地二進(jìn)制格式；
xml：XML格式；
stats：打印出統(tǒng)計(jì)信息，不能轉(zhuǎn)換回Edits日志文件。
4.2.1.4.6 離線Image文件視圖
離線Image文件視圖是一個(gè)工具，用于將hdfs fsimage文件的內(nèi)容轉(zhuǎn)儲(chǔ)為可讀的格式，并提供只讀WebHDFS API，以允許離線分析和檢查Hadoop集群的命名空間。該工具能夠相對快速地處理非常大的image文件。該工具處理Hadoop版本2.4及更高版本中包含的布局格式。如果要處理較早的布局格式，可以使用oiv_legacy Command的離線Image文件視圖。如果該工具無法處理fsimage文件，它會(huì)完全退出。另外，離線Image文件視圖不需要運(yùn)行Hadoop集群。它完全離線運(yùn)行。
離線Image文件視圖提供了幾個(gè)輸出處理器：
Web是默認(rèn)的輸出處理器。它啟動(dòng)一個(gè)HTTP服務(wù)器，公開只讀WebHDFS API。用戶可以通過使用HTTP REST API交互地查看命名空間；
XML創(chuàng)建fsimage的XML文檔，并包含fsimage中的所有信息。此處理器的輸出可通過XML工具進(jìn)行自動(dòng)處理和分析；
FileDistribution是用于分析命名空間Image中文件大小的工具。為了運(yùn)行工具，應(yīng)該通過指定maxSize和一個(gè)步驟來定義整數(shù)[0，maxSize]的范圍。整數(shù)范圍被分成指定步長的段：[0，s [1]，...，s [n-1]，maxSize]，并且處理器計(jì)算系統(tǒng)中有多少文件落入每個(gè)段（s [i -1]，s [i]）。請注意，大于maxSize的文件總是落入最后一個(gè)段。默認(rèn)情況下，輸出文件格式化為一個(gè)制表符分隔的兩個(gè)列表：Size和NumFiles。其中Size代表段的開始，numFiles是形成Image的文件數(shù)，該大小落在該段中。通過指定選項(xiàng)-format，輸出文件將以可讀的方式格式化；
分隔：生成一個(gè)文本文件，其中包含inode和inode下的inode所共有的所有元素，用分隔符分隔。默認(rèn)分隔符為\t，但可以通過-delimiter參數(shù)更改；
ReverseXML：與XML處理器功能相反，它從XML文件重建fsimage。此處理器可以輕松地創(chuàng)建fsimages進(jìn)行測試。
4.2.1.5 快照
HDFS快照是文件系統(tǒng)的只讀時(shí)間點(diǎn)副本。利用快照，可以讓HDFS在數(shù)據(jù)損壞時(shí)恢復(fù)到過去一個(gè)已知正確的時(shí)間點(diǎn)。可以對文件系統(tǒng)的子樹或整個(gè)文件系統(tǒng)進(jìn)行快照。快照的一些常見用例是數(shù)據(jù)備份，防止用戶錯(cuò)誤和災(zāi)難恢復(fù)。
HDFS快照的實(shí)現(xiàn)是高效的：
快照創(chuàng)建是即時(shí)的：成本是O（1）*，*不包括inode查找時(shí)間；
僅當(dāng)相對于快照進(jìn)行修改時(shí)才使用附加內(nèi)存：內(nèi)存使用為O（M），其中M是修改的文件/目錄的數(shù)量；
不復(fù)制datanode中的塊：快照文件記錄塊列表和文件大小。沒有數(shù)據(jù)復(fù)制；
快照不會(huì)對常規(guī)HDFS操作產(chǎn)生不利影響：按照時(shí)間倒序順序記錄修改，以便可以直接訪問當(dāng)前數(shù)據(jù)。通過從當(dāng)前數(shù)據(jù)中減去修改來計(jì)算快照數(shù)據(jù)。
4.2.1.5.1 Snapshottable目錄
一旦目錄設(shè)置為可快照，就可以對任何目錄進(jìn)行快照。snaphottable目錄能夠容納65,536個(gè)同步快照。可快照目錄的數(shù)量沒有限制。管理員可以將任何目錄設(shè)置為可快照。如果快照目錄中有快照，則在刪除所有快照之前，不能刪除或重命名目錄。
當(dāng)前不允許嵌套snaphottable目錄。換句話說，如果一個(gè)目錄的祖先或后代是一個(gè)snaphottable目錄，則不能將其設(shè)置為snaphottable。
4.2.2 輔助功能
4.2.2.1 瀏覽器界面
典型的HDFS安裝配置Web服務(wù)器以通過可配置的TCP端口公開HDFS命名空間。這允許用戶使用web瀏覽器導(dǎo)航HDFS命名空間并查看其文件的內(nèi)容。
NameNode和DataNode每個(gè)都運(yùn)行內(nèi)部Web服務(wù)器，以顯示有關(guān)集群當(dāng)前狀態(tài)的基本信息。如果使用默認(rèn)配置，NameNode 首頁位于http://namenode-name:9870/(http://namenode-name:9870/(hadoop3.x)（hadoop3.X）。它列出集群中的DataNode和集群的基本統(tǒng)計(jì)信息。Web界面也可以用于瀏覽文件系統(tǒng)（使用NameNode首頁上的“瀏覽文件系統(tǒng)”鏈接）。
4.2.2.2 插件
有一種用插件訪問其內(nèi)部數(shù)據(jù)的方式，將hadoop-eclipse-plugin-version.jar包拷貝到eclipse中的plugins目錄下，并進(jìn)行相應(yīng)的配置，即可直接用eclipse訪問HDFS的數(shù)據(jù)，已及對其進(jìn)行操作，操作方式與在windows環(huán)境操作文件相似。
4.2.2.3 JAVA編程
HDFS提供了一個(gè)FileSystem Java API,支持用寫java代碼的方式來訪問HDFS的數(shù)據(jù)。
4.2.3 可擴(kuò)展性
現(xiàn)在，Hadoop已經(jīng)運(yùn)行在上千個(gè)節(jié)點(diǎn)的集群上。HDFS集群只有一個(gè)NameNode節(jié)點(diǎn)。目前，NameNode上可用內(nèi)存大小是一個(gè)主要的擴(kuò)展限制。在超大型的集群中，增大HDFS存儲(chǔ)文件的平均大小能夠增大集群的規(guī)模，而不需要增加NameNode的內(nèi)存。默認(rèn)配置也許并不適合超大規(guī)模的集群。
4.2.4 文件權(quán)限和安全性
這里的文件權(quán)限和其他常見平臺(tái)如Linux的文件權(quán)限類似。R:read w:write x:execute權(quán)限x對于文件忽略，對于文件夾表示是否允許訪問其內(nèi)容。如果zhangsan在linux系統(tǒng)中使用hadoop命令創(chuàng)建一個(gè)文件，那么這個(gè)文件在HDFS中的owner就是zhangsan。
目前，安全性不僅僅限于簡單的文件權(quán)限。HDFS還支持網(wǎng)絡(luò)驗(yàn)證協(xié)議（比如Kerberos）來對用戶身份進(jìn)行驗(yàn)證和對數(shù)據(jù)進(jìn)行加密傳輸。
4.2.4.1 HDFS權(quán)限指南
Hadoop分布式文件系統(tǒng)（HDFS）為共享大多數(shù)POSIX模型的文件和目錄實(shí)現(xiàn)了一個(gè)權(quán)限模型。每個(gè)文件和目錄都與所有者和組相關(guān)聯(lián)。文件或目錄對作為所有者的用戶，對于該組成員的其他用戶以及對所有其他用戶具有單獨(dú)的權(quán)限。對于文件，讀取文件需要r權(quán)限，并且需要w權(quán)限寫入或附加到文件。對于目錄，需要r權(quán)限列出目錄的內(nèi)容，需要w權(quán)限才能創(chuàng)建或刪除文件或目錄，并且需要x權(quán)限才能訪問目錄的子目錄。
與POSIX模型相反，沒有針對文件的setuid或setgid位，因?yàn)闆]有可執(zhí)行文件的概念。對于目錄，沒有setuid或setgid bits目錄作為簡化。防止除超級(jí)用戶、目錄所有者或文件所有者之外的任何人刪除或移動(dòng)目錄中的文件。總的來說，文件或目錄的權(quán)限是它的模式。通常，將使用用于表示和顯示模式的Unix習(xí)慣，包括使用八進(jìn)制數(shù)。創(chuàng)建文件或目錄時(shí)，其所有者是客戶端進(jìn)程的用戶標(biāo)識(shí)，其組是父目錄（BSD規(guī)則）的組。
HDFS還為POSIX ACL（訪問控制列表）提供了可選的支持，以通過針對特定命名用戶或命名組的細(xì)粒度規(guī)則擴(kuò)充文件權(quán)限。訪問HDFS的每個(gè)客戶端進(jìn)程都具有由用戶名和組列表組成的兩部分身份。每當(dāng)HDFS必須對客戶端進(jìn)程訪問的文件或目錄foo執(zhí)行權(quán)限檢查時(shí)：
如果用戶名與foo的所有者匹配，則測試所有者權(quán)限;
否則，如果foo的組匹配組列表的任何成員，則測試組權(quán)限；
否則，將測試foo的其他權(quán)限。
如果權(quán)限檢查失敗，則客戶端操作失敗。
4.3 HDFS高可用性（QJM）
在Hadoop 2.0.0之前，NameNode是HDFS集群中的單點(diǎn)故障（SPOF）。每個(gè)集群都有一個(gè)NameNode，如果該機(jī)器或進(jìn)程不可用，則作為整體的集群將不可用，直到NameNode被重新啟動(dòng)或在單獨(dú)的機(jī)器上啟動(dòng)。
這會(huì)以兩種主要方式影響HDFS集群的總可用性：
在計(jì)劃外事件（如計(jì)算機(jī)崩潰）的情況下，群集將不可用，直到操作員重新啟動(dòng)NameNode；
計(jì)劃的維護(hù)事件（如NameNode計(jì)算機(jī)上的軟件或硬件升級(jí)）將導(dǎo)致集群停機(jī)時(shí)間的窗口。
HDFS高可用性功能通過在具有熱備份的主/從配置中提供在同一集群中運(yùn)行兩個(gè)（以及3.0.0或更多個(gè)）冗余NameNode的選項(xiàng)來解決上述問題。這允許在機(jī)器崩潰的情況下快速故障切換到新的NameNode，或者出于計(jì)劃維護(hù)的目的，由管理員主動(dòng)發(fā)起故障切換。
4.3.1 原理
hadoop2.x之后，Clouera提出了QJM/Qurom Journal Manager，這是一個(gè)基于Paxos算法實(shí)現(xiàn)的HDFS HA方案，它給出了一種較好的解決思路和方案, 在典型的HA群集中，兩個(gè)或多個(gè)單獨(dú)的計(jì)算機(jī)配置為NameNode。在任何時(shí)間點(diǎn)，只有一個(gè)NameNode處于活動(dòng)狀態(tài)，而其他的處于待機(jī)狀態(tài)。活動(dòng)NameNode負(fù)責(zé)集群中的所有客戶端操作，而Standby只維護(hù)足夠的狀態(tài)以在必要時(shí)提供快速故障轉(zhuǎn)移。示意圖如下：
為了使備用節(jié)點(diǎn)保持其與活動(dòng)節(jié)點(diǎn)同步的狀態(tài)，兩個(gè)節(jié)點(diǎn)都與一組稱為“日志節(jié)點(diǎn)”（JN）的獨(dú)立守護(hù)進(jìn)程通信。當(dāng)活動(dòng)節(jié)點(diǎn)執(zhí)行任何命名空間修改時(shí)，它持久地將修改的記錄記錄到這些JN中的大多數(shù)。備用節(jié)點(diǎn)能夠從JN讀取編輯。
基本原理就是用2N+1臺(tái) JN 存儲(chǔ)Edits，每次寫數(shù)據(jù)操作有大多數(shù)（>=N+1）返回成功時(shí)即認(rèn)為該次寫成功。當(dāng)然這個(gè)算法所能容忍的是最多有N臺(tái)機(jī)器掛掉，如果多于N臺(tái)掛掉，這個(gè)算法就失效了。這個(gè)原理是基于Paxos算法。
在HA架構(gòu)里面SecondaryNameNode這個(gè)角色已經(jīng)不存在了，為了保持standby NN時(shí)時(shí)的與主Active NN的元數(shù)據(jù)保持一致，他們之間交互通過一系列守護(hù)的輕量級(jí)進(jìn)程JournalNode
任何修改操作在 Active NN上執(zhí)行時(shí)，JN進(jìn)程同時(shí)也會(huì)記錄修改log到至少半數(shù)以上的JN中，這時(shí) Standby NN 監(jiān)測到JN 里面的同步log發(fā)生變化了會(huì)讀取 JN 里面的修改log，然后同步到自己的的目錄鏡像樹里面，如下圖：
當(dāng)發(fā)生故障時(shí)，Active的 NN 掛掉后，Standby NN 會(huì)在它成為Active NN 前，讀取所有的JN里面的修改日志，這樣就能高可靠的保證與掛掉的NN的目錄鏡像樹一致，然后無縫的接替它的職責(zé)，維護(hù)來自客戶端請求，從而達(dá)到一個(gè)高可用的目的。
為了提供快速故障轉(zhuǎn)移，還必需備用節(jié)點(diǎn)具有關(guān)于集群中塊的位置的最新信息。為了實(shí)現(xiàn)這一點(diǎn)，DataNode被配置有所有NameNode的位置，并且向所有NameNode發(fā)送塊位置信息和心跳。
4.3.2 QJM的主要優(yōu)勢
不需要配置額外的高共享存儲(chǔ)，降低了復(fù)雜度和維護(hù)成本；
消除spof；
系統(tǒng)健壯的程度是可配置的；
JN不會(huì)因?yàn)槠渲幸慌_(tái)的延遲而影響整體的延遲，而且也不會(huì)因?yàn)镴N的數(shù)量增多而影響性能（因?yàn)镹N向JN發(fā)送日志是并行的）。
4.3.3 只有一個(gè)NN能命令DN
每個(gè)NN改變狀態(tài)的時(shí)候，向DN發(fā)送自己的狀態(tài)和一個(gè)序列號(hào)；
DN在運(yùn)行過程中維護(hù)此序列號(hào)，當(dāng)failover時(shí)，新的NN在返回DN心跳時(shí)會(huì)返回自己的active狀態(tài)和一個(gè)更大的序列號(hào)。DN接收到這個(gè)返回則認(rèn)為該NN為新的active；
如果這時(shí)原來的active NN恢復(fù)，返回給DN的心跳信息包含active狀態(tài)和原來的序列號(hào)，這時(shí)DN就會(huì)拒絕這個(gè)NN的命令。
4.3.4 只有一個(gè)NN響應(yīng)客戶端
訪問standby nn的客戶端直接失敗。在RPC層封裝了一層，通過FailoverProxyProvider以重試的方式連接NN。通過若干次連接一個(gè)NN失敗后嘗試連接新的NN，對客戶端的影響是重試的時(shí)候增加一定的延遲。客戶端可以設(shè)置重試次數(shù)和時(shí)間。
Hadoop提供了ZKFailoverController角色，部署在每個(gè)NameNode的節(jié)點(diǎn)上，作為一個(gè)deamon進(jìn)程, 簡稱zkfc，示例圖如下：
4.3.5 FailoverController組成
HealthMonitor：監(jiān)控NameNode是否處于unavailable或unhealthy狀態(tài)。當(dāng)前通過RPC調(diào)用NN相應(yīng)的方法完成；
ActiveStandbyElector：管理和監(jiān)控自己在ZK中的狀態(tài)；
ZKFailoverController：它訂閱HealthMonitor 和ActiveStandbyElector 的事件，并管理NameNode的狀態(tài)。
4.3.6 ZKFailoverController職責(zé)
健康監(jiān)測：周期性的向它監(jiān)控的NN發(fā)送健康探測命令，從而來確定某個(gè)NameNode是否處于健康狀態(tài)，如果機(jī)器宕機(jī)，心跳失敗，那么zkfc就會(huì)標(biāo)記它處于一個(gè)不健康的狀態(tài)；
會(huì)話管理：如果NN是健康的，zkfc就會(huì)在zookeeper中保持一個(gè)打開的會(huì)話，如果NameNode同時(shí)還是Active狀態(tài)的，那么zkfc還會(huì)在Zookeeper中占有一個(gè)類型為短暫類型的znode，當(dāng)這個(gè)NN掛掉時(shí)，這個(gè)znode將會(huì)被刪除，然后備用的NN，將會(huì)得到這把鎖，升級(jí)為主NN，同時(shí)標(biāo)記狀態(tài)為Active；
當(dāng)宕機(jī)的NN新啟動(dòng)時(shí)，它會(huì)再次注冊zookeper，發(fā)現(xiàn)已經(jīng)有znode鎖了，便會(huì)自動(dòng)變?yōu)镾tandby狀態(tài)，如此往復(fù)循環(huán)，保證高可靠，目前可以支持兩個(gè)以上NN；
master選舉：如上所述，通過在zookeeper中維持一個(gè)短暫類型的znode，來實(shí)現(xiàn)搶占式的鎖機(jī)制，從而判斷哪個(gè)NameNode為Active狀態(tài)。
注意，在HA群集中，Standby NameNode還執(zhí)行命名空間狀態(tài)的檢查點(diǎn)，因此不需要在HA群集中運(yùn)行Secondary NameNode，CheckpointNode或BackupNode。
4.4 HDFS高可用性（NFS）
NFS的方式的HA的配置與啟動(dòng)，和QJM方式基本上是一樣，唯一不同的地方就是active namenode和standby namenode共享edits文件的方式。QJM方式是采用journalnode來共享edits文件，而NFS方式則是采用NFS遠(yuǎn)程共享目錄來共享edits文件。
NFS允許用戶像訪問本地文件系統(tǒng)一樣訪問遠(yuǎn)程文件系統(tǒng)，而將NFS引入HDFS后，用戶可像讀寫本地文件一樣讀寫HDFS上的文件，大大簡化了HDFS使用，這是通過引入一個(gè)NFS gateway服務(wù)實(shí)現(xiàn)的，該服務(wù)能將NFS協(xié)議轉(zhuǎn)換為HDFS訪問協(xié)議，具體如下圖所示。
4.5 HDFS Federation
4.5.1 HDFS的兩個(gè)主要層
命名空間
由目錄，文件和塊組成；
它支持所有與命名空間相關(guān)的文件系統(tǒng)操作，如創(chuàng)建，刪除，修改和列出文件和目錄。
塊存儲(chǔ)服務(wù)
包括兩部分：
塊管理（在Namenode中執(zhí)行）
①通過處理注冊和定期心跳提供Datanode集群成員身份；
②處理并維護(hù)塊的位置；
③支持塊相關(guān)操作，如創(chuàng)建，刪除，修改和獲取塊位置；
④管理副本放置，低復(fù)制塊的塊復(fù)制，以及刪除超過復(fù)制的塊。
存儲(chǔ)
由Datanodes通過在本地文件系統(tǒng)上存儲(chǔ)塊并允許讀/寫訪問來提供。
先前的HDFS架構(gòu)僅允許整個(gè)集群使用單個(gè)命名空間。在該配置中，單個(gè)Namenode管理命名空間。HDFS Federration通過向HDFS添加對多個(gè)Namenodes /命名空間的支持來解決此限制。
4.5.2 原理
單Active NN的架構(gòu)使得HDFS在集群擴(kuò)展性和性能上都有潛在的問題，當(dāng)集群大到一定程度后，NN進(jìn)程使用的內(nèi)存可能會(huì)達(dá)到上百G，NN成為了性能的瓶頸。
常用的估算公式為1G對應(yīng)1百萬個(gè)塊，按缺省塊大小計(jì)算的話，大概是64T (這個(gè)估算比例是有比較大的富裕的，其實(shí)，即使是每個(gè)文件只有一個(gè)塊，所有元數(shù)據(jù)信息也不會(huì)有1KB/block)。
為了水平擴(kuò)展名稱服務(wù)，F(xiàn)ederration使用多個(gè)獨(dú)立的Namenodes/命名空間。Namenodes之間管理的數(shù)據(jù)是共享的，但同時(shí)也是獨(dú)立的，不需要彼此協(xié)調(diào)。Datanodes被所有Namenode用作塊的公共存儲(chǔ)。每個(gè)Datanode注冊集群中的所有Namenode。Datanodes發(fā)送定期心跳和塊報(bào)告。它們還處理來自Namenode的命令。
為了解決這個(gè)問題,Hadoop 2.x、Hadoop 3.x提供了HDFS Federation, 示意圖如下：
多個(gè)NN共用一個(gè)集群里的存儲(chǔ)資源，每個(gè)NN都可以單獨(dú)對外提供服務(wù)。
每個(gè)NN都會(huì)定義一個(gè)存儲(chǔ)池，有單獨(dú)的id，每個(gè)DN都為所有存儲(chǔ)池提供存儲(chǔ)。
DN會(huì)按照存儲(chǔ)池id向其對應(yīng)的NN匯報(bào)塊信息，同時(shí)，DN會(huì)向所有NN匯報(bào)本地存儲(chǔ)可用資源情況。
如果需要在客戶端方便的訪問若干個(gè)NN上的資源，可以使用客戶端掛載表，把不同的目錄映射到不同的NN，但NN上必須存在相應(yīng)的目錄。
4.5.3 設(shè)計(jì)優(yōu)勢
改動(dòng)最小，向前兼容；現(xiàn)有的NN無需任何配置改動(dòng)；如果現(xiàn)有的客戶端只連某臺(tái)NN的話，代碼和配置也無需改動(dòng)；
分離命名空間管理和塊存儲(chǔ)管理；
客戶端掛載表：通過路徑自動(dòng)對應(yīng)NN、使Federation的配置改動(dòng)對應(yīng)用透明。
4.5.4 ViewF
View文件系統(tǒng)（ViewFs）提供了一種管理多個(gè)Hadoop文件系統(tǒng)命名空間（或命名空間卷）的方法。它對于在HDFS Federation中具有多個(gè)命名空間的集群特別有用。ViewF類似于一些Unix/Linux系統(tǒng)中的客戶端安裝表。ViewF可用于創(chuàng)建個(gè)性化命名空間視圖以及每個(gè)集群的常見視圖。
View文件系統(tǒng)具有多個(gè)集群的Hadoop系統(tǒng)的上下文中顯示，每個(gè)集群可以聯(lián)合到多個(gè)命名空間中，以提供每個(gè)群集的全局命名空間，以便應(yīng)用程序可以以類似于聯(lián)合前的方式運(yùn)行。
4.5.4.1 單個(gè)Namenode集群
在HDFS聯(lián)合之前，集群具有單個(gè)命名空間，為該集群提供單個(gè)文件系統(tǒng)命名空間。如果有多個(gè)集群。則每個(gè)集群的文件系統(tǒng)命名空間是完全獨(dú)立和不相交的。此外，物理存儲(chǔ)不是在集群之間共享（即Datanodes不是跨集群共享的）。
4.5.4.2 Federation和ViewF
如果有多個(gè)集群。每個(gè)集群都有一個(gè)或多個(gè)命名空間。每個(gè)namenode都有自己的命名空間。namenode屬于一個(gè)且僅一個(gè)集群。但是與單個(gè)namenode集群不同的是：同一集群中的namenode共享該集群的物理存儲(chǔ)。集群中的命名空間與前面一樣是獨(dú)立的。
操作根據(jù)存儲(chǔ)需求決定群集中每個(gè)namenode上存儲(chǔ)的內(nèi)容。例如，他們可以將所有用戶數(shù)據(jù)（/user/<username>）放在一個(gè)命名空間中，將所有feed數(shù)據(jù)（/data）放置在另一個(gè)命名空間中，將所有項(xiàng)目（/projects）放在另一個(gè)命名空間等等。
4.5.4.3 使用ViewF的每個(gè)集群的全局命名空間
為了提供透明度，ViewF文件系統(tǒng)（即客戶端裝載表）用于創(chuàng)建每個(gè)集群獨(dú)立的集群命名空間視圖，這與單個(gè)Namenode集群中的命名空間類似。客戶端安裝表（如Unix安裝表），并使用舊的命名約定安裝新的命名空間卷。下圖顯示了裝載四個(gè)命名空間卷/user，/data，/projects和/tmp的裝載表：
ViewF實(shí)現(xiàn)了Hadoop文件系統(tǒng)接口，就像HDFS和本地文件系統(tǒng)一樣。這是一個(gè)普通的文件系統(tǒng)，它只允許鏈接到其他文件系統(tǒng)。所有shell命令與ViewFS一起使用，與HDFS和本地文件系統(tǒng)一樣。
5. 命令指南
所有的hadoop命令均由bin/hdfs腳本引發(fā)。不指定參數(shù)運(yùn)行hdfs腳本會(huì)打印所有命令的描述。
用法：hdfs [SHELL_OPTIONS] COMMAND [GENERIC_OPTIONS] [COMMAND_OPTIONS]
Hadoop有一個(gè)選項(xiàng)解析框架用于解析一般的選項(xiàng)和運(yùn)行類。
由于字?jǐn)?shù)限制，本文分為上下兩篇分別在頭條和二條推送，后半部分內(nèi)容請見今日二條推送。
更多精彩干貨內(nèi)容，敬請搜索關(guān)注清華-青島數(shù)據(jù)科學(xué)研究院官方公眾平臺(tái)“數(shù)據(jù)派THU”