《深入理解Hadoop（原书第2版）》——2.3Hadoop系统的组成
本節書摘來自華章計算機《深入理解Hadoop（原書第2版）》一書中的第2章，第2.3節，作者 [美]薩米爾·瓦德卡（Sameer Wadkar），馬杜·西德林埃（Madhu Siddalingaiah），杰森·文納（Jason Venner），譯 于博，馮傲風，更多章節內容可以訪問云棲社區“華章計算機”公眾號查看。
2.3Hadoop系統的組成
本節內容會細致深入地講解Hadoop系統的各個組成部分。我們先介紹構成Hadoop 1.x 系統的組件，再介紹構成Hadoop 2.x 系統的新組件。宏觀上說，Hadoop 1.x系統有以下幾個守護進程：
- 名稱節點（NameNode）：維護著存儲在HDFS上的所有文件的元數據信息。這些元數據信息包括組成文件的數據塊信息，及這些數據塊在數據節點上的位置。正如你將看到的，這個組件正是使用Hadoop 1.x搭建大型計算集群系統的瓶頸所在。
- 輔助名稱節點（Secondary NameNode）：這不是名稱節點的熱備份。實際上，它作為Hadoop平臺的一個組件，其命名不是很恰當。它為名稱節點組件執行一些內務處理功能（housekeeping functions）。
- 數據節點（DataNode）：把真正的數據塊存放在本地硬盤上，這些數據塊組成了保存在HDFS上的每個文件。
- 作業跟蹤器（JobTracker）：這是Hadoop系統的主要組件之一，它負責一個任務的整個執行過程。它的具體功能包括：調度各個子任務（Mapper任務和Reducer任務各自的子任務）到各自的計算節點運行，時刻監控任務運行和計算節點的健康狀況，對失敗的子任務重新調度執行。正如我們即將演示的，就像名稱節點一樣，這個組件是使用Hadoop 1.x搭建大型計算集群系統的瓶頸所在。
- 任務跟蹤器（TaskTracker）：運行在各個數據節點上，用來啟動和管理各個Map/Reduce任務。與作業跟蹤器進行通信。
Hadoop 1.x集群有兩種類型的節點：主節點（master nodes）和從節點（slave nodes）。
主節點負責執行如下幾個守護進程：
- 名稱節點進程
- 輔助名稱節點進程
- 作業跟蹤器進程
從節點分布在整個集群上并執行如下幾個守護進程：
- 數據節點進程
- 任務跟蹤器進程
在整個集群上，雖然每種主節點守護進程只有一個運行實例，但是其數據節點進程和任務跟蹤器進程有多個運行實例。在一個規模較小的或者用于開發/測試的集群上，三個主節點進程全部運行在一臺服務器上。對于生產環境系統或者規模較大的集群，三個主節點進程分別運行在不同的服務器上是明智的選擇。
2.3.1Hadoop 分布式文件系統
Hadoop分布式文件系統(HDFS)用于支持數據處理程序要處理的大文件。這樣的程序在處理數據的時候，有一次寫、多次讀的特點。
HDFS文件系統由以下幾個守護進程協調地運行來提供服務：
- 名稱節點進程
- 輔助名稱節點進程
- 數據節點進程
HDFS系統也是主從架構的。運行名稱節點進程的服務器為主節點，運行數據節點進程的服務器為從節點。一般情況下，集群中的每個從節點都會運行一個數據節點進程。這個數據節點進程管理著掛載到這個數據節點上的存儲設備。HDFS系統提供一個統一的文件系統命名空間，用戶就像使用一個文件系統一樣來存取集群節點上的數據。名稱節點進程負責管理這些存儲在集群上的文件的元數據。
首先，你應該理解集群中文件的物理存儲方式。在Hadoop系統中，每個文件被分隔為多個數據塊。一個典型的數據塊大小為64MB，也可以將其配置為32MB或者128MB。在HDFS中，文件塊的大小是按照文件的大小來配置的。如果一個文件的大小不是一個文件塊大小的整數倍，空間也不會浪費很多，因為只是最后一個文件塊未被完全占滿。一個大文件會被分隔為多個數據塊來存儲。
每個數據塊存儲在數據節點上。為了防止節點故障，這些數據塊是有備份的。在Hadoop系統中，備份數量默認配置為3。具備機架感知功能的Hadoop系統把文件的一個數據塊存放在本地機架上的一臺計算節點上（假設Hadoop客戶端運行在本地機架中的一臺數據節點上，否則，Hadoop客戶端會隨機選擇一個機架）。這個數據塊的第二個備份會被存放在另外一個遠程機架上的計算節點中。這個數據塊的第三個備份會被存放在第二個數據塊備份機架上的另一臺計算節點中。Hadoop系統借助一個單獨配置的網絡拓撲文件實現機架感知功能，這個網絡拓撲文件配置了機架到計算節點的域名系統（DNS）名稱之間的映射，該網絡拓撲文件的路徑配置在Hadoop配置文件中。
許多Hadoop系統會把文件備份因子降為2。運行在EMC 公司的Isilon硬件之上的Hadoop系統就是這樣一個例子。這樣做的原因是這套硬件系統使用了RAID 5的技術，這個技術本身就內置了數據的冗余備份，從而可以降低Hadoop系統的文件備份因子。降低文件備份因子的一個很明顯的好處就是提高了系統I/O性能（少寫一個備份）。這個鏈接中的白皮書講解了這樣的系統架構設計：http://www.emc.com/collateral/software/white-papers/h10528-wp-hadoop-on-isilon.pdf。
為什么不把三個文件數據塊的備份分別存放到不同的機架上呢？畢竟，這樣做可以增加數據冗余度。這樣做的話，抵御機架故障的能力更強，而且還可以增加機架的數據吞吐量。但是，機架故障的概率遠低于計算節點故障的概率，而且把數據塊備份到不同的機架可導致Hadoop系統寫性能的大幅下降。所以，一個折中的方案就是把兩個數據塊的備份存放在同一個遠程機架上的不同計算機點中，以此換取Hadoop系統寫性能的提高。這種基于Hadoop系統性能限制的巧妙設計在Hadoop系統中是很常見的。
2.文件元數據和名稱節點
當客戶端向HDFS請求讀取或者存儲一個文件的時候，它需要知道要訪問的數據節點是哪一個。知道這個信息之后，客戶端可以直接訪問那個數據節點。文件的元數據信息由名稱節點來負責維護。
HDFS系統提供一個統一的文件系統命名空間，用戶就像使用一個文件系統一樣來存取集群節點上的數據。HDFS把存儲在目錄中的文件按照一定的層級展示出來，目錄是可以嵌套的。所有文件和目錄的元數據信息都由名稱節點來負責管理。
名稱節點管理所有的文件操作，包括文件/目錄的打開、關閉、重命名、移動等等。數據節點就負責存儲實際的文件數據。這是一個非常重要的區別。當客戶點請求或者發送文件數據，文件的數據在物理上是不經過名稱節點傳輸的。否則這將是一個極其嚴重的瓶頸。客戶端僅僅是簡單地從名稱節點獲取文件的元數據，然后根據其元數據信息直接從數據節點獲取文件的數據塊。
名稱節點存儲的一些元數據包括：
- 文件/目錄名稱及相對于其父目錄的位置。
- 文件和目錄的所有權及權限。
- 各個數據塊的文件名。所有數據塊以文件的形式存放在數據節點的本地文件系統的目錄中，該目錄可以被Hadoop系統管理員配置。
需要注意的是名稱節點并不存儲每個數據塊的位置（數據節點的身份信息）。數據節點的身份信息（DataNode identity）在集群啟動的時候從每個數據節點獲取。名稱節點維護的信息是，HDFS上的文件由哪些數據塊（數據節點上每個數據塊的文件名）組成。
元數據存儲在名稱節點的本地磁盤上，但是為了快速訪問，在集群操作的時候會把這些元信息加載到內存。這個策略對于提高Hadoop系統的操作性能是很關鍵的，但是同時也成為了Hadoop系統的一個瓶頸，由此催生出了Hadoop 2.x系統。
每個元數據信息大約占用200字節的RAM。假設一個1GB大小的文件，數據塊的大小為64MB。這么大的一個文件需要16×3（包括文件備份數量）＝48個數據塊的存儲量。現在假設有1000個文件，每個文件的大小為1MB。這么大的一個文件需要1000×3（包括文件備份數量）＝3000 個數據塊的存儲量（每個文件只需要占用數據塊1MB的存儲空間即可，但是多個文件不能存儲在同一個數據塊中）。這樣的話，元數據的數據量將會大幅增長。這將會導致名稱節點更大量的內存占用。這個例子也解釋了為什么Hadoop系統更適合存儲大文件，而不適合存儲大量的小文件。海量的小文件會輕易地拖垮名稱節點服務器。
名稱節點服務器上存放元數據的文件為fsimage。Hadoop系統運行期間任何涉及對元數據修改的操作都保存在內存中，并且被持久存儲到另外一個名為edits的文件。輔助名稱節點會周期性地把edits文件中的信息合并到fsimage文件中。（當我們在講解輔助名稱節點的時候，會深入細致地分析這個合并過程。）保存到HDFS上的實際文件數據并不會存放在fsimage和edits文件中，實際的數據存放在運行著數據節點守護進程的從節點的數據塊中。正如前文講到的，這些數據塊以文件的形式存放在集群的從節點中。這些數據塊中存放的是文件的原始數據，不存放文件元數據。但是，如果名稱節點中保存的元數據丟失了，會導致整個集群不可用。名稱節點中的元數據為客戶端提供了數據塊的信息，這些存放在從節點中的數據塊存有文件的真實數據。
數據節點守護進程周期性的發送心跳信息給名稱節點。這使得名稱節點可以感知所有數據節點的健康狀況，從而，客戶端的請求不會被發送到故障數據節點。
一個HDFS文件系統的寫操作涉及文件的創建。從客戶端的角度來看，HDFS系統不支持文件的更新。（這樣說并不十分準確，因為在HBase中已經使用了HDFS系統的文件追加特性。但是，不建議客戶端使用這樣的功能。）在下文的講述中，我們假定HDFS文件系統的默認備份因子為3。
圖2-3用圖表的形式描述了HDFS文件系統寫操作過程，通過這張圖表我們對整個操作過程有了一個大致的認識。
客戶端把一個文件寫入到HDFS文件系統需要經過以下幾個步驟：
1）客戶端在聯系名稱節點之前，會把文件數據流式地讀入（streaming the file contents）到客戶端本地文件系統中的一個臨時文件中。
2）當文件數據的大小達到一個數據塊的大小時，客戶端就聯系名稱節點。
3）名稱節點會在HDFS文件系統的層級結構中創建一個文件，然后把數據塊的標識符和數據節點上的位置信息發送給客戶端。這個數據節點數據塊信息列表里面還包括了其備份節點的數據塊信息列表。
4）進行完上述的步驟之后，客戶端就會根據上一步的數據塊信息把本地臨時文件中的數據刷新（flush）到集群上的數據塊中（只寫入到第一個數據節點中）。這樣，真實的文件數據就放在了集群數據節點本地文件存儲系統中。
5）當文件（客戶端可以訪問的HDFS文件）被關閉時，名稱節點會執行一個提交操作，從而使得該文件在集群中為可見狀態。如果在提交操作完成之前名稱節點掛掉了，這個文件就丟失了。
其中步驟4我們要拿出來詳細講解一下，這個步驟中的刷新操作過程如下：
1）第一個數據節點以數據包（其大小一般為4KB）的形式從客戶端接收數據。當這一小部分數據寫入到第一個數據節點的本地存儲中時，它還會被傳送到第二個數據節點中保存。
2）當第二個數據節點開始把數據塊寫入到本地磁盤時，這個包含文件數據塊的數據包會被同時傳送到第三個數據節點。
3）最終，這個包含文件數據的數據包寫入到第三個數據節點中，此時，這部分的文件數據及其備份就以數據管道的方式存放到HDFS文件系統中。
4）保存包含文件數據的數據包成功之后，其確認包（acknowledgment packet）會從保存了該數據包的計算節點通過數據管道返回給前一個保存了該數據包的計算節點。最后，第一個數據節點會發送確認包到客戶端。
5）當客戶端接收到了數據塊保存成功的確認，數據塊就被認為是持久地存儲到了集群中的計算節點上。客戶端會發送最終的確認信息給名稱節點。
6）在數據管道中的任何數據節點發生故障，數據管道就會關閉。文件數據將會被寫入其他數據節點。名稱節點會感知到文件數據沒有備份完成，就會執行重新備份的過程，把數據備份到狀態良好的節點，以確保達到要求的文件備份水平。
7）每個數據塊都會有一個校驗和，這個校驗和用來檢測數據塊的完整性。這些校驗和存放在HDFS中另外一個隱藏的文件中，當讀取數據塊的時候用來校驗數據塊的完整性。
現在我們來講解如何從HDFS中讀取一個文件。圖2-4展示了HDFS系統讀文件的過程。
客戶端從HDFS中讀取文件的步驟為：
1）客戶端訪問名稱節點，名稱節點返回組成文件的數據塊列表及數據塊的位置（包括備份數據塊的位置）。
2）客戶端會直接訪問數據節點以獲取數據塊中的數據。如果此時其訪問的數據節點出現故障，就會訪問存放備份數據塊的數據節點。
3）讀取數據塊的時候會計算該數據塊的校驗和，并將該校驗和與寫入文件時的校驗和作比較。如果檢驗失敗，則從其他數據節點獲取備份數據塊。
在HDFS系統上刪除一個文件，遵從以下步驟：
1）名稱節點僅僅重命名了文件路徑，使其移動到了/trash目錄。需要注意的是，這個操作過程是鏈接到重命名文件路徑的元數據的更新操作。這個執行過程非常迅速。/trash 目錄中的文件會保存一段時間，這個保存時間是預先確定的（當前設定為6小時而且當前不可配置）。在這段時間內，把刪除的文件從/trash目錄中移動出來即可迅速地恢復該文件。
2）當/trash目錄中的文件超過了保存時間時，名稱節點就會將該文件從HDFS命名空間中刪除。
3）刪除文件會使得該文件相關的數據塊被釋放，HDFS系統隨后會顯示增加了一些空閑空間。
HDFS系統中的文件備份因子是可變的，它可以減小。通過一次心跳信息，這個文件備份因子的變化信息就可以由名稱節點發出，數據節點就會動態地從本地存儲系統中刪除相應的數據塊，這樣一來，集群就會有更多的空閑存儲空間了。所以，名稱節點可以動態維護文件的備份數量。
6.確保HDFS系統的可靠性
Hadoop系統和HDFS系統都有很強的抗故障能力。在以下兩種情況下會造成數據丟失：
- 數據節點故障：每個數據節點周期性地發送心跳信息到名稱節點（默認3秒鐘一次）。如果名稱節點在預先設定的時間段內沒有收到心跳信息，它就會認為數據節點有故障了。此刻，名稱節點就會主動地對存儲在故障數據節點上的數據塊重新備份，把相關數據塊（從其他健康節點的備份數據塊獲取）轉移到狀態健康的數據節點。這樣就可以確保數據塊備份數量不變。
- 位腐（bit rot）現象導致的數據損壞：這是指當電荷（在傳輸過程中）發生衰減而導致的數據丟失的情況。在HDFS系統讀取數據塊的操作過程中會進行數據校驗和核對，這種情況的數據損壞就會被發現。如果數據塊的校驗失敗了，便認為這個數據塊已經損壞，就會讀取該數據塊的備份，然后名稱節點會重新備份這個損壞了數據塊，使得數據塊的備份數量達到預先設定的數據塊備份數量。
2.3.2輔助名稱節點
現在我們來討論輔助名稱節點在Hadoop系統中的角色。這個組件因為它不合適的名字而導致很多錯誤的理解。輔助名稱節點不是用于進行故障切換的節點。
通過前文，我們知道名稱節點在內存中維護著所有的元數據。名稱節點最先從存放在本地文件系統中的fsimage文件將元數據加載到內存中。在Hadoop系統中的一系列操作運行過程中，元數據信息在內存中不斷更新。為了防止數據丟失，這些數據操作記錄還會被持久存儲到另外一個名為edits的本地文件中。
fsimage文件并不實際存儲各個數據塊的位置。這些信息是Hadoop系統在每個數據節點啟動的時候，名稱節點從每個數據節點獲取的，并被存放在名稱節點的內存中。
edits文件是用來在Hadoop系統運行期間收集元數據的變化的。如果Hadoop系統重啟了，在Hadoop重啟的過程中，edits文件中的內容會與fsimage文件中的內容合并。顯然，這會拖慢Hadoop系統的重啟時間。輔助名稱節點就是來處理這個問題的。
輔助名稱節點的作用就是周期性地把edits文件中的內容與fsimage文件中的內容合并。為此目的，輔助名稱節點會周期性地順序執行下列步驟：
1）輔助名稱節點會請求名稱節點來結轉（roll over）edits文件，確保新的更新保存到一個新的文件。這個新的文件名字叫做edits.new。
2）輔助名稱節點向名稱節點請求獲取fsimage文件和edits文件。
3）輔助名稱節點把edits文件和fsimage文件合并，生成一個新的fsimage文件。
4）名稱節點從輔助名稱節點接收到新生成的fsimage文件，并替代舊的fsimage文件。同時將edits文件中的內容替換成步驟1中創建的edit.new文件的內容。
5）更新fstime文件來記錄發生的檢查點操作。
現在應該很清楚為什么名稱節點可以導致Hadoop 1.x系統單點故障。如果edits文件和fsimage文件數據損壞了，存放在HDFS系統上的所有數據都會丟失。所以，集群中的數據節點可以是安裝了JBOD（不使用RAID技術的數組硬盤）的商用服務器，而名稱節點和輔助名稱節點必須安裝了更為可靠的存儲系統（基于RAID技術的存儲系統），以確保數據不丟失。前面提到的那兩個文件還必須要定期備份。如果這兩個文件需要從其備份文件恢復，那么從當前到備份時刻所有的數據操作都會丟失。表2-1總結了HDFS系統中名稱節點上的關鍵文件。
2.3.3任務跟蹤器
任務跟蹤器（TaskTracker）守護進程在集群中每臺計算節點中運行，接收諸如Map、Reduce和Shuffle這些操作任務的請求。每個任務跟蹤器都會分配一定的槽位數（a set of slots），其槽位數的數量一般與計算節點上可用的CPU核數一致。任務跟蹤器接收到一個（來自作業跟蹤器）的請求之后，就會啟動一個任務（task），任務跟蹤器會為這個任務初始化一個新的JVM。JVM重用是可以的，但這項功能在實際用法示例中并不常見。使用Hadoop 平臺的大多數用戶都將該功能關閉了。任務跟蹤器分配一項任務取決于它的可用槽位（slots）數量（槽位數量＝實際運行的任務數量）。任務跟蹤器負責向作業跟蹤器（JobTracker）發送心跳消息。除了向作業跟蹤器反饋任務跟蹤器的運行狀況之外，心跳信息中還包括了任務跟蹤器當前可用的槽位數量。
2.3.4作業跟蹤器
作業跟蹤器（JobTracker）守護進程負責啟動和監控MapReduce作業。當一個客戶端向Hadoop系統提交一個作業，作業的啟動流程如圖2-5所示。
該過程的詳細步驟如下：
1）作業跟蹤器接收到了作業請求。
2）大多數的MapReduce作業都需要一個或多個輸入文件目錄。任務跟蹤器向名稱節點發出請求，獲得一個數據節點的列表，這個列表上的數據節點中存儲了組成輸入文件數據的數據塊。
3）作業跟蹤器為作業的執行做準備工作。在這個步驟中，任務跟蹤器確定執行該作業需要的任務（Map任務和Reduce任務）數量。作業跟蹤器盡量把這些任務都調度到離數據塊最近的位置上運行。
4）作業跟蹤器把任務提交到每個任務跟蹤器節點去執行。任務跟蹤器節點監控任務執行情況。任務跟蹤器以預先設定的時間間隔發送心跳信息到作業跟蹤器。如果作業跟蹤器在預先設定的時間間隔之后，沒有收到任務跟蹤器發來的心跳信息，那么就認為該任務跟蹤器節點出現故障，任務就會被調度到另外一個節點去運行。
5）一旦所有的任務都執行完畢，作業跟蹤器就會更新作業狀態為成功。如果任務反復失敗達到一定的數量（這個數值可以通過Hadoop系統的配置文件來指定），作業跟蹤器就會宣布作業運行失敗。
6）客戶端會輪詢作業跟蹤器及時地獲得作業運行狀態。
到目前為止對Hadoop 1.x系統組件的講解，可以很清楚地知道，作業跟蹤器的故障會導致Hadoop系統的單點故障。如果作業跟蹤器節點掛掉，集群上所有的任務都將無法正確運行。同樣，由于僅有一個作業跟蹤器節點運行，在多任務同時運行的系統環境中，會增加該作業跟蹤器節點的工作負載。
總結
以上是生活随笔為你收集整理的《深入理解Hadoop（原书第2版）》——2.3Hadoop系统的组成的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 《微信公众平台开发最佳实践》——2.4
- 下一篇： 《MATLAB图像处理375例》——1.