本節(jié)書摘來自華章計(jì)算機(jī)《深入理解Hadoop（原書第2版）》一書中的第2章，第2.3節(jié)，作者 [美]薩米爾·瓦德卡（Sameer Wadkar），馬杜·西德林埃（Madhu Siddalingaiah），杰森·文納（Jason Venner），譯 于博，馮傲風(fēng)，更多章節(jié)內(nèi)容可以訪問云棲社區(qū)“華章計(jì)算機(jī)”公眾號查看。

2.3Hadoop系統(tǒng)的組成

本節(jié)內(nèi)容會(huì)細(xì)致深入地講解Hadoop系統(tǒng)的各個(gè)組成部分。我們先介紹構(gòu)成Hadoop 1.x 系統(tǒng)的組件，再介紹構(gòu)成Hadoop 2.x 系統(tǒng)的新組件。宏觀上說，Hadoop 1.x系統(tǒng)有以下幾個(gè)守護(hù)進(jìn)程：

• 名稱節(jié)點(diǎn)（NameNode）：維護(hù)著存儲在HDFS上的所有文件的元數(shù)據(jù)信息。這些元數(shù)據(jù)信息包括組成文件的數(shù)據(jù)塊信息，及這些數(shù)據(jù)塊在數(shù)據(jù)節(jié)點(diǎn)上的位置。正如你將看到的，這個(gè)組件正是使用Hadoop 1.x搭建大型計(jì)算集群系統(tǒng)的瓶頸所在。
• 輔助名稱節(jié)點(diǎn)（Secondary NameNode）：這不是名稱節(jié)點(diǎn)的熱備份。實(shí)際上，它作為Hadoop平臺的一個(gè)組件，其命名不是很恰當(dāng)。它為名稱節(jié)點(diǎn)組件執(zhí)行一些內(nèi)務(wù)處理功能（housekeeping functions）。
• 數(shù)據(jù)節(jié)點(diǎn)（DataNode）：把真正的數(shù)據(jù)塊存放在本地硬盤上，這些數(shù)據(jù)塊組成了保存在HDFS上的每個(gè)文件。
• 作業(yè)跟蹤器（JobTracker）：這是Hadoop系統(tǒng)的主要組件之一，它負(fù)責(zé)一個(gè)任務(wù)的整個(gè)執(zhí)行過程。它的具體功能包括：調(diào)度各個(gè)子任務(wù)（Mapper任務(wù)和Reducer任務(wù)各自的子任務(wù)）到各自的計(jì)算節(jié)點(diǎn)運(yùn)行，時(shí)刻監(jiān)控任務(wù)運(yùn)行和計(jì)算節(jié)點(diǎn)的健康狀況，對失敗的子任務(wù)重新調(diào)度執(zhí)行。正如我們即將演示的，就像名稱節(jié)點(diǎn)一樣，這個(gè)組件是使用Hadoop 1.x搭建大型計(jì)算集群系統(tǒng)的瓶頸所在。
• 任務(wù)跟蹤器（TaskTracker）：運(yùn)行在各個(gè)數(shù)據(jù)節(jié)點(diǎn)上，用來啟動(dòng)和管理各個(gè)Map/Reduce任務(wù)。與作業(yè)跟蹤器進(jìn)行通信。

Hadoop 1.x集群有兩種類型的節(jié)點(diǎn)：主節(jié)點(diǎn)（master nodes）和從節(jié)點(diǎn)（slave nodes）。

主節(jié)點(diǎn)負(fù)責(zé)執(zhí)行如下幾個(gè)守護(hù)進(jìn)程：

• 名稱節(jié)點(diǎn)進(jìn)程
• 輔助名稱節(jié)點(diǎn)進(jìn)程
• 作業(yè)跟蹤器進(jìn)程

從節(jié)點(diǎn)分布在整個(gè)集群上并執(zhí)行如下幾個(gè)守護(hù)進(jìn)程：

• 數(shù)據(jù)節(jié)點(diǎn)進(jìn)程
• 任務(wù)跟蹤器進(jìn)程

在整個(gè)集群上，雖然每種主節(jié)點(diǎn)守護(hù)進(jìn)程只有一個(gè)運(yùn)行實(shí)例，但是其數(shù)據(jù)節(jié)點(diǎn)進(jìn)程和任務(wù)跟蹤器進(jìn)程有多個(gè)運(yùn)行實(shí)例。在一個(gè)規(guī)模較小的或者用于開發(fā)/測試的集群上，三個(gè)主節(jié)點(diǎn)進(jìn)程全部運(yùn)行在一臺服務(wù)器上。對于生產(chǎn)環(huán)境系統(tǒng)或者規(guī)模較大的集群，三個(gè)主節(jié)點(diǎn)進(jìn)程分別運(yùn)行在不同的服務(wù)器上是明智的選擇。

2.3.1Hadoop 分布式文件系統(tǒng)

Hadoop分布式文件系統(tǒng)(HDFS)用于支持?jǐn)?shù)據(jù)處理程序要處理的大文件。這樣的程序在處理數(shù)據(jù)的時(shí)候，有一次寫、多次讀的特點(diǎn)。

HDFS文件系統(tǒng)由以下幾個(gè)守護(hù)進(jìn)程協(xié)調(diào)地運(yùn)行來提供服務(wù)：

• 名稱節(jié)點(diǎn)進(jìn)程
• 輔助名稱節(jié)點(diǎn)進(jìn)程
• 數(shù)據(jù)節(jié)點(diǎn)進(jìn)程

HDFS系統(tǒng)也是主從架構(gòu)的。運(yùn)行名稱節(jié)點(diǎn)進(jìn)程的服務(wù)器為主節(jié)點(diǎn)，運(yùn)行數(shù)據(jù)節(jié)點(diǎn)進(jìn)程的服務(wù)器為從節(jié)點(diǎn)。一般情況下，集群中的每個(gè)從節(jié)點(diǎn)都會(huì)運(yùn)行一個(gè)數(shù)據(jù)節(jié)點(diǎn)進(jìn)程。這個(gè)數(shù)據(jù)節(jié)點(diǎn)進(jìn)程管理著掛載到這個(gè)數(shù)據(jù)節(jié)點(diǎn)上的存儲設(shè)備。HDFS系統(tǒng)提供一個(gè)統(tǒng)一的文件系統(tǒng)命名空間，用戶就像使用一個(gè)文件系統(tǒng)一樣來存取集群節(jié)點(diǎn)上的數(shù)據(jù)。名稱節(jié)點(diǎn)進(jìn)程負(fù)責(zé)管理這些存儲在集群上的文件的元數(shù)據(jù)。

Hadoop文件的本質(zhì)是塊存儲

首先，你應(yīng)該理解集群中文件的物理存儲方式。在Hadoop系統(tǒng)中，每個(gè)文件被分隔為多個(gè)數(shù)據(jù)塊。一個(gè)典型的數(shù)據(jù)塊大小為64MB，也可以將其配置為32MB或者128MB。在HDFS中，文件塊的大小是按照文件的大小來配置的。如果一個(gè)文件的大小不是一個(gè)文件塊大小的整數(shù)倍，空間也不會(huì)浪費(fèi)很多，因?yàn)橹皇亲詈笠粋€(gè)文件塊未被完全占滿。一個(gè)大文件會(huì)被分隔為多個(gè)數(shù)據(jù)塊來存儲。

每個(gè)數(shù)據(jù)塊存儲在數(shù)據(jù)節(jié)點(diǎn)上。為了防止節(jié)點(diǎn)故障，這些數(shù)據(jù)塊是有備份的。在Hadoop系統(tǒng)中，備份數(shù)量默認(rèn)配置為3。具備機(jī)架感知功能的Hadoop系統(tǒng)把文件的一個(gè)數(shù)據(jù)塊存放在本地機(jī)架上的一臺計(jì)算節(jié)點(diǎn)上（假設(shè)Hadoop客戶端運(yùn)行在本地機(jī)架中的一臺數(shù)據(jù)節(jié)點(diǎn)上，否則，Hadoop客戶端會(huì)隨機(jī)選擇一個(gè)機(jī)架）。這個(gè)數(shù)據(jù)塊的第二個(gè)備份會(huì)被存放在另外一個(gè)遠(yuǎn)程機(jī)架上的計(jì)算節(jié)點(diǎn)中。這個(gè)數(shù)據(jù)塊的第三個(gè)備份會(huì)被存放在第二個(gè)數(shù)據(jù)塊備份機(jī)架上的另一臺計(jì)算節(jié)點(diǎn)中。Hadoop系統(tǒng)借助一個(gè)單獨(dú)配置的網(wǎng)絡(luò)拓?fù)湮募?shí)現(xiàn)機(jī)架感知功能，這個(gè)網(wǎng)絡(luò)拓?fù)湮募渲昧藱C(jī)架到計(jì)算節(jié)點(diǎn)的域名系統(tǒng)（DNS）名稱之間的映射，該網(wǎng)絡(luò)拓?fù)湮募穆窂脚渲迷贖adoop配置文件中。

許多Hadoop系統(tǒng)會(huì)把文件備份因子降為2。運(yùn)行在EMC 公司的Isilon硬件之上的Hadoop系統(tǒng)就是這樣一個(gè)例子。這樣做的原因是這套硬件系統(tǒng)使用了RAID 5的技術(shù)，這個(gè)技術(shù)本身就內(nèi)置了數(shù)據(jù)的冗余備份，從而可以降低Hadoop系統(tǒng)的文件備份因子。降低文件備份因子的一個(gè)很明顯的好處就是提高了系統(tǒng)I/O性能（少寫一個(gè)備份）。這個(gè)鏈接中的白皮書講解了這樣的系統(tǒng)架構(gòu)設(shè)計(jì)：http://www.emc.com/collateral/software/white-papers/h10528-wp-hadoop-on-isilon.pdf。

為什么不把三個(gè)文件數(shù)據(jù)塊的備份分別存放到不同的機(jī)架上呢？畢竟，這樣做可以增加數(shù)據(jù)冗余度。這樣做的話，抵御機(jī)架故障的能力更強(qiáng)，而且還可以增加機(jī)架的數(shù)據(jù)吞吐量。但是，機(jī)架故障的概率遠(yuǎn)低于計(jì)算節(jié)點(diǎn)故障的概率，而且把數(shù)據(jù)塊備份到不同的機(jī)架可導(dǎo)致Hadoop系統(tǒng)寫性能的大幅下降。所以，一個(gè)折中的方案就是把兩個(gè)數(shù)據(jù)塊的備份存放在同一個(gè)遠(yuǎn)程機(jī)架上的不同計(jì)算機(jī)點(diǎn)中，以此換取Hadoop系統(tǒng)寫性能的提高。這種基于Hadoop系統(tǒng)性能限制的巧妙設(shè)計(jì)在Hadoop系統(tǒng)中是很常見的。

2.文件元數(shù)據(jù)和名稱節(jié)點(diǎn)

當(dāng)客戶端向HDFS請求讀取或者存儲一個(gè)文件的時(shí)候，它需要知道要訪問的數(shù)據(jù)節(jié)點(diǎn)是哪一個(gè)。知道這個(gè)信息之后，客戶端可以直接訪問那個(gè)數(shù)據(jù)節(jié)點(diǎn)。文件的元數(shù)據(jù)信息由名稱節(jié)點(diǎn)來負(fù)責(zé)維護(hù)。

HDFS系統(tǒng)提供一個(gè)統(tǒng)一的文件系統(tǒng)命名空間，用戶就像使用一個(gè)文件系統(tǒng)一樣來存取集群節(jié)點(diǎn)上的數(shù)據(jù)。HDFS把存儲在目錄中的文件按照一定的層級展示出來，目錄是可以嵌套的。所有文件和目錄的元數(shù)據(jù)信息都由名稱節(jié)點(diǎn)來負(fù)責(zé)管理。

名稱節(jié)點(diǎn)管理所有的文件操作，包括文件/目錄的打開、關(guān)閉、重命名、移動(dòng)等等。數(shù)據(jù)節(jié)點(diǎn)就負(fù)責(zé)存儲實(shí)際的文件數(shù)據(jù)。這是一個(gè)非常重要的區(qū)別。當(dāng)客戶點(diǎn)請求或者發(fā)送文件數(shù)據(jù)，文件的數(shù)據(jù)在物理上是不經(jīng)過名稱節(jié)點(diǎn)傳輸?shù)摹７駝t這將是一個(gè)極其嚴(yán)重的瓶頸。客戶端僅僅是簡單地從名稱節(jié)點(diǎn)獲取文件的元數(shù)據(jù)，然后根據(jù)其元數(shù)據(jù)信息直接從數(shù)據(jù)節(jié)點(diǎn)獲取文件的數(shù)據(jù)塊。

名稱節(jié)點(diǎn)存儲的一些元數(shù)據(jù)包括：

• 文件/目錄名稱及相對于其父目錄的位置。
• 文件和目錄的所有權(quán)及權(quán)限。
• 各個(gè)數(shù)據(jù)塊的文件名。所有數(shù)據(jù)塊以文件的形式存放在數(shù)據(jù)節(jié)點(diǎn)的本地文件系統(tǒng)的目錄中，該目錄可以被Hadoop系統(tǒng)管理員配置。

需要注意的是名稱節(jié)點(diǎn)并不存儲每個(gè)數(shù)據(jù)塊的位置（數(shù)據(jù)節(jié)點(diǎn)的身份信息）。數(shù)據(jù)節(jié)點(diǎn)的身份信息（DataNode identity）在集群啟動(dòng)的時(shí)候從每個(gè)數(shù)據(jù)節(jié)點(diǎn)獲取。名稱節(jié)點(diǎn)維護(hù)的信息是，HDFS上的文件由哪些數(shù)據(jù)塊（數(shù)據(jù)節(jié)點(diǎn)上每個(gè)數(shù)據(jù)塊的文件名）組成。

元數(shù)據(jù)存儲在名稱節(jié)點(diǎn)的本地磁盤上，但是為了快速訪問，在集群操作的時(shí)候會(huì)把這些元信息加載到內(nèi)存。這個(gè)策略對于提高Hadoop系統(tǒng)的操作性能是很關(guān)鍵的，但是同時(shí)也成為了Hadoop系統(tǒng)的一個(gè)瓶頸，由此催生出了Hadoop 2.x系統(tǒng)。

每個(gè)元數(shù)據(jù)信息大約占用200字節(jié)的RAM。假設(shè)一個(gè)1GB大小的文件，數(shù)據(jù)塊的大小為64MB。這么大的一個(gè)文件需要16×3（包括文件備份數(shù)量）＝48個(gè)數(shù)據(jù)塊的存儲量。現(xiàn)在假設(shè)有1000個(gè)文件，每個(gè)文件的大小為1MB。這么大的一個(gè)文件需要1000×3（包括文件備份數(shù)量）＝3000 個(gè)數(shù)據(jù)塊的存儲量（每個(gè)文件只需要占用數(shù)據(jù)塊1MB的存儲空間即可，但是多個(gè)文件不能存儲在同一個(gè)數(shù)據(jù)塊中）。這樣的話，元數(shù)據(jù)的數(shù)據(jù)量將會(huì)大幅增長。這將會(huì)導(dǎo)致名稱節(jié)點(diǎn)更大量的內(nèi)存占用。這個(gè)例子也解釋了為什么Hadoop系統(tǒng)更適合存儲大文件，而不適合存儲大量的小文件。海量的小文件會(huì)輕易地拖垮名稱節(jié)點(diǎn)服務(wù)器。

名稱節(jié)點(diǎn)服務(wù)器上存放元數(shù)據(jù)的文件為fsimage。Hadoop系統(tǒng)運(yùn)行期間任何涉及對元數(shù)據(jù)修改的操作都保存在內(nèi)存中，并且被持久存儲到另外一個(gè)名為edits的文件。輔助名稱節(jié)點(diǎn)會(huì)周期性地把edits文件中的信息合并到fsimage文件中。（當(dāng)我們在講解輔助名稱節(jié)點(diǎn)的時(shí)候，會(huì)深入細(xì)致地分析這個(gè)合并過程。）保存到HDFS上的實(shí)際文件數(shù)據(jù)并不會(huì)存放在fsimage和edits文件中，實(shí)際的數(shù)據(jù)存放在運(yùn)行著數(shù)據(jù)節(jié)點(diǎn)守護(hù)進(jìn)程的從節(jié)點(diǎn)的數(shù)據(jù)塊中。正如前文講到的，這些數(shù)據(jù)塊以文件的形式存放在集群的從節(jié)點(diǎn)中。這些數(shù)據(jù)塊中存放的是文件的原始數(shù)據(jù)，不存放文件元數(shù)據(jù)。但是，如果名稱節(jié)點(diǎn)中保存的元數(shù)據(jù)丟失了，會(huì)導(dǎo)致整個(gè)集群不可用。名稱節(jié)點(diǎn)中的元數(shù)據(jù)為客戶端提供了數(shù)據(jù)塊的信息，這些存放在從節(jié)點(diǎn)中的數(shù)據(jù)塊存有文件的真實(shí)數(shù)據(jù)。

數(shù)據(jù)節(jié)點(diǎn)守護(hù)進(jìn)程周期性的發(fā)送心跳信息給名稱節(jié)點(diǎn)。這使得名稱節(jié)點(diǎn)可以感知所有數(shù)據(jù)節(jié)點(diǎn)的健康狀況，從而，客戶端的請求不會(huì)被發(fā)送到故障數(shù)據(jù)節(jié)點(diǎn)。

HDFS系統(tǒng)寫文件的機(jī)制

一個(gè)HDFS文件系統(tǒng)的寫操作涉及文件的創(chuàng)建。從客戶端的角度來看，HDFS系統(tǒng)不支持文件的更新。（這樣說并不十分準(zhǔn)確，因?yàn)樵贖Base中已經(jīng)使用了HDFS系統(tǒng)的文件追加特性。但是，不建議客戶端使用這樣的功能。）在下文的講述中，我們假定HDFS文件系統(tǒng)的默認(rèn)備份因子為3。

圖2-3用圖表的形式描述了HDFS文件系統(tǒng)寫操作過程，通過這張圖表我們對整個(gè)操作過程有了一個(gè)大致的認(rèn)識。

客戶端把一個(gè)文件寫入到HDFS文件系統(tǒng)需要經(jīng)過以下幾個(gè)步驟：

1）客戶端在聯(lián)系名稱節(jié)點(diǎn)之前，會(huì)把文件數(shù)據(jù)流式地讀入（streaming the file contents）到客戶端本地文件系統(tǒng)中的一個(gè)臨時(shí)文件中。

2）當(dāng)文件數(shù)據(jù)的大小達(dá)到一個(gè)數(shù)據(jù)塊的大小時(shí)，客戶端就聯(lián)系名稱節(jié)點(diǎn)。

3）名稱節(jié)點(diǎn)會(huì)在HDFS文件系統(tǒng)的層級結(jié)構(gòu)中創(chuàng)建一個(gè)文件，然后把數(shù)據(jù)塊的標(biāo)識符和數(shù)據(jù)節(jié)點(diǎn)上的位置信息發(fā)送給客戶端。這個(gè)數(shù)據(jù)節(jié)點(diǎn)數(shù)據(jù)塊信息列表里面還包括了其備份節(jié)點(diǎn)的數(shù)據(jù)塊信息列表。

4）進(jìn)行完上述的步驟之后，客戶端就會(huì)根據(jù)上一步的數(shù)據(jù)塊信息把本地臨時(shí)文件中的數(shù)據(jù)刷新（flush）到集群上的數(shù)據(jù)塊中（只寫入到第一個(gè)數(shù)據(jù)節(jié)點(diǎn)中）。這樣，真實(shí)的文件數(shù)據(jù)就放在了集群數(shù)據(jù)節(jié)點(diǎn)本地文件存儲系統(tǒng)中。

5）當(dāng)文件（客戶端可以訪問的HDFS文件）被關(guān)閉時(shí)，名稱節(jié)點(diǎn)會(huì)執(zhí)行一個(gè)提交操作，從而使得該文件在集群中為可見狀態(tài)。如果在提交操作完成之前名稱節(jié)點(diǎn)掛掉了，這個(gè)文件就丟失了。

其中步驟4我們要拿出來詳細(xì)講解一下，這個(gè)步驟中的刷新操作過程如下：

1）第一個(gè)數(shù)據(jù)節(jié)點(diǎn)以數(shù)據(jù)包（其大小一般為4KB）的形式從客戶端接收數(shù)據(jù)。當(dāng)這一小部分?jǐn)?shù)據(jù)寫入到第一個(gè)數(shù)據(jù)節(jié)點(diǎn)的本地存儲中時(shí)，它還會(huì)被傳送到第二個(gè)數(shù)據(jù)節(jié)點(diǎn)中保存。

2）當(dāng)?shù)诙€(gè)數(shù)據(jù)節(jié)點(diǎn)開始把數(shù)據(jù)塊寫入到本地磁盤時(shí)，這個(gè)包含文件數(shù)據(jù)塊的數(shù)據(jù)包會(huì)被同時(shí)傳送到第三個(gè)數(shù)據(jù)節(jié)點(diǎn)。

3）最終，這個(gè)包含文件數(shù)據(jù)的數(shù)據(jù)包寫入到第三個(gè)數(shù)據(jù)節(jié)點(diǎn)中，此時(shí)，這部分的文件數(shù)據(jù)及其備份就以數(shù)據(jù)管道的方式存放到HDFS文件系統(tǒng)中。

4）保存包含文件數(shù)據(jù)的數(shù)據(jù)包成功之后，其確認(rèn)包（acknowledgment packet）會(huì)從保存了該數(shù)據(jù)包的計(jì)算節(jié)點(diǎn)通過數(shù)據(jù)管道返回給前一個(gè)保存了該數(shù)據(jù)包的計(jì)算節(jié)點(diǎn)。最后，第一個(gè)數(shù)據(jù)節(jié)點(diǎn)會(huì)發(fā)送確認(rèn)包到客戶端。

5）當(dāng)客戶端接收到了數(shù)據(jù)塊保存成功的確認(rèn)，數(shù)據(jù)塊就被認(rèn)為是持久地存儲到了集群中的計(jì)算節(jié)點(diǎn)上。客戶端會(huì)發(fā)送最終的確認(rèn)信息給名稱節(jié)點(diǎn)。

6）在數(shù)據(jù)管道中的任何數(shù)據(jù)節(jié)點(diǎn)發(fā)生故障，數(shù)據(jù)管道就會(huì)關(guān)閉。文件數(shù)據(jù)將會(huì)被寫入其他數(shù)據(jù)節(jié)點(diǎn)。名稱節(jié)點(diǎn)會(huì)感知到文件數(shù)據(jù)沒有備份完成，就會(huì)執(zhí)行重新備份的過程，把數(shù)據(jù)備份到狀態(tài)良好的節(jié)點(diǎn)，以確保達(dá)到要求的文件備份水平。

7）每個(gè)數(shù)據(jù)塊都會(huì)有一個(gè)校驗(yàn)和，這個(gè)校驗(yàn)和用來檢測數(shù)據(jù)塊的完整性。這些校驗(yàn)和存放在HDFS中另外一個(gè)隱藏的文件中，當(dāng)讀取數(shù)據(jù)塊的時(shí)候用來校驗(yàn)數(shù)據(jù)塊的完整性。

HDFS系統(tǒng)讀文件的機(jī)制

現(xiàn)在我們來講解如何從HDFS中讀取一個(gè)文件。圖2-4展示了HDFS系統(tǒng)讀文件的過程。

客戶端從HDFS中讀取文件的步驟為：

1）客戶端訪問名稱節(jié)點(diǎn)，名稱節(jié)點(diǎn)返回組成文件的數(shù)據(jù)塊列表及數(shù)據(jù)塊的位置（包括備份數(shù)據(jù)塊的位置）。

2）客戶端會(huì)直接訪問數(shù)據(jù)節(jié)點(diǎn)以獲取數(shù)據(jù)塊中的數(shù)據(jù)。如果此時(shí)其訪問的數(shù)據(jù)節(jié)點(diǎn)出現(xiàn)故障，就會(huì)訪問存放備份數(shù)據(jù)塊的數(shù)據(jù)節(jié)點(diǎn)。

3）讀取數(shù)據(jù)塊的時(shí)候會(huì)計(jì)算該數(shù)據(jù)塊的校驗(yàn)和，并將該校驗(yàn)和與寫入文件時(shí)的校驗(yàn)和作比較。如果檢驗(yàn)失敗，則從其他數(shù)據(jù)節(jié)點(diǎn)獲取備份數(shù)據(jù)塊。

HDFS系統(tǒng)刪除文件的機(jī)制

在HDFS系統(tǒng)上刪除一個(gè)文件，遵從以下步驟：

1）名稱節(jié)點(diǎn)僅僅重命名了文件路徑，使其移動(dòng)到了/trash目錄。需要注意的是，這個(gè)操作過程是鏈接到重命名文件路徑的元數(shù)據(jù)的更新操作。這個(gè)執(zhí)行過程非常迅速。/trash 目錄中的文件會(huì)保存一段時(shí)間，這個(gè)保存時(shí)間是預(yù)先確定的（當(dāng)前設(shè)定為6小時(shí)而且當(dāng)前不可配置）。在這段時(shí)間內(nèi)，把刪除的文件從/trash目錄中移動(dòng)出來即可迅速地恢復(fù)該文件。

2）當(dāng)/trash目錄中的文件超過了保存時(shí)間時(shí)，名稱節(jié)點(diǎn)就會(huì)將該文件從HDFS命名空間中刪除。

3）刪除文件會(huì)使得該文件相關(guān)的數(shù)據(jù)塊被釋放，HDFS系統(tǒng)隨后會(huì)顯示增加了一些空閑空間。

HDFS系統(tǒng)中的文件備份因子是可變的，它可以減小。通過一次心跳信息，這個(gè)文件備份因子的變化信息就可以由名稱節(jié)點(diǎn)發(fā)出，數(shù)據(jù)節(jié)點(diǎn)就會(huì)動(dòng)態(tài)地從本地存儲系統(tǒng)中刪除相應(yīng)的數(shù)據(jù)塊，這樣一來，集群就會(huì)有更多的空閑存儲空間了。所以，名稱節(jié)點(diǎn)可以動(dòng)態(tài)維護(hù)文件的備份數(shù)量。

6.確保HDFS系統(tǒng)的可靠性

Hadoop系統(tǒng)和HDFS系統(tǒng)都有很強(qiáng)的抗故障能力。在以下兩種情況下會(huì)造成數(shù)據(jù)丟失：

• 數(shù)據(jù)節(jié)點(diǎn)故障：每個(gè)數(shù)據(jù)節(jié)點(diǎn)周期性地發(fā)送心跳信息到名稱節(jié)點(diǎn)（默認(rèn)3秒鐘一次）。如果名稱節(jié)點(diǎn)在預(yù)先設(shè)定的時(shí)間段內(nèi)沒有收到心跳信息，它就會(huì)認(rèn)為數(shù)據(jù)節(jié)點(diǎn)有故障了。此刻，名稱節(jié)點(diǎn)就會(huì)主動(dòng)地對存儲在故障數(shù)據(jù)節(jié)點(diǎn)上的數(shù)據(jù)塊重新備份，把相關(guān)數(shù)據(jù)塊（從其他健康節(jié)點(diǎn)的備份數(shù)據(jù)塊獲取）轉(zhuǎn)移到狀態(tài)健康的數(shù)據(jù)節(jié)點(diǎn)。這樣就可以確保數(shù)據(jù)塊備份數(shù)量不變。
• 位腐（bit rot）現(xiàn)象導(dǎo)致的數(shù)據(jù)損壞：這是指當(dāng)電荷（在傳輸過程中）發(fā)生衰減而導(dǎo)致的數(shù)據(jù)丟失的情況。在HDFS系統(tǒng)讀取數(shù)據(jù)塊的操作過程中會(huì)進(jìn)行數(shù)據(jù)校驗(yàn)和核對，這種情況的數(shù)據(jù)損壞就會(huì)被發(fā)現(xiàn)。如果數(shù)據(jù)塊的校驗(yàn)失敗了，便認(rèn)為這個(gè)數(shù)據(jù)塊已經(jīng)損壞，就會(huì)讀取該數(shù)據(jù)塊的備份，然后名稱節(jié)點(diǎn)會(huì)重新備份這個(gè)損壞了數(shù)據(jù)塊，使得數(shù)據(jù)塊的備份數(shù)量達(dá)到預(yù)先設(shè)定的數(shù)據(jù)塊備份數(shù)量。

2.3.2輔助名稱節(jié)點(diǎn)

現(xiàn)在我們來討論輔助名稱節(jié)點(diǎn)在Hadoop系統(tǒng)中的角色。這個(gè)組件因?yàn)樗缓线m的名字而導(dǎo)致很多錯(cuò)誤的理解。輔助名稱節(jié)點(diǎn)不是用于進(jìn)行故障切換的節(jié)點(diǎn)。

通過前文，我們知道名稱節(jié)點(diǎn)在內(nèi)存中維護(hù)著所有的元數(shù)據(jù)。名稱節(jié)點(diǎn)最先從存放在本地文件系統(tǒng)中的fsimage文件將元數(shù)據(jù)加載到內(nèi)存中。在Hadoop系統(tǒng)中的一系列操作運(yùn)行過程中，元數(shù)據(jù)信息在內(nèi)存中不斷更新。為了防止數(shù)據(jù)丟失，這些數(shù)據(jù)操作記錄還會(huì)被持久存儲到另外一個(gè)名為edits的本地文件中。

fsimage文件并不實(shí)際存儲各個(gè)數(shù)據(jù)塊的位置。這些信息是Hadoop系統(tǒng)在每個(gè)數(shù)據(jù)節(jié)點(diǎn)啟動(dòng)的時(shí)候，名稱節(jié)點(diǎn)從每個(gè)數(shù)據(jù)節(jié)點(diǎn)獲取的，并被存放在名稱節(jié)點(diǎn)的內(nèi)存中。

edits文件是用來在Hadoop系統(tǒng)運(yùn)行期間收集元數(shù)據(jù)的變化的。如果Hadoop系統(tǒng)重啟了，在Hadoop重啟的過程中，edits文件中的內(nèi)容會(huì)與fsimage文件中的內(nèi)容合并。顯然，這會(huì)拖慢Hadoop系統(tǒng)的重啟時(shí)間。輔助名稱節(jié)點(diǎn)就是來處理這個(gè)問題的。

輔助名稱節(jié)點(diǎn)的作用就是周期性地把edits文件中的內(nèi)容與fsimage文件中的內(nèi)容合并。為此目的，輔助名稱節(jié)點(diǎn)會(huì)周期性地順序執(zhí)行下列步驟：

1）輔助名稱節(jié)點(diǎn)會(huì)請求名稱節(jié)點(diǎn)來結(jié)轉(zhuǎn)（roll over）edits文件，確保新的更新保存到一個(gè)新的文件。這個(gè)新的文件名字叫做edits.new。

2）輔助名稱節(jié)點(diǎn)向名稱節(jié)點(diǎn)請求獲取fsimage文件和edits文件。

3）輔助名稱節(jié)點(diǎn)把edits文件和fsimage文件合并，生成一個(gè)新的fsimage文件。

4）名稱節(jié)點(diǎn)從輔助名稱節(jié)點(diǎn)接收到新生成的fsimage文件，并替代舊的fsimage文件。同時(shí)將edits文件中的內(nèi)容替換成步驟1中創(chuàng)建的edit.new文件的內(nèi)容。

5）更新fstime文件來記錄發(fā)生的檢查點(diǎn)操作。

現(xiàn)在應(yīng)該很清楚為什么名稱節(jié)點(diǎn)可以導(dǎo)致Hadoop 1.x系統(tǒng)單點(diǎn)故障。如果edits文件和fsimage文件數(shù)據(jù)損壞了，存放在HDFS系統(tǒng)上的所有數(shù)據(jù)都會(huì)丟失。所以，集群中的數(shù)據(jù)節(jié)點(diǎn)可以是安裝了JBOD（不使用RAID技術(shù)的數(shù)組硬盤）的商用服務(wù)器，而名稱節(jié)點(diǎn)和輔助名稱節(jié)點(diǎn)必須安裝了更為可靠的存儲系統(tǒng)（基于RAID技術(shù)的存儲系統(tǒng)），以確保數(shù)據(jù)不丟失。前面提到的那兩個(gè)文件還必須要定期備份。如果這兩個(gè)文件需要從其備份文件恢復(fù)，那么從當(dāng)前到備份時(shí)刻所有的數(shù)據(jù)操作都會(huì)丟失。表2-1總結(jié)了HDFS系統(tǒng)中名稱節(jié)點(diǎn)上的關(guān)鍵文件。

2.3.3任務(wù)跟蹤器

任務(wù)跟蹤器（TaskTracker）守護(hù)進(jìn)程在集群中每臺計(jì)算節(jié)點(diǎn)中運(yùn)行，接收諸如Map、Reduce和Shuffle這些操作任務(wù)的請求。每個(gè)任務(wù)跟蹤器都會(huì)分配一定的槽位數(shù)（a set of slots），其槽位數(shù)的數(shù)量一般與計(jì)算節(jié)點(diǎn)上可用的CPU核數(shù)一致。任務(wù)跟蹤器接收到一個(gè)（來自作業(yè)跟蹤器）的請求之后，就會(huì)啟動(dòng)一個(gè)任務(wù)（task），任務(wù)跟蹤器會(huì)為這個(gè)任務(wù)初始化一個(gè)新的JVM。JVM重用是可以的，但這項(xiàng)功能在實(shí)際用法示例中并不常見。使用Hadoop 平臺的大多數(shù)用戶都將該功能關(guān)閉了。任務(wù)跟蹤器分配一項(xiàng)任務(wù)取決于它的可用槽位（slots）數(shù)量（槽位數(shù)量＝實(shí)際運(yùn)行的任務(wù)數(shù)量）。任務(wù)跟蹤器負(fù)責(zé)向作業(yè)跟蹤器（JobTracker）發(fā)送心跳消息。除了向作業(yè)跟蹤器反饋任務(wù)跟蹤器的運(yùn)行狀況之外，心跳信息中還包括了任務(wù)跟蹤器當(dāng)前可用的槽位數(shù)量。

2.3.4作業(yè)跟蹤器

作業(yè)跟蹤器（JobTracker）守護(hù)進(jìn)程負(fù)責(zé)啟動(dòng)和監(jiān)控MapReduce作業(yè)。當(dāng)一個(gè)客戶端向Hadoop系統(tǒng)提交一個(gè)作業(yè)，作業(yè)的啟動(dòng)流程如圖2-5所示。

該過程的詳細(xì)步驟如下：

1）作業(yè)跟蹤器接收到了作業(yè)請求。

2）大多數(shù)的MapReduce作業(yè)都需要一個(gè)或多個(gè)輸入文件目錄。任務(wù)跟蹤器向名稱節(jié)點(diǎn)發(fā)出請求，獲得一個(gè)數(shù)據(jù)節(jié)點(diǎn)的列表，這個(gè)列表上的數(shù)據(jù)節(jié)點(diǎn)中存儲了組成輸入文件數(shù)據(jù)的數(shù)據(jù)塊。

3）作業(yè)跟蹤器為作業(yè)的執(zhí)行做準(zhǔn)備工作。在這個(gè)步驟中，任務(wù)跟蹤器確定執(zhí)行該作業(yè)需要的任務(wù)（Map任務(wù)和Reduce任務(wù)）數(shù)量。作業(yè)跟蹤器盡量把這些任務(wù)都調(diào)度到離數(shù)據(jù)塊最近的位置上運(yùn)行。

4）作業(yè)跟蹤器把任務(wù)提交到每個(gè)任務(wù)跟蹤器節(jié)點(diǎn)去執(zhí)行。任務(wù)跟蹤器節(jié)點(diǎn)監(jiān)控任務(wù)執(zhí)行情況。任務(wù)跟蹤器以預(yù)先設(shè)定的時(shí)間間隔發(fā)送心跳信息到作業(yè)跟蹤器。如果作業(yè)跟蹤器在預(yù)先設(shè)定的時(shí)間間隔之后，沒有收到任務(wù)跟蹤器發(fā)來的心跳信息，那么就認(rèn)為該任務(wù)跟蹤器節(jié)點(diǎn)出現(xiàn)故障，任務(wù)就會(huì)被調(diào)度到另外一個(gè)節(jié)點(diǎn)去運(yùn)行。

5）一旦所有的任務(wù)都執(zhí)行完畢，作業(yè)跟蹤器就會(huì)更新作業(yè)狀態(tài)為成功。如果任務(wù)反復(fù)失敗達(dá)到一定的數(shù)量（這個(gè)數(shù)值可以通過Hadoop系統(tǒng)的配置文件來指定），作業(yè)跟蹤器就會(huì)宣布作業(yè)運(yùn)行失敗。

6）客戶端會(huì)輪詢作業(yè)跟蹤器及時(shí)地獲得作業(yè)運(yùn)行狀態(tài)。

到目前為止對Hadoop 1.x系統(tǒng)組件的講解，可以很清楚地知道，作業(yè)跟蹤器的故障會(huì)導(dǎo)致Hadoop系統(tǒng)的單點(diǎn)故障。如果作業(yè)跟蹤器節(jié)點(diǎn)掛掉，集群上所有的任務(wù)都將無法正確運(yùn)行。同樣，由于僅有一個(gè)作業(yè)跟蹤器節(jié)點(diǎn)運(yùn)行，在多任務(wù)同時(shí)運(yùn)行的系統(tǒng)環(huán)境中，會(huì)增加該作業(yè)跟蹤器節(jié)點(diǎn)的工作負(fù)載。

總結(jié)

以上是生活随笔為你收集整理的《深入理解Hadoop（原书第2版）》——2.3Hadoop系统的组成的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。