前段時間搭建了一套Hadoop集群的測試環(huán)境，因為服務器故障，廢了。這幾天閑來無事，想著把Storm用Yarn管理起來，于是再來一遍，同時也梳理下Hadoop組件中的一些概念。所謂書讀百遍其義自見，不熟的系統(tǒng)多搭幾遍，總會熟悉了，也就是所謂的刻意練習吧。

先簡單的說下。

Hadoop文件存儲的基礎是HDFS(Hadoop Distributed File System)，HDFS的實現(xiàn)依賴于NameNode和DataNode，DataNode用來存儲具體數(shù)據(jù)，NameNode用來管理多個DataNode中分別存儲的是什么。

理解起來也不難，因為HDFS是分布式的文件系統(tǒng)，也就是有很多機器用來存儲數(shù)據(jù)，一個大文件可能分布在多個機器上，也可能是一臺機器上，具體分布在哪些或哪個機器上，每塊數(shù)據(jù)塊的副本在哪，得需要一個總管來管理，這個總管就是NameNode，具體存儲機器的就是DataNode。

簡單的說完了，接下來就復雜的說。

1. HDFS架構(gòu)

HDFS是主/從架構(gòu)，一個HDFS只有一個NameNode（這里的一個是指起作用的只有一個，在NameNode的HA狀態(tài)下，也是只有一個NameNode起作用，其他的NameNode節(jié)點只是備份，家有千口，主事一人嘛）。這個NameNode管理整個文件系統(tǒng)的命名空間（The File System Namespace），并且調(diào)節(jié)客戶端對文件的訪問。DataNode用來存儲數(shù)據(jù)，還有一些DataNode用來管理連接到運行節(jié)點的存儲。HDFS公開文件系統(tǒng)的命名空間，允許用戶在文件系統(tǒng)中存儲數(shù)據(jù)。

在HDFS內(nèi)部，一個文件被分割為一個或多個數(shù)據(jù)塊，這些數(shù)據(jù)塊存儲在一組DataNode上。NameNode負責文件系統(tǒng)的命名空間操作，比如對文件或文件夾執(zhí)行打開、關閉，以及重命名操作，同時，也負責將數(shù)據(jù)塊映射到DataNode上。DataNode負責向客戶端提供對文件系統(tǒng)的讀取和寫入請求的處理。DataNode還能根據(jù)NameNode的指示，執(zhí)行數(shù)據(jù)塊的創(chuàng)建、刪除和復制操作。

NameNode和DataNode通常運行在普通商用服務器上（這里是針對小型機這種又貴很又特別貴的機器說的），這些機器一般裝的是Linux。HDFS使用Java實現(xiàn)的，而且Java號稱是一處編譯到處運行，也就是只要有Java環(huán)境，就能運行NameNode和DataNode。典型的部署方式是，一臺機器運行NameNode，其他機器運行DataNode，每臺機器一個進程。（當然也可能一臺機器上有多個DataNode，但是生產(chǎn)環(huán)境應該不會有這種情況，畢竟沒有任何好處）

HDFS的這種主從架構(gòu)保證了，所有的數(shù)據(jù)都會從NameNode經(jīng)過，這樣也簡化了系統(tǒng)的體系結(jié)構(gòu)，NameNode就是老大，所有數(shù)據(jù)都經(jīng)過他。當然老大也可能出現(xiàn)意外，就得需要其他HA的部署方式（找?guī)讉€小弟時刻準備接替老大），這個后面再說。

2. 文件系統(tǒng)

HDFS文件系統(tǒng)設計與傳統(tǒng)分層文件系統(tǒng)類似，有文件夾，文件夾里可以有文件夾或文件。客戶端可以對這些文件夾或文件進行操作，比如創(chuàng)建、刪除、移動、重命名等。不過目前還不支持軟連接和硬連接，后面可能會支持。

如前面所說，這個命名空間由NameNode維護。所有的文件/文件夾的名字、屬性、復制因子都由NameNode記錄。

3. 數(shù)據(jù)復制

HDFS設計用于在大型集群中存儲非常大的文件，它將每個文件存儲為一組數(shù)據(jù)塊塊中，除了最后一塊外，所有文件塊大小相同（默認是64MB），HDFS通過復制數(shù)據(jù)塊塊進行容錯，每個文件的數(shù)據(jù)塊大小、復制因子都是可配的?？蛻舳丝梢灾付ㄎ募母北緮?shù)，可以在創(chuàng)建時指定，也可以在之后修改。HDFS中的文件是一次寫入的，并且在任何時候都有一個明確的作者。

NameNode來管理所有數(shù)據(jù)塊復制操作，它定期與集群中每個DataNode進行心跳和文件塊報告。收到心跳意味著DataNode正常運行，文件塊報告是DataNode上所有文件塊的列表。

3.1 副本存儲

副本存儲的位置對于HDFS的可靠性和性能是至關重要的，優(yōu)化副本存儲是HDFS與大多數(shù)其他分布式文件系統(tǒng)區(qū)分開來的優(yōu)點之一，這是一個經(jīng)過大量調(diào)整和體驗的功能。機架感知副本存儲策略的目的是提高數(shù)據(jù)可靠性、可用性和網(wǎng)絡帶寬的高利用率。目前的副本存儲策略是朝這個方向努力的第一步。實施這一政策的短期目標是對生產(chǎn)系統(tǒng)進行驗證，更多的了解其行為，并為更加復雜的策略進行測試和研究奠定基礎。

大型的HDFS實例通常運行在多個機架上，不同機架中的兩個節(jié)點之間通信必須通過交換機。通產(chǎn)，同一機架上的機器之間的網(wǎng)絡速率會優(yōu)于不同機架間的速率。

NameNode通過Hadoop 機架感知中介紹的方式確定每個DataNode所屬的機架ID。一個簡單但不是最優(yōu)策略是將副本存儲在不同的機架上，這樣可以防止整個機架故障導致數(shù)據(jù)丟失，并允許讀取數(shù)據(jù)時使用多個機架的帶寬。該策略保證可以在集群中均勻分配副本，可以輕松平衡組件故障時的負載。但是，這種策略會因為需要將副本數(shù)據(jù)寫到多個機架，而增加寫入成本。

常見情況中，復制因子是3，HDFS的副本存儲策略是將一個副本放置在當前機架上的一個節(jié)點上，另一個位于另一個機架上的某個節(jié)點上，最后一個放置第二個機架上的另一個節(jié)點上。這種策略減少了機架間的通信，從而提高寫入性能。機架故障的概率遠小于節(jié)點故障的概率，這種策略不會影響數(shù)據(jù)可靠性和可用性。但是，它會降低讀取數(shù)據(jù)的網(wǎng)絡帶寬，因為數(shù)據(jù)塊放置在兩個機架上，而不是三個。使用這種策略，副本不會均勻的分布在機架中。還有一種比較好的策略，就是三分之一的副本在一個節(jié)點上，三分之一的副本在另一個機架上，其余的均勻分布在其他機器上，這種方式可以改善寫入策略，不會影響數(shù)據(jù)可靠性或讀取性能。不過這種方式還在開發(fā)中。

3.2 副本選擇

為了最大限度的減少全局帶寬消耗和讀取延遲，HDFS嘗試讓讀取器讀取最接近的副本。如果在同一機架上存在副本，就優(yōu)先讀取該副本。如果HDFS跨越多個數(shù)據(jù)中心，則優(yōu)先讀取當前數(shù)據(jù)中心的副本。

3.3 安全模式（SafeMode）

在啟動的時候，NameNode進入一個成為安全模式的特殊狀態(tài)。NameNode處于安全模式時，不會復制數(shù)據(jù)塊。NameNode從DataNode節(jié)點接收心跳和數(shù)據(jù)塊報告，數(shù)據(jù)塊報告包含DataNode存儲的數(shù)據(jù)塊列表信息。每個數(shù)據(jù)塊有指定的最小數(shù)量副本。當使用NameNode檢入該數(shù)據(jù)塊的最小副本數(shù)量時，數(shù)據(jù)塊被認為是安全復制的。在NameNode檢查數(shù)據(jù)塊的安全復制結(jié)束后（可配的時間段，再加上30秒），NameNode退出安全模式。然后它開始檢查是否有少于指定數(shù)量的數(shù)據(jù)塊列表，將這些數(shù)據(jù)塊復制到其他DataNode。

4. 文件系統(tǒng)元數(shù)據(jù)

HDFS由NameNode存儲命名空間信息，NameNode使用名為EditLog的事務日志持續(xù)記錄文件系統(tǒng)元數(shù)據(jù)發(fā)生的每個更改。比如，在HDFS中創(chuàng)建一個新的文件會導致NameNode在EditLog中插入一條記錄，用于記錄該操作。同樣的，修改文件的復制因子也會新增一條記錄。NameNode使用本機文件系統(tǒng)存儲EditLog文件。整個文件系統(tǒng)命名空間（包括塊映射文件和文件系統(tǒng)屬性等信息）存儲在一個名為FsImage的文件中，該文件也是存儲在NameNode所在的本機文件系統(tǒng)中。

NameNode在內(nèi)存中存儲整個文件系統(tǒng)的命名空間和文件數(shù)據(jù)塊映射關系，這個元數(shù)據(jù)存儲模塊設計為緊湊存儲，可以在4GB內(nèi)存的NameNode中可以支持大量的文件和文件夾。在NameNode啟動時，它從磁盤讀取FsImage和EditLog，將所有從EditLog的事務應用到FsImage的內(nèi)存表示中，并將這個新版本的FsImage文件中。該操作會截斷舊的EditLog，因為其中的事務操作已經(jīng)應用到FsImage文件中。這個過程成為檢查點（checkpoint）。在當前版本中，檢查點操作只會發(fā)生在NameNode啟動時，正在增加定期檢查點檢查操作。

DataNode將HDFS數(shù)據(jù)存儲在其本地文件系統(tǒng)的文件中，DataNode不知道HDFS的文件數(shù)據(jù)，它只是將HDFS文件數(shù)據(jù)的數(shù)據(jù)塊存儲在本地文件系統(tǒng)中的單獨文件中。DataNode不會存儲同一文件夾下的所有文件，相反，它會確定每個文件夾的最佳文件數(shù)量，并適當?shù)膭?chuàng)建子文件夾。在同一文件夾中創(chuàng)建所有本地文件是不合適的，因為本地文件系統(tǒng)可能無法在單個文件夾中有效支持存儲大量文件。當DataNode啟動時，它會掃描其本地文件系統(tǒng)，生產(chǎn)與每個文件對應的所有HDFS數(shù)據(jù)塊數(shù)控報告，并發(fā)送給NameNode。

5. 通信協(xié)議

所有HDFS的通信協(xié)議是基于TCP/IP協(xié)議的。客戶端通過客戶端協(xié)議與NameNode建立連接，并通信。DataNode通過DataNode協(xié)議與NameNode通信。NameNode從不發(fā)起通信請求，它只響應客戶端和DataNode發(fā)出的請求。

6. 穩(wěn)健性

HDFS的主要目標是可靠性存儲，即使發(fā)生故障，也能夠很好的支撐存儲。比較常見的故障類型有：NameNode故障、DataNode故障、網(wǎng)絡分區(qū)異常。

6.1 數(shù)據(jù)磁盤故障，心跳和重新復制

每個DataNode會定期向NameNode發(fā)送心跳請求。網(wǎng)絡分區(qū)可能導致一部分DataNode與NameNode失去連接，NameNode通過心跳檢測這種情況，如果發(fā)現(xiàn)長時間沒有心跳的DataNode，則標記為丟棄，而且不再轉(zhuǎn)發(fā)任何新的IO請求，這些DataNode的數(shù)據(jù)也不在作用于HDFS。DataNode的死亡可能導致某些數(shù)據(jù)塊的復制因子低于設定值，NameNode會不斷掃描哪些數(shù)據(jù)塊需要復制，并在必要的時候進行復制。重復復制可能是因為DataNode不可用、副本文件損壞、DataNode硬盤損壞，或者文件復制因子增加。

6.2 集群重新平衡

HDFS架構(gòu)與數(shù)據(jù)重新平衡方案兼容，如果DataNode上的可用空間低于閥值，數(shù)據(jù)會從一個DataNode移動到另一個DataNode。在對特定文件的需求突然增加的情況下，可能會動態(tài)創(chuàng)建其他副本來重新平衡集群中的數(shù)據(jù)。（這種類型的數(shù)據(jù)重新平衡還未實現(xiàn)）。

6.3 數(shù)據(jù)的完整性

DataNode存儲的數(shù)據(jù)塊可能會被破壞，這可能是因為存儲設備故障、網(wǎng)絡故障或軟件錯誤導致的。HDFS客戶端會對HDFS文件內(nèi)容進行校驗和檢查。當客戶端創(chuàng)建一個HDFS文件時，它會計算文件的每個塊的檢驗碼，然后將該校驗碼存儲在同一HDFS命名空間中的隱藏文件中。當客戶端操作文件時，會將從DataNode接收到的數(shù)據(jù)與存儲的校驗文件進行校驗和匹配。如果沒有成功，客戶端會從該數(shù)據(jù)塊的其他副本讀取數(shù)據(jù)。

6.4 元數(shù)據(jù)磁盤故障

FsImage和EditLog是HDFS的核心數(shù)據(jù)結(jié)構(gòu)，如果這些文件被損壞，可能導致HDFS實例不可用。因此，NameNode可以配置維護FsImage和EditLog的多個副本。對FsImage或EditLog的任何更新，這些副本也跟著更新。當時這樣可能會導致NameNode的TPS。但是，這種性能的降低是可以接受的，因為即使HDFS應用程序本質(zhì)上是數(shù)據(jù)密集型，但卻不是元數(shù)據(jù)密集型的。當NameNode重啟時，它會選擇最新的FsImage和EditLog使用。

比較常見的多備份存儲是一份存在本地文件系統(tǒng)中，一份存儲在遠程網(wǎng)絡文件系統(tǒng)中。

因為NameNode單點的，所以可能會出現(xiàn)HDFS集群的單點故障，需要手動干預。這個時候就需要NameNode的HA方案，這個后面再說。

6.5 Secondary NameNode

前面說過，NameNode是單點的，如果NameNode宕機，系統(tǒng)中的文件會丟失，所以Hadoop提供還提供了一種機制：Secondary NameNode。

Secondary NameNode比較有意思，它并不能直接作為NameNode使用，它只是定期將FsImage和EditLog合并，防止EditLog文件過大。通常Secondary NameNode也是運行在單獨的機器上，因為日志合并操作需要占用大量的內(nèi)存和CPU。Secondary NameNode會保存合并后的元數(shù)據(jù)，一旦NameNode宕機，而且元數(shù)據(jù)不可用，就可以使用Secondary NameNode備份的數(shù)據(jù)。

但是，Secondary NameNode總是落后與NameNode，所以在NameNode宕機后，數(shù)據(jù)丟失是不可避免的。一般這種情況就會使用元數(shù)據(jù)的遠程備份與Secondary NameNode中的合并數(shù)據(jù)共同作為NameNode的元數(shù)據(jù)文件。

6.6 快照

快照功能支持在特定時刻存儲數(shù)據(jù)副本，可以在出現(xiàn)數(shù)據(jù)損壞的情況下，將HDFS回滾到之前的時間點。（目前還不支持，之后會增加）

7 數(shù)據(jù)

7.1 數(shù)據(jù)塊

HDFS是為了存儲大文件的。與HDFS兼容的程序是處理大型數(shù)據(jù)集的，這些應用通常是一次寫入，多次讀取，并且要求在讀取速率上滿足要求。HDFS恰好滿足“一次寫入、多次讀取”的要求。在HDFS中，數(shù)據(jù)塊大小默認是64MB。所以，大文件在HDFS內(nèi)存切成64MB的數(shù)據(jù)塊，每個數(shù)據(jù)塊會存儲在不同的DataNode上。

7.2 階段

客戶端創(chuàng)建文件的請求不會立即到達NameNode。一開始，客戶端將文件緩存到臨時文件中，寫入操作透明的重定向到該臨時文件中。當臨時文件超過一個HDFS數(shù)據(jù)塊的大小時，客戶端將連接NameNode，NameNode會把文件名插入到文件系統(tǒng)中，為其分配一個數(shù)據(jù)塊。NameNode使用DataNode和目標數(shù)據(jù)塊響應客戶端請求。然后客戶端將數(shù)據(jù)塊信息從本地臨時文件刷新到指定的DataNode中。關閉文件時，臨時文件中剩余的未刷新數(shù)據(jù)將傳輸?shù)紻ataNode，然后，客戶端通知NameNode文件關閉，此時，NameNode將文件創(chuàng)建操作提交到持久存儲。如果NameNode在文件關閉前宕機， 則文件丟失。

HDFS采用上述方式是經(jīng)過仔細考慮的，這些應用需要流式寫入文件，如果客戶端寫入遠程文件時沒有使用客戶端緩沖，網(wǎng)速和網(wǎng)絡情況將會大大影響吞吐率。這種做法也是有先例的，早起的分布式文件系統(tǒng)也是采用這種方式，比如ASF。POSIX要求已經(jīng)放寬，以便實現(xiàn)高性能的數(shù)據(jù)上傳。

7.3 復制流水線

如上所述，當客戶端數(shù)據(jù)寫入HDFS時，首先將數(shù)據(jù)寫入本地緩存文件。如果HDFS文件的復制因子是3，當本地緩存文件大小累積到數(shù)據(jù)塊大小時，客戶端從NameNode查詢寫入副本的DataNode列表。然后，客戶端將數(shù)據(jù)塊刷新到第一個DataNode中，這個DataNode以小數(shù)據(jù)（4KB）接收數(shù)據(jù)，將數(shù)據(jù)寫入本地存儲庫，并將該部分數(shù)據(jù)傳輸?shù)降诙€DataNode，第二個DataNode存儲后，將數(shù)據(jù)發(fā)送給第三個DataNode。因此，DataNode可以在流水線中接收來自前一個的數(shù)據(jù)，同時將數(shù)據(jù)發(fā)送給流水線的下一個，以此類推。

8 易使用

可以以多種方式訪問HDFS，HDFS提供了一個Java API，C語言包裝器也可用。也可以使用瀏覽器瀏覽HDFS實例文件。（目前正在通過使用WebDAV協(xié)議公開HDFS）。

8.1 FS Shell

HDFS允許以文件和文件夾的形式組織數(shù)據(jù)，提供了一個名為“FS shell”的命令行界面，可讓用戶與HDFS中的數(shù)據(jù)進行交互。該命令集語法類似與用戶熟悉的其他shell（比如bash，csh）。以下是一些實例：

操作 命令

創(chuàng)建/foodir文件夾 bin/hadoop dfs -mkdir /foodir

刪除/foodir文件夾 bin/hadoop fs -rm -R /foodir

查看文件/foodir/myfile.txt的內(nèi)容 bin/hadoop dfs -cat /foodir/myfile.txt

FS shell針對需要腳本語言與存儲數(shù)據(jù)進行交互的應用場景。

8.2 DFSAdmin

DFSAdmin命令集用于管理HDFS集群，這些應該是由HDFS管理員使用的命令，以下是一些實例：

操作 命令

集群置為安全模式 bin/hadoop dfsadmin -safemode enter

生成DataNode列表 bin/hadoop dfsadmin -report

啟動或停止DataNode bin/hadoop dfsadmin -refreshNodes

8.3 瀏覽器接口

典型的HDFS安裝會配置web服務器，以配置TCP端口公開HDFS命名空間，這允許用戶瀏覽HDFS命名空間，并使用web瀏覽器查看文件內(nèi)容。

9 空間復用

9.1 文件刪除

如果回收站功能可用，通過FS Shell刪除的文件不會立馬刪除，而是移動到回收站中（每個用戶的回收文件夾不同，是在各自的用戶目錄的.Trash中，即/user//.Trash）。只要文件還保留在回收站中，就可以很快恢復。

大多數(shù)的刪除文件會移動到回收站的current目錄（即/user//.Trash/Current）中，在配置的時間內(nèi)，HDFS創(chuàng)建會創(chuàng)建檢查點（/user//.Trash/），并在舊的檢查點過期后刪除。具體可以查看刪除操作。

文件在回收站的時間過期后，NameNode會從HDFS命名空間中刪除文件，同時，釋放相關聯(lián)的數(shù)據(jù)塊空間。

文件刪除后，客戶端可以取消刪除。可以通過瀏覽/trash文件夾，查找文件。/trash文件夾中包含被刪除文件的最新副本。目前HDFS會從/trash刪除超過6小時的文件。（/trash類似于文件系統(tǒng)中的回收站、垃圾桶等功能）。

下面是使用FS Shell刪除文件的操作：

在當前目錄中創(chuàng)建兩個文件：test1、test2

$ hadoop fs -mkdir -p delete/test1 $ hadoop fs -mkdir -p delete/test2 $ hadoop fs -ls delete/ Found 2 items drwxr-xr-x   - hadoop hadoop          0 2015-05-08 12:39 delete/test1 drwxr-xr-x   - hadoop hadoop          0 2015-05-08 12:40 delete/test2

刪除test1：

$ hadoop fs -rm -r delete/test1 Moved: hdfs://localhost:8020/user/hadoop/delete/test1 to trash at: hdfs://localhost:8020/user/hadoop/.Trash/Current

使用skipTrash選項刪除test2：

$ hadoop fs -rm -r -skipTrash delete/test2 Deleted delete/test2

查看回收站中的文件只有test1：

$ hadoop fs -ls .Trash/Current/user/hadoop/delete/ Found 1 items\ drwxr-xr-x   - hadoop hadoop          0 2015-05-08 12:39 .Trash/Current/user/hadoop/delete/test1

也就是test1進入回收站，test2之間刪除了。

9.2 減少復制因子

當文件的復制因子減少后，NameNode選擇可以刪除的多余副本，在下一個心跳時將信息傳輸給DataNode，DataNode刪除相應的數(shù)據(jù)塊，并釋放空間。調(diào)用setReplication API和集群使用可用空間可能會有延遲。