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

---

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

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

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

二級名稱節(jié)點

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

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

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

從HDFS客戶端讀取

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

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

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

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

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

Map Task

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

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

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

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

Map Task非本地

雖然Job Tracker總是試圖選擇與當(dāng)?shù)財?shù)據(jù)做Map task的節(jié)點，但它可能并不總是能夠這樣做。其中一個原因可能是因為所有的節(jié)點與本地數(shù)據(jù)，已經(jīng)有太多的其他任務(wù)運行，并且不能接受了。

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

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

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

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

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

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

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

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

不平衡的Hadoop集群

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

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

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

Hadoop集群均衡器

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

Balancer目光聚焦于節(jié)點間有效儲存的差異，力所能及的將平衡維持在一定的臨界值上。假如發(fā)現(xiàn)剩余大量儲存空間的節(jié)點，Balancer將找出儲存空間剩余量少的節(jié)點并把數(shù)據(jù)剪切到有大量剩余空間的節(jié)點上。只有的終端上輸入指令Balancer才會運行，當(dāng)接收到終端取消命令或者終端被關(guān)閉時，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ī)組添加時候就會用到它，甚至一經(jīng)開啟就會運行整個星期。給均衡器低帶寬可以讓它保持著長時間的運行。

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

來源：CSDN