答案是否定的。

當做一個簡單的資料轉換，且只需要Map操作時，mapreduce的處理效率要比Spark高，因為Spark預處理和啟動的成本比較高

Mapreduce因為存在時間長，所以對多種場景都有優化，而Spark高效的處理場景相對較少。

Spark資源利用率低：
MapReduce在處理完task後會立即釋放資源，因為它的資源申請是以Task為粒度的；而Spark executor在完成任務處理後並不會關閉，繼續等待後序任務的處理，資源不能得到釋放

效能
Spark 在記憶體中處理資料，而 Hadoop MapReduce 是通過 map 和 reduce 操作在磁碟中處理資料。因此從這個角度上講 Spark 的效能應該是超過 Hadoop MapReduce 的。
然而，既然在記憶體中處理，Spark 就需要很大的記憶體容量。就像一個標準的資料庫系統操作一樣， Spark 每次將處理過程載入到記憶體之中，然後該操作作為快取一直保持在記憶體中直到下一步操作。如果 Spark 與其它資源需求型服務一同執行在 Hadoop YARN 上，又或者資料塊太大以至於不能完全讀入記憶體，此時 Spark 的效能就會有很大的降低。
與此相反， MapReduce 會在一個工作完成的時候立即結束該程序，因此它可以很容易的和其它服務共同執行而不會產生明顯的效能降低。
當涉及需要重複讀取同樣的資料進行迭代式計算的時候，Spark 有著自身優勢。 但是當涉及單次讀取、類似 ETL (抽取、轉換、載入)操作的任務，比如資料轉化、資料整合等時，MapReduce 絕對是不二之選，因為它就是為此而生的。
小結：當資料大小適於讀入記憶體，尤其是在專用叢集上時，Spark 表現更好;Hadoop MapReduce 適用於那些資料不能全部讀入記憶體的情況，同時它還可以與其它服務同時執行。
使用難度

Spark 有著靈活方便的Java，Scala和 Python 的API，同時對已經熟悉 SQL 的技術員工來說， Spark 還適用 Spark SQL(也就是之前被人熟知的 Shark)。多虧了 Spark 提供的簡單易用的構造模組，我們可以很容易的編寫自定義函式。它甚至還囊括了可以即時反饋的互動式命令模式。
Hadoop MapReduce 是用 Java 編寫的，但由於其難於程式設計而備受詬病。儘管需要一定時間去學習語法，Pig 還是在一定程度上簡化了這個過程， Hive也為平臺提供了 SQL 的相容。一些 Hadoop 工具也可以無需程式設計直接執行 MapReduce 任務。Xplenty 就是一個基於 Hadoop 的資料整合服務，而且也不需要進行任何程式設計和部署。
儘管 Hive 提供了命令列介面，但 MapReduce 並沒有互動式模式。諸如 Impala，Presto 和 Tez 等專案都在嘗試希望為 Hadoop 提供全互動式查詢模式。
安裝與維護方面， Spark 並不繫結在 Hadoop 上，雖然 在 Hortonworks(HDP 2.2 版) 和 Cloudera(CDH 5 版) 的產品中 Spark 和 Hadoop MapReduce 都包含在其分散式系統中。(注： Cloudera， Hortonworks 及 MapR 是 Hadoop 領域三大知名的初創公司，致力於打造更好的 Hadoop 企業版應用)。
小結：Spark 更易於程式設計，同時也包含互動式模式;Hadoop MapReduce 不易程式設計但是現有的很多工具使其更易於使用。
成本
Spark 和 Hadoop MapReduce 都是開源的，但是機器和人工的花費仍是不可避免的。
這兩個框架既可以在商用伺服器上也可以執行在雲端，下表可以看到它們有著相似的硬體需求：
框架 Apache Spark Apache Hadoop balanced workload slaves
核心 8–16 4
記憶體 8 GB 到數百GB 24 GB
硬碟 4–8 4–6 1TB
網路 10 GB 或更多 1 GB 乙太網
Spark 叢集的記憶體至少要和需要處理的資料塊一樣大，因為只有資料塊和記憶體大小合適才能發揮出其最優的效能。所以如果真的需要處理非常大的資料，Hadoop 絕對是合適之選，畢竟硬碟的費用要遠遠低於記憶體的費用。
考慮到 Spark 的效能標準，在執行相同的任務的時候，需要的硬體更少而執行速度卻更快，因此應該是更合算的，尤其是在雲端的時候，此時只需要即用即付。
在技術人員方面，即使 Hadoop 從 2005 年就開始普及，但是 MapReduce 方面的專家仍然存在著短缺。而對於從 2010 年才開始普及的 Spark ，這又意味著什麼呢? 或許投身 Spark 學習的人正在快速增加，但是相比於 Hadoop MapReduce 仍然存在著更大的技術人才的缺口。
進一步講，現存了大量的 Hadoop 即服務的資料和基於 Hadoop 的服務(比如我們 Xplenty 的資料整合服務)，這些都降低對技術人員能力和底層硬體知識的要求。相比之下，幾乎沒有現有可選的 Spark 服務，僅有的那些也是新產品。
小結：根據基準要求， Spark 更加合算， 儘管人工成本會很高。依靠著更多熟練的技術人員和 Hadoop 即服務的供給， Hadoop MapReduce 可能更便宜。
相容性
Spark 既可以單獨執行，也可以在 Hadoop YARN 上，或者在預置 Mesos 上以及雲端。它支援實現 Hadoop 輸入正規化的資料來源，所以可以整合所有 Hadoop 支援的資料來源和檔案格式。 根據 Spark 官方教程， 它還可以通過 JDBC 和 ODBC 同 BI(商業智慧) 工具一起執行。 Hive 和 Pig 也在逐步實現這樣的功能。
小結： Spark 和 Hadoop MapReduce 具有相同的資料型別和資料來源的相容性。
資料處理
除了平常的資料處理，Spark 可以做的遠不止這點：它還可以處理圖和利用現有的機器學習庫。高效能也使得 Spark 在實時處理上的表現和批處理上的表現一樣好。這也催生了一個更好的機遇，那就是用一個平臺解決所有問題而不是隻能根據任務選取不同的平臺，畢竟所有的平臺都需要學習和維護。
Hadoop MapReduce 在批處理上表現卓越。如果需要進行實時處理，可以利用另外的平臺比如 Storm 或者 Impala，而圖處理則可以用 Giraph。MapReduce 過去是用 Mahout 做機器學習的，但其負責人已經將其拋棄轉而支援 Spark 和 h2o(機器學習引擎)。
小結：Spark 是資料處理的瑞士軍刀;Hadoop MapReduce 是批處理的突擊刀。
容錯
和 MapReduce 一樣， Spark 會重試每個任務並進行預測執行。然而，MapReduce 是依賴於硬碟驅動器的，所以如果一項處理中途失敗，它可以從失敗處繼續執行，而 Spark 則必須從頭開始執行，所以 MapReduce 這樣節省了時間。
小結：Spark 和 Hadoop MapReduce 都有著較好的容錯能力，但是 Hadoop MapReduce 要稍微更好一點。
安全性
在安全性上， 此時的 Spark 還略顯不足。 授權驗證由共享祕鑰機制支援，網路使用者介面則通過 servlet 過濾器和事件日誌保護。Spark 可以執行在 YARN 上並配合使用 HDFS， 這也就意味著它同時還擁有 Kerberos 認證授權驗證，HDFS 檔案許可機制和節點間的加密機制。
Hadoop MapReduce 擁有所有 Hadoop 支援的安全機制，同時也整合了其它基於 Hadoop 的安全專案， 比如 Knox 閘道器和 Sentry。志在解決 Hadoop 安全的 Rhino 專案也只是在新增 Sentry 支援時添加了 Spark 支援。否則 Spark 開發者們只能自己去提升其安全性了。
小結： Spark 的安全機制仍處在發展期。 Hadoop MapReduce 擁有更多安全控制機制和專案。
總結
Spark 是大資料領域冉冉升起的新星，但是 Hadoop MapReduce 仍有著較廣的應用領域。
在記憶體中進行資料處理使得 Spark 具有較好的效能表現，也比較高效合算。它相容所有 Hadoop 的資料來源和檔案格式， 支援多種語言的簡單易用的 API 也使人們更快速的可以上手。 Spark 甚至實現了圖處理和機器學習工具。
Hadoop MapReduce 是一個更加成熟的平臺，為進行批處理而生。當遇到確實非常大的資料以至於無法完全讀入記憶體，又或是依靠著大量對該平臺有經驗的技術人員，它可能會比 Spark 更加合算。 而且圍繞 Hadoop MapReduce 的衍生系統正在依靠著更多的支撐專案、工具和雲服務而更加壯大。
但是即使看上去 Spark 像是最終的贏家，問題在於我們永遠不會單獨使用它—我們需要 HDFS 儲存資料，或許還會需要用到 HBase，Hive，Pig，Impala 或其他 Hadoop 專案。這意味著在處理非常大的資料的時候，Spark 仍然需要同 Hadoop 和 MapReduce 共同執行。