談到大數據,相信大家對hadoop和Apache Spark這兩個名字并不陌生。然而,最近業(yè)界有一些人正在大張旗鼓的宣揚Hadoop將死,Spark將立。他們究竟是危言聳聽?嘩眾取寵?還是眼光獨到堪破未來呢?與Hadoop相比,Spark技術如何?現工業(yè)界大數據技術都在使用何種技術?如果現在想要參加大數據培訓的話,應該從哪一種開始呢?
(1)先說二者之間的區(qū)別吧。
首先,Hadoop與Spark解決問題的層面不同。
Hadoop和Apache Spark兩者都是大數據框架,但是各自存在的目的不盡相同。Hadoop實質上更多是一個分布式數據基礎設施: 它將巨大的數據集分派到一個由普通計算機組成的集群中的多個節(jié)點進行存儲,意味著您不需要購買和維護昂貴的服務器硬件。
同時,Hadoop還會索引和跟蹤這些數據,讓大數據處理和分析效率達到前所未有的高度。Spark,則是那么一個專門用來對那些分布式存儲的大數據進行處理的工具,它并不會進行分布式數據的存儲。
其次,還有一點也值得注意——這兩者的災難恢復方式迥異。因為Hadoop將每次處理后的數據都寫入到磁盤上,所以其天生就能很有彈性的對系統(tǒng)錯誤進行處理。
Spark的數據對象存儲在分布于數據集群中的叫做彈性分布式數據集(RDD: Resilient Distributed Dataset)中。這些數據對象既可以放在內存,也可以放在磁盤,所以RDD同樣也可以提供完成的災難恢復功能。
由于兩者的側重點不同,使用場景不同,大講臺老師認為其實并沒有替代之說。Spark更適合于迭代運算比較多的ML和DM運算。因為在Spark里面,有RDD的概念。RDD可以cache到內存中,那么每次對RDD數據集的操作之后的結果,都可以存放到內存中,下一個操作可以直接從內存中輸入,省去了MapReduce大量的磁盤IO操作。但是,我們也要看到spark的限制:內存。我認為Hadoop雖然費時,但是在OLAP等大規(guī)模數據的應用場景,還是受歡迎的。目前Hadoop涵蓋了從數據收集、到分布式存儲,再到分布式計算的各個領域,在各領域都有自己獨特優(yōu)勢。
(2)為什么有這么多人不看好Hadoop,力捧Spark呢?
很多人在談到Spark代替Hadoop的時候,其實很大程度上指的是代替MapReduce。
MapReduce的缺陷很多,最大的缺陷之一是Map + Reduce的模型。這個模型并不適合描述復雜的數據處理過程。很多公司把各種奇怪的Machine Learning計算用MR模型描述,不斷挖掘MR潛力,對系統(tǒng)工程師和Ops也是極大挑戰(zhàn)了。很多計算,本質上并不是一個Map,Shuffle再Reduce的結構,比如我編譯一個SubQuery的SQL,每個Query都做一次Group By,我可能需要Map,Reduce+Reduce,中間不希望有無用的Map;又或者我需要Join,這對MapReduce來說簡直是噩夢,什么給左右表加標簽,小表用Distributed Cache分發(fā),各種不同Join的Hack,都是因為MapReduce本身是不直接支持Join的,其實我需要的是,兩組不同的計算節(jié)點掃描了數據之后按照Key分發(fā)數據到下一個階段再計算,就這么簡單的規(guī)則而已;再或者我要表示一組復雜的數據Pipeline,數據在一個無數節(jié)點組成的圖上流動,而因為MapReduce的呆板模型,我必須一次一次在一個Map/Reduce步驟完成之后不必要地把數據寫到磁盤上再讀出,才能繼續(xù)下一個節(jié)點,因為Map Reduce2個階段完成之后,就算是一個獨立計算步驟完成,必定會寫到磁盤上等待下一個Map Reduce計算。
上面這些問題,算是每個號稱下一代平臺都嘗試解決的。現在號稱次世代平臺現在做的相對有前景的是Hortonworks的Tez和Databricks的Spark。他們都嘗試解決了上面說的那些問題。Tez和Spark都可以很自由地描述一個Job里執(zhí)行流。他們相對現在的MapReduce模型來說,極大的提升了對各種復雜處理的直接支持,不需要再絞盡腦汁“挖掘”MR模型的潛力。綜上,Spark數據處理速度秒殺MapReduce因為其處理數據的方式不一樣,會比MapReduce快上很多。
(3)可以判Hadoop“死刑”嗎?
目前備受追捧的Spark還有很多缺陷,比如:
穩(wěn)定性方面,由于代碼質量問題,Spark長時間運行會經常出錯,在架構方面,由于大量數據被緩存在RAM中,Java回收垃圾緩慢的情況嚴重,導致Spark性能不穩(wěn)定,在復雜場景中SQL的性能甚至不如現有的Map/Reduce。不能處理大數據,單獨機器處理數據過大,或者由于數據出現問題導致中間結果超過RAM的大小時,常常出現RAM空間不足或無法得出結果。然而,Map/Reduce運算框架可以處理大數據,在這方面,Spark不如Map/Reduce運算框架有效。不能支持復雜的SQL統(tǒng)計;目前Spark支持的SQL語法完整程度還不能應用在復雜數據分析中。在可管理性方面,SparkYARN的結合不完善,這就為使用過程中埋下隱憂,容易出現各種難題。大講臺老師并不想說Spark和Hadoop誰強誰弱,而是想告訴大家——在比較Hadoop和Spark方面要記住的最重要一點就是,它們并不是非此即彼的關系,因為它們不是相互排斥,也不是說一方是另一方的簡易替代者。兩者彼此兼容,這使得這對組合成為一種功能極其強大的解決方案,適合諸多大數據應用場合。
也就是說,大數據行業(yè)的老鳥們如果只會Hadoop就要當心了,擠出時間來學習Spark和其他新技術是絕對必要的;而對于目前正準備嘗試大數據培訓的朋友們,從Hadoop開始仍然是最好的選擇。長遠來看新技術總會不斷出現,不管是Spark還是Tez似乎都有著更美妙的大數據前景,然而沒有人會勸你完全拋開Hadoop。
- 特朗普宣布200億美元投資計劃,在美國多地建設數據中心
- 工信部:“點、鏈、網、面”體系化推進算力網絡工作 持續(xù)提升算網綜合供給能力
- 2025年超融合基礎設施的4大趨勢
- 2025年將影響數據中心的5個云計算趨勢
- 80萬輛大眾汽車因AWS云配置錯誤導致數據泄露,包含“高精度”位置記錄
- 名創(chuàng)優(yōu)品超4000家門店接入“碰一下”支付,引爆年輕消費熱潮
- 免稅店也能用“碰一下”支付了!中免海南免稅店:碰一下就優(yōu)惠
- 報告:人工智能推動數據中心系統(tǒng)支出激增25%
- 密態(tài)計算技術助力農村普惠金融 螞蟻密算、網商銀行項目入選大數據“星河”案例
- 專利糾紛升級!Netflix就虛擬機專利侵權起訴博通及VMware
免責聲明:本網站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿,凡在本網站出現的信息,均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性,但不保證有關資料的準確性及可靠性,讀者在使用前請進一步核實,并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏,概不負任何法律責任。任何單位或個人認為本網站中的網頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時,應及時向本網站提出書面權利通知或不實情況說明,并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網站在收到上述法律文件后,將會依法盡快聯(lián)系相關文章源頭核實,溝通刪除相關內容或斷開相關鏈接。