最近幾年關於Apache Spark框架的聲音是越來越多，而且慢慢地成為大數據領域的主流系統。最近幾年Apache Spark和Apache Hadoop的Google趨勢可以證明這一點：
最近幾年關於Apache Spark框架的聲音是越來越多，而且慢慢地成為大數據領域的主流系統。最近幾年Apache Spark和Apache Hadoop的Google趨勢可以證明這一點：
大家可以關注weixin公眾號：大數據技術工程師，瞭解更多相關spark內容
上圖已經明顯展示出最近五年，Apache Spark越來越受開發者們的歡迎，大家通過Google搜索更多關於Spark的信息。然而很多人對Apache Spark的認識存在誤解，在這篇文章中，將介紹我們對Apache Spark的幾個主要的誤解，以便給那些想將Apache Spark應用到其系統中的人作為參考。這裡主要包括以下幾個方
• Spark是一種內存技術;
• Spark要比Hadoop快 10x-100x;
• Spark在數據處理方面引入了全新的技術
誤解一：Spark是一種內存技術
大家對Spark最大的誤解就是其是一種內存技術(in-memory technology)。其實不是這樣的!沒有一個Spark開發者正式說明這個，這是對Spark計算過程的誤解。
我們從頭開始說明。什麼樣的技術才能稱得上是內存技術?在我看來，就是允許你將數據持久化(persist)在RAM中並有效處理的技術。然而Spark並不具備將數據數據存儲在RAM的選項，雖然我們都知道可以將數據存儲在HDFS, Tachyon, HBase, Cassandra等系統中，但是不管是將數據存儲在磁盤還是內存，都沒有內置的持久化代碼( native persistence code)。它所能做的事就是緩存(cache)數據，而這個並不是數據持久化(persist)。已經緩存的數據可以很容易地被刪除，並且在後期需要時重新計算。
但是即使有這些信息，仍然有些人還是會認為Spark就是一種基於內存的技術，因為Spark是在內存中處理數據的。這當然是對的，因為我們無法使用其他方式來處理數據。操作系統中的API都只能讓你把數據從塊設備加載到內存，然後計算完的結果再存儲到塊設備中。我們無法直接在HDD設備上計算;所以現代系統中的所有處理基本上都是在內存中進行的。
雖然Spark允許我們使用內存緩存以及LRU替換規則，但是你想想現在的RDBMS系統，比如Oracle 和 PostgreSQL，你認為它們是如何處理數據的?它們使用共享內存段(shared memory segment)作為table pages的存儲池，所有的數據讀取以及寫入都是通過這個池的，這個存儲池同樣支持LRU替換規則;所有現代的數據庫同樣可以通過LRU策略來滿足大多數需求。但是為什麼我們並沒有把Oracle 和 PostgreSQL稱作是基於內存的解決方案呢?你再想想Linux IO，你知道嗎?所有的IO操作也是會用到LRU緩存技術的。
你現在還認為Spark在內存中處理所有的操作嗎?你可能要失望了。比如Spark的核心：shuffle，其就是將數據寫入到磁盤的。如果你再SparkSQL中使用到group by語句，或者你將RDD轉換成PairRDD並且在其之上進行一些聚合操作，這時候你強制讓Spark根據key的哈希值將數據分發到所有的分區中。shuffle的處理包括兩個階段：map 和 reduce。Map操作僅僅根據key計算其哈希值，並將數據存放到本地文件系統的不同文件中，文件的個數通常是reduce端分區的個數;Reduce端會從 Map端拉取數據，並將這些數據合併到新的分區中。所有如果你的RDD有M個分區，然後你將其轉換成N個分區的PairRDD，那麼在shuffle階段將會創建 M*N 個文件!雖然目前有些優化策略可以減少創建文件的個數，但這仍然無法改變每次進行shuffle操作的時候你需要將數據先寫入到磁盤的事實!
所以結論是：Spark並不是基於內存的技術!它其實是一種可以有效地使用內存LRU策略的技術。
誤解二：Spark要比Hadoop快 10x-100x
相信大家在Spark的官網肯定看到了如下所示的圖片
如果想及時瞭解Spark、Hadoop或者Hbase相關的文章，歡迎關注微信公共帳號：iteblog_hadoop
這個圖片是分別使用 Spark 和 Hadoop 運行邏輯迴歸(Logistic Regression)機器學習算法的運行時間比較，從上圖可以看出Spark的運行速度明顯比Hadoop快上百倍!但是實際上是這樣的嗎?大多數機器學習算法的核心部分是什麼?其實就是對同一份數據集進行相同的迭代計算，而這個地方正是Spark的LRU算法所驕傲的地方。當你多次掃描相同的數據集時，你只需要在首次訪問時加載它到內存，後面的訪問直接從內存中獲取即可。這個功能非常的棒!但是很遺憾的是，官方在使用Hadoop運行邏輯迴歸的時候很大可能沒有使用到HDFS的緩存功能，而是採用極端的情況。如果在Hadoop中運行邏輯迴歸的時候採用到HDFS緩存功能，其表現很可能只會比Spark差3x-4x，而不是上圖所展示的一樣。
根據經驗，企業所做出的基準測試報告一般都是不可信的!一般獨立的第三方基準測試報告是比較可信的，比如：TPC-H。他們的基準測試報告一般會覆蓋絕大部分場景，以便真實地展示結果。
一般來說，Spark比MapReduce運行速度快的原因主要有以下幾點：
• task啟動時間比較快，Spark是fork出線程;而MR是啟動一個新的進程;
• 更快的shuffles，Spark只有在shuffle的時候才會將數據放在磁盤，而MR卻不是。
• 更快的工作流：典型的MR工作流是由很多MR作業組成的，他們之間的數據交互需要把數據持久化到磁盤才可以;而Spark支持DAG以及pipelining，在沒有遇到shuffle完全可以不把數據緩存到磁盤。
• 緩存：雖然目前HDFS也支持緩存，但是一般來說，Spark的緩存功能更加高效，特別是在SparkSQL中，我們可以將數據以列式的形式儲存在內存中。
所有的這些原因才使得Spark相比Hadoop擁有更好的性能表現;在比較短的作業確實能快上100倍，但是在真實的生產環境下，一般只會快 2.5x – 3x!
誤解三：Spark在數據處理方面引入了全新的技術
事實上，Spark並沒有引入任何革命性的新技術!其擅長的LRU緩存策略和數據的pipelining處理其實在MPP數據庫中早就存在!Spark做出重要的一步是使用開源的方式來實現它!並且企業可以免費地使用它。大部分企業勢必會選擇開源的Spark技術，而不是付費的MPP技術。
閱讀更多 大數據信息站 的文章
