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

---

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

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

考慮一下這個場景，整個機架的服務(wù)器網(wǎng)絡(luò)脫落，也許是因為一個機架交換機故障或電源故障。這個名稱節(jié)點將開始指示集群中的其余節(jié)點重新復(fù)制該機架中丟失的所有數(shù)據(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端口讀取一個塊。直到前塊完成，它才會進入下一個塊。

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

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

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

Map Task

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

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

開始此過程，客戶端機器提交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ù)進展。這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知識，可推薦同一機架中的其他節(jié)點的名稱節(jié)點。作業(yè)跟蹤器將把這個任務(wù)交給同一機架中的一個節(jié)點，節(jié)點去尋找的數(shù)據(jù)時，它需要的名稱節(jié)點將指示其機架中的另一個節(jié)點來獲取數(shù)據(jù)。

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

第二階段的Map Reduce框架稱為Reduce。機器上的Map任務(wù)已經(jīng)完成了和生成它們的中間數(shù)據(jù)。現(xiàn)在我們需要收集所有的這些中間數(shù)據(jù)，組合并提純以便進一步處理，這樣我們會有一個最終結(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ò)交換機擁有精心設(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)涵蓋的進程中，把文件分成塊，流水線復(fù)制這些塊等。當(dāng)完成時，客戶機可以從HDFS和被認為是完整的工作里讀取Results.txt。

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

如果你是一個勤奮的網(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集群購買更多機架服務(wù)器和網(wǎng)絡(luò)。

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

新的服務(wù)器是閑置的，直到我開始加載新數(shù)據(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ò)帶寬很小，默認只有1MB/s。帶寬可以通過hdfs-site.xml文件中的dfs.balance.bandwidthPerSec參數(shù)來設(shè)置。

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

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

來源：CSDN