Apache Spark常見的三大誤解
最近幾年關於Apache Spark框架的聲音是越來越多,而且慢慢地成為大資料領域的主流系統。最近幾年Apache Spark和Apache Hadoop的Google趨勢可以證明這一點:
最近幾年關於Apache Spark框架的聲音是越來越多,而且慢慢地成為大資料領域的主流系統。最近幾年Apache Spark和Apache Hadoop的Google趨勢可以證明這一點:
上圖已經明顯展示出最近五年,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相關的文章,歡迎加群;834325294
這個圖片是分別使用 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技術。
在這裡我為大家介紹一個大資料的交流群,834325294大家有興趣的話可以加進來,每週每晚都有大資料基礎與專案實戰的課程更新,也可以和大家一起相互學習交流討論,群裡的這些我整理了一些,可以加群直接找群主免費領取哦、
相關文章
- Apache Spark技術實戰之6 -- spark-submit常見問題及其解決ApacheSparkMIT
- 關於大資料的常見誤解大資料
- 常見的web錯誤Web
- 對web應用程式安全的常見誤解Web
- C/C++常見錯誤詳解C++
- PHP編譯安裝時常見錯誤解決辦法,php編譯常見錯誤PHP編譯
- 常見的錯誤 SQL 用法SQL
- SOCKS代理的常見誤區
- MySQL 常見錯誤MySql
- oracle 常見錯誤Oracle
- Elasticsearch常見的5個錯誤及解決策略Elasticsearch
- Oracle 常見的錯誤問題及解決方法Oracle
- 常見的80004005錯誤及其解決方法 (轉)
- 對JAVA語言的十個常見誤解(轉)Java
- 派克斯常見錯誤程式碼詳解
- Hadoop常見錯誤及解決方案Hadoop
- 開發常見錯誤及解決方案
- Go 常見錯誤集錦 | 字串底層原理及常見錯誤Go字串
- Go常見錯誤集錦 | 字串底層原理及常見錯誤Go字串
- 海外常見的http錯誤程式碼原因與解決HTTP
- ORACLE常見錯誤程式碼的分析與解決(轉)Oracle
- Go常見錯誤第15篇:interface使用的常見錯誤和最佳實踐Go
- 常見的資料分析誤區
- 常見的 PostgreSQL 升級錯誤SQL
- js作用域的常見錯誤JS
- mysql replication常見錯誤MySql
- Apache Kyuubi 助力 CDH 解鎖 Spark SQLApacheSparkSQL
- Apache Spark 記憶體管理詳解ApacheSpark記憶體
- 關於Apache Hadoop的常見問題解答ApacheHadoop
- Apache重寫規則的常見應用(轉)Apache
- 好程式設計師分享ApacheSpark常見的三大誤解程式設計師ApacheSpark
- 對定義過程和敏捷性的常見誤解敏捷
- 常見的七種Hadoop和Spark專案案例HadoopSpark
- 爬蟲常見錯誤程式碼及解決措施爬蟲
- MySQL資料庫常見錯誤及解決方案MySql資料庫
- MySQL常見錯誤分析與解決方法總結MySql
- 常見的授權錯誤及原因
- 常見的錯誤日誌型別型別