Hadoop教程：Hadoop集群和網(wǎng)絡(luò)的基本原理(二)

---

Hadoop的Rack Awareness

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

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

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

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

準(zhǔn)備HDFS寫入

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

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

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

HDFS載入通道

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

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

HDFS通道載入成功

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

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

Client寫入跨度集群

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

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

來源：CSDN