這是來自于阿里技術(shù)嘉年華的一個分享，因為在百度也考慮過類似的事情，所以聽得比較有感悟，這里把相關(guān)內(nèi)容整理一下。

首先尊重版權(quán)，還是把原鏈接和作者貼上：

http://adc.alibabatech.org/carnival/history/schedule/2013/detail/main/286?video=0

來自于阿里吳威工程師的分享

 

首先需要說明一點，跨機(jī)房hadoop可能應(yīng)用場景并不是很多，國內(nèi)像BAT這種巨頭也許需要，但是大部分的中小公司也許并不需要這個，也許這是個屠龍之技，呵呵。

把這個問題分三段來講，第一段是問題出現(xiàn)的背景，第二段是解決該問題的難點，第三段是最終的解決方案。

（一） 背景：

先要看下為什么需要做一個跨機(jī)房的大集群？

大集群的優(yōu)點在于數(shù)據(jù)管理和授權(quán)容易（這個問題在一個多部門的大公司還是很重要的）；跨部門的使用數(shù)據(jù)容易，無需重復(fù)拉取數(shù)據(jù)。

在集群達(dá)到一定規(guī)模時，單機(jī)房（機(jī)房內(nèi)的容量是有限的）已經(jīng)無法滿足集群的需求了，要想一勞永逸的解決問題，需要建設(shè)一個跨機(jī)房的hadoop集群。

（二）技術(shù)挑戰(zhàn)：

2.1 NameNode的性能問題：

         在管理一個巨大的hadoop集群時，由于原始的Namenode是單節(jié)點，因此會成為一個性能瓶頸，遇到的性能問題主要包括兩方面：存儲容量問題（存儲元數(shù)據(jù)）和計算壓力（處理rpc請求，修改內(nèi)存樹時候需要全局鎖）問題。

         其中存儲容量問題可以依賴內(nèi)存的垂直擴(kuò)展來解決，但是計算壓力卻很難通過提升硬件來解決（因為目前廠商的主要發(fā)展方向是多核，而非提高主頻）

2.2機(jī)房之間的網(wǎng)絡(luò)限制：

         機(jī)房之間的網(wǎng)絡(luò)永遠(yuǎn)是個硬件條件的限制，跨機(jī)房的網(wǎng)絡(luò)傳輸帶來了數(shù)據(jù)延時和帶寬限制：

1， 延時一般是在10ms之內(nèi)，而hadoop上大部分運行的是離線作業(yè)，基本可接受

2， 帶寬限制的問題比較大，因為單機(jī)房內(nèi)的點對點帶寬一般是在1Gbps，而機(jī)房之間的帶寬確在20Mbps左右，非常有限。

2.3資源組之間的管理

         每個部門可以看做一個資源組，它們可能會互相使用對方的數(shù)據(jù)，因此如何規(guī)劃計算和存儲的位置就很重要，否則會在多個機(jī)房之間出現(xiàn)大量的數(shù)據(jù)拷貝。

（三）解決方案：

先看下整個跨集群hadoop的架構(gòu)圖：

 

重點介紹里面三點，也就是和上面三個問題相對應(yīng)的：

1， 可以看到這里畫出了兩個NN（namenode），它們實際上還是屬于一個hadoop集群，這是業(yè)界里的一個解決方案：HDFS Fedaration，它為了解決元數(shù)據(jù)節(jié)點性能問題；

2， 可以看到這里有一個cross node節(jié)點，它是用來在兩個機(jī)房之間同步數(shù)據(jù)的，它的設(shè)計考慮到了機(jī)房間的網(wǎng)絡(luò)限制；

3， 最后是groupA、groupB，這是為了解決數(shù)據(jù)產(chǎn)出方和使用方關(guān)系來用的。

3.1 Federation

Federation相關(guān)資料見：

http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/Federation.html#HDFS_Federation

為了水平擴(kuò)展Namenode，federation使用了多個互相獨立的namenode。它們之間互相不需要通信，每個datenode需要向全部namenode注冊并發(fā)送信息。

BlockPool是屬于一個namenode的block集合，每個blockpool之間也是互相獨立的。

         在federation里，有一個需要關(guān)注的問題，就是多個namenode的地址如何對用戶進(jìn)行透明？它采用的解決方案是目錄樹掛載的方案（社區(qū)有個viewFS，應(yīng)該就是為了解決這個問題）：熟悉linux或者nfs的朋友應(yīng)該都知道mount這個概念，目錄樹掛載就是這個意思。

不過使用目錄樹掛載也存在著一個問題，就是各個子目錄下的存儲資源需要人為的介入管理，不能出現(xiàn)嚴(yán)重的不均。

3.2 crossNode

         機(jī)房間的網(wǎng)絡(luò)限制要求不能出現(xiàn)大規(guī)模、長時間的數(shù)據(jù)拷貝，需要一個專門管理機(jī)房間數(shù)據(jù)拷貝的進(jìn)程，叫做crossNode。它是獨立部署的一個節(jié)點，和元數(shù)據(jù)節(jié)點是分離的。

         它能提供的功能概括來說主要包括以下三點：

a） 根據(jù)預(yù)置的跨機(jī)房文件，進(jìn)行數(shù)據(jù)拷貝

b） 處理實時的數(shù)據(jù)拷貝請求

c） 進(jìn)行跨機(jī)房的數(shù)據(jù)流量控制

如何得知跨機(jī)房文件列表？

         由于離線任務(wù)基本都是定時觸發(fā)的，可以根據(jù)對歷史作業(yè)的分析來形成一個跨機(jī)房文件列表

3.3   資源組之間的管理

各個資源組之間存在數(shù)據(jù)的依賴，我們希望通過資源組管理，能實現(xiàn)大部分任務(wù)在本機(jī)房內(nèi)產(chǎn)出數(shù)據(jù)，只有少量跨機(jī)房產(chǎn)出數(shù)據(jù)；大部分任務(wù)讀取本機(jī)房的數(shù)據(jù)副本，只有少量跨機(jī)房讀取數(shù)據(jù)。

為了標(biāo)識資源組之間的數(shù)據(jù)依賴性，定義一個資源組之間的距離概念：一個資源組訪問另一個資源組的數(shù)據(jù)量越多，則兩者的距離越近，應(yīng)該將距離接近的資源組放在同一個機(jī)房內(nèi)。

為了讓計算和產(chǎn)出盡可能地靠近，使用一個MRProxy，對于不同類型的任務(wù)做不同處理：

a）            離線計算：跨機(jī)房列表中的數(shù)據(jù)正在傳輸中（DC1->DC2），DC2上的 Job 被暫停調(diào)度，等待傳輸完畢

b）            Ad-hoc查詢：DC2上的 Job 需要讀DC1上的數(shù)據(jù)，Job暫停調(diào)度，通知 CrossNode，數(shù)據(jù)傳輸完畢后繼續(xù)調(diào)度

c）             特殊情況：跨機(jī)房數(shù)據(jù) Join，DC1大表，DC2小表，Job 調(diào)度到DC1上，跨機(jī)房直接讀取DC2數(shù)據(jù)，無需等待

 

由于是根據(jù)視頻和ppt整理，并沒有代碼或者文檔，所以可能有些地方的理解有偏差，歡迎來提意見~