Spark2.1.0模型設計與基本架構（上）

　　隨着近十年互聯網的迅猛發展，愈來愈多的人融入了互聯網——利用搜索引擎查詢詞條或問題；社交圈子從現實搬到了Facebook、Twitter、微信等社交平臺上；女孩子們如今少了逛街，多了在各大電商平臺上的購買；喜歡棋牌的人可以在對戰平臺上找到世界各地的玩家對弈。在國內隨着網民數量的持續增長，形成互聯網公司的數據在體量、產生速度、多樣性等方面呈現出巨大的變化。

　　互聯網產生的數據相較於傳統軟件產生的數據，有着數據挖掘的巨大潛力。經過對數據的挖掘，能夠統計出PV、UV，計算出不一樣設備與註冊率、促銷與下單率之間的關係，甚至構建熱點分析、人羣畫像等算法模型，產生一系列報表、圖形、離線統計、實時計算的產品。互聯網公司若是能有效利用這些數據，將對決策和戰略發展起到相當重要的做用。

　　在大數據的大勢之下，Hadoop、Spark、Flink、Storm、Dremel、Impala、Tez等一系列大數據技術如雨後春筍般不斷涌現。工程師們正在使用這些工具在摸索中前行。        

　　Spark是一個通用的並行計算框架，由加州伯克利大學（UCBerkeley）的AMP實驗室開發於2009年，並於2010年開源。2013年成長爲Apache旗下在大數據領域最活躍的開源項目之一。

　　Spark目前已經走過了0.x和1.x兩個時代，如今正在2.x時代穩步發展。Spark從2012年10月15日發佈0.6到2016年1月4日發佈1.6只通過了三年時間，那時候差很少每月都會有新的版本發佈，平均每一個季度會發佈一個新的二級版本。

　　自從2016年7月發佈了2.0.0版本以來，只在當年12月又發佈了2.1.0版本，直到目前爲止尚未新的二級版本發佈。Spark發佈新版本的節奏明顯慢了下來，固然這也跟Spark團隊過於激進的決策（好比不少API不能向前兼容，讓用戶無力吐槽）有關。

　　Spark也是基於map reduce 算法模型實現的分佈式計算框架，擁有Hadoop MapReduce所具備的優勢，而且解決了Hadoop MapReduce中的諸多缺陷。

Hadoop MRv1的侷限

　　早在Hadoop1.0版本，當時採用的是MRv1版本的MapReduce編程模型。MRv1版本的實現都封裝在org.apache.hadoop.mapred包中，MRv1的Map和Reduce是經過接口實現的。MRv1包括三個部分：

• 運行時環境（JobTracker和TaskTracker）；
• 編程模型（MapReduce）；
• 數據處理引擎（Map任務和Reduce任務）。

　　MRv1存在如下不足。

• 可擴展性差：在運行時，JobTracker既負責資源管理又負責任務調度，當集羣繁忙時，JobTracker很容易成爲瓶頸，最終致使它的可擴展性問題。
• 可用性差：採用了單節點的Master，沒有備用Master及選舉操做，這致使一旦Master出現故障，整個集羣將不可用。
• 資源利用率低：TaskTracker 使用slot等量劃分本節點上的資源量。slot表明計算資源（CPU、內存等）。一個Task 獲取到一個slot 後纔有機會運行，Hadoop 調度器負責將各個TaskTracker 上的空閒slot 分配給Task 使用。一些Task並不能充分利用slot，而其餘Task也沒法使用這些空閒的資源。slot 分爲Map slot 和Reduce slot 兩種，分別供MapTask 和Reduce Task 使用。有時會由於做業剛剛啓動等緣由致使MapTask不少，而Reduce Task任務尚未調度的狀況，這時Reduce slot也會被閒置。
• 不能支持多種MapReduce框架：沒法經過可插拔方式將自身的MapReduce框架替換爲其餘實現，如Spark、Storm等。

      MRv1的示意如圖1。

​

圖1   MRv1示意圖

　　Apache爲了解決以上問題，對Hadoop升級改造，MRv2最終誕生了。MRv2中，重用了MRv1中的編程模型和數據處理引擎。可是運行時環境被重構了。JobTracker被拆分紅了通用的資源調度平臺（ResourceManager，簡稱RM）、節點管理器（NodeManager）和負責各個計算框架的任務調度模型（ApplicationMaster，簡稱AM）。ResourceManager依然負責對整個集羣的資源管理，可是在任務資源的調度方面只負責將資源封裝爲Container分配給ApplicationMaster 的一級調度，二級調度的細節將交給ApplicationMaster去完成，這大大減輕了ResourceManager 的壓力，使得ResourceManager 更加輕量。NodeManager負責對單個節點的資源管理，並將資源信息、Container運行狀態、健康情況等信息上報給ResourceManager。ResourceManager 爲了保證Container的利用率，會監控Container，若是Container未在有限的時間內使用，ResourceManager將命令NodeManager殺死Container，以便於將資源分配給其餘任務。MRv2的核心再也不是MapReduce框架，而是Yarn。在以Yarn爲核心的MRv2中，MapReduce框架是可插拔的，徹底能夠替換爲其餘MapReduce實現，好比Spark、Storm等。MRv2的示意如圖2所示。

圖2   MRv2示意圖

　　Hadoop MRv2雖然解決了MRv1中的一些問題，可是因爲對HDFS的頻繁操做（包括計算結果持久化、數據備份、資源下載及Shuffle等）致使磁盤I/O成爲系統性能的瓶頸，所以只適用於離線數據處理或批處理，而不能支持對迭代式、流式數據的處理。

Spark的特色

　　Spark看到MRv2的問題，對MapReduce作了大量優化，總結以下：

• 減小磁盤I/O：隨着實時大數據應用愈來愈多，Hadoop做爲離線的高吞吐、低響應框架已不能知足這類需求。HadoopMapReduce的map端將中間輸出和結果存儲在磁盤中，reduce端又須要從磁盤讀寫中間結果，勢必形成磁盤IO成爲瓶頸。Spark容許將map端的中間輸出和結果存儲在內存中，reduce端在拉取中間結果時避免了大量的磁盤I/O。Hadoop Yarn中的ApplicationMaster申請到Container後，具體的任務須要利用NodeManager從HDFS的不一樣節點下載任務所需的資源（如Jar包），這也增長了磁盤I/O。Spark將應用程序上傳的資源文件緩衝到Driver本地文件服務的內存中，當Executor執行任務時直接從Driver的內存中讀取，也節省了大量的磁盤I/O。
• 增長並行度：因爲將中間結果寫到磁盤與從磁盤讀取中間結果屬於不一樣的環節，Hadoop將它們簡單的經過串行執行銜接起來。Spark把不一樣的環節抽象爲Stage，容許多個Stage既能夠串行執行，又能夠並行執行。
• 避免從新計算：當Stage中某個分區的Task執行失敗後，會從新對此Stage調度，但在從新調度的時候會過濾已經執行成功的分區任務，因此不會形成重複計算和資源浪費。
• 可選的Shuffle排序：HadoopMapReduce在Shuffle以前有着固定的排序操做，而Spark則能夠根據不一樣場景選擇在map端排序或者reduce端排序。
• 靈活的內存管理策略：Spark將內存分爲堆上的存儲內存、堆外的存儲內存、堆上的執行內存、堆外的執行內存4個部分。Spark既提供了執行內存和存儲內存之間是固定邊界的實現，又提供了執行內存和存儲內存之間是「軟」邊界的實現。Spark默認使用「軟」邊界的實現，執行內存或存儲內存中的任意一方在資源不足時均可以借用另外一方的內存，最大限度的提升資源的利用率，減小對資源的浪費。Spark因爲對內存使用的偏好，內存資源的多寡和使用率就顯得尤其重要，爲此Spark的內存管理器提供的Tungsten實現了一種與操做系統的內存Page很是類似的數據結構，用於直接操做操做系統內存，節省了建立的Java對象在堆中佔用的內存，使得Spark對內存的使用效率更加接近硬件。Spark會給每一個Task分配一個配套的任務內存管理器，對Task粒度的內存進行管理。Task的內存能夠被多個內部的消費者消費，任務內存管理器對每一個消費者進行Task內存的分配與管理，所以Spark對內存有着更細粒度的管理。

基於以上所列舉的優化，Spark官網聲稱性能比Hadoop快100倍，如圖3所示。即使是內存不足須要磁盤I/O時，其速度也是Hadoop的10倍以上。

​

圖3   Hadoop與Spark執行邏輯迴歸時間比較

Spark還有其餘一些特色。

• 檢查點支持：Spark的RDD之間維護了血緣關係（lineage），一旦某個RDD失敗了，則能夠由父RDD重建。雖然lineage可用於錯誤後RDD的恢復，但對於很長的lineage來講，恢復過程很是耗時。若是應用啓用了檢查點，那麼在Stage中的Task都執行成功後，SparkContext將把RDD計算的結果保存到檢查點，這樣當某個RDD執行失敗後，在由父RDD重建時就不須要從新計算，而直接從檢查點恢復數據。
• 易於使用。Spark如今支持Java、Scala、Python和R等語言編寫應用程序，大大下降了使用者的門檻。自帶了80多個高等級操做符，容許在Scala，Python，R的shell中進行交互式查詢。
• 支持交互式：Spark使用Scala開發，並藉助於Scala類庫中的Iloop實現交互式shell，提供對REPL（Read-eval-print-loop）的實現。
• 支持SQL查詢。在數據查詢方面，Spark支持SQL及Hive SQL，這極大的方便了傳統SQL開發和數據倉庫的使用者。
• 支持流式計算：與MapReduce只能處理離線數據相比，Spark還支持實時的流計算。Spark依賴SparkStreaming對數據進行實時的處理，其流式處理能力還要強於Storm。
• 可用性高。Spark自身實現了Standalone部署模式，此模式下的Master能夠有多個，解決了單點故障問題。Spark也徹底支持使用外部的部署模式，好比YARN、Mesos、EC2等。
• 豐富的數據源支持：Spark除了能夠訪問操做系統自身的文件系統和HDFS，還能夠訪問Kafka、Socket、Cassandra、HBase、Hive、Alluxio（Tachyon）以及任何Hadoop的數據源。這極大地方便了已經使用HDFS、HBase的用戶順利遷移到Spark。
• 豐富的文件格式支持：Spark支持文本文件格式、Csv文件格式、Json文件格式、Orc文件格式、Parquet文件格式、Libsvm文件格式，也有利於Spark與其餘數據處理平臺的對接。

Spark使用場景

　　Hadoop經常使用於解決高吞吐、批量處理的業務場景，例如對瀏覽量的離線統計。若是須要實時查看瀏覽量統計信息，Hadoop顯然不符合這樣的要求。Spark經過內存計算能力極大地提升了大數據處理速度，知足了以上場景的須要。此外，Spark還支持交互式查詢，SQL查詢，流式計算，圖計算，機器學習等。經過對Java、Python、Scala、R等語言的支持，極大地方便了用戶的使用。

　　筆者就目前所知道的Spark應用場景，進行介紹。

1.醫療健康

　　看病是一個很是典型的分析過程——醫生根據患者的一些徵兆、檢驗結果，結合醫生本人的經驗得出結論，最後給出相應的治療方案。如今國內的醫療情況是各地區醫療水平良莠不齊，醫療資源也很是緊張，特別是高水平醫生更爲緊缺，好醫院的地區分佈很不均衡。大城市有更完善的醫療體系，而農村可能就只有幾個赤腳醫生。一些農民看病可能要從村裏坐車到鎮，再到縣城，再到地級市甚至省會城市，看病的路程堪比征程。

　　大數據根據患者的患病徵兆、檢驗報告，經過病理分析模型找出病因並給出具體的治療方案。即使是醫療水平落後的地區，只須要輸入患者的患病徵兆和病例數據既可體驗高水平醫師的服務。經過Spark從海量數據中實時計算出病因，各個地區的醫療水平和效率將得到大幅度提高，同時也能很好的下降由於醫生水平而致使誤診的機率。

　　實施醫療健康的必然措施是監測和預測。經過監測不斷更新整個醫療基礎庫的知識，並經過醫療健康模型預測出疾病易發的地區和人羣。

2.電商

　　經過對用戶的消費習慣、季節、產品使用週期等數據的收集，創建算法模型來判斷消費者將來一個月、幾個月甚至一年的消費需求（不是簡單的根據你已經消費的產品，顯示推薦廣告位），進而提升訂單轉化率。

　　在市場營銷方面，經過給買家打標籤，構建人羣畫像，進而針對不一樣的人羣，精準投放廣告、紅包或優惠券。

3.安全領域

　　面對日益複雜的網絡安全，經過檢測和數據分析區分出不一樣的安全類型。並針對不一樣的安全類型，實施不一樣的防護、打擊措施。

• 端安全：使用安全衛士、雲查殺對通過大數據分析獲得的病毒、木馬等進行防護。
• 電商安全：反刷單、反欺詐、合規。
• 金融安全：風險控制。
• 企業安全：反入侵。
• 國家安全：輿情監測，打擊罪犯。

4.金融領域

　　構建金融雲，經過對巨量的計量數據收集。經過Spark實時處理分析，利用低延遲的數據處理能力，應對急迫的業務需求和數據增加。

　　量化投資——收集大宗商品的價格，黃金，石油等各類數據，分析黃金、股票等指數趨勢，支持投資決策。

　　除了以上領域外，在搜索引擎、生態圈異常檢測、生物計算等諸多領域都有普遍的應用場景。

版本變遷

　　通過5年多的發展，Spark目前的大版本是2.3.0。Spark主要版本的發展過程以下：

1. Spark誕生於UCBerkeley的AMP實驗室（2009）。
2. Spark正式對外開源（2010）。
3. Spark 0.6.0版本發佈（2012-10-15），大範圍的性能改進，增長了一些新特性，並對Standalone部署模式進行了簡化。
4. Spark 0.7.0版本發佈（2013-02-27），增長了更多關鍵特性，例如：PythonAPI、Spark Streaming的alpha版本等。
5. Spark接受進入Apache孵化器（2013-06-21）。
6. Spark 0.8.0版本發佈（2013-09-25），一些新功能及可用性改進。
7. Spark 0.8.1版本發佈（2013-12-19），支持Scala 2.9，YARN 2.2，Standalone部署模式下調度的高可用性，shuffle的優化等。
8. Spark 0.9.0版本發佈（2014-02-02），增長了GraphX、機器學習、流式計算等新特性，對核心引擎的優化（外部聚合、增強對YARN的支持）等。
9. Spark 1.0.0版本發佈（2014-05-30），增長了Spark SQL。對MLlib、GraphX和Spark Streaming都增長了新特性並進行了優化。Spark核心引擎還增長了對安全YARN集羣的支持。
10. Spark 1.1.0版本發佈（2014-09-11）。對MLlib andSpark SQL進行了顯著的擴展等。
11. Spark 1.2.0版本發佈（2014-12-18），Spark SQL增長了對HIVE 1三、動態分區的支持，SparkStreaming增長了Python語言的API等。
12. Spark 1.3.0版本發佈（2015-03-13），在Spark SQL 中增長了DataFrameAPI。
13. Spark 1.4.0版本發佈（2015-06-11），增長了R語言的API，對Spark核心引擎的可用性進行了改進，對MLlib和Spark Streaming進行了擴展。
14. Spark 1.5.0版本發佈（2015-09-09），對各類功能和API進行了修改或改進。
15. Spark 1.6.0版本發佈（2016-01-04），對Spark Core、Spark SQL、Spark Streaming、MLlib的API進行了改進，對SparkCore和Spark SQL的性能進行了優化。
16. Spark 2.0.0版本發佈（2016-07-26），增長API的穩定性，對SQL 2003標準的支持，性能的優化，結構化的Streaming，R語言UDF的支持等。
17. Spark 2.1.0版本發佈（2016-12-28），主要對結構化的Streaming進行了改進。
18. Spark 2.2.0版本發佈（2017-07-11），正式提供非實驗性質的結構化的Streaming。
19. Spark 2.3.0版本發佈（2018-02-28），增長結構化Streaming的連續處理，Kubernetes的調度後端。

基本概念

　　要想對Spark有總體性的瞭解，推薦讀者閱讀Matei Zaharia的Spark論文。此處筆者先介紹Spark中的一些概念：

• RDD（resillient distributed dataset）：彈性分佈式數據集。Spark應用程序經過使用Spark的轉換API能夠將RDD封裝爲一系列具備血緣關係的RDD，也就是DAG。只有經過Spark的動做API纔會將RDD及其DAG提交到DAGScheduler。RDD的祖先必定是一個跟數據源相關的RDD，負責從數據源迭代讀取數據。
• DAG（Directed Acycle graph）：有向無環圖。在圖論中，若是一個有向圖沒法從某個頂點出發通過若干條邊回到該點，則這個圖是一個有向無環圖（DAG圖）。Spark使用DAG來反映各RDD之間的依賴或血緣關係。
• Partition：數據分區。即一個RDD的數據能夠劃分爲多少個分區。Spark根據Partition的數量來肯定Task的數量。
• NarrowDependency：窄依賴。即子RDD依賴於父RDD中固定的Partition。NarrowDependency分爲OneToOneDependency和RangeDependency兩種。
• ShuffleDependency：Shuffle依賴，也稱爲寬依賴。即子RDD對父RDD中的全部Partition均可能產生依賴。子RDD對父RDD各個Partition的依賴將取決於分區計算器（Partitioner）的算法。
• Job：用戶提交的做業。當RDD及其DAG被提交給DAGScheduler調度後，DAGScheduler會將全部RDD中的轉換及動做視爲一個Job。一個Job由一到多個Task組成。
• Stage：Job的執行階段。DAGScheduler按照ShuffleDependency做爲Stage的劃分節點對RDD的DAG進行Stage劃分（上游的Stage將爲ShuffleMapStage）。所以一個Job可能被劃分爲一到多個Stage。Stage分爲ShuffleMapStage和ResultStage兩種。
• Task：具體執行任務。一個Job在每一個Stage內都會按照RDD的Partition 數量，建立多個Task。Task分爲ShuffleMapTask和ResultTask兩種。ShuffleMapStage中的Task爲ShuffleMapTask，而ResultStage中的Task爲ResultTask。ShuffleMapTask和ResultTask相似於Hadoop中的 Map任務和Reduce任務。

Scala與Java的比較

　　目前愈來愈多的語言能夠運行在Java虛擬機上，Java平臺上的多語言混合編程正成爲一種潮流。在混合編程模式下能夠充分利用每種語言的特色和優點，以便更好地完成功能。Spark同時選擇了Scala和Java做爲開發語言，也是爲了充分利用兩者各自的優點。表1對這兩種語言進行比較。

表1   Scala與Java的比較

	Scala	Java
語言類型	面向函數爲主，兼有面向對象	面向對象（Java8也增長了lambda函數編程）
簡潔性	很是簡潔	不簡潔
類型推斷	豐富的類型推斷，例如深度和鏈式的類型推斷、 duck type 、隱式類型轉換等，但也所以增長了編譯時長	少許的類型推斷
可讀性	通常，豐富的語法糖致使的各類奇幻用法，例如方法簽名、隱式轉換	好
學習成本	較高	通常
語言特性	很是豐富的語法糖和更現代的語言特性，例如 Option 、模式匹配、使用空格的方法調用	豐富
併發編程	使用Actor的消息模型	使用阻塞、鎖、阻塞隊列等

注意：雖然Actor是Scala語言最初進行推廣時，最吸引人的特性之一，可是隨着Akka更增強大的Actor類庫的出現，Scala已經在官方網站宣佈廢棄Scala自身的Actor編程模型，轉而全面擁抱Akka提供的Actor編程模型。與此同時，從Spark2.0.0版本開始，Spark卻放棄了使用Akka，轉而使用Netty實現了本身的Rpc框架。遙想當年Scala「鼓吹」Actor編程模型優於Java的同步編程模型時，又有誰會想到現在這種場面呢？

　　Scala做爲函數式編程的表明，天生適合並行運行，若是用Java語言實現相同的功能會顯得很是臃腫。不少介紹Spark的新聞或文章常常以Spark內核代碼行數少或API精煉等內容做爲宣傳的「法器」，這應該也是選擇Scala的緣由之一。另外一方面，因爲函數式編程更接近計算機思惟，所以便於經過算法從大數據中建模，這也更符合Spark做爲大數據框架的理念吧！

　　因爲Java適合服務器、中間件開發，因此Spark使用Java更多的是開發底層的基礎設施或中間件。

模塊設計

整個Spark主要由如下模塊組成：

• Spark Core：Spark的核心功能實現，包括：基礎設施、SparkContext（Application經過SparkContext提交）、Spark執行環境（SparkEnv）、存儲體系、調度系統、計算引擎、部署模式、任務提交與執行等。
• Spark SQL：提供SQL處理能力，便於熟悉關係型數據庫操做的工程師進行交互查詢。此外，還爲熟悉Hive開發的用戶提供了對Hive SQL的支持。
• Spark Streaming：提供流式計算處理能力，目前支持ApacheKafka、Apache Flume、Amazon Kinesis和簡單的TCP套接字等數據源。在早期的Spark版本中還自帶對Twitter、MQTT、ZeroMQ等的支持，如今用戶想要支持這些工具必須本身開發實現。此外，Spark Streaming還提供窗口操做用於對必定週期內的流數據進行處理。
• GraphX：基於圖論，實現的支持分佈式的圖計算處理框架。GraphX的基礎是點、邊等圖論的理論。GraphX 基於圖計算的Pregel模型提供了多種多樣的Pregel API，這些Pregel API能夠解決圖計算中的常見問題。
• MLlib：Spark提供的機器學習庫。MLlib提供了機器學習相關的統計、分類、迴歸等領域的多種算法實現。其一致的API接口大大下降了用戶的學習成本。

Spark SQL、Spark Streaming、GraphX、MLlib的能力都是創建在覈心引擎之上，如圖4。

圖4   Spark各模塊依賴關係

Spark核心功能

　　Spark Core中提供了Spark最基礎與最核心的功能，主要包括：

• 基礎設施：在Spark中有不少基礎設施，被Spark中的各類組件普遍使用。這些基礎設施包括Spark配置（SparkConf）、Spark內置的Rpc框架（在早期Spark版本中Spark使用的是Akka）、事件總線（ListenerBus）、度量系統。SparkConf用於管理Spark應用程序的各類配置信息。Spark內置的Rpc框架使用Netty實現，有同步和異步的多種實現，Spark各個組件間的通訊都依賴於此Rpc框架。若是說Rpc框架是跨機器節點不一樣組件間的通訊設施，那麼事件總線就是SparkContext內部各個組件間使用事件——監聽器模式異步調用的實現。度量系統由Spark中的多種度量源（Source）和多種度量輸出（Sink）構成，完成對整個Spark集羣中各個組件運行期狀態的監控。
• SparkContext：一般而言，用戶開發的Spark應用程序（Application）的提交與執行都離不開SparkContext的支持。在正式提交Application以前，首先須要初始化SparkContext。SparkContext隱藏了網絡通訊、分佈式部署、消息通訊、存儲體系、計算引擎、度量系統、文件服務、Web UI等內容，應用程序開發者只須要使用SparkContext提供的API完成功能開發。
• SparkEnv：Spark執行環境（SparkEnv）是Spark中的Task運行所必須的組件。SparkEnv內部封裝了Rpc環境（RpcEnv）、序列化管理器、廣播管理器（BroadcastManager）、map任務輸出跟蹤器（MapOutputTracker）、存儲體系、度量系統（MetricsSystem）、輸出提交協調器（OutputCommitCoordinator）等Task運行所需的各類組件。
• 存儲體系：Spark優先考慮使用各節點的內存做爲存儲，當內存不足時纔會考慮使用磁盤，這極大地減小了磁盤I/O，提高了任務執行的效率，使得Spark適用於實時計算、迭代計算、流式計算等場景。在實際場景中，有些Task是存儲密集型的，有些則是計算密集型的，因此有時候會形成存儲空間很空閒，而計算空間的資源又很緊張。Spark的內存存儲空間與執行存儲空間之間的邊界能夠是「軟」邊界，所以資源緊張的一方能夠借用另外一方的空間，這既能夠有效利用資源，又能夠提升Task的執行效率。此外，Spark的內存空間還提供了Tungsten的實現，直接操做操做系統的內存。因爲Tungsten省去了在堆內分配Java對象，所以能更加有效的利用系統的內存資源，而且由於直接操做系統內存，空間的分配和釋放也更迅速。在Spark早期版本還使用了之內存爲中心的高容錯的分佈式文件系統Alluxio（Tachyon）供用戶進行選擇。Alluxio可以爲Spark提供可靠的內存級的文件共享服務。
• 調度系統：調度系統主要由DAGScheduler和TaskScheduler組成，它們都內置在SparkContext中。DAGScheduler負責建立Job、將DAG中的RDD劃分到不一樣的Stage、給Stage建立對應的Task、批量提交Task等功能。TaskScheduler負責按照FIFO或者FAIR等調度算法對批量Task進行調度；爲Task分配資源；將Task發送到集羣管理器分配給當前應用的Executor上由Executor負責執行等工做。現現在，Spark增長了SparkSession和DataFrame等新的API，SparkSession底層實際依然依賴於SparkContext。
• 計算引擎：計算引擎由內存管理器（MemoryManager）、Tungsten、任務內存管理器（TaskMemoryManager）、Task、外部排序器（ExternalSorter）、Shuffle管理器（ShuffleManager）等組成。MemoryManager除了對存儲體系中的存儲內存提供支持和管理，還外計算引擎中的執行內存提供支持和管理。Tungsten除用於存儲外，也能夠用於計算或執行。TaskMemoryManager對分配給單個Task的內存資源進行更細粒度的管理和控制。ExternalSorter用於在map端或reduce端對ShuffleMapTask計算獲得的中間結果進行排序、聚合等操做。ShuffleManager用於將各個分區對應的ShuffleMapTask產生的中間結果持久化到磁盤，並在reduce端按照分區遠程拉取ShuffleMapTask產生的中間結果。

Spark擴展功能

　　爲了擴大應用範圍，Spark陸續增長了一些擴展功能，主要包括：

• Spark SQL：因爲SQL具備普及率高、學習成本低等特色，爲了擴大Spark的應用面，所以增長了對SQL及Hive的支持。Spark SQL的過程能夠總結爲：首先使用SQL語句解析器（SqlParser）將SQL轉換爲語法樹（Tree），而且使用規則執行器（RuleExecutor）將一系列規則（Rule）應用到語法樹，最終生成物理執行計劃並執行的過程。其中，規則包括語法分析器（Analyzer）和優化器（Optimizer）。Hive的執行過程與SQL相似。
• Spark Streaming：Spark Streaming與Apache Storm相似，也用於流式計算。SparkStreaming支持Kafka、Flume、Kinesis和簡單的TCP套接字等多種數據輸入源。輸入流接收器（Receiver）負責接入數據，是接入數據流的接口規範。Dstream是Spark Streaming中全部數據流的抽象，Dstream能夠被組織爲DStreamGraph。Dstream本質上由一系列連續的RDD組成。
• GraphX：Spark提供的分佈式圖計算框架。GraphX主要遵循總體同步並行計算模式（Bulk Synchronous Parallell，簡稱BSP）下的Pregel模型實現。GraphX提供了對圖的抽象Graph，Graph由頂點（Vertex）、邊（Edge）及繼承了Edge的EdgeTriplet（添加了srcAttr和dstAttr用來保存源頂點和目的頂點的屬性）三種結構組成。GraphX目前已經封裝了最短路徑、網頁排名、鏈接組件、三角關係統計等算法的實現，用戶能夠選擇使用。
• MLlib：Spark提供的機器學習框架。機器學習是一門涉及機率論、統計學、逼近論、凸分析、算法複雜度理論等多領域的交叉學科。MLlib目前已經提供了基礎統計、分類、迴歸、決策樹、隨機森林、樸素貝葉斯、保序迴歸、協同過濾、聚類、維數縮減、特徵提取與轉型、頻繁模式挖掘、預言模型標記語言、管道等多種數理統計、機率論、數據挖掘方面的數學算法。

有關Spark2.1.0架構相關的其他內容，請繼續閱讀《Spark2.1.0模型設計與基本架構（下）》一文。

引用：本文的圖1和圖2都來源自http://blog.chinaunix.net/uid-28311809-id-4383551.html。