重新復制缺失副本

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

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

二級名稱節點

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

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

如果名稱節點死亡，二級名稱節點保留的文件可用于恢復名稱節點。

從HDFS客戶端讀取

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

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

從HDFS中讀取數據節點

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

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

Map Task

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

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

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

每個Map任務完成后，每個節點在其臨時本地存儲中存儲其本地計算的結果。這被稱作“中間數據”。 下一步將通過網絡傳輸發送此中間數據到Reduce任務最終計算節點上運行。

Map Task非本地

雖然Job Tracker總是試圖選擇與當地數據做Map task的節點，但它可能并不總是能夠這樣做。其中一個原因可能是因為所有的節點與本地數據，已經有太多的其他任務運行，并且不能接受了。

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

Reduce Task從Map Tasks計算接收到的數據

第二階段的Map Reduce框架稱為Reduce。機器上的Map任務已經完成了和生成它們的中間數據。現在我們需要收集所有的這些中間數據，組合并提純以便進一步處理，這樣我們會有一個最終結果。

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

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

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

我們簡單的字數統計工作并不會導致大量的中間數據在網絡上傳輸。然而，其他工作可能會產生大量的中間數據，比如對TB級數據進行排序。

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

不平衡的Hadoop集群

Hadoop可以為你的組織提供一個真正的成功，它讓你身邊的數據開發出了很多之前未發現的業務價值。當業務人員了解這一點，你可以確信，很快就會有更多的錢為你的Hadoop集群購買更多機架服務器和網絡。

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

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

Hadoop集群均衡器

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

Balancer目光聚焦于節點間有效儲存的差異，力所能及的將平衡維持在一定的臨界值上。假如發現剩余大量儲存空間的節點，Balancer將找出儲存空間剩余量少的節點并把數據剪切到有大量剩余空間的節點上。只有的終端上輸入指令Balancer才會運行，當接收到終端取消命令或者終端被關閉時，Balancer將會關閉。

Balancer可以調用的網絡帶寬很小，默認只有1MB/s。帶寬可以通過hdfs-site.xml文件中的dfs.balance.bandwidthPerSec參數來設置。

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

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

來源：CSDN