Spark的誤解-不僅Spark是內存計算爽丹,Hadoop也是內存計算

那么Spark的真正特點是什么?拋開Spark的執(zhí)行模型的方式乳附,它的特點無非就是多個任務之間數(shù)據(jù)通信不需要借助硬盤而是通過內存,大大提高了程序的執(zhí)行效率色罚。

市面上有一些初學者的誤解碰缔,他們拿SparkHadoop比較時就會說,Spark是內存計算戳护,內存計算是Spark的特性金抡。請問在計算機領域,MySQL,Redis,SSH框架等等他們不是內存計算嗎?依據(jù)馮諾依曼體系結構腌且,有什么技術的程序不是在內存中運行梗肝,需要數(shù)據(jù)從硬盤中拉取,然后供CPU進行執(zhí)行?所有說Spark的特點是內存計算相當于什么都沒有說铺董。




大數(shù)據(jù)學習群:716581014

那么Spark的真正特點是什么?拋開Spark的執(zhí)行模型的方式巫击,它的特點無非就是多個任務之間數(shù)據(jù)通信不需要借助硬盤而是通過內存,大大提高了程序的執(zhí)行效率精续。而Hadoop由于本身的模型特點坝锰,多個任務之間數(shù)據(jù)通信是必須借助硬盤落地的。那么Spark的特點就是數(shù)據(jù)交互不會走硬盤重付。只能說多個任務的數(shù)據(jù)交互不走硬盤顷级,但是Spark的shuffle過程和Hadoop一樣仍然必須走硬盤的。

誤解一:Spark是一種內存技術

大家對Spark最大的誤解就是spark一種內存技術确垫。其實沒有一個Spark開發(fā)者正式說明這個愕把,這是對Spark計算過程的誤解。Spark是內存計算沒有錯誤森爽,但是這并不是它的特性,只是很多專家在介紹spark的特性時嚣镜,簡化后就成了spark是內存計算爬迟。

什么樣是內存技術?就是允許你將數(shù)據(jù)持久化在RAM中并有效處理的技術。然而Spark并不具備將數(shù)據(jù)數(shù)據(jù)存儲在RAM的選項菊匿,雖然我們都知道可以將數(shù)據(jù)存儲在HDFS, HBase等系統(tǒng)中付呕,但是不管是將數(shù)據(jù)存儲在磁盤還是內存计福,都沒有內置的持久化代碼。它所能做的事就是緩存數(shù)據(jù)徽职,而這個并不是數(shù)據(jù)持久化象颖。已經(jīng)緩存的數(shù)據(jù)可以很容易地被刪除,并且在后期需要時重新計算姆钉。

但是有人還是會認為Spark就是一種基于內存的技術说订,因為Spark是在內存中處理數(shù)據(jù)的。這當然是對的潮瓶,因為我們無法使用其他方式來處理數(shù)據(jù)陶冷。操作系統(tǒng)中的API都只能讓你把數(shù)據(jù)從塊設備加載到內存,然后計算完的結果再存儲到塊設備中毯辅。我們無法直接在HDD設備上計算;所以現(xiàn)代系統(tǒng)中的所有處理基本上都是在內存中進行的埂伦。

然Spark允許我們使用內存緩存以及LRU替換規(guī)則,但是你想想現(xiàn)在的RDBMS系統(tǒng)思恐,比如Oracle 沾谜,你認為它們是如何處理數(shù)據(jù)的?它們使用共享內存段作為table pages的存儲池,所有的數(shù)據(jù)讀取以及寫入都是通過這個池的胀莹,這個存儲池同樣支持LRU替換規(guī)則;所有現(xiàn)代的數(shù)據(jù)庫同樣可以通過LRU策略來滿足大多數(shù)需求基跑。但是為什么我們并沒有把Oracle 稱作是基于內存的解決方案呢?再想想操作系統(tǒng)IO,你知道嗎?所有的IO操作也是會用到LRU緩存技術的嗜逻。

Spark在內存中處理所有的操作嗎?Spark的核心:shuffle涩僻,其就是將數(shù)據(jù)寫入到磁盤的。shuffle的處理包括兩個階段:map 和 reduce栈顷。Map操作僅僅根據(jù)key計算其哈希值逆日,并將數(shù)據(jù)存放到本地文件系統(tǒng)的不同文件中,文件的個數(shù)通常是reduce端分區(qū)的個數(shù);Reduce端會從 Map端拉取數(shù)據(jù)萄凤,并將這些數(shù)據(jù)合并到新的分區(qū)中室抽。所有如果你的RDD有M個分區(qū),然后你將其轉換成N個分區(qū)的PairRDD靡努,那么在shuffle階段將會創(chuàng)建 M*N 個文件!雖然目前有些優(yōu)化策略可以減少創(chuàng)建文件的個數(shù)坪圾,但這仍然無法改變每次進行shuffle操作的時候你需要將數(shù)據(jù)先寫入到磁盤的事實!



所以結論是:Spark并不是基于內存的技術!它其實是一種可以有效地使用內存LRU策略的技術。

誤解二:Spark要比Hadoop快 10x-100x

大家在Spark的官網(wǎng)肯定看到了如下所示的圖片



這個圖片是分別使用 Spark 和 Hadoop 運行邏輯回歸(Logistic Regression)機器學習算法的運行時間比較惑朦,從上圖可以看出Spark的運行速度明顯比Hadoop快上百倍!但是實際上是這樣的嗎?大多數(shù)機器學習算法的核心部分是什么?其實就是對同一份數(shù)據(jù)集進行相同的迭代計算兽泄,而這個地方正是Spark的LRU算法所驕傲的地方。當你多次掃描相同的數(shù)據(jù)集時漾月,你只需要在首次訪問時加載它到內存病梢,后面的訪問直接從內存中獲取即可。這個功能非常的棒!但是很遺憾的是,官方在使用Hadoop運行邏輯回歸的時候很大可能沒有使用到HDFS的緩存功能蜓陌,而是采用極端的情況觅彰。如果在Hadoop中運行邏輯回歸的時候采用到HDFS緩存功能,其表現(xiàn)很可能只會比Spark差3x-4x钮热,而不是上圖所展示的一樣填抬。

根據(jù)經(jīng)驗,企業(yè)所做出的基準測試報告一般都是不可信的!一般獨立的第三方基準測試報告是比較可信的隧期,比如:TPC-H飒责。他們的基準測試報告一般會覆蓋絕大部分場景,以便真實地展示結果厌秒。

一般來說读拆,Spark比MapReduce運行速度快的原因主要有以下幾點:

task啟動時間比較快,Spark是fork出線程;而MR是啟動一個新的進程;

更快的shuffles鸵闪,Spark只有在shuffle的時候才會將數(shù)據(jù)放在磁盤檐晕,而MR卻不是。

更快的工作流:典型的MR工作流是由很多MR作業(yè)組成的蚌讼,他們之間的數(shù)據(jù)交互需要把數(shù)據(jù)持久化到磁盤才可以;而Spark支持DAG以及pipelining辟灰,在沒有遇到shuffle完全可以不把數(shù)據(jù)緩存到磁盤。

緩存:雖然目前HDFS也支持緩存篡石,但是一般來說芥喇,Spark的緩存功能更加高效,特別是在SparkSQL中凰萨,我們可以將數(shù)據(jù)以列式的形式儲存在內存中继控。

所有的這些原因才使得Spark相比Hadoop擁有更好的性能表現(xiàn);在比較短的作業(yè)確實能快上100倍,但是在真實的生產環(huán)境下胖眷,一般只會快 2.5x ~ 3x!


大數(shù)據(jù)學習可以加群:716581014

?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 序言:七十年代末武通,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子珊搀,更是在濱河造成了極大的恐慌冶忱,老刑警劉巖,帶你破解...
    沈念sama閱讀 217,907評論 6 506
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件境析,死亡現(xiàn)場離奇詭異囚枪,居然都是意外死亡,警方通過查閱死者的電腦和手機劳淆,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,987評論 3 395
  • 文/潘曉璐 我一進店門链沼,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人沛鸵,你說我怎么就攤上這事忆植。” “怎么了?”我有些...
    開封第一講書人閱讀 164,298評論 0 354
  • 文/不壞的土叔 我叫張陵朝刊,是天一觀的道長。 經(jīng)常有香客問我蜈缤,道長拾氓,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 58,586評論 1 293
  • 正文 為了忘掉前任底哥,我火速辦了婚禮咙鞍,結果婚禮上,老公的妹妹穿的比我還像新娘趾徽。我一直安慰自己续滋,他們只是感情好,可當我...
    茶點故事閱讀 67,633評論 6 392
  • 文/花漫 我一把揭開白布孵奶。 她就那樣靜靜地躺著疲酌,像睡著了一般。 火紅的嫁衣襯著肌膚如雪了袁。 梳的紋絲不亂的頭發(fā)上朗恳,一...
    開封第一講書人閱讀 51,488評論 1 302
  • 那天,我揣著相機與錄音载绿,去河邊找鬼粥诫。 笑死,一個胖子當著我的面吹牛崭庸,可吹牛的內容都是我干的怀浆。 我是一名探鬼主播,決...
    沈念sama閱讀 40,275評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼怕享,長吁一口氣:“原來是場噩夢啊……” “哼执赡!你這毒婦竟也來了?” 一聲冷哼從身側響起熬粗,我...
    開封第一講書人閱讀 39,176評論 0 276
  • 序言:老撾萬榮一對情侶失蹤搀玖,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后驻呐,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體灌诅,經(jīng)...
    沈念sama閱讀 45,619評論 1 314
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 37,819評論 3 336
  • 正文 我和宋清朗相戀三年含末,在試婚紗的時候發(fā)現(xiàn)自己被綠了猜拾。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 39,932評論 1 348
  • 序言:一個原本活蹦亂跳的男人離奇死亡佣盒,死狀恐怖挎袜,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤盯仪,帶...
    沈念sama閱讀 35,655評論 5 346
  • 正文 年R本政府宣布紊搪,位于F島的核電站,受9級特大地震影響全景,放射性物質發(fā)生泄漏耀石。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 41,265評論 3 329
  • 文/蒙蒙 一爸黄、第九天 我趴在偏房一處隱蔽的房頂上張望滞伟。 院中可真熱鬧,春花似錦炕贵、人聲如沸梆奈。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,871評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽亩钟。三九已至,卻和暖如春钥弯,著一層夾襖步出監(jiān)牢的瞬間径荔,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 32,994評論 1 269
  • 我被黑心中介騙來泰國打工脆霎, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留总处,地道東北人。 一個月前我還...
    沈念sama閱讀 48,095評論 3 370
  • 正文 我出身青樓睛蛛,卻偏偏與公主長得像鹦马,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子忆肾,可洞房花燭夜當晚...
    茶點故事閱讀 44,884評論 2 354

推薦閱讀更多精彩內容