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