數(shù)據(jù)密集型計算：MapReduce與Hadoop的真正競爭力

互聯(lián)網(wǎng)絡用戶的劇增和寬帶網(wǎng)絡的普及，使得互聯(lián)網(wǎng)絡服務的本質(zhì)是以海量數(shù)據(jù)處理為中心的服務。從搜索引擎、視頻共享到電子商務，互聯(lián)網(wǎng)絡服務的成功與否在很大程度上依賴于所提供數(shù)據(jù)的規(guī)模和質(zhì)量，數(shù)據(jù)處理的及時性、有效數(shù)據(jù)的比例等。

Gordon Bell、Jim Gray和Alex Szalay在2006年1月的Computer雜志上發(fā)表的“Petascale computational systems”中指出，計算機科學正在發(fā)生變化，以數(shù)據(jù)密集（Data-intensive）型計算為主要趨勢。高性能計算系統(tǒng)必須設(shè)計為一個均衡的系統(tǒng)，不僅僅是單純的處理器性能達到Peta級，而且也包括I/O和網(wǎng)絡。數(shù)據(jù)的局部性（Data Locality）在PB級的數(shù)據(jù)處理中顯得尤為重要，即應該盡量讓計算靠近數(shù)據(jù)存儲而不是遠程拷貝數(shù)據(jù)進行計算。Gordon的因特網(wǎng)經(jīng)濟模型表明，在因特網(wǎng)上遠程移動1字節(jié)數(shù)據(jù)的代價是昂貴的，這只有在平均每字節(jié)數(shù)據(jù)需要耗費10萬個CPU指令周期處理時才是劃算的。數(shù)據(jù)局部性對軟件的設(shè)計提出了挑戰(zhàn)，因為大多數(shù)的中間件都未考慮數(shù)據(jù)移動的昂貴代價和未利用數(shù)據(jù)的緩存策略。


海量數(shù)據(jù)處理問題的挑戰(zhàn) 海量數(shù)據(jù)處理能力面對的挑戰(zhàn)是：

n          面對PB級數(shù)據(jù)，很難完全在內(nèi)存中完成處理過程，很大程度上依賴于磁盤I/O，并且需要可擴展的處理能力

n          需要降低數(shù)據(jù)處理的成本，包括利用普通商用PC服務器組成的集群，最小化每單元計算能力、RAM和I/O的成本

n          需要保障在大規(guī)模計算過程中的可靠性


每18到24個月CPU頻率和磁盤傳輸速率，RAM和磁盤容量會加倍，但是磁盤尋址時間由于音圈電機定位的限制其發(fā)展速度卻近乎常數(shù)（每年不到5%）。 可擴展的海量數(shù)據(jù)計算必須從依賴于磁盤尋址時間（seek-time）的計算轉(zhuǎn)到依賴于磁盤傳輸時間（transfer-time)，即傳統(tǒng)的關(guān)系數(shù)據(jù)庫系統(tǒng)技術(shù)不再適用。

Map/Reduce最早由Google研發(fā)人員提出。這種處理方式實際上是在數(shù)據(jù)存放的時候不建立索引，等實際處理數(shù)據(jù)的時候再將這些數(shù)據(jù)讀入內(nèi)存進行排序，并可以將數(shù)據(jù)分隔在不同的機器上同時進行處理。Map/Reduce把對數(shù)據(jù)記錄的所有操作都歸結(jié)兩個步驟：其中Map對現(xiàn)有數(shù)據(jù)做一個先期處理，得到一個中間數(shù)據(jù)集，Reduce再對中間數(shù)據(jù)集進行去重、過濾等后期處理，最后得到所要的結(jié)果。在使用Map/Reduce框架時，待處理的數(shù)據(jù)先通過順序讀磁盤進行分別處理，在內(nèi)存中排序后交由合并程序進行后處理，盡量避免了磁盤的隨機存取操作，使得海量數(shù)據(jù)的處理效率得到快速提高。

Yahoo的Hadoop開發(fā)人員經(jīng)過試驗，在10MB/s傳輸速率和10ms的磁盤尋道時間的情況下，更新1TB數(shù)據(jù)中的100M數(shù)據(jù)，如果使用基于傳統(tǒng)B樹的關(guān)系數(shù)據(jù)庫系統(tǒng)，則隨機更新需要1000天，批處理更新需要100天，而使用順序讀取的排序/合并的新型數(shù)據(jù)處理方法（如Map/Reduce）只需要1天，即效率提高100倍！

如果需要處理100T的數(shù)據(jù)集，在1個節(jié)點上，以50MB/s的速度掃描需要23天，而平均故障間隔時間（MTBF）為3年。如果在1000個節(jié)點的集群上，33分鐘可以完成掃描，但MTBF為1天。這就需要新的框架來實現(xiàn)可靠性的保障，同時這種可靠性也是可擴展和容易管理的。