云計(jì)算和Hadoop中網(wǎng)絡(luò)是討論得相對比較少的領(lǐng)域。本文原文由Dell企業(yè)技術(shù)專家Brad Hedlund撰寫，他曾在思科工作多年，專長是數(shù)據(jù)中心、云網(wǎng)絡(luò)等。文章素材基于作者自己的研究、實(shí)驗(yàn)和Cloudera的培訓(xùn)資料。

本文將著重于討論Hadoop集群的體系結(jié)構(gòu)和方法，及它如何與網(wǎng)絡(luò)和服務(wù)器基礎(chǔ)設(shè)施的關(guān)系。最開始我們先學(xué)習(xí)一下Hadoop集群運(yùn)作的基礎(chǔ)原理。

Hadoop里的服務(wù)器角色

Hadoop主要的任務(wù)部署分為3個(gè)部分，分別是：Client機(jī)器，主節(jié)點(diǎn)和從節(jié)點(diǎn)。主節(jié)點(diǎn)主要負(fù)責(zé)Hadoop兩個(gè)關(guān)鍵功能模塊HDFS、Map Reduce的監(jiān)督。當(dāng)Job Tracker使用Map Reduce進(jìn)行監(jiān)控和調(diào)度數(shù)據(jù)的并行處理時(shí)，名稱節(jié)點(diǎn)則負(fù)責(zé)HDFS監(jiān)視和調(diào)度。從節(jié)點(diǎn)負(fù)責(zé)了機(jī)器運(yùn)行的絕大部分，擔(dān)當(dāng)所有數(shù)據(jù)儲存和指令計(jì)算的苦差。每個(gè)從節(jié)點(diǎn)既扮演者數(shù)據(jù)節(jié)點(diǎn)的角色又沖當(dāng)與他們主節(jié)點(diǎn)通信的守護(hù)進(jìn)程。守護(hù)進(jìn)程隸屬于Job Tracker，數(shù)據(jù)節(jié)點(diǎn)在歸屬于名稱節(jié)點(diǎn)。

Client機(jī)器集合了Hadoop上所有的集群設(shè)置，但既不包括主節(jié)點(diǎn)也不包括從節(jié)點(diǎn)。取而代之的是客戶端機(jī)器的作用是把數(shù)據(jù)加載到集群中，遞交給Map Reduce數(shù)據(jù)處理工作的描述，并在工作結(jié)束后取回或者查看結(jié)果。在小的集群中（大約40個(gè)節(jié)點(diǎn)）可能會面對單物理設(shè)備處理多任務(wù)，比如同時(shí)Job Tracker和名稱節(jié)點(diǎn)。作為大集群的中間件，一般情況下都是用獨(dú)立的服務(wù)器去處理單個(gè)任務(wù)。

在真正的產(chǎn)品集群中是沒有虛擬服務(wù)器和管理層的存在的，這樣就沒有了多余的性能損耗。Hadoop在Linux系統(tǒng)上運(yùn)行的最好，直接操作底層硬件設(shè)施。這就說明Hadoop實(shí)際上是直接在虛擬機(jī)上工作。這樣在花費(fèi)、易學(xué)性和速度上有著無與倫比的優(yōu)勢。

Hadoop集群

上面是一個(gè)典型Hadoop集群的構(gòu)造。一系列機(jī)架通過大量的機(jī)架轉(zhuǎn)換與機(jī)架式服務(wù)器（不是刀片服務(wù)器）連接起來，通常會用1GB或者2GB的寬帶來支撐連接。10GB的帶寬雖然不常見，但是卻能顯著的提高CPU核心和磁盤驅(qū)動(dòng)器的密集性。上一層的機(jī)架轉(zhuǎn)換會以相同的帶寬同時(shí)連接著許多機(jī)架，形成集群。大量擁有自身磁盤儲存器、CPU及DRAM的服務(wù)器將成為從節(jié)點(diǎn)。同樣有些機(jī)器將成為主節(jié)點(diǎn)，這些擁有少量磁盤儲存器的機(jī)器卻有著更快的CPU及更大的DRAM。

下面我們來看一下應(yīng)用程序是怎樣運(yùn)作的吧：

adoop的工作流程

在計(jì)算機(jī)行業(yè)競爭如此激烈的情況下，究竟什么是Hadoop的生存之道？它又切實(shí)的解決了什么問題？簡而言之，商業(yè)及政府都存在大量的數(shù)據(jù)需要被快速的分析和處理。把這些大塊的數(shù)據(jù)切開，然后分給大量的計(jì)算機(jī)，讓計(jì)算機(jī)并行的處理這些數(shù)據(jù) — 這就是Hadoop能做的。

下面這個(gè)簡單的例子里，我們將有一個(gè)龐大的數(shù)據(jù)文件（給客服部門的電子郵件）。我想快速的截取下“Refund”在郵件中出現(xiàn)的次數(shù)。這是個(gè)簡單的字?jǐn)?shù)統(tǒng)計(jì)練習(xí)。Client將把數(shù)據(jù)加載到集群中（File.txt），提交數(shù)據(jù)分析工作的描述（word cout），集群將會把結(jié)果儲存到一個(gè)新的文件中（Results.txt），然后Client就會讀結(jié)果文檔。

向HDFS里寫入File

Hadoop集群在沒有注入數(shù)據(jù)之前是不起作用的，所以我們先從加載龐大的File.txt到集群中開始。首要的目標(biāo)當(dāng)然是數(shù)據(jù)快速的并行處理。為了實(shí)現(xiàn)這個(gè)目標(biāo)，我們需要竟可能多的機(jī)器同時(shí)工作。最后，Client將把數(shù)據(jù)分成更小的模塊，然后分到不同的機(jī)器上貫穿整個(gè)集群。模塊分的越小，做數(shù)據(jù)并行處理的機(jī)器就越多。同時(shí)這些機(jī)器機(jī)器還可能出故障，所以為了避免數(shù)據(jù)丟失就需要單個(gè)數(shù)據(jù)同時(shí)在不同的機(jī)器上處理。所以每塊數(shù)據(jù)都會在集群上被重復(fù)的加載。Hadoop的默認(rèn)設(shè)置是每塊數(shù)據(jù)重復(fù)加載3次。這個(gè)可以通過hdfs-site.xml文件中的dfs.replication參數(shù)來設(shè)置。

Client把File.txt文件分成3塊。Cient會和名稱節(jié)點(diǎn)達(dá)成協(xié)議（通常是TCP 9000協(xié)議）然后得到將要拷貝數(shù)據(jù)的3個(gè)數(shù)據(jù)節(jié)點(diǎn)列表。然后Client將會把每塊數(shù)據(jù)直接寫入數(shù)據(jù)節(jié)點(diǎn)中（通常是TCP 50010協(xié)議）。收到數(shù)據(jù)的數(shù)據(jù)節(jié)點(diǎn)將會把數(shù)據(jù)復(fù)制到其他數(shù)據(jù)節(jié)點(diǎn)中，循環(huán)只到所有數(shù)據(jù)節(jié)點(diǎn)都完成拷貝為止。名稱節(jié)點(diǎn)只負(fù)責(zé)提供數(shù)據(jù)的位置和數(shù)據(jù)在族群中的去處（文件系統(tǒng)元數(shù)據(jù)）。

Hadoop的Rack Awareness

Hadoop還擁有“Rack Awareness”的理念。作為Hadoop的管理員，你可以在集群中自行的定義從節(jié)點(diǎn)的機(jī)架數(shù)量。但是為什么這樣做會給你帶來麻煩呢？兩個(gè)關(guān)鍵的原因是：數(shù)據(jù)損失預(yù)防及網(wǎng)絡(luò)性能。別忘了，為了防止數(shù)據(jù)丟失，每塊數(shù)據(jù)都會拷貝在多個(gè)機(jī)器上。假如同一塊數(shù)據(jù)的多個(gè)拷貝都在同一個(gè)機(jī)架上，而恰巧的是這個(gè)機(jī)架出現(xiàn)了故障，那么這帶來的絕對是一團(tuán)糟。為了阻止這樣的事情發(fā)生，則必須有人知道數(shù)據(jù)節(jié)點(diǎn)的位置，并根據(jù)實(shí)際情況在集群中作出明智的位置分配。這個(gè)人就是名稱節(jié)點(diǎn)。

假使通個(gè)機(jī)架中兩臺機(jī)器對比不同機(jī)架的兩臺機(jī)器會有更多的帶寬更低的延時(shí)。大部分情況下這是真實(shí)存在的。機(jī)架轉(zhuǎn)換的上行帶寬一般都低于其下行帶寬。此外，機(jī)架內(nèi)的通信的延時(shí)一般都低于跨機(jī)架的（也不是全部）。那么假如Hadoop能實(shí)現(xiàn)“Rack Awareness”的理念，那么在集群性能上無疑會有著顯著的提升！是的，它真的做到了！太棒了，對不對？

但是掃興的事情發(fā)生了，首次使用你必須手動(dòng)的去定義它。不斷的優(yōu)化，保持信息的準(zhǔn)確。假如機(jī)架轉(zhuǎn)換能夠自動(dòng)的給名稱節(jié)點(diǎn)提供它的數(shù)據(jù)節(jié)點(diǎn)列表，這樣又完美了？或者反過來，數(shù)據(jù)節(jié)點(diǎn)可以自行的告知名稱節(jié)點(diǎn)他們所連接的機(jī)架轉(zhuǎn)換，這樣也的話也同樣完美。

在括補(bǔ)結(jié)構(gòu)中網(wǎng)絡(luò)中，假如能知道名稱節(jié)點(diǎn)可以通過OpenFlow控制器查詢到節(jié)點(diǎn)的位置，那無疑是更加令人興奮的。

準(zhǔn)備HDFS寫入

現(xiàn)在Client已經(jīng)把File.txt分塊并做好了向集群中加載的準(zhǔn)備，下面先從Block A開始。Client向名稱節(jié)點(diǎn)發(fā)出寫File.txt的請求，從名稱節(jié)點(diǎn)處獲得通行證，然后得到每塊數(shù)據(jù)目標(biāo)數(shù)據(jù)節(jié)點(diǎn)的列表。名稱節(jié)點(diǎn)使用自己的Rack Awareness數(shù)據(jù)來改變數(shù)據(jù)節(jié)點(diǎn)提供列表。核心規(guī)則就是對于每塊數(shù)據(jù)3份拷貝，總有兩份存在同一個(gè)機(jī)架上，另外一份則必須放到另一個(gè)機(jī)架上。所以給Client的列表都必須遵從這個(gè)規(guī)則。

在Client將File.txt的“Block A”部分寫入集群之前，Client還期待知道所有的目標(biāo)數(shù)據(jù)節(jié)點(diǎn)是否已準(zhǔn)備就緒。它將取出列表中給Block A準(zhǔn)備的第一個(gè)數(shù)據(jù)節(jié)點(diǎn)，打開TCP 50010協(xié)議，并告訴數(shù)據(jù)節(jié)點(diǎn)，注意！準(zhǔn)備好接收1塊數(shù)據(jù)，這里還有一份列表包括了數(shù)據(jù)節(jié)點(diǎn)5和數(shù)據(jù)節(jié)點(diǎn)6，確保他們同樣已準(zhǔn)備就緒。然后再由1傳達(dá)到5，接著5傳達(dá)到6。

數(shù)據(jù)節(jié)點(diǎn)將從同樣的TCP通道中響應(yīng)上一級的命令，只到Client收到原始數(shù)據(jù)節(jié)點(diǎn)1發(fā)送的的“就緒”。只到此刻，Client才真正的準(zhǔn)備在集群中加載數(shù)據(jù)塊。

HDFS載入通道

當(dāng)數(shù)據(jù)塊寫入集群后，3個(gè)（當(dāng)然數(shù)據(jù)節(jié)點(diǎn)個(gè)數(shù)參照上文的設(shè)置）數(shù)據(jù)節(jié)點(diǎn)將打開一個(gè)同步通道。這就意味著，當(dāng)一個(gè)數(shù)據(jù)節(jié)點(diǎn)接收到數(shù)據(jù)后，它同時(shí)將在通道中給下一個(gè)數(shù)據(jù)節(jié)點(diǎn)送上一份拷貝。

這里同樣是一個(gè)借助Rack Awareness數(shù)據(jù)提升集群性能的例子。注意到?jīng)]有，第二個(gè)和第三個(gè)數(shù)據(jù)節(jié)點(diǎn)運(yùn)輸在同一個(gè)機(jī)架中，這樣他們之間的傳輸就獲得了高帶寬和低延時(shí)。只到這個(gè)數(shù)據(jù)塊被成功的寫入3個(gè)節(jié)點(diǎn)中，下一個(gè)就才會開始。

HDFS通道載入成功

當(dāng)3個(gè)節(jié)點(diǎn)都成功的接收到數(shù)據(jù)塊后，他們將給名稱節(jié)點(diǎn)發(fā)送個(gè)“Block Received”報(bào)告。并向通道返回“Success”消息，然后關(guān)閉TCP回話。Client收到成功接收的消息后會報(bào)告給名稱節(jié)點(diǎn)數(shù)據(jù)已成功接收。名稱節(jié)點(diǎn)將會更新它元數(shù)據(jù)中的節(jié)點(diǎn)位置信息。Client將會開啟下一個(gè)數(shù)據(jù)塊的處理通道，只到所有的數(shù)據(jù)塊都寫入數(shù)據(jù)節(jié)點(diǎn)。

Hadoop會使用大量的網(wǎng)絡(luò)帶寬和存儲。我們將代表性的處理一些TB級別的文件。使用Hadoop的默認(rèn)配置，每個(gè)文件都會被復(fù)制三份。也就是1TB的文件將耗費(fèi)3TB的網(wǎng)絡(luò)傳輸及3TB的磁盤空間。

Client寫入跨度集群

每個(gè)塊的復(fù)制管道完成后的文件被成功寫入到集群。如預(yù)期的文件被散布在整個(gè)集群的機(jī)器，每臺機(jī)器有一個(gè)相對較小的部分?jǐn)?shù)據(jù)。個(gè)文件的塊數(shù)越多，更多的機(jī)器的數(shù)據(jù)有可能傳播。更多的CPU核心和磁盤驅(qū)動(dòng)器，意味著數(shù)據(jù)能得到更多的并行處理能力和更快的結(jié)果。這是建造大型的、寬的集群的背后的動(dòng)機(jī)，為了數(shù)據(jù)處理更多、更快。當(dāng)機(jī)器數(shù)增加和集群增寬時(shí)，我們的網(wǎng)絡(luò)需要進(jìn)行適當(dāng)?shù)臄U(kuò)展。

擴(kuò)展集群的另一種方法是深入。就是在你的機(jī)器擴(kuò)展更多個(gè)磁盤驅(qū)動(dòng)器和更多的CPU核心，而不是增加機(jī)器的數(shù)量。在擴(kuò)展深度上，你把自己的注意力集中在用較少的機(jī)器來滿足更多的網(wǎng)絡(luò)I/O需求上。在這個(gè)模型中，你的Hadoop集群如何過渡到萬兆以太網(wǎng)節(jié)點(diǎn)成為一個(gè)重要的考慮因素。

名稱節(jié)點(diǎn)

名稱節(jié)點(diǎn)包含所有集群的文件系統(tǒng)元數(shù)據(jù)和監(jiān)督健康狀況的數(shù)據(jù)節(jié)點(diǎn)以及協(xié)調(diào)對數(shù)據(jù)的訪問。這個(gè)名字節(jié)點(diǎn)是HDFS的中央控制器。它本身不擁有任何集群數(shù)據(jù)。這個(gè)名稱節(jié)點(diǎn)只知道塊構(gòu)成一個(gè)文件，并在這些塊位于集群中。

數(shù)據(jù)節(jié)點(diǎn)每3秒通過TCP信號交換向名稱節(jié)點(diǎn)發(fā)送檢測信號，使用相同的端口號定義名稱節(jié)點(diǎn)守護(hù)進(jìn)程，通常TCP 9000。每10個(gè)檢測信號作為一個(gè)塊報(bào)告，那里的數(shù)據(jù)節(jié)點(diǎn)告知它的所有塊的名稱節(jié)點(diǎn)。塊報(bào)告允許名稱節(jié)點(diǎn)構(gòu)建它的元數(shù)據(jù)和確保第三塊副本存在不同的機(jī)架上存在于不同的節(jié)點(diǎn)上。

名稱節(jié)點(diǎn)是Hadoop分布式文件系統(tǒng)（HDFS）的一個(gè)關(guān)鍵組件。沒有它，客戶端將無法從HDFS寫入或讀取文件，它就不可能去調(diào)度和執(zhí)行Map Reduce工作。正因?yàn)槿绱?，用雙電源、熱插拔風(fēng)扇、冗余網(wǎng)卡連接等等來裝備名稱節(jié)點(diǎn)和配置高度冗余的企業(yè)級服務(wù)器使一個(gè)不錯(cuò)的想法。

重新復(fù)制缺失副本

如果名稱節(jié)點(diǎn)停止從一個(gè)數(shù)據(jù)節(jié)點(diǎn)接收檢測信號，假定它已經(jīng)死亡，任何數(shù)據(jù)必須也消失了?；趬K從死亡節(jié)點(diǎn)接受到報(bào)告，這個(gè)名稱節(jié)點(diǎn)知道哪個(gè)副本連同節(jié)點(diǎn)塊死亡，并可決定重新復(fù)制這些塊到其他數(shù)據(jù)節(jié)點(diǎn)。它還將參考機(jī)架感知數(shù)據(jù)，以保持在一個(gè)機(jī)架內(nèi)的兩個(gè)副本。

考慮一下這個(gè)場景，整個(gè)機(jī)架的服務(wù)器網(wǎng)絡(luò)脫落，也許是因?yàn)橐粋€(gè)機(jī)架交換機(jī)故障或電源故障。這個(gè)名稱節(jié)點(diǎn)將開始指示集群中的其余節(jié)點(diǎn)重新復(fù)制該機(jī)架中丟失的所有數(shù)據(jù)塊。如果在那個(gè)機(jī)架中的每個(gè)服務(wù)器有12TB的數(shù)據(jù)，這可能是數(shù)百個(gè)TB的數(shù)據(jù)需要開始穿越網(wǎng)絡(luò)。

二級名稱節(jié)點(diǎn)

Hadoop服務(wù)器角色被稱為二級名稱節(jié)點(diǎn)。一個(gè)常見的誤解是，這個(gè)角色為名稱節(jié)點(diǎn)提供了一個(gè)高可用性的備份，這并非如此。

二級名稱節(jié)點(diǎn)偶爾連接到名字節(jié)點(diǎn)，并獲取一個(gè)副本的名字節(jié)點(diǎn)內(nèi)存中的元數(shù)據(jù)和文件用于存儲元數(shù)據(jù)。二級名稱節(jié)點(diǎn)在一個(gè)新的文件集中結(jié)合這些信息，并將其遞送回名稱節(jié)點(diǎn)，同時(shí)自身保留一份復(fù)本。

如果名稱節(jié)點(diǎn)死亡，二級名稱節(jié)點(diǎn)保留的文件可用于恢復(fù)名稱節(jié)點(diǎn)。

從HDFS客戶端讀取

當(dāng)客戶想要從HDFS讀取一個(gè)文件，它再一次咨詢名稱節(jié)點(diǎn)，并要求提供文件塊的位置。

客戶從每個(gè)塊列表選擇一個(gè)數(shù)據(jù)節(jié)點(diǎn)和用TCP的50010端口讀取一個(gè)塊。直到前塊完成，它才會進(jìn)入下一個(gè)塊。

從HDFS中讀取數(shù)據(jù)節(jié)點(diǎn)

有些情況下，一個(gè)數(shù)據(jù)節(jié)點(diǎn)守護(hù)進(jìn)程本身需要從HDFS中讀取數(shù)據(jù)塊。一種這樣的情況是數(shù)據(jù)節(jié)點(diǎn)被要求處理本地沒有的數(shù)據(jù)，因此它必須從網(wǎng)絡(luò)上的另一個(gè)數(shù)據(jù)節(jié)點(diǎn)檢索數(shù)據(jù)，在它開始處理之前。

另一個(gè)重要的例子是這個(gè)名稱節(jié)點(diǎn)的Rack Awareness認(rèn)知提供了最佳的網(wǎng)絡(luò)行為。當(dāng)數(shù)據(jù)節(jié)點(diǎn)詢問數(shù)據(jù)塊里名稱節(jié)點(diǎn)的位置時(shí)，名稱節(jié)點(diǎn)將檢查是否在同一機(jī)架中的另一種數(shù)據(jù)節(jié)點(diǎn)有數(shù)據(jù)。如果是這樣，這個(gè)名稱節(jié)點(diǎn)從檢索數(shù)據(jù)里提供了機(jī)架上的位置。該流程不需要遍歷兩個(gè)以上的交換機(jī)和擁擠的鏈接找到另一個(gè)機(jī)架中的數(shù)據(jù)。在機(jī)架上檢索的數(shù)據(jù)更快，數(shù)據(jù)處理就可以開始的更早，,工作完成得更快。

Map Task

現(xiàn)在file.txt在我的機(jī)器集群中蔓延，我有機(jī)會提供極其快速和高效的并行處理的數(shù)據(jù)。包含Hadoop的并行處理框架被稱為Map Reduce，模型中命名之后的兩個(gè)步驟是Map和Reduce。

第一步是Map過程。這就是我們同時(shí)要求我們的機(jī)器他們本地的數(shù)據(jù)塊上來運(yùn)行一個(gè)計(jì)算。在這種情況下，我們要求我們的機(jī)器對“Refund”這個(gè)詞在File.txt的數(shù)據(jù)塊中出現(xiàn)的次數(shù)進(jìn)行計(jì)數(shù)。

開始此過程，客戶端機(jī)器提交Map Reduce作業(yè)的Job Tracker，詢問“多少次不會在File.txt 中出現(xiàn)Refund”(意譯Java代碼)。Job Tracker查詢名稱節(jié)點(diǎn)了解哪些數(shù)據(jù)節(jié)點(diǎn)有File.txt塊。Job Tracker提供了這些節(jié)點(diǎn)上運(yùn)行的Task Tracker與Java代碼需要在他們的本地?cái)?shù)據(jù)上執(zhí)行的Map計(jì)算。這個(gè)Task Tracker啟動(dòng)一個(gè)Map任務(wù)和監(jiān)視任務(wù)進(jìn)展。這Task Tracker提供了檢測信號并向Job Tracker返回任務(wù)狀態(tài)。

每個(gè)Map任務(wù)完成后，每個(gè)節(jié)點(diǎn)在其臨時(shí)本地存儲中存儲其本地計(jì)算的結(jié)果。這被稱作“中間數(shù)據(jù)”。 下一步將通過網(wǎng)絡(luò)傳輸發(fā)送此中間數(shù)據(jù)到Reduce任務(wù)最終計(jì)算節(jié)點(diǎn)上運(yùn)行。

Map Task非本地

雖然Job Tracker總是試圖選擇與當(dāng)?shù)財(cái)?shù)據(jù)做Map task的節(jié)點(diǎn)，但它可能并不總是能夠這樣做。其中一個(gè)原因可能是因?yàn)樗械墓?jié)點(diǎn)與本地?cái)?shù)據(jù)，已經(jīng)有太多的其他任務(wù)運(yùn)行，并且不能接受了。

在這種情況下, Job Tracker將查閱名稱節(jié)點(diǎn)的Rack Awareness知識，可推薦同一機(jī)架中的其他節(jié)點(diǎn)的名稱節(jié)點(diǎn)。作業(yè)跟蹤器將把這個(gè)任務(wù)交給同一機(jī)架中的一個(gè)節(jié)點(diǎn)，節(jié)點(diǎn)去尋找的數(shù)據(jù)時(shí)，它需要的名稱節(jié)點(diǎn)將指示其機(jī)架中的另一個(gè)節(jié)點(diǎn)來獲取數(shù)據(jù)。

Reduce Task從Map Tasks計(jì)算接收到的數(shù)據(jù)

第二階段的Map Reduce框架稱為Reduce。機(jī)器上的Map任務(wù)已經(jīng)完成了和生成它們的中間數(shù)據(jù)。現(xiàn)在我們需要收集所有的這些中間數(shù)據(jù)，組合并提純以便進(jìn)一步處理，這樣我們會有一個(gè)最終結(jié)果。

Job Tracker在集群中的任何一個(gè)節(jié)點(diǎn)上開始一個(gè)Reduce任務(wù)，并指示Reduce任務(wù)從所有已完成的Map任務(wù)中獲取中間數(shù)據(jù)。Map任務(wù)可能幾乎同時(shí)應(yīng)對Reducer，導(dǎo)致讓你一下子有大量的節(jié)點(diǎn)發(fā)送TCP數(shù)據(jù)到一個(gè)節(jié)點(diǎn)。這種流量狀況通常被稱為“Incast”或者“fan-in”。對于網(wǎng)絡(luò)處理大量的incast條件，其重要的網(wǎng)絡(luò)交換機(jī)擁有精心設(shè)計(jì)的內(nèi)部流量管理能力，以及足夠的緩沖區(qū)（不太大也不能太小）。

Reducer任務(wù)現(xiàn)在已經(jīng)從Map任務(wù)里收集了所有的中間數(shù)據(jù)，可以開始最后的計(jì)算階段。在本例中，我們只需添加出現(xiàn)“Refund”這個(gè)詞的總數(shù)，并將結(jié)果寫入到一個(gè)名為Results的txt文件里。

這個(gè)名為Results的txt文件，被寫入到HDFS以下我們已經(jīng)涵蓋的進(jìn)程中，把文件分成塊，流水線復(fù)制這些塊等。當(dāng)完成時(shí)，客戶機(jī)可以從HDFS和被認(rèn)為是完整的工作里讀取Results.txt。

我們簡單的字?jǐn)?shù)統(tǒng)計(jì)工作并不會導(dǎo)致大量的中間數(shù)據(jù)在網(wǎng)絡(luò)上傳輸。然而，其他工作可能會產(chǎn)生大量的中間數(shù)據(jù)，比如對TB級數(shù)據(jù)進(jìn)行排序。

如果你是一個(gè)勤奮的網(wǎng)絡(luò)管理員，你將了解更多關(guān)于Map Reduce和你的集群將運(yùn)行的作業(yè)類型，以及作業(yè)類型如何影響你的網(wǎng)絡(luò)流量。如果你是一個(gè)Hadoop網(wǎng)絡(luò)明星，你甚至能夠提出更好的代碼來解決Map Reduce任務(wù)，以優(yōu)化網(wǎng)絡(luò)的性能，從而加快工作完工時(shí)間。

不平衡的Hadoop集群

Hadoop可以為你的組織提供一個(gè)真正的成功，它讓你身邊的數(shù)據(jù)開發(fā)出了很多之前未發(fā)現(xiàn)的業(yè)務(wù)價(jià)值。當(dāng)業(yè)務(wù)人員了解這一點(diǎn)，你可以確信，很快就會有更多的錢為你的Hadoop集群購買更多機(jī)架服務(wù)器和網(wǎng)絡(luò)。

當(dāng)你在現(xiàn)有的Hadoop集群里添加新的機(jī)架服務(wù)器和網(wǎng)絡(luò)這種情況時(shí)，你的集群是不平衡的。在這種情況下，機(jī)架1&2是我現(xiàn)有的包含F(xiàn)ile.txt的機(jī)架和運(yùn)行我的Map Reduce任務(wù)的數(shù)據(jù)。當(dāng)我添加了兩個(gè)新的架到集群，我的File.txt數(shù)據(jù)并不會自動(dòng)開始蔓延到新的機(jī)架。

新的服務(wù)器是閑置的，直到我開始加載新數(shù)據(jù)到集群中。此外,如果機(jī)架1&2上服務(wù)器都非常繁忙，Job Tracker可能沒有其他選擇，但會指定File.txt上的Map任務(wù)到新的沒有本地?cái)?shù)據(jù)的服務(wù)器上。新的服務(wù)器需要通過網(wǎng)絡(luò)去獲取數(shù)據(jù)。作為結(jié)果，你可能看到更多的網(wǎng)絡(luò)流量和較長工作完成時(shí)間。

Hadoop集群均衡器

為了彌補(bǔ)集群的平衡性，Hadoop還包含了均衡器。

Balancer目光聚焦于節(jié)點(diǎn)間有效儲存的差異，力所能及的將平衡維持在一定的臨界值上。假如發(fā)現(xiàn)剩余大量儲存空間的節(jié)點(diǎn)，Balancer將找出儲存空間剩余量少的節(jié)點(diǎn)并把數(shù)據(jù)剪切到有大量剩余空間的節(jié)點(diǎn)上。只有的終端上輸入指令Balancer才會運(yùn)行，當(dāng)接收到終端取消命令或者終端被關(guān)閉時(shí)，Balancer將會關(guān)閉。

Balancer可以調(diào)用的網(wǎng)絡(luò)帶寬很小，默認(rèn)只有1MB/s。帶寬可以通過hdfs-site.xml文件中的dfs.balance.bandwidthPerSec參數(shù)來設(shè)置。

Balancer是集群的好管家。沒當(dāng)有新機(jī)組添加時(shí)候就會用到它，甚至一經(jīng)開啟就會運(yùn)行整個(gè)星期。給均衡器低帶寬可以讓它保持著長時(shí)間的運(yùn)行。

個(gè)人認(rèn)為假如均衡器能成為Hadoop的核心而不是只是一項(xiàng)功能，那樣一定會比較有意思！

原文鏈接：http://bradhedlund.com/2011/09/10/understanding-hadoop-clusters-and-the-network/