Hadoop的生命週期有多久？

Hadoop技術已經無處不在。不管是好是壞，Hadoop已經成為 大數據 的代名詞。短短几年間，Hadoop從一種邊緣技術成為事實上的標準。看來，不僅現在Hadoop是企業 大數據 的標準，而且在未來，它的地位似乎一時難以動搖。

谷歌文件系統與MapReduce

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

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

再回頭看看開源世界中的Hadoop，Apache Hadoop的分佈式文件系統(HDFS)和HadoopMapReduce完全是谷歌文件系統(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，ApachePig和Hive。但對熟知SQL的人們而言，他們忽略了一個基本事實-構建MapReduce的目標就在於管理數據處理工作。它的核心能力在於工作流管理，而不是即時數據分析。

與之形成鮮明對比的是，很多BI或數據分析查詢基本上都要求即時、交互和低延遲。這意味著，使用Hadoop不僅需要規劃流程圖，而且需要為許多查詢分析裁減不必要的工作流。即便如此，我們也要花費數分鐘等待工作開始，然後花費數小時等待工作流完成，並且這個過程也非常不利於交互式體驗。因此，谷歌研發了Dremel予以應對。Dremel是Google的“交互式”數據分析系統，可以在幾秒鐘內處理PB級別的數據，並能輕鬆應對即時查詢。

在此我向大家推薦一個大數據開發交流圈：658558542 裡面整理了一大份學習資料，全都是些乾貨，包括大數據技術入門，大數據離線處理、數據實時處理、Hadoop 、Spark、Flink、推薦系統算法以及源碼解析等，送給每一位大數據小夥伴，讓自學更輕鬆。這裡不止是小白聚集地，還有大牛在線解答！歡迎初學和進階中的小夥伴一起進群學習交流，共同進步！

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中，以節點為中心計算。Step0時每節點都活動著，每個節點主動“給停止投票”進入不活動狀態。如果接收到消息，則激活。沒有活動節點和消息時，整個算法結束。容錯是通過檢查點來做的。在每個超步開始的時候，對主從節點分別備份。

總結

儘管當前大數據技術的核心依然是Hadoop，但谷歌卻已經為我們展現了許多更先進的大數據技術。谷歌開發這些技術的本意並不是要立刻拋棄掉MapReduce，但毫無疑問這是未來大數據技術的趨勢。儘管已經出現了上述大數據技術的開源實現，但我們不禁要問，Hadoop的輝煌還能延續多久?

感謝您的觀看，如有不足之處，歡迎批評指正。

對大數據感興趣的同學可以關注我，並在後臺私信發送關鍵字：“大數據”即可獲取免費的大數據學習資料。

知識體系已整理好（筆記，PPT，學習視頻），歡迎大家來領取！