這是來自于阿里技術(shù)嘉年華的一個(gè)分享，因?yàn)樵诎俣纫部紤]過類似的事情，所以聽得比較有感悟，這里把相關(guān)內(nèi)容整理一下。
首先尊重版權(quán)，還是把原鏈接和作者貼上：
http://adc.alibabatech.org/carnival/history/schedule/2013/detail/main/286?video=0
來自于阿里吳威工程師的分享
首先需要說明一點(diǎn)，跨機(jī)房hadoop可能應(yīng)用場(chǎng)景并不是很多，國(guó)內(nèi)像BAT這種巨頭也許需要，但是大部分的中小公司也許并不需要這個(gè)，也許這是個(gè)屠龍之技，呵呵。
把這個(gè)問題分三段來講，第一段是問題出現(xiàn)的背景，第二段是解決該問題的難點(diǎn)，第三段是最終的解決方案。
（一） 背景：
先要看下為什么需要做一個(gè)跨機(jī)房的大集群？
大集群的優(yōu)點(diǎn)在于數(shù)據(jù)管理和授權(quán)容易（這個(gè)問題在一個(gè)多部門的大公司還是很重要的）；跨部門的使用數(shù)據(jù)容易，無需重復(fù)拉取數(shù)據(jù)。
在集群達(dá)到一定規(guī)模時(shí)，單機(jī)房（機(jī)房?jī)?nèi)的容量是有限的）已經(jīng)無法滿足集群的需求了，要想一勞永逸的解決問題，需要建設(shè)一個(gè)跨機(jī)房的hadoop集群。
（二）技術(shù)挑戰(zhàn)：
2.1 NameNode的性能問題：
在管理一個(gè)巨大的hadoop集群時(shí)，由于原始的Namenode是單節(jié)點(diǎn)，因此會(huì)成為一個(gè)性能瓶頸，遇到的性能問題主要包括兩方面：存儲(chǔ)容量問題（存儲(chǔ)元數(shù)據(jù)）和計(jì)算壓力（處理rpc請(qǐng)求，修改內(nèi)存樹時(shí)候需要全局鎖）問題。
其中存儲(chǔ)容量問題可以依賴內(nèi)存的垂直擴(kuò)展來解決，但是計(jì)算壓力卻很難通過提升硬件來解決（因?yàn)槟壳皬S商的主要發(fā)展方向是多核，而非提高主頻）
2.2機(jī)房之間的網(wǎng)絡(luò)限制：
機(jī)房之間的網(wǎng)絡(luò)永遠(yuǎn)是個(gè)硬件條件的限制，跨機(jī)房的網(wǎng)絡(luò)傳輸帶來了數(shù)據(jù)延時(shí)和帶寬限制：
1， 延時(shí)一般是在10ms之內(nèi)，而hadoop上大部分運(yùn)行的是離線作業(yè)，基本可接受
2， 帶寬限制的問題比較大，因?yàn)閱螜C(jī)房?jī)?nèi)的點(diǎn)對(duì)點(diǎn)帶寬一般是在1Gbps，而機(jī)房之間的帶寬確在20Mbps左右，非常有限。
2.3資源組之間的管理
每個(gè)部門可以看做一個(gè)資源組，它們可能會(huì)互相使用對(duì)方的數(shù)據(jù)，因此如何規(guī)劃計(jì)算和存儲(chǔ)的位置就很重要，否則會(huì)在多個(gè)機(jī)房之間出現(xiàn)大量的數(shù)據(jù)拷貝。
（三）解決方案：
先看下整個(gè)跨集群hadoop的架構(gòu)圖：
重點(diǎn)介紹里面三點(diǎn)，也就是和上面三個(gè)問題相對(duì)應(yīng)的：
1， 可以看到這里畫出了兩個(gè)NN（namenode），它們實(shí)際上還是屬于一個(gè)hadoop集群，這是業(yè)界里的一個(gè)解決方案：HDFS Fedaration，它為了解決元數(shù)據(jù)節(jié)點(diǎn)性能問題；
2， 可以看到這里有一個(gè)cross node節(jié)點(diǎn)，它是用來在兩個(gè)機(jī)房之間同步數(shù)據(jù)的，它的設(shè)計(jì)考慮到了機(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使用了多個(gè)互相獨(dú)立的namenode。它們之間互相不需要通信，每個(gè)datenode需要向全部namenode注冊(cè)并發(fā)送信息。
BlockPool是屬于一個(gè)namenode的block集合，每個(gè)blockpool之間也是互相獨(dú)立的。
在federation里，有一個(gè)需要關(guān)注的問題，就是多個(gè)namenode的地址如何對(duì)用戶進(jìn)行透明？它采用的解決方案是目錄樹掛載的方案（社區(qū)有個(gè)viewFS，應(yīng)該就是為了解決這個(gè)問題）：熟悉linux或者nfs的朋友應(yīng)該都知道mount這個(gè)概念，目錄樹掛載就是這個(gè)意思。
不過使用目錄樹掛載也存在著一個(gè)問題，就是各個(gè)子目錄下的存儲(chǔ)資源需要人為的介入管理，不能出現(xiàn)嚴(yán)重的不均。
3.2 crossNode
機(jī)房間的網(wǎng)絡(luò)限制要求不能出現(xiàn)大規(guī)模、長(zhǎng)時(shí)間的數(shù)據(jù)拷貝，需要一個(gè)專門管理機(jī)房間數(shù)據(jù)拷貝的進(jìn)程，叫做crossNode。它是獨(dú)立部署的一個(gè)節(jié)點(diǎn)，和元數(shù)據(jù)節(jié)點(diǎn)是分離的。
它能提供的功能概括來說主要包括以下三點(diǎn)：
a） 根據(jù)預(yù)置的跨機(jī)房文件，進(jìn)行數(shù)據(jù)拷貝
b） 處理實(shí)時(shí)的數(shù)據(jù)拷貝請(qǐng)求
c） 進(jìn)行跨機(jī)房的數(shù)據(jù)流量控制
如何得知跨機(jī)房文件列表？
由于離線任務(wù)基本都是定時(shí)觸發(fā)的，可以根據(jù)對(duì)歷史作業(yè)的分析來形成一個(gè)跨機(jī)房文件列表
3.3 資源組之間的管理
各個(gè)資源組之間存在數(shù)據(jù)的依賴，我們希望通過資源組管理，能實(shí)現(xiàn)大部分任務(wù)在本機(jī)房?jī)?nèi)產(chǎn)出數(shù)據(jù)，只有少量跨機(jī)房產(chǎn)出數(shù)據(jù)；大部分任務(wù)讀取本機(jī)房的數(shù)據(jù)副本，只有少量跨機(jī)房讀取數(shù)據(jù)。
為了標(biāo)識(shí)資源組之間的數(shù)據(jù)依賴性，定義一個(gè)資源組之間的距離概念：一個(gè)資源組訪問另一個(gè)資源組的數(shù)據(jù)量越多，則兩者的距離越近，應(yīng)該將距離接近的資源組放在同一個(gè)機(jī)房?jī)?nèi)。
為了讓計(jì)算和產(chǎn)出盡可能地靠近，使用一個(gè)MRProxy，對(duì)于不同類型的任務(wù)做不同處理：
a） 離線計(jì)算：跨機(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整理，并沒有代碼或者文檔，所以可能有些地方的理解有偏差，歡迎來提意見~