Ness SES首席技術官：最終，Hadoop老了！
對于Hadoop飄忽不定的未來，Ness SES的***技術官(CTO)Moshe Kranc寫下了這篇文章。
計算機世界充斥著大量先動者的產品，但最終都會被追隨者所取代，后來者從創新者的錯誤中學習并繼續發展。我相信這是Hadoop的命運，因為Spark和Cassandra等已經在大數據社區獲得了持續發展的動力。
為了證明上述觀點，我需要先來講一點歷史。
“Hadoop作為一個概念徹底改變了數據處理世界，并最終迎來了大數據時代!”
大約20年前，Doug Cutting在創建Web搜索引擎時面臨兩大問題：
- 如何可靠地存儲所有信息?
- 如何創建大量查找索引?
之后，Hadoop誕生了。它包括分布式、高可用的文件系統和用于大規模并行計算的Map-Reduce框架。
MapReduce確實是革命性的，它讓曾經難以解決的問題可以在幾分鐘內被解決。但是，它沒有利用內存來提高性能，并且在處理增量更改時很糟糕，例如，將單個新推文的索引添加到現有的完整Web索引。
隨著時間的推移，Hadoop用Tez取代了原來的MapReduce框架，Tez使用定向非循環圖進行并行處理，理論基于微軟2010年有關Dryad的論文。但是，Tez已經被另一款產品搶先了，這款產品就是Spark。Spark的實現更通用，例如，可以有效檢查和恢復各計算階段的數據。Spark可以運行在Hadoop生態系統中(它很快將取代Tez)，或者它可以在自己的獨立環境中運行。越來越多的項目選擇Spark作為其大數據解決方案，將Hadoop Spark或Spark standalone作為次要選擇。目前超過25%的Spark項目在Hadoop之外運行，并且這一比例在不斷上升。
很多大數據人士堅信Haoop會有一個光明年代，認為Spark和Hadoop根本沒有可比性，不愿意承認Hadoop的年代感。
Hadoop文件系統(HDFS)也在展示其年代感。例如，它需要一個活動的NameNode才能運行，并且它使用Zookeeper來監控NameNode可用性。因此，當Zookeeper檢測到活動的NameNode崩潰時，它可能會經歷長達一分鐘的“斷電”。Hadoop已經發展出提高可用性的機制，但其他大數據系統(如Cassandra's)早已實現了高可用性，而無需主節點或外部監控工具，從而消除掉電風險。
大數據領域的趨勢越來越明顯。Hadoop作為一個概念徹底改變了數據處理世界，迎來了大數據時代。但是，作為一個產品和生態系統的Hadoop正在顯示其年代感，對于許多用例來說，它已經被Spark等更現代的技術所取代，后者可以從Hadoop不斷增長的痛苦中學習。Spark具有更通用和可擴展的編程模型，這使得它更易于分析。它還可以通過Spark Streaming處理Motion中的大數據，并作為強大圖形數據庫(GraphX)和全功能數據科學庫(MLib)的基礎。
也許這就解釋了最近Gartner報告的發現，盡管對大數據解決方案的需求在不斷增長，但對Hadoop的需求并沒有像預期那樣加速，企業對Hadoop的熱情很低。
事實上，絕大多數接受調查的企業表示他們現在或未來都沒有計劃投資Hadoop。所以，盡管Spark，Cassandra和MongoDB等其他大數據技術仍然吸引了很多公司的興趣，但Hadoop似乎正在遭受需求下滑的困擾。
領先的Hadoop廠商Cloudera和Hortonworks可能仍然有很高的估值，但他們花費太多的時間去發展每個新客戶，并且還沒有突破到主流企業。
為什么對Hadoop缺乏熱情?一些分析師指責總擁有成本較高，另一些則認為是尋找具備必要技能的工程師存在困難。對我而言，這些只是說Hadoop正在顯示其年齡感的不同方式。與任何具備20年歷史的軟件系統一樣，Hadoop多年來也在不斷發展，每一次演變都使生態系統更加復雜，難以部署或維護。像Spark這樣的新系統具有更年輕和更健壯的代碼庫，對年輕的工程師而言，Spark等現代工具擁有比Hadoop更易于使用的現代編程API范例。
沒有Hadoop，Spark和Cassandra恐怕不會取得現在的成績。對Hadoop感恩的同時，我們或許要開始學會遺忘Hadoop，畢竟，它已經不年輕了。
