在巨量資料處理技術領域快速竄起的Spark，正是藉助In-Memory的處理技術，大幅加速反應速度，解決了MapReduce會耗用大量I/O的問題。
在IT的世界裡有一項鐵則，當資料愈靠近處理器（CPU），反應的速度就會愈快。現今許多解決方案也都開始倡導In-Memory，直接將資料存放在記憶體，以便進一步加快處理速度。而這樣的概念，如今也套用在巨量資料分析上。
近年來，在巨量資料處理技術領域快速竄起的Spark，正是藉助In-Memory的處理技術，大幅加速分析速度。2014年Sort Benchmark Competition（資料排序基準競賽）中，Databricks公司使用Spark，在207台的叢集中，以23分鐘的成績刷新紀錄。相較之下，2013年由Yahoo創下的記錄，是在2,100台的叢集中使用MapReduce，花費了72分鐘完成。這項成就也讓Spark一戰成名。
 |
| ▲ IBM軟體事業處高級資訊工程師蘇友信指出，採用Spark可以避免MapReduce耗用大量I/O問題。 |
IBM軟體事業處高級資訊工程師蘇友信指出，Spark之所以受到矚目，主要是因為它能解決MapReduce會耗用大量I/O的問題。他解釋，MapReduce為了確保足夠的可靠性，所以會大量運用硬碟進行資料交換，而硬碟畢竟有其物理限制，最快不過15,000轉，因而導致效能不佳。
而另一方面，由於MapReduce的思維邏輯一定是Map–Reduce的流程，思維邏輯必須拆成片段，往往也讓程式人員很難在MapReduce上撰寫程式（Programming），這些限制也讓企業發現原來要走進MapReduce的世界，需要花很大的力氣學習新框架，並且在它的框架下改變程式風格（Style）。但是Spark不同之處在於，從資料分析到結果，中間的一連串邏輯可以用一支程式就寫完，邏輯的思考更為直覺，而且不會有I/O效能的問題。
儘管Spark在效率上取得極大的優勢，但至今仍無法完全取代MapReduce，蘇友信認為，這中間還存在舊包袱以及可行性的問題。一方面，在企業環境中，依然有很多舊的演算法必須執行在MapReduce上，而另一方面，從現狀來看，單一記憶體容量不可能高於硬碟，當資料量大到一個極致時，例如10PB時，企業勢必會考量可行性，「坦白說，在一個叢集中要部署這麼大量的記憶體並不容易，就算硬體架構做得到，成本也是一大考量。」
在架構層面上，Spark還有一個特點，它能獨立安裝在一台機器，或多台機器構成的叢集，簡單的說，Spark只負責運算，並不介意後端的儲存空間是一般的儲存設備或是Hadoop分散式檔案系統（HDFS）構成的空間，甚至安裝在一台電腦上也可以運行。
「只不過，由於Hadoop比Spark更早被推出，而企業也可能已經採購多台伺服器，將Spark架在Hadoop平台上，更能有效利用資源，特別是當企業需要把資料存放在NoSQL資料庫時，Hadoop上就有很好的生態系，例如HBase就可以存放資料。」但是他也建議，當企業要這麼做時，最好能夠擴充伺服器上的記憶體，「別忘了，Spark是藉助In-Memory的處理技術才能得到好的反應速度，如果不拉高記憶體容量，效果依然會不好。」