ApacheSpark常見的三大誤解分別是什么

ApacheSpark常見的三大誤解分別是什么，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

ApacheSpark常見的三大誤解

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

　　大家對Spark最大的誤解就是其是一種內存技術（in-memorytechnology）。其實不是這樣的！沒有一個Spark開發(fā)者正式說明這個，這是對Spark計算過程的誤解。

　　我們從頭開始說明。什么樣的技術才能稱得上是內存技術？在我看來，就是允許你將數(shù)據(jù)持久化（persist）在RAM中并有效處理的技術。然而Spark并不具備將數(shù)據(jù)數(shù)據(jù)存儲在RAM的選項，雖然我們都知道可以將數(shù)據(jù)存儲在HDFS,Tachyon,HBase,Cassandra等系統(tǒng)中，但是不管是將數(shù)據(jù)存儲在磁盤還是內存，都沒有內置的持久化代碼（nativepersistencecode）。它所能做的事就是緩存（cache）數(shù)據(jù)，而這個并不是數(shù)據(jù)持久化（persist）。已經(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和PostgreSQL，你認為它們是如何處理數(shù)據(jù)的？它們使用共享內存段（sharedmemorysegment）作為tablepages的存儲池，所有的數(shù)據(jù)讀取以及寫入都是通過這個池的，這個存儲池同樣支持LRU替換規(guī)則；所有現(xiàn)代的數(shù)據(jù)庫同樣可以通過LRU策略來滿足大多數(shù)需求。但是為什么我們并沒有把Oracle和PostgreSQL稱作是基于內存的解決方案呢？你再想想LinuxIO，你知道嗎？所有的IO操作也是會用到LRU緩存技術的。

　　你現(xiàn)在還認為Spark在內存中處理所有的操作嗎？你可能要失望了。比如Spark的核心：shuffle，其就是將數(shù)據(jù)寫入到磁盤的。如果你再SparkSQL中使用到groupby語句，或者你將RDD轉換成PairRDD并且在其之上進行一些聚合操作，這時候你強制讓Spark根據(jù)key的哈希值將數(shù)據(jù)分發(fā)到所有的分區(qū)中。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和Hadoop運行邏輯回歸（LogisticRegression）機器學習算法的運行時間比較，從上圖可以看出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倍，但是在真實的生產(chǎn)環(huán)境下，一般只會快2.5x~3x！

誤解三：Spark在數(shù)據(jù)處理方面引入了全新的技術

　　事實上，Spark并沒有引入任何革命性的新技術！其擅長的LRU緩存策略和數(shù)據(jù)的pipelining處理其實在MPP數(shù)據(jù)庫中早就存在！Spark做出重要的一步是使用開源的方式來實現(xiàn)它！并且企業(yè)可以免費地使用它。大部分企業(yè)勢必會選擇開源的Spark技術，而不是付費的MPP技術

關于ApacheSpark常見的三大誤解分別是什么問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業(yè)資訊頻道了解更多相關知識。