Hadoop的輝煌還能延續多久？

Hadoop技術已經無處不在。不論是好是壞，Hadoop已經成爲大數據的代名詞。短短几年間，Hadoop從一種邊緣技術成爲事實上的標準。看來，不只如今Hadoop是企業大數據的標準，並且在將來，它的地位彷佛一時難以動搖。

谷歌文件系統與MapReduce

咱們先來探討一下Hadoop的靈魂——MapReduce。面對數據的爆炸性增加，谷歌的工程師Jeff Dean和Sanjay Ghemawat架構併發布了兩個開創性的系統：谷歌文件系統（GFS）和谷歌MapReduce（GMR）。前者是一個出色而實用的解決方案-使用常規的硬件擴展並管理數據，後者一樣輝煌，造就了一個適用於大規模並行處理的計算框架。

谷歌MapReduce（GMR）爲普通開發者/用戶進行大數據處理提供了簡易的方式，並使之快速、具有容錯性。谷歌文件系統（GFS）和谷歌MapReduce（GMR）也爲谷歌搜索引擎對網頁進行抓取、分析提供了核心動力。

再回頭看看開源世界中的Hadoop，Apache Hadoop的分佈式文件系統（HDFS）和Hadoop MapReduce徹底是谷歌文件系統（GFS）和谷歌MapReduce（GMR）的開源實現。Hadoop項目已經發展成爲一個生態系統，並觸及了大數據領域的方方面面。但從根本上，它的核心是MapReduce。

Hadoop是否能夠趕超谷歌？

一個有趣的現象是，MapReduce在谷歌已再也不顯赫。當企業矚目MapReduce的時候，谷歌好像早已進入到了下一個時代。事實上，咱們談論的這些技術早就不是新技術了，MapReduce也不例外。

我但願在後Hadoop時代下面這些技術可以更具競爭性。儘管許多Apache社區的項目和商業化Hadoop項目都很是活躍，並以來自HBase、Hive和下一代MapReduce（YARN）的技術不斷完善着Hadoop體系，我依然認爲，Hadoop核心（HDFS和Zookeeper）須要脫離MapReduce並以全新的架構加強本身的競爭力，真正與谷歌技術一較高下。

過濾不斷增加的索引，分析不斷變化的數據集。Hadoop的偉大之處在於，它一旦開始運行，就會飛速地分析你的數據。儘管如此，在每次分析數據以前，即添加、更改或刪除數據以後，咱們都必須將整個數據集進行流式處理。這意味着，隨着數據集的膨脹，分析時間也會隨之增長，且不可預期。

那麼，谷歌又是怎麼作到搜索結果愈來愈實時呈現呢？一個名爲Percolator的增量處理引擎取代了谷歌MapReduce（GMR）。經過對新建、更改和已刪除文檔的處理，並使用二級索引進行高效的分類、查詢，谷歌可以顯著地下降實現其目標的時間。

Percolator的做者寫道：「將索引系統轉化爲一個增量系統……文檔平均處理延遲的因子下降到了如今的100。」這句話的意思是，索引Web上新內容的速度比以前MapReduce系統快了100倍。

谷歌Dremel即時數據分析解決方案

谷歌和Hadoop社區曾致力於構建基於MapReduce的易用性即時數據分析工具，如谷歌的並行處理語言Sawzall，Apache Pig和Hive。但對熟知SQL的人們而言，他們忽略了一個基本事實-構建MapReduce的目標就在於管理數據處理工做。它的核心能力在於工做流管理，而不是即時數據分析。

與之造成鮮明對比的是，不少BI或數據分析查詢基本上都要求即時、交互和低延遲。這意味着，使用Hadoop不只須要規劃流程圖，並且須要爲許多查詢分析裁減沒必要要的工做流。即使如此，咱們也要花費數分鐘等待工做開始，而後花費數小時等待工做流完成，而且這個過程也很是不利於交互式體驗。所以，谷歌研發了Dremel予以應對。Dremel是Google 的「交互式」數據分析系統，能夠在幾秒鐘內處理PB級別的數據，並能輕鬆應對即時查詢。

Google Dremel的設計特色：

Dremel是一個可擴展的大型系統。在一個PB級別的數據集上面，將任務縮短到秒級，無疑須要大量的併發。磁盤的順序讀速度在100MB/S上下，那麼在1S內處理1TB數據，意味着至少須要有1萬個磁盤的併發讀! Google一貫是用廉價機器辦大事的好手。可是機器越多，出問題機率越大，如此大的集羣規模，須要有足夠的容錯考慮，保證整個分析的速度不被集羣中的個別節點影響。 

Dremel是MapReduce的補充。和MapReduce同樣，Dremel也須要GFS這樣的文件系統做爲存儲層。在設計之初，Dremel並不是是MapReduce的替代品，它只是能夠執行很是快的分析，在使用的時候，經常用它來處理MapReduce的結果集或者用來創建分析原型。 

Dremel的數據模型是嵌套的。互聯網數據經常是非關係型的。Dremel還須要有一個靈活的數據模型，這個數據模型相當重要。Dremel支持一個嵌套的數據模型，相似於JSON。而傳統的關係模型，因爲不可避免的有大量的JOIN操做，在處理如此大規模的數據的時候，每每是有心無力的。

Dremel中的數據是採用列式存儲的。使用列式存儲，分析的時候，能夠只掃描須要的那部分數據的時候，減小CPU和磁盤的訪問量。同時列式存儲是壓縮友好的，使用壓縮，能夠綜合CPU和磁盤，發揮最大的效能。

Dremel結合了Web搜索和並行DBMS的技術。Dremel借鑑了Web搜索中的「查詢樹」的概念，將一個相對巨大複雜的查詢，分割成較小較簡單的查詢。大事化小，小事化了，能併發的在大量節點上跑。另外，和並行DBMS相似，Dremel能夠提供了一個SQL-like的接口，就像Hive和Pig那樣。

谷歌的圖數據計算框架Pregel

谷歌MapReduce是專門爲抓取、分析世界上最龐大的圖形架構-internet而設計的，但針對大規模圖算法（如圖遍歷（BFS）、PageRank，最短路徑（SSSP）等）的計算則顯得效率低下。所以，谷歌構建了Pregel。

Pregel給人的印象很是深入。Pregel不只能高效執行SSSP或PageRank算法，更使人驚訝的是，公佈的數據顯示Pregel處理一個有着幾十億節點、上萬億條邊的圖，只需數分鐘便可完成，其執行時間隨着圖的大小呈線性增加。

Pregel基於BSP模型，就是「計算」-「通訊」-「同步」的模式：

• 輸入輸出爲有向圖

• 分紅超步

• 以節點爲中心計算，超步內每一個節點執行本身的任務，執行節點的順序不肯定

• 兩個超步之間是通訊階段

在Pregel中，以節點爲中心計算。Step 0時每節點都活動着，每一個節點主動「給中止投票」進入不活動狀態。若是接收到消息，則激活。沒有活動節點和消息時，整個算法結束。容錯是經過檢查點來作的。在每一個超步開始的時候，對主從節點分別備份。

總結

儘管當前大數據技術的核心依然是Hadoop，但谷歌卻已經爲咱們展示了許多更先進的大數據技術。谷歌開發這些技術的本意並非要馬上拋棄掉MapReduce，但毫無疑問這是將來大數據技術的趨勢。儘管已經出現了上述大數據技術的開源實現，但咱們不由要問，Hadoop的輝煌還能延續多久？（張志平/編譯）