Hadoop的Rack Awareness

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

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

但是掃興的事情發(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的請(qǐng)求，從名稱節(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ī)則就是對(duì)于每塊數(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)上一級(jí)的命令，只到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è)就才會(huì)開始。

HDFS通道載入成功

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

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

Client寫入跨度集群

每個(gè)塊的復(fù)制管道完成后的文件被成功寫入到集群。如預(yù)期的文件被散布在整個(gè)集群的機(jī)器，每臺(tái)機(jī)器有一個(gè)相對(duì)較小的部分?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è)重要的考慮因素。

來源：CSDN