Ness SES技術長：最終，Hadoop老了！

  對於Hadoop飄忽不定的未來，Ness SES的技術長(CTO)Moshe Kranc寫下了這篇文章。

　　計算機世界充斥著大量先動者的產品，但最終都會被追隨者所取代，後來者從創新者的錯誤中學習並繼續發展。我相信這是Hadoop的命運，因為Spark和Cassandra等已經在大資料社群獲得了持續發展的動力。

　　為了證明上述觀點，我需要先來講一點歷史。

　　“Hadoop作為一個概念徹底改變了資料處理世界，並最終迎來了大資料時代!”

　　大約20年前，Doug Cutting在建立Web搜尋引擎時面臨兩大問題：

　　1、如何可靠地儲存所有資訊?

　　2、如何建立大量查詢索引?

　　之後，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，畢竟，它已經不年輕了。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31077337/viewspace-2154071/，如需轉載，請註明出處，否則將追究法律責任。