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 13、動態分區的支持，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的比較

註意：雖然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目前已經提供了基礎統計、分類、回歸、決策樹、隨機森林、朴素貝葉斯、保序回歸、協同過濾、聚類、維數縮減、特征提取與轉型、頻繁模式挖掘、預言模型標記語言、管道等多種數理統計、概率論、數據挖掘方面的數學演算法。

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

關於《Spark內核設計的藝術 架構設計與實現》

經過近一年的準備，基於Spark2.1.0版本的《Spark內核設計的藝術 架構設計與實現》一書現已出版發行，圖書如圖：

​

紙質版售賣鏈接如下：

京東：https://item.jd.com/12302500.html