Hadoop即將過時了嗎？
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 倍！
類似大型強子對撞機產生的數據將不斷變大，推ter 也是如此。這也是為什么 HBase 中會新增觸發流程，而 推ter 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 所做的那樣。