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

首先尊重版權，還是把原鏈接和作者貼上：

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

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

 

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

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

（一） 背景：

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

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

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

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

2.1 NameNode的性能問題：

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

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

2.2機房之間的網絡限制：

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

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

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

2.3資源組之間的管理

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

（三）解決方案：

先看下整個跨集群hadoop的架構圖：

 

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

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

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

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

3.1 Federation

Federation相關資料見：

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

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

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

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

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

3.2 crossNode

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

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

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

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

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

如何得知跨機房文件列表？

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

3.3   資源組之間的管理

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

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

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

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

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

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

 

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