深入理解Hadoop集群和網(wǎng)絡(luò)
本文側(cè)重于Hadoop集群的體系結(jié)構(gòu)和方法，以及它與網(wǎng)絡(luò)和服務(wù)器基礎(chǔ)設(shè)施這件的關(guān)系。文章的素材主要來自于研究工作以及同現(xiàn)實(shí)生活中運(yùn)行Hadoop集群客戶的討論。如果你也在你的數(shù)據(jù)中心運(yùn)行產(chǎn)品級(jí)的Hadoop集群，那么我希望你能寫下有價(jià)值的評(píng)論。
Hadoop集群部署時(shí)有三個(gè)角色：Client machines, Master nodes和Slave nodes。
Master nodes負(fù)責(zé)Hadoop的兩個(gè)關(guān)鍵功能：數(shù)據(jù)存儲(chǔ)（HDFS）；以及運(yùn)行在這個(gè)數(shù)據(jù)之上的并行計(jì)算，又稱為Map-Reduce。Name node負(fù)責(zé)調(diào)度數(shù)據(jù)存儲(chǔ)，而Job Tracker則負(fù)責(zé)并行數(shù)據(jù)處理的調(diào)度（使用Map-Reduce技術(shù)）。Slave nodes由大量的機(jī)器組成，完成數(shù)據(jù)存儲(chǔ)以及運(yùn)行計(jì)算這樣的臟活。每個(gè)slave node都運(yùn)行Data node和Task Tracker daemon，這些slave daemon和master nodes的相應(yīng)daemon進(jìn)行通信。Task tracker daemon由Job Tracker管理，Data node Daemon由Name node管理。
Client機(jī)器包含了Hadoop集群的所有設(shè)置，但是它既不是Master也不是Slave。Client的角色是向集群保存數(shù)據(jù)，提交 Map-Reduce jobs（描述如何處理數(shù)據(jù)），獲取查看MR jobs的計(jì)算結(jié)果。在小型集群中（40節(jié)點(diǎn)）你可能會(huì)發(fā)現(xiàn)一個(gè)物理機(jī)器扮演多個(gè)角色，比如既是Job Tracker又是Name node，在中等或者大規(guī)模集群中，一般都是用獨(dú)立的服務(wù)器負(fù)責(zé)單獨(dú)的角色。
在真正的產(chǎn)品集群中，不存在虛擬服務(wù)器和虛擬機(jī)平臺(tái)，因?yàn)樗麄儍H會(huì)導(dǎo)致不必要的性能損耗。Hadoop最好運(yùn)行在linux機(jī)器上，直接工作于底層硬件之上。換句話說，Hadoop可以工作在虛擬機(jī)之上，對(duì)于學(xué)習(xí)Hadoop是一個(gè)不錯(cuò)的廉價(jià)方法，我本身就有一個(gè)6-node的Hadoop cluster運(yùn)行Windows 7 laptop的VMware Workstation之上
上圖是Hadoop集群的典型架構(gòu)。機(jī)架服務(wù)器（不是刀鋒服務(wù)器）分布在多個(gè)機(jī)架中，連接到一個(gè)1GB(2GB)帶寬的機(jī)架交換機(jī)，機(jī)架交換機(jī)連接到上一層的交換機(jī)，這樣所有的節(jié)點(diǎn)通過最上層的交換機(jī)連接到一起。大部分的服務(wù)器都是Slave nodes配置有大的磁盤存儲(chǔ) 中等的CPU和DRAM，少部分是Master nodes配置較少的存儲(chǔ)空間 但是有強(qiáng)大的CPU和大DRAM
本文中，我們不討論網(wǎng)絡(luò)設(shè)計(jì)的各種細(xì)節(jié)，而是把精力放在其他方面。首先我們看下應(yīng)用的工作流程。
為什么會(huì)出現(xiàn)Hadoop？ 它又解決了什么問題？ 簡(jiǎn)單的說，是由于商業(yè)和政府有大量的數(shù)據(jù)需要快速分析和處理，如果我們把這些巨大的數(shù)據(jù)切分為小的數(shù)據(jù)塊分散到多臺(tái)計(jì)算機(jī)中，并且用這些計(jì)算機(jī)并行處理分配給他們的小塊數(shù)據(jù)，可以快速的得到結(jié)果，這就是Hadoop能做的事情。
在我們的簡(jiǎn)單例子中，我們有一個(gè)大文件保存著所有發(fā)給客戶服務(wù)部分的郵件，想要快速統(tǒng)計(jì)單詞"Refund"被輸入了多少次，這個(gè)結(jié)果有助于評(píng)估對(duì)退換貨部門的需求，以指定相應(yīng)對(duì)策。這是一個(gè)簡(jiǎn)單的單詞計(jì)數(shù)練習(xí)。Client上傳數(shù)據(jù)到集群(File.txt)，提交一個(gè)job來描述如何分析數(shù)據(jù)，集群存儲(chǔ)結(jié)果到一個(gè)新文件(Result.txt)，然后Client讀取結(jié)果文件。
沒有加載數(shù)據(jù)，Hadoop集群就沒有任何用途。所以我們首先從加載大文件File.txt到集群中以便處理。目標(biāo)是能夠快速并行處理許多數(shù)據(jù)，為了達(dá)到這個(gè)目的需要盡可能多的機(jī)器能夠同時(shí)操縱文件數(shù)據(jù)。Client把數(shù)據(jù)文件切分成許多小blocks，然后把他們分散到集群的不同機(jī)器上。塊數(shù)越多，用來處理這些數(shù)據(jù)的機(jī)器就越多。同時(shí)這些機(jī)器一定會(huì)失效，所以要確保每個(gè)數(shù)據(jù)塊保存到多個(gè)機(jī)器上以防止數(shù)據(jù)丟失。所以每個(gè)數(shù)據(jù)塊在存入集群時(shí)會(huì)進(jìn)行復(fù)制。Hadoop的標(biāo)準(zhǔn)設(shè)定是集群中的每個(gè)block有三份copy，這個(gè)配置可以由hdfs-site.xml的dfs.replication 參數(shù)設(shè)置
Client把文件File.txt分成3塊，對(duì)于每一塊，Client和Name node協(xié)商獲取可以保存它以及備份塊的Data nodes列表。Client然后直接寫block數(shù)據(jù)到Data node，Data node負(fù)責(zé)寫入數(shù)據(jù)并且復(fù)制copy到其他的Data nodes。重復(fù)操作，直到所有的塊寫完。Name node本身不參與數(shù)據(jù)保存，Name node僅僅提供文件數(shù)據(jù)位置以及數(shù)據(jù)可用位置（文件系統(tǒng)元數(shù)據(jù)）
Hadoop引入了Rack Awareness的概念。作為Hadoop系統(tǒng)管理員，你能夠手動(dòng)定義集群中每一個(gè)slave Data node的rack號(hào)。為什么要把自己置于這種麻煩呢？有兩個(gè)關(guān)鍵的原因：數(shù)據(jù)丟失和網(wǎng)絡(luò)性能。記住每一個(gè)數(shù)據(jù)塊都會(huì)被復(fù)制到多臺(tái)Data node上，以防止某臺(tái)機(jī)器失效導(dǎo)致數(shù)據(jù)丟失。有沒有可能一份數(shù)據(jù)的所有備份恰好都在同一個(gè)機(jī)架上，而這個(gè)機(jī)架又出現(xiàn)了故障，比如交換機(jī)失效或者電源失效。為了防止這種情況，Name node需要知道Data nodes在網(wǎng)絡(luò)拓?fù)渲械奈恢茫⑶沂褂眠@個(gè)信息決定數(shù)據(jù)應(yīng)該復(fù)制到集群的什么位置。
我們還假定同一機(jī)架的兩臺(tái)機(jī)器間相比不同機(jī)架的兩臺(tái)機(jī)器間 有更高的帶寬和更低的網(wǎng)絡(luò)延遲，在大部分情況下是正確的。機(jī)架交換機(jī)的上行帶寬通常小于下行帶寬。此外，機(jī)架內(nèi)延遲通常低于機(jī)架間延遲。如果上面的假定成立，那么采用Rack Awareness既可以通過優(yōu)化位置保護(hù)數(shù)據(jù)，同時(shí)提升網(wǎng)絡(luò)性能，豈不是太cool了。是的，的確是這樣，非常cool，對(duì)不對(duì)。
別急，Not cool的是Rack Awareness是需要手工定義的，并且要持續(xù)的更新它，并且保證這個(gè)信息精確。如果機(jī)架交換機(jī)可以自動(dòng)提供它下面的Data node列表給Name node，那就更c(diǎn)ool了。或者如果Data nodes可以自動(dòng)告知Name node他們屬于哪個(gè)交換機(jī)，一樣很cool.
此外，讓人感興趣的是OpenFlow 網(wǎng)絡(luò)，Name node可以請(qǐng)求OpenFlow控制器關(guān)于節(jié)點(diǎn)位置的拓?fù)淝闆r。
Client準(zhǔn)備寫文件File.txt到集群時(shí)，把文件劃分為塊，塊A為第一個(gè)塊。Client向Name node申請(qǐng)寫文件File.txt，從Name node獲得許可，并且接收到一個(gè)Data nodes列表（3個(gè)表項(xiàng)），每一個(gè)Data nodes用來寫入塊A的一個(gè)copy。Name node使用Rack Awareness來決定這個(gè)Data nodes列表。規(guī)則是：對(duì)于每一個(gè)數(shù)據(jù)塊，兩個(gè) copy存放在一個(gè)機(jī)架上，另外一個(gè)copy存放在另外一個(gè)機(jī)架上。
#p#
在Client寫B(tài)lock A之前，它要知道準(zhǔn)備接受”Block A“ copy的Data nodes是否以及做好了準(zhǔn)備。首先，Client選擇list中的第一個(gè)節(jié)點(diǎn)Data Node1，打開一個(gè)TCP50010鏈接然后請(qǐng)求：“hey，準(zhǔn)備接受一個(gè)block，這是一個(gè)Data nodes列表（2個(gè)表項(xiàng)），Data node5和Data node6”，請(qǐng)確保他們兩個(gè)也準(zhǔn)備好了“；于是Data Node1打開一個(gè)到Data node5的TCP500100連接然后說：”Hey，準(zhǔn)備接受一個(gè)block，這是一個(gè)Data nodes列表（1個(gè)表項(xiàng)），Data node6”，請(qǐng)確保他準(zhǔn)備好了“；Data Node5同樣會(huì)問Data Node6：“Hey, 準(zhǔn)備好接收一個(gè)block嗎“
”準(zhǔn)備就緒“的響應(yīng)通過已經(jīng)創(chuàng)建好的TCP pipeline傳回來，直到Data Node1發(fā)送一個(gè)"Ready"給Client。現(xiàn)在Client可以開始寫入數(shù)據(jù)了。
寫入數(shù)據(jù)的過程中，在涉及寫操作的Data nodes之間創(chuàng)建一個(gè)復(fù)制pipeline。也就是說一個(gè)數(shù)據(jù)節(jié)點(diǎn)接收數(shù)據(jù)的同時(shí)，同時(shí)會(huì)把這份數(shù)據(jù)通過pipeline push到下一個(gè)Node中。
從上圖可以看到，Rack Awareness起到了改善集群性能的做用。Data node5和Data node6在同一個(gè)機(jī)架上，因此pipeline的最后一步復(fù)制是發(fā)生在機(jī)架內(nèi)，這就受益于機(jī)架內(nèi)帶寬以及低延遲。在Data node1, Data node5, Data node6完成block A之前，block B的操作不會(huì)開始。
當(dāng)三個(gè)Nodes成功的接收到Block A后，揮發(fā)送"Block received"報(bào)告給Name node，同時(shí)發(fā)送"Success"到pipeline中，然后關(guān)閉TCP事務(wù)。Client在接收到Success信息后，通知Name node數(shù)據(jù)塊已經(jīng)成功的寫入。Name node更新File.txt中Block A的metadata信息（包含Name locations信息）
Client現(xiàn)在可以開始Block B的傳輸了
隨著File.txt的塊被寫入，越來越多的Data nodes涉及到pipeline中，散落到機(jī)架內(nèi)的熱點(diǎn)，以及跨機(jī)架的復(fù)制
Hadoop占用了很多的網(wǎng)絡(luò)帶寬和存儲(chǔ)空間。Hadoop專為處理大文件而生，比如TB級(jí)尺寸的文件。每一個(gè)文件在網(wǎng)絡(luò)和存儲(chǔ)中都被復(fù)制了三次。如果你有一個(gè)1TB的文件，那么將消耗3TB的網(wǎng)絡(luò)帶寬，同時(shí)要消耗3TB的磁盤空間存貯這個(gè)文件。
隨著每塊的復(fù)制pipeline的完成，文件被成功的寫入集群。文件散落在集群內(nèi)的機(jī)器上，每個(gè)機(jī)器保存文件的一小部分?jǐn)?shù)據(jù)。組成文件的塊數(shù)目越多，數(shù)據(jù)散落的機(jī)器就越多，將來更多的CPU和磁盤驅(qū)動(dòng)器就能參與到并行處理中來，提供更強(qiáng)大更快的處理能力。這也是建造巨大集群的原動(dòng)力。當(dāng)機(jī)器的數(shù)變多，集群則變得wide，網(wǎng)絡(luò)也相應(yīng)的需要擴(kuò)展。
擴(kuò)展集群的另外一種方法是deep擴(kuò)展。就是維持機(jī)器數(shù)據(jù)不便，而是增加機(jī)器的CPU處理能力和磁盤驅(qū)動(dòng)器的數(shù)目。在這種情況下，需要提高網(wǎng)絡(luò)的I/O吞吐量以適應(yīng)增大的機(jī)器處理能力，因此如何讓Hadoop集群運(yùn)行10GB nodes稱為一個(gè)重要的考慮。
Name node保存集群內(nèi)所有文件的metadata，監(jiān)督Data nodes的健康以及協(xié)調(diào)數(shù)據(jù)的存取。Name node是HDFS的控制中心。它本身并不保存任何cluster data。Name node知道一個(gè)文件由哪些塊組成以及這些塊存放在集群內(nèi)的什么地方。Name node告訴Client需要和哪些Data node交互，管理集群的存儲(chǔ)容量，掌握Data node的健康狀況，確保每一個(gè)數(shù)據(jù)塊都符合系統(tǒng)備份策略。
Data node每3秒鐘發(fā)送一個(gè)heartbeats給Name node ，二者使用TCP9000端口的TCP握手來實(shí)現(xiàn)heartbeats。每十個(gè)heartbeats會(huì)有一個(gè)block report，Data node告知它所保存的數(shù)據(jù)塊。block report使得Namenode能夠重建它的metadata以確保每個(gè)數(shù)據(jù)block有足夠的copy，并且分布在不同的機(jī)架上。
Name node是Hadoop Distributed File System(HDFS)的關(guān)鍵部件。沒有Name node，clients無法從HDFS讀寫數(shù)據(jù)，也無法執(zhí)行Map Reduce jobs。因此Name node 最好配置為一臺(tái)高冗余的企業(yè)級(jí)服務(wù)器：雙電源，熱插拔風(fēng)扇，冗余NIC連接等。
如果Name node收不到某Data node的heartbeats，那么Name node假定這個(gè)Data node死機(jī)并且Data node上的所有數(shù)據(jù)也丟失了。通過這臺(tái)dead Data node的block report，Name node知道哪些block copies需要復(fù)制到其他Data nodes。Name node參考Rack Awareness數(shù)據(jù)來選擇接收新copy的Data node，并遵守以下復(fù)制規(guī)則：一個(gè)機(jī)架保存兩份copies，另一個(gè)機(jī)架保存第三份copy。
考慮由于機(jī)架交換機(jī)或者機(jī)架電源失敗導(dǎo)致的整個(gè)機(jī)架Data node都失效的情況。Name node將指導(dǎo)集群內(nèi)的剩余Data nodes開始復(fù)制失效機(jī)架上的所有數(shù)據(jù)。如果失效機(jī)架上服務(wù)器的存儲(chǔ)容量為12TB，那么這將導(dǎo)致數(shù)百TB的數(shù)據(jù)在網(wǎng)絡(luò)中傳輸。
Secondary Name node是Hadoop的一種服務(wù)器角色。一個(gè)很普遍的誤解是它提供了對(duì)Name node的高可用性備份，實(shí)際上不是。
Secondary Name node偶爾會(huì)連接到Name node(缺省為每小時(shí))，同步Name node in-memory metadata以及保存metadata的文件。Secondary Name node合并這些信息到一個(gè)組新的文件中，保存到本地的同時(shí)把這些文件發(fā)送回Name Node。
當(dāng)Name node宕機(jī)，保存在Secondary Name node中的文件可以用來恢復(fù)Name node。在一個(gè)繁忙的集群中，系統(tǒng)管理員可以配置同步時(shí)間為更小的時(shí)間間隔，比如每分鐘。
當(dāng)一個(gè)Client想要從HDFS獲取一個(gè)文件時(shí)，比如job的輸出結(jié)果。Client首先從Name node查詢文件block的位置。Name node返回一個(gè)包含所有block位置的鏈表，每個(gè)block位置包含全部copies所在的Data node
Client選取一個(gè)數(shù)據(jù)塊的Data node位置，通過TCP50010端口從這個(gè)Data node讀取一塊，在讀取完當(dāng)前塊之前，Client不會(huì)處理下一塊。
在某些情況下Data node daemon本身需要從HDFS讀取數(shù)據(jù)塊。比如Data Node被請(qǐng)求處理自身不存在的數(shù)據(jù)，因而它必須從網(wǎng)絡(luò)上的其他Data node獲得數(shù)據(jù)然后才能開始處理。
#p#
另外一種情況是Name node的Rack Awareness信息提供的網(wǎng)絡(luò)優(yōu)化行為。當(dāng)Data node向Name node查詢數(shù)據(jù)塊位置信息，Name node優(yōu)先查看請(qǐng)求者所在的機(jī)架內(nèi)的Data nodes包含這個(gè)數(shù)據(jù)塊。如果包含，那么Name node把這個(gè)Data node提供給請(qǐng)求的Data node。這樣可以保證數(shù)據(jù)僅在in-rack內(nèi)流動(dòng)，可以加快數(shù)據(jù)的處理速度以及job的完成速度
現(xiàn)在File.txt分散到集群的機(jī)器中這樣就可以提供更快更有效的并行處理速度。Hadoop并行處理框架稱為Map Reduce，名稱來自于并行處理的兩個(gè)重要步驟：Map和Reduce
第一步是Map 過程，這個(gè)步驟同時(shí)請(qǐng)求所有包含數(shù)據(jù)的Data node運(yùn)行計(jì)算。在我們的例子中則是請(qǐng)求這些Data node統(tǒng)計(jì)存儲(chǔ)在他們上的File.txt數(shù)據(jù)塊包含多少此Refund
要達(dá)到這個(gè)目的，Client首先提交Map Reduce job給Job tracker，發(fā)送請(qǐng)求：“How many times does Refund occur in file.txt”。Job tracker向Name node查詢哪些Data nodes包含文件File.txt的數(shù)據(jù)塊。然后Job Tracker在這些Data nodes上運(yùn)行Java代碼 在Data node的本地?cái)?shù)據(jù)上執(zhí)行Map計(jì)算。Task Tracker啟動(dòng)一個(gè)Map task監(jiān)測(cè)這些tasks的執(zhí)行。Task Tracker通過heartbeats向Job Tracker匯報(bào)task的狀態(tài)。
當(dāng)每一個(gè)Map task都完成后，計(jì)算結(jié)果保存在這些節(jié)點(diǎn)的臨時(shí)存儲(chǔ)區(qū)內(nèi)，我們稱之為"intermediate data"。下一步是把這些中間數(shù)據(jù)通過網(wǎng)絡(luò)發(fā)送給運(yùn)行Reduce的節(jié)點(diǎn)以便完成最后的計(jì)算。
Job tracker總是嘗試選擇包含待處理數(shù)據(jù)的Data node做Map task，但是有時(shí)不會(huì)這樣。比如，所有包含這塊數(shù)據(jù)的Data node已經(jīng)有太多的tasks正在運(yùn)行，不再接收其他的task.
這種情況下，Job Tracker將詢問Name node，Name node會(huì)根據(jù)Rack Awareness建議一個(gè)in-rack Data node。Job tracker把task分配給這個(gè)in-rack Data node。這個(gè)Data node會(huì)在Name node的指導(dǎo)下從包含待處理數(shù)據(jù)的in-rack Data node獲取數(shù)據(jù)。
Map Reduce 框架的第二部分叫做Reduce。Map task已經(jīng)完成了計(jì)算，計(jì)算結(jié)果保存在intermediate data。現(xiàn)在我們需要把所有的中間數(shù)據(jù)匯集到一起作進(jìn)一步處理得到最終結(jié)果。
Job Tracker可以在集群內(nèi)的任意一個(gè)node上執(zhí)行Reduce，它指導(dǎo)Reduce task從所有完成Map trasks的Data node獲取中間數(shù)據(jù)。這些Map tasks可能同時(shí)響應(yīng)Reducer，這就導(dǎo)致了很多nodes幾乎同時(shí)向單一節(jié)點(diǎn)發(fā)起TCP連接。我們稱之為incast或者fan-in(微突發(fā)流)。如果這種微突發(fā)流比較多，那么就要求網(wǎng)絡(luò)交換機(jī)有良好的內(nèi)部流量管理能力，以及相應(yīng)的buffers。這種間歇性的buffers使用可能會(huì)影響其他的網(wǎng)絡(luò)行為。這需要另開一篇詳細(xì)討論。
Reducer task已經(jīng)收集了所有intermediate data，現(xiàn)在可以做最后計(jì)算了。在這個(gè)例子中，我們只需簡(jiǎn)單的把數(shù)字相加就得到了最終結(jié)果，寫入result.txt
我們的這個(gè)例子并沒有導(dǎo)致很多的intermediate data在網(wǎng)絡(luò)間傳輸。然而其他的jobs可能會(huì)產(chǎn)生大量的intermediate data：比如，TB級(jí)數(shù)據(jù)的排序，輸出的結(jié)果是原始數(shù)據(jù)集的重新排序，結(jié)果尺寸和原始文件大小一致。Map Reduce過程會(huì)產(chǎn)生多大的網(wǎng)絡(luò)流量王權(quán)依賴于給定的Job類型。
如果你對(duì)網(wǎng)絡(luò)管理很感興趣，那么你將了解更多Map Reduce和你運(yùn)行集群的Jobs類型，以及這些Jobs類型如何影響到網(wǎng)絡(luò)。如果你是一個(gè)Hadoop網(wǎng)絡(luò)的狂熱愛好者，那么你可能會(huì)建議寫更好的 Map Reduce jobs代碼來優(yōu)化網(wǎng)絡(luò)性能，更快的完成Job
Hadoop通過在現(xiàn)有數(shù)據(jù)的基礎(chǔ)上提供某種商業(yè)價(jià)值，從而在你的組織內(nèi)獲得成功。當(dāng)人們意識(shí)到它的價(jià)值，那么你可能獲得更多的資金購買更多的機(jī)架和服務(wù)器，來擴(kuò)展現(xiàn)有的Hadoop集群。
當(dāng)增加一個(gè)裝滿服務(wù)器的新機(jī)架到Hadoop集群中時(shí)，你可能會(huì)面臨集群不平衡的局面。在上圖的例子中，Rack1和Rack2是已經(jīng)存在的機(jī)器，保存著文件File.txt并且正在運(yùn)行Map Reduce jogs。當(dāng)我們?cè)黾觾蓚€(gè)新的機(jī)架到集群中時(shí)，F(xiàn)ile.txt 數(shù)據(jù)并不會(huì)神奇的自動(dòng)散布到新的機(jī)架中。
新的Data node服務(wù)器由于沒有數(shù)據(jù)只能空閑著，直到Client開始保存新的數(shù)據(jù)到集群中。此外當(dāng)Rack1和Rack2上的服務(wù)器都滿負(fù)荷的工作，那么Job Tracker可能沒有別的選擇，只能把作用在File.txt上的Map task分配到這些沒有數(shù)據(jù)的新服務(wù)器上，新服務(wù)器需要通過網(wǎng)絡(luò)跨機(jī)架獲取數(shù)據(jù)。這就導(dǎo)致更多的網(wǎng)絡(luò)流量，更慢的處理速度。
為了處理這種情況，Hadoop包含一個(gè)時(shí)髦的工具叫做balancer
Balancer查看節(jié)點(diǎn)可用存儲(chǔ)的差異性，在達(dá)到特定的閥值后嘗試執(zhí)行balance。有很多空閑空間的新節(jié)點(diǎn)將被檢測(cè)到，然后balancer 開始從空閑空間很少的Data node拷貝數(shù)據(jù)到這個(gè)新節(jié)點(diǎn)。Balancer通過控制臺(tái)的命令行啟動(dòng)，通過控制臺(tái)取消或者關(guān)閉balancer
Balancer可用的網(wǎng)絡(luò)流量是非常低的，缺省設(shè)置為1MB/s。可以通過hdfs-site.xml的df.balance.bandwidthPerSec參數(shù)來修改。
Balancer是你的集群的好管家。在你增加服務(wù)器時(shí)一定會(huì)用到它，定期（每周）運(yùn)行一次也是一個(gè)好主意。Balancer使用缺省帶寬可能會(huì)導(dǎo)致很長(zhǎng)時(shí)間才能完成工作，比如幾天或者幾周。
本文是基于Training from Cloudera 的學(xué)習(xí) 以及對(duì)我的Hadoop實(shí)驗(yàn)環(huán)境的觀測(cè)。這里討論的內(nèi)容都是基于latest stable release of Cloudera's CDH3 distribution of Hadoop 。本文并沒有討論Hadoop的新技術(shù)，比如：Hadoop on Demand(HOD)和HDFS Federation ，但是這些的確值得花時(shí)間去研究。
英文原文：http://bradhedlund.com/2011/09/10/understanding-hadoop-clusters-and-the-network/
