Ness SES技術長:最終,Hadoop老了!

趙鈺瑩發表於2018-05-07

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

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

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

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

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

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

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

  之後,Hadoop誕生了。它包括分散式、高可用的檔案系統和用於大規模平行計算的Map-Reduce框架。

Ness SES技術長:最終,Hadoop老了

  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)早已實現了高可用性,而無需主節點或外部監控工具,從而消除掉電風險。

Ness SES技術長:最終,Hadoop老了

  大資料領域的趨勢越來越明顯。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/,如需轉載,請註明出處,否則將追究法律責任。

相關文章