導讀：原先支持Hadoop的四大商業機構紛紛宣布支持Spark，包含知名Hadoop解決方案供應商Cloudera和知名的Hadoop供應商MapR。
現在再寫這篇文章感覺有些不合時宜，目前，貌似很少人再討論大數據，也很少人再討論hadoop。整理這篇文章，是為了探尋新的技術方向。
先來看看幾篇討論文章(有刪減)：
Hadoop是否已死，Spark稱霸
由于Hadoop的MapReduce高延遲的死穴，導致Hadoop無力處理很多對時間有要求的場景，人們對其批評越來越多，Hadoop無力改變現在而導致正在死亡。
原先支持Hadoop的四大商業機構紛紛宣布支持Spark，包含知名Hadoop解決方案供應商Cloudera和知名的Hadoop供應商MapR。
Mahout將不再接受任何形式的以MapReduce形式實現的算法，另外一方面，Mahout宣布新的算法基于Spark
Cloudera的機器學習框架Oryx的執行引擎也將由Hadoop的MapReduce替換成Spark
Google已經開始將負載從MapReduce轉移到Pregel和Dremel上
FaceBook則將負載轉移到Presto上
Hadoop為何不改進自己?
Hadoop的改進基本停留在代碼層次，也就是修修補補的事情，這就導致了Hadoop現在具有深度的“技術債務”，負載累累;
Hadoop本身的計算模型決定了Hadoop上的所有工作都要轉化成Map、Shuffle和Reduce等核心階段，由于每次計算都要從磁盤讀或者寫數據，同時真個計算模型需要網絡傳輸，這就導致了越來越不能忍受的延遲性，同時在前一個任務運行完之前，任何一個任務都不可以運行，這直接導致了其無力支持交互式應用;
那么，為什么不全部重新寫一個更好的Hadoop呢?答案是Spark的出現使得沒有必要這樣做了。
Spark是繼Hadoop之后，成為替代Hadoop的下一代云計算大數據核心技術，目前Spark已經構建了自己的整個大數據處理生態系統，如流處理、圖技術、機器學習、NoSQL查詢等方面都有自己的技術，并且是Apache Project。
為什么需要Spark?
Spark是可以革命Hadoop的目前替代者，能夠做Hadoop做的一切事情，同時速度比Hadoop快了100倍以上。不得不提的是Spark的“One stack to rule them all”的特性，Spark的特點之一就是用一個技術堆棧解決云計算大數據中流處理、圖技術、機器學習、交互式查詢、誤差查詢等所有的問題。只需要一個技術團隊通過Spark就可以搞定一切問題，而如果基于Hadoop就需要分別構建實時流處理團隊、數據統計分析團隊、數據挖掘團隊等，而且這些團隊之間無論是代碼還是經驗都不可相互借鑒，會形成巨大的成本，而使用Spark就不存在這個問題。
上面的文章極力的推崇Spark，我們來用數據對比下Hadoop和Spark。以下為Google Trends關于Hadoop的全球搜索趨勢，從圖上看，確實Hadoop從2015年開始，關注度在每況日下。
以下為Apache Spark的搜索趨勢數據，從趨勢看也是呈下降趨勢，但下降的幅度沒有Hadoop的快。
Hadoop的現狀與未來
Hadoop這個單詞如今鋪天蓋地，幾乎成了大數據的代名詞。僅僅數年時間，Hadoop從邊緣技術迅速成長為一個事實標準。如今想玩轉大數據，搞企業分析或者商業智能，沒有Hadoop還真不行。但Hadoop狂熱的背后卻醞釀著一場技術變革，Hadoop的核心技術在Google那里已經過時，因為Hadoop并不擅長處理“快數據”。今天，Hadoop似乎已經毫無爭議地成了企業大數據技術標準，看上去Hadoop將根植企業，其地位在未來十年似乎都不會動搖。企業真的會為一個盛極而衰的技術買單嗎?
起源：Google File System(GFS)和Google MapReduce
為了迎接數據大爆炸的挑戰，Google的工程師Jeff Dean和Sanjay Ghemawat架構了兩個影響深遠的系統：Google File System(GFS)和Google MapReduce(GMR)。前者是一個能在通用硬件上管理EB(Exabyte)級數據的出色的可行方案。后者則是一個能在通用服務器上針對上述EB級數據進行大規模并行處理數據的模型設計實現。GMR和GFS成了Google搜索引擎數據處理引擎的核心，該引擎抓取、分析并分級web頁面，并最終為用戶呈現日常搜索結果。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倍!
用于點對點分析的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。Github上還有一個項目 Golden Orb 可用。
總結
總而言之，Hadoop是一個可以在普通通用硬件集群上進行大規模數據處理的優秀工具。但是如果你希望處理動態數據集、點對點分析或者圖數據結構，那么Google已經為我們展示了大大優于MapReduce范型的技術選擇。毫無疑問，Percolator、Dremel和Pregel將成為大數據的新“三巨頭”，正如Google的老“三巨頭”：GFS、GMR和BigTable所做的那樣。
對于Google來說，Hadoop背后代表的技術已被淘汰。取而代之的是新的技術。
Google后Hadoop時代的新“三駕馬車”——Caffeine、Pregel、Dremel
Hadoop的火爆要得益于Google在2003年底和2004年公布的兩篇研究論文，其中一份描述了 GFS(Google File System) ，GFS是一個可擴展的大型數據密集型應用的分布式文件系統，該文件系統可在廉價的硬件上運行，并具有可靠的容錯能力，該文件系統可為用戶提供極高的計算性能，而同時具備小的硬件投資和運營成本。另外一篇則描述了 MapReduce ，MapReduce是一種處理大型及超大型數據集并生成相關執行的編程模型。其主要思想是從函數式編程語言里借來的，同時也包含了從矢量編程語言里借來的特性。基于MapReduce編寫的程序是在成千上萬的普通PC機上被并行分布式自動執行的。
8年后，Hadoop已經被廣泛使用在網絡上，并涉及數據分析和各類數學運算任務。但Google卻提出更好的技術。在2009年，網絡巨頭開始使用新的技術取代GFS和MapReduce。Mike Olson表示“這些技術代表未來的趨勢。如果你想知道大規模、高性能的數據處理基礎設施的未來趨勢如何，我建議你看看Google即將推出的研究論文”。
Caffeine
自Hadoop興起以來，Google已經發布了三篇研究論文，主要闡述了基礎設施如何支持龐大網絡操作。其中一份詳細描述了Caffeine，Caffeine主要為Google網絡搜索引擎提供支持。在Google采用Caffeine之前，Google使用MapReduce和分布式文件系統(如GFS)來構建搜索索引(從已知的Web頁面索引中)。在2010年，Google搜索引擎發生了重大變革。Google將其搜索遷移到新的軟件平臺，他們稱之為“Caffeine”。Caffeine是Google出自自身的設計，Caffeine使Google能夠更迅速的添加新的鏈接(包括新聞報道以及博客文章等)到自身大規模的網站索引系統中，相比于以往的系統，新系統可提供“50%新生”的搜索結果。在本質上Caffeine丟棄MapReduce轉而將索引放置在由Google開發的分布式數據庫BigTable上。作為Google繼GFS和MapReduce兩項創新后的又一項創新，其在設計用來針對海量數據處理情形下的管理結構型數據方面具有巨大的優勢。這種海量數據可以定義為在云計算平臺中數千臺普通服務器上PB級的數據。
Pregel
Pregel是一個圖形數據庫，主要用于繪制大量網上信息之間關系。而更吸引人的是另外一個在論文中被稱之為Dremel的工具。
Dremel
Dremel是一種分析信息的方式，Dremel可跨越數千臺服務器運行，允許“查詢”大量的數據。這類似于使用SQL對傳統關系數據庫進行分析。區別在于Dremel可以在極快的速度處理網絡規模的海量數據。據Google提交的文件顯示你可以在幾秒的時間處理PB級的數據查詢。
目前Hadoop已經提供了在龐大數據集上運行類似SQL的查詢工具(如Hadoop生態圈中的項目Pig和Hive)。但其會有一些延遲，原因是其是“批處理”平臺，提交一個任務后需要幾分鐘或幾小時時間才能完成，雖然可以得到查詢結果，但相比于Pig和Hive，Dremel幾乎是瞬時的。Dremel 是專門為即時查詢而設計的。Dremel可在大約3秒鐘時間里處理1PB的數據查詢請求。
Cloudera的Mike Olson表示盡管Hadoop取得的成功不容置疑，但構建Hadoop生態圈的公司和企業顯然慢了，而同樣的情況也出現在Dremel上，Google在2010年公布了Dremel的相關文檔，但這個文檔還沒有被第三方企業充分利用起來，目前以色列的工程團隊正在建設被稱為OpenDremel的克隆平臺。
備注： Apache Drill 和Apache Impala的思想來自于Dremel。
Hype Cycle for Data Management, 2017
知名IT研究與顧問咨詢公司Gartner發布的《2017年數據管理技術成熟度曲線》，報告用極其顯眼的紅色標識出Hadoop在到達“生產成熟期”之前即被淘汰。
除此之外，Gartner的調查還揭示了Hadoop使用量的下滑，Gartner還預測，到2018年，70%的Hadoop部署將無法實現節約成本和收入增長的目標，主要原因是技能不足和技術整合困難。
