【前言：本文主要從任務處理的運行模式為角度，分析Spark計算模型，希望幫助大家對Spark有一個更深入的瞭解。同時拿MapReduce和Spark計算模型做對比，強化對Spark和MapReduce理解】
從整體上看，無論是Spark還是MapReduce都是多進程模型。如，MapReduce是由很多MapTask、ReduceTask等進程級別的實例組成的；Spark是由多個worker、executor等進程級別實例組成。但是當細分到具體的處理任務，MapReduce仍然是多進程級別，這一點在文章《詳解MapReduce》（WeChat official account：大數據學習與分享）已有說明。而Spark處理任務的單位task是運行在executor中的線程，是多線程級別的。
對於多進程，我們可以很容易控制它們能夠使用的資源，並且一個進程的失敗一般不會影響其他進程的正常運行，但是進程的啟動和銷燬會佔用很多時間，同時該進程申請的資源在進程銷燬時也會釋放，這就造成了對資源的頻繁申請和釋放也是很影響性能的，這也是MapReduce廣為詬病的原因之一。
對於MapReduce處理任務模型，有如下特點：
1.每個MapTask、ReduceTask都各自運行在一個獨立的JVM進程中，因此便於細粒度控制每個task佔用的資源（資源可控性好）
2.每個MapTask/ReduceTask都要經歷申請資源 -> 運行task -> 釋放資源的過程。強調一點：每個MapTask/ReduceTask運行完畢所佔用的資源必須釋放，並且這些釋放的資源不能夠為該任務中其他task所使用
3.可以通過JVM重用在一定程度上緩解MapReduce讓每個task動態申請資源且運行完後馬上釋放資源帶來的性能開銷
但是JVM重用並不是多個task可以並行運行在一個JVM進程中，而是對於同一個job，一個JVM上最多可以順序執行的task數目，這個需要配置參數mapred.job.reuse.jvm.num.tasks，默認1。
對於多線程模型的Spark正好與MapReduce相反，這也決定了Spark比較適合運行低延遲的任務。在Spark中處於同一節點上的task以多線程的方式運行在一個executor進程中，構建了一個可重用的資源池，有如下特點：
1.每個executor單獨運行在一個JVM進程中，每個task則是運行在executor中的一個線程。很顯然線程線程級別的task啟動速度更快
2.同一節點上所有task運行在一個executor中，有利於共享內存。比如通過Spark的廣播變量，將某個文件廣播到executor端，那麼在這個executor中的task不用每個都拷貝一份處理，而只需處理這個executor持有的共有文件即可
3.executor所佔資源不會在一些task運行結束後立即釋放掉，可連續被多批任務使用，這避免了每個任務重複申請資源帶來的開銷
但是多線程模型有一個缺陷：同一節點的一個executor中多個task很容易出現資源徵用。畢竟資源分配最細粒度是按照executor級別的，無法對運行在executor中的task做細粒度控制。這也導致在運行一些超大數據量的任務並且資源比較有限時，運行不太穩定。相比較而言，MapReduce更有利於這種大任務的平穩運行。