Hadoop這個(gè)單詞如今鋪天蓋地，幾乎成了大數(shù)據(jù)的代名詞。僅僅數(shù)年時(shí)間，Hadoop從邊緣技術(shù)迅速成長為一個(gè)事實(shí)標(biāo)準(zhǔn)。如今想玩轉(zhuǎn)大數(shù)據(jù)，搞企業(yè)分析或者商業(yè)智能，沒有Hadoop還真不行。但Hadoop狂熱的背后卻醞釀著一場技術(shù)變革，Hadoop的核心技術(shù)在Google那里已經(jīng)過時(shí)，因?yàn)镠adoop并不擅長處理“快數(shù)據(jù)”。
今天，Hadoop似乎已經(jīng)毫無爭議地成了企業(yè)大數(shù)據(jù)技術(shù)標(biāo)準(zhǔn)，看上去Hadoop將根植企業(yè)，其地位在未來十年似乎都不會(huì)動(dòng)搖。但是GigaOM的專欄作家Mike Miller卻發(fā)出了“不和諧”的聲音：“企業(yè)真的會(huì)為一個(gè)盛極而衰的技術(shù)買單嗎？”
起源：Google文件系統(tǒng)和Google MapReduce
為了探討Hadoop的生命周期我們需要回溯Hadoop的靈感源泉——Google的MapReduce。為了迎接數(shù)據(jù)大爆炸的挑戰(zhàn)，Google的工程師Jeff Dean和Sanjay Ghemawat架構(gòu)了兩個(gè)影響深遠(yuǎn)的系統(tǒng)：Google File System（GFS）和Google MapReduce（GMR）。前者是一個(gè)能在通用硬件上管理EB（Exabyte）級數(shù)據(jù)的出色的可行方案。后者則是一個(gè)同樣出色的，能在通用服務(wù)器上大規(guī)模并行處理數(shù)據(jù)的模型設(shè)計(jì)實(shí)現(xiàn)。
GMR的出彩之處在于能夠讓普通的Google用戶和開發(fā)者也能夠進(jìn)行高速、容錯(cuò)的大數(shù)據(jù)處理。GMR和GFS成了搜索引擎數(shù)據(jù)處理引擎的核心，該引擎抓取、分析并分級web頁面，并最終為用戶呈現(xiàn)日常搜索結(jié)果。
Hadoop生態(tài)系統(tǒng)
我們再回頭看看Apache Hadoop的兩大組成部分：Hadoop分布式文件系統(tǒng)和Hadoop，確實(shí)就是GFS和GMR的翻版。雖然Hadoop正在發(fā)展成為一個(gè)無所不包的數(shù)據(jù)管理和處理生態(tài)系統(tǒng)，但是在這個(gè)生態(tài)系統(tǒng)的核心，依然是MapReduce系統(tǒng)。所有的數(shù)據(jù)和應(yīng)用最終都將降解為Map和Reduce的工作。
Google已經(jīng)進(jìn)化，Hadoop能否跟上？
有趣的事情是，GMR已經(jīng)不再占據(jù)Google軟件堆棧中的顯赫位置。當(dāng)企業(yè)被Hadoop解決方案鎖定到MapReduce上時(shí)，Google卻已經(jīng)準(zhǔn)備淘汰MapReduce技術(shù)。雖然Apache項(xiàng)目和Hadoop商業(yè)發(fā)行版本試圖通過HBase、Hive和下一代MapReduce（亦即YARN）彌補(bǔ)Hadoop的短板。但筆者認(rèn)為只有用全新的，非MapReduce架構(gòu)的技術(shù)替代Hadoop內(nèi)核（HDFS和Zookeeper）才能與谷歌的技術(shù)抗衡。（這里有一個(gè)更加技術(shù)性的闡述：gluecon-miller-horizon）
增量索引過濾器（Percolator for incremental indexing）和頻繁變化數(shù)據(jù)集分析。Hadoop是一臺大型“機(jī)器”，當(dāng)啟動(dòng)并全速運(yùn)轉(zhuǎn)時(shí)處理數(shù)據(jù)的性能驚人，你唯一需要操心的就是硬盤的傳輸速度跟不上。但是每次你準(zhǔn)備啟動(dòng)分析數(shù)據(jù)時(shí)，都需要把所有的數(shù)據(jù)都過一遍，當(dāng)數(shù)據(jù)集越來越龐大時(shí)，這個(gè)問題將導(dǎo)致分析時(shí)間無限延長。
那么Google是如何解決讓搜索結(jié)果返回速度越來越接近實(shí)時(shí)的呢？答案是用增量處理引擎Percolator代替GMR。通過只處理新增的、改動(dòng)過的或刪除的文檔和使用二級指數(shù)來高效率建目錄，返回查詢結(jié)果。Percolator論文的作者寫道：“將索引系統(tǒng)轉(zhuǎn)換成增量系統(tǒng)…將文檔處理延遲縮短了100倍。”這意味著索引web新內(nèi)容的速度比用MapReduce快100倍！
類似大型強(qiáng)子對撞機(jī)產(chǎn)生的數(shù)據(jù)將不斷變大，Twitter也是如此。這也是為什么HBase中會(huì)新增觸發(fā)流程，而Twitter Storm正在成為實(shí)時(shí)處理流數(shù)據(jù)的熱門技術(shù)。
用于點(diǎn)對點(diǎn)分析的Dremel。Google和Hadoop生態(tài)系統(tǒng)都致力于讓MapReduce成為可用的點(diǎn)對點(diǎn)分析工具。從Sawzall到Pig和Hive，創(chuàng)建了大量的界面層，但是盡管這讓Hadoop看上去更像SQL系統(tǒng)，但是人們忘記了一個(gè)基本事實(shí)——MapReduce(以及Hadoop)是為組織數(shù)據(jù)處理任務(wù)開發(fā)的系統(tǒng)，誕生于工作流內(nèi)核，而不是點(diǎn)對點(diǎn)分析。
今天有大量的BI/分析查詢都是點(diǎn)對點(diǎn)模式，屬于互動(dòng)和低延遲的分析。Hadoop的Map和Reduce工作流讓很多分析師望而卻步，而且工作啟動(dòng)和完成工作流運(yùn)行的漫長周期對于很多互動(dòng)性分析來說意味著糟糕的用戶體驗(yàn)。于是，Google發(fā)明了Dremel（業(yè)界也稱之為BigQuery產(chǎn)品）專用工具，可以讓分析師數(shù)秒鐘內(nèi)就掃描成PB（Petabyte）的數(shù)據(jù)完成點(diǎn)到點(diǎn)查詢，而且還能支持可視化。Google在Dremel的論文中聲稱：“Dremel能夠在數(shù)秒內(nèi)完成數(shù)萬億行數(shù)據(jù)的聚合查詢，比MapReduce快上100倍！”
分析圖數(shù)據(jù)的Pregel。Google MapReduce的設(shè)計(jì)初衷是分析世界上最大的數(shù)據(jù)圖譜——互聯(lián)網(wǎng)。但是在分析人際網(wǎng)絡(luò)、電信設(shè)備、文檔和其他一些圖數(shù)據(jù)時(shí)就沒有那么靈光了，例如MapReduce在計(jì)算單源最短路徑（SSSP）時(shí)效率非常低下，已有的并行圖算法庫Parallel BGL或者CGMgraph又沒有容錯(cuò)。
于是Google開發(fā)了Pregel，一個(gè)可以在分布式通用服務(wù)器上處理PB級別圖數(shù)據(jù)的大型同步處理應(yīng)用。與Hadoop經(jīng)常在處理圖數(shù)據(jù)時(shí)產(chǎn)生指數(shù)級數(shù)據(jù)放大相比，Pregel能夠自然高效地處理SSSP或PageRank等圖算法，所用時(shí)間要短得多，代碼也簡潔得多。
目前唯一能與Pregel媲美的開源選擇是Giraph，這是一個(gè)早期的Apache孵化項(xiàng)目，調(diào)用了HDFS和Zookeeper。Githb上還有一個(gè)項(xiàng)目Golden Orb可用。
總結(jié)
總而言之，Hadoop是一個(gè)可以在普通通用硬件集群上進(jìn)行大規(guī)模數(shù)據(jù)處理的優(yōu)秀工具。但是如果你希望處理動(dòng)態(tài)數(shù)據(jù)集、點(diǎn)對點(diǎn)分析或者圖數(shù)據(jù)結(jié)構(gòu)，那么Google已經(jīng)為我們展示了大大優(yōu)于MapReduce范型的技術(shù)選擇。毫無疑問，Percolator、Dremel和Pregel將成為大數(shù)據(jù)的新“三巨頭”，正如Google的老“三巨頭”：GFS、GMR和BigTable所做的那樣。
