Hadoop MapReduce採用了多程序模型，而Spark採用了多執行緒模型：

Apache Spark的高效能一定程度上取決於它採用的非同步併發模型（這裡指server/driver 端採用的模型），這與Hadoop 2.0（包括YARN和MapReduce）是一致的。Hadoop 2.0自己實現了類似Actor的非同步併發模型，實現方式是epoll+狀態機，而Apache Spark則直接採用了開源軟體Akka，該軟體實現了Actor模型，效能非常高。儘管二者在server端採用了一致的併發模型，但在任務級別（特指 Spark任務和MapReduce任務）上卻採用了不同的並行機制：Hadoop MapReduce採用了多程序模型，而Spark採用了多執行緒模型。

注意，本文的多程序和多執行緒，指的是同一個節點上多個任務的執行模 式。無論是MapReduce和Spark，整體上看，都是多程序：MapReduce應用程式是由多個獨立的Task程序組成的；Spark應用程式的 執行環境是由多個獨立的Executor程序構建的臨時資源池構成的。

多程序模型便於細粒度控制每個任務佔用的資源，但會消耗較多的啟動時間，不適合執行低延遲型別的作業，這是MapReduce廣為詬病的原因之一。而多執行緒模型則相反，該模型使得Spark很適合執行低延遲型別的作業。總之，Spark同節點上的任務以多執行緒的方式執行在一個JVM程序中，可帶來以下好處：

1）任務啟動速度快，與之相反的是MapReduce Task程序的慢啟動速度，通常需要1s左右；

2）同節點上所有任務執行在一個程序中，有利於共享記憶體。這非常適合記憶體密集型任務，尤其對於那些需要載入大量詞典的應用程式，可大大節省記憶體。

3） 同節點上所有任務可執行在一個JVM程序(Executor)中，且Executor所佔資源可連續被多批任務使用，不會在執行部分任務後釋放掉，這避免 了每個任務重複申請資源帶來的時間開銷，對於任務數目非常多的應用，可大大降低執行時間。與之對比的是MapReduce中的Task：每個Task單獨 申請資源，用完後馬上釋放，不能被其他任務重用，儘管1.0支援JVM重用在一定程度上彌補了該問題，但2.0尚未支援該功能。

儘管Spark的過執行緒模型帶來了很多好處，但同樣存在不足，主要有：

1）由於同節點上所有任務執行在一個程序中，因此，會出現嚴重的資源爭用，難以細粒度控制每個任務佔用資源。與之相 反的是MapReduce，它允許使用者單獨為Map Task和Reduce Task設定不同的資源，進而細粒度控制任務佔用資源量，有利於大作業的正常平穩執行。

下面簡要介紹MapReduce的多程序模型和Spark的多執行緒模型。

1.MapReduce多程序模型

1） 每個Task執行在一個獨立的JVM程序中；

2） 可單獨為不同型別的Task設定不同的資源量，目前支援記憶體和CPU兩種資源；

3） 每個Task執行完後，將釋放所佔用的資源，這些資源不能被其他Task複用，即使是同一個作業相同型別的Task。也就是說，每個Task都要經歷“申請資源—> 執行Task –> 釋放資源”的過程。

2.Spark多執行緒模型

1） 每個節點上可以執行一個或多個Executor服務；

2） 每個Executor配有一定數量的slot，表示該Executor中可以同時執行多少個ShuffleMapTask或者ReduceTask；

3） 每個Executor單獨執行在一個JVM程序中，每個Task則是執行在Executor中的一個執行緒；

4） 同一個Executor內部的Task可共享記憶體，比如通過函式SparkContext#broadcast廣播的檔案或者資料結構只會在每個Executor中載入一次，而不會像MapReduce那樣，每個Task載入一次；

5） Executor一旦啟動後，將一直執行，且它的資源可以一直被Task複用，直到Spark程式執行完成後才釋放退出。

總體上看，Spark採用的是經典的scheduler/workers模式， 每個Spark應用程式執行的第一步是構建一個可重用的資源池，然後在這個資源池裡執行所有的ShuffleMapTask和ReduceTask（注 意，儘管Spark程式設計方式十分靈活，不再侷限於編寫Mapper和Reducer，但是在Spark引擎內部只用兩類Task便可表示出一個複雜的應用 程式，即ShuffleMapTask和ReduceTask），而MapReduce應用程式則不同，它不會構建一個可重用的資源池，而是讓每個 Task動態申請資源，且執行完後馬上釋放資源。