從集羣資源管理和任務調度角度看spark

講spark的文章很多，切入點無非就是三個：框架應用、源碼和原理講解、性能優化

個人覺得上面的三個視角切入點都過於偏重細節，比較適合行業工程師（應用開發、研發、維護）；對於初入行的學習者和非工程師角色比較不友好，本文嘗試從一個更高視角去介紹spark，儘量讓大家明白這個東西是個什麼，如何演化過來的；爲什麼它會長成現在模樣，包括那些模塊。

0. 集羣資源管理與任務調度系統出現的背景

（1）出現背景

提高集羣資源利用率。

在大數據時代，爲了存儲和處理海量數據，需要規模較大的服務器集羣或者數據中心，一般說來，這些集羣上運行着數量衆多類型紛雜的應用程序和服務，比如離線作業，流式作業，迭代式作業，crawler server，web server等，傳統的做法是，每種類型的作業或者服務對應一個單獨的集羣，以避免相互干擾。這樣，集羣被分割成數量衆多的小集羣，有的集羣運行Hadoop，有的運行Storm，有的運行Spark，有的運行web server，然而，由於不同類型的作業/服務需要的資源量不同，因此，這些小集羣的利用率通常很不均衡，有的集羣滿負荷、資源緊張，而另外一些則長時間閒置、資源利用率極低，爲了提高資源整體利用率，一種解決方案是將這些小集羣合併成一個大集羣，讓它們共享這個大集羣的資源，並由一個資源統一調度系統進行資源管理和分配，這就誕生了Borg，YARN，Mesos，Torca，Corona。從集羣共享角度看，這類系統實際上將公司的所有硬件資源抽象成一個臺大型計算機，供所有用戶使用。

服務自動化部署

一旦將所有計算資源抽象成一個“大型計算機”後，就會產生一個問題：公司的各種服務如何進行部署？同樣，Borg/YARN/Mesos/Torca/Corona一類系統需要具備服務自動化部署的功能，因此，從服務部署的角度看，這類系統實際上是服務統一管理系統，這類系統提供服務資源申請，服務自動化部署，服務容錯等動能。

以上只是簡單的介紹了這一類系統的設計動機和產生背景，接下來從兩個角度解析這類系統。

角度一：數據中心編程

任何一個公司內部所有的硬件資源均可看做一個數據中心，通過Borg/YARN/Mesos/Torca/Corona一類系統對這些資源進行統一管理後，用戶所有的程序和服務將通過一個統一入口進入數據中心，並由這類系統爲之分配資源、監控程序和服務運行狀態，並在失敗時啓用必要的容錯機制，彙報程序的執行進度等，而至於應用程序或者服務運行在具體哪臺機器上，所在機器的ip、端口號是什麼，則用戶無需管理，全部交由統一管理系統進行管理（用戶也許可以查詢到）。

具體說來，採用此類系統之後，當用戶執行應用程序或者部署服務時，只需通過一個配置文件描述應用程序或服務需要的資源（比如CPU、內存、磁盤、操作系統類型等）、待執行的命令、依賴的外部文件等信息，然後通過一個客戶端提交到Borg/YARN/Mesos/Torca/Corona上，剩下的工作則完全交給系統。

角度二：生態系統

從另外一個角度看，Borg/YARN/Mesos/Torca/Corona一類系統可以爲公司構建一個內部的生態系統，所有應用程序和服務可以“和平而友好”地運行在該生態系統上。有了這類系統之後，你不必憂愁使用Hadoop的哪個版本，是Hadoop 0.20.2還是 Hadoop 1.0，你也不必爲選擇何種計算模型而苦惱，因此各種軟件版本，各種計算模型可以一起運行在一臺“超級計算機”上了。

從開源角度看，YARN的提出，從一定程度上弱化了多計算框架的優劣之爭。YARN是在Hadoop MapReduce基礎上演化而來的，在MapReduce時代，很多人批評MapReduce不適合迭代計算和流失計算，於是出現了Spark和Storm等計算框架，而這些系統的開發者則在自己的網站上或者論文裏與MapReduce對比，鼓吹自己的系統多麼先進高效，而出現了YARN之後，則形勢變得明朗：MapReduce只是運行在YARN之上的一類應用程序抽象，Spark和Storm本質上也是，他們只是針對不同類型的應用開發的，沒有優劣之別，各有所長，合併共處，而且，今後所有計算框架的開發，不出意外的話，也應是在YARN之上。這樣，一個以YARN爲底層資源管理平臺，多種計算框架運行於其上的生態系統誕生了。

（2）目前的挑戰

數據中心的負載種類越來越多，有批處理任務、實時查詢任務、流式服務等；
異構負載的資源需求越來越多樣化，資源約束和偏好越來越複雜，例如：一個任務運行需要考慮CPU、內存、網絡、磁盤甚至內存帶寬、網絡帶寬等，還需要考慮數據本地行，對物理機的偏好等；
不同類型任務在實際調度過程中不可避免會調度至相同的數據節點上，這就需要對不同種類的任務進行隔離以減少兩者之間的干擾；
調度過程中的動態資源調整；
任務搶佔模式下的重調度機制；
故障恢復；
集羣中不可知原因的長尾問題；
集羣資源利用率低，全球雲服務器的平均物理資源利用率低於20%，並且通常在邏輯資源幾乎全部分配的前提下實際的物理資源利用量不及資源申請總量的一半；

（3）抽象模型
其實集羣資源管理和任務調度系統就是一個複雜的多維混合揹包問題，揹包問題應該是動態規劃問題中最經典的問題。我們可以將集羣中的每個數據節點比作一個揹包，不同揹包不同維度的容量是不同的，將任務比作是需要放置的物品，任務所需要的資源就是其花費，而任務運行產生的租賃費用即爲效益。我們需要做的就是在滿足任務需求的前提下將其放置在適合的揹包中，保證集羣利用率最高。但是實際的調度過程和該算法還有很多不同的地方，例如：

揹包問題只是一個推演的過程，我們可以使用一些數據結構來保存一些中間結果來推導出最優的分配方式。但是實際的調度中來了一個任務我們要馬上根據現有的資源情況進行分配，而不能暫時存留一個分配方案，等多有任務都提交完成之後再根據最優的方案進行任務放置；
不同的任務在實際運行過程中有一定的優先級，需要保證高優先級的任務最先被保證，這就增加了調度的難度；
任務在運行過程中的資源需求不是一成不變的，有時候會隨着時間的變化增加資源需求，這就是彈性調度需要解決的問題。
任務之間還會產生干擾，並且不同資源敏感度的任務在不同資源維度上的干擾是不同的；
資源管理和調度系統相當於系統的大腦，其要處理所有數據節點和任務的各種請求，所以其核心的調度邏輯一定不能太過複雜，如果考慮所有的情況後再進行調度，勢必會延長調度時間，這是任務執行所不能容忍的；
因此對於一個資源管理和任務調度系統來說，其的職能就表明其不可能是一個完美的系統，也不可能是一個通用的系統，需要針對不同的業務場景進行改造，因此就在工業界和學術界激起了廣泛的研究和探索。

（4）系統演進

整體上來說分爲：單層調度系統，兩層調度系統，共享狀態調度系統，分佈式調度系統，混合式調度系統。
Google提出MR模型
批處理框架Hadoop的出現
內存計算框架Spark的出現
資源管理框架Mesos、YARN、borg的出現
基於狀態共享的Omega
完全的分佈式調度器Sparrow
中心式和分佈式相結合的混合架構Mercury
支持快速故障恢復的Fuxi
支持在離線混合調度的阿里混布系統
基於容器的集羣管理框架kubernetes的出現

（5）一些分配策略演進

FIFO方式，先來先分配後來後分配；該方式雖然不能保證調度最優但是因爲簡單在目前的資源調度系統中也廣泛使用；
公平調度，將資源分配爲多個不同的資源池，每個資源池中分配一定比例的資源，任務在資源池中按照最大最小策略（例如有三個任務分別需要的資源是2 ，4， 4 個單位，而現在總共有9個單位資源，首先每個任務平均得到3個單位資源，因爲第一個任務多了一個單位資源，其將多出的一個單位資源再平均分配給任務二和三，所以最終任務一得到2個單位資源，任務二得到3.5個單位資源，任務三得到3.5個單位資源）或者加權的最大最小策略（不同任務具有不同的優先級，所以在平均分配的時候還需要考慮權重）進行資源分配。
DRF主資源優先調度。對於一個任務來說其主資源是其各維度資源申請中佔比最大的資源，例如一個任務需要<2CPU,4G>，現在有<4CPU, 10G>,比例爲1/2,4/10，那麼CPU就是該任務的主資源。在分配時候選擇主資源佔比最小的任務進行優先分配，目前該方式被廣泛的應用在各種調度系統中。有興趣的可以搜索相關論文查看其詳細的論證過程。
最短作業優先調度。有研究表明採用最短作業優先調度的方式可以提高系統資源利用率，其實也比較容易理解，短作業需要的資源少所以在分配的時候可以儘快被滿足，另外短作業的執行時間少，所以可以儘快的釋放資源，這對於提高集羣吞吐量和利用率都有好處。但是這種方式也存在缺點就是長作業會出現長時間得不到資源而餓死的情況；另外任務的執行時間預先是不可預知的；
能力調度器，被默認應用在YARN中。其原理是爲不同的用戶組構建不同層級的任務隊列。在進行分配時，優先選擇min{use/分配}的隊列進行分配，在隊列內部按照FIFO的策略進行選擇。所以選擇的過程可以總結爲下面步驟：（1）根據最小滿足比選擇一個任務隊列；（2）在任務隊列中選擇一個具體的任務；（3）從該任務中選擇一個資源申請請求，因爲一個任務可能會對應多個資源申請請求；得到這個請求之後與目前的剩餘資源情況進行匹配，然後進行調度；
Tetris算法。考慮到任務的資源申請需求越來越多樣，需要考慮不同維度資源的權重問題，其核心思想是將資源申請表示爲多維向量，進行歸一化處理並與集羣剩餘資源進行點積運算，優先響應權重最大的資源請求。該方法從算法論證的角度來看能夠在一定程度提高調度的準確度和效率，但是其在資源分配過程中需要進行較爲複雜的運算，採用的並不多。並且目前主流的資源調度系統中在資源申請方面僅考慮了CPU和內存兩個維度的資源。
延遲調度策略。如果當前分配的資源不能夠滿足諸如數據本地行等需求，可以暫時放棄該輪分配，等待下一輪分配，通過設定一個放棄次數閾值來進行。

1. 集羣資源管理與任務調度系統架構

集羣資源管理和任務調度設計兩個方面：（1）集羣管理，主要負載集羣中資源的管理和調度，給定一個任務需求，其能夠在目前情況下給出較優的調度方案；（2）任務調度，來了很多的任務我們應該選擇哪個任務來進行分配；這兩個方面是相輔相成的關係，任何一個方面的優化都會帶來集羣整體性能的提升。因爲任務調度主要涉及調度策略部分，在上面一節中有一些論述，並且任務調度本身帶有一些隨機性，所以對其的研究相對較少，下面主要針對資源管理系統進行簡要總結。

總的來說目前的調度系統可以分爲：單層調度系統、兩層調度系統、共享狀態調度系統、分佈式調度系統和混合式調度系統。每種調度系統的存在都有其背景，下面主要從產生的背景、實現的原理、存在的缺點、典型的系統等方面進行闡述。需要注意的是，雖然有這麼多種調度系統，但是目前工業界使用的大部分還是單層或者兩層的調度系統，原因是這些架構設計方案成熟，已經經歷了多年的線上實踐，可以平穩運行；另外就是這些調度系統擁有比較好的生態和社區，能夠兼容現有的生態，節省研究的成本。所以一些小型公司大多還是採用Hadoop相關的系統，只有專門針對雲計算市場的公司，例如阿里雲、騰訊雲、華爲雲等會專門研發自己的調度系統。

1.1 單層調度系統

產生背景：該調度系統是大規模數據分析和雲計算出現的雛形，其產生主要就是進行大規模的集羣管理以提高數據處理能力。
基本原理：單層調度系統融合了資源管理和任務調度，有一箇中心式的JobTracker負責進行集羣資源的合理分配、任務的統一調度、集羣計算節點信息的統計維護、任務執行過程中的狀態管理等。
優點：（1）JobTracker能夠感知集羣中所有資源和任務的執行狀態，能夠進行全局最優的資源分配和調度，避免任務間的干擾，適當進行任務搶佔，保證任務計算效率和服務質量；（2）架構模型簡單，只有一個全局的管理者負責進行所有管理。
缺點：（1）JobTracker作爲集羣的中心，存在單點瓶頸問題，不能支持大規模集羣；（2）內部實現異常複雜，因爲一個調度器中需要實現所有的功能模塊；（3）負載種類的增加會導致系統需要進行不斷的迭代，這將增加系統的複雜性，不利於後期的維護和擴展；（4）只支持單類型的任務，MR類型的批處理任務；
典型的調度系統：Hadoop1.*版本；K8S中的kube-scheduler，Paragon,Quasar。

1.2 雙層調度器

產生背景：爲了解決單層調度系統的擴展性問題，系統實現負責，需要不斷迭代，不能支持不同類型任務等缺點
實現原理：將資源管理和任務調度解耦。集羣資源管理器負責維護集羣中的資源信息並將資源分配給具體的任務，任務管理器負責申請資源並將申請到的資源根據用戶邏輯進行細分和具體的任務調度，節點管理器負責維護節點上的所有信息，包括：任務的運行狀況，節點資源剩餘情況等。通過三者之間的協調來進行資源資源管理和任務調度。
優點：（1）資源管理器只負責資源分配，任務調度由應用完成，提高了系統的擴展性和模塊化設計；（2）任務調度邏輯由具體的任務完成，能夠提供對不同類型任務的支持；（3）內部實現模塊化，利於維護和擴展；
缺點：（1）任務無法感知全局的資源情況，只能基於request/offer來進行資源獲取，無法有效避免異構負載之間的性能干擾問題；（2）任務調度和資源管理解耦不利於實現多任務間的優先級搶佔；（3）所有任務的資源請求都需要資源管理器進行處理，此外其還需要與節點管理器之間維持通信，導致資源管理器存在單點問題；
典型系統：
- Mesos：最先將資源管理和任務調度解耦的offer-based（基於資源供應）方案，其有一箇中心的資源管理器，通過採用一些分配策略將資源分配給不同的計算框架，每個計算框架依據自身的邏輯、資源偏好等採取增量或者All-or-Nothing的方式決定接受還是拒絕分配的資源，計算框架根據分配到的資源進行下一步的資源分配和任務執行。優點：實現邏輯簡單，兩層調度；缺點：（1）調度結果不是全局最優的；（2）存在單點瓶頸，因爲中央資源管理器需要逐個詢問計算框架是否需要資源；（3）無法支持搶佔，資源一旦分配不能夠搶佔回收；（4）DRF策略過於理想化；（5）併發度不高，因爲對於某個slave的資源剩餘信息，需要逐個詢問計算框架是否需要資源,，基於串行輪詢方式；
- YARN：基本思想與Mesos相同，但其採用requese-based方式進行資源申請，但是在YARN中有三個模塊，RM負責資源管理，AM負責任務資源申請和運行；優點：（1）支持不同的調度策略可以保證任務優先級、多租戶容量管理、資源公平共享、彈性伸縮（當某個租戶需要資源時會搶佔共享出去的資源）等；（2）應用擴展方便，只要根據提供的AM 相關API就可以實現用戶的任務執行邏輯；缺點：存在單點瓶頸問題；故障處理和容錯方面不夠完善；對於隔離的支持不夠友好；
- borg：最早融合資源隔離、資源超售、機器打分、多任務優先級於一體的資源管理系統。採用二層調度框架，節點管理器Borglet定期將自己節點的資源和任務執行情況彙報給BorgMaster，每個應用內的調度器根據自身保存的集羣信息做調度決策，然後由Master決定是否允許其資源申請。在此基礎上其做了一些優化，例如：用戶控制訪問、節點打分、多任務派遣、多維度資源隔離和進程隔離、可插拔的調度策略等，支持數千種不同的應用和服務，支持數萬臺規模的集羣。但是目前其爲閉源系統，這些思想僅能通過論文中獲取，具體的實現細節並不清楚。
- Fuxi。其是阿里雲針對離線作業的調度系統，與其相對的是針對在線服務端額調度系統Sigma。伏羲的設計思想與YARN非常相似，具體的資源分配也相似。但是伏羲針對故障恢復和可用性方面記性了優化擴展，能夠基於已有的信息進行快速的故障恢復，並提供多級黑名單機制。

1.3 共享狀態調度器

產生背景：前面的調度器存在一個問題就是應用在進行資源申請的時候無法獲知到集羣的全局資源信息，這就導致無法進行全局最優的調度，共享狀態調度器就是爲了解決這個問題。
基本原理：是一個半分佈式的架構，通過共享集羣狀態爲應用提供全局的資源視圖，並採用樂觀併發機制進行資源申請和釋放，來提高系統的併發度。
優點：（1）支持全局最優調度；（2）能夠一定程度的提高併發度；
缺點：（1）高併發資源請求下會造成頻繁的資源競爭；（2）不利於實現任務的優先級搶佔；（3）資源全局副本維護模塊存在單點瓶頸；
典型系統：
- Omega:Omega系統中存在多個調度器，每個調度器中都保存集羣資源的副本信息，每個調度器可以按照副本信息進行任務調度，在進行資源申請和調度時採用樂觀鎖的併發方式進行。目前其只是在模擬環境下進行實驗，並沒有真正在線上進行測試。
- Apollo：綜合考慮了微軟生產平臺Scope的擴展性、用戶羣間的公平調度、提高資源利用率、縮短工作時間（數據本地行、任務特性、任務預測）的解決方案。核心包括兩個方面：（1）利用實時系統維護和更新每個任務的等待時間矩陣作爲調度的基礎和參考，需要考慮子任務調度到哪個計算節點上更合適；（2）在計算節點設置獨立的任務等待隊列，採集其上的任務執行情況，依次根據相關成本模型進行較優的調度決策。其主要針對海量短作業進行設計。
- JetScope：在Apollo的基礎上對交互式數據分析任務進行了特殊的優化處理，通過Gang調度策略對低延遲交互式作業進行調度優化。
- Nomad

1.4 分佈式調度器

產生背景：提供系統吞吐率和併發度
基本原理：完全分佈式的調度系統之間沒有通訊協作，每個分佈式調度器根據自己最少的先驗知識進行最快的決策，每個調度器單獨響應任務，總體的執行計劃於資源分配服從統計意義。目前還處於學術研究階段，尚未真正運用至生產環境中。
優點：提高吞吐量和併發度
缺點：（1）調度質量得不到保障；（2）資源非公平分配；（3）不能支持多租戶管理；（4）不能避免不同任務之間的性能干擾；
典型系統：Sparrow：是一個完全的去中心化的分佈式調度系統，通常用於滿足低延遲高吞吐的短任務場景。系統包含多個調度器，這些調度器分佈在集羣的節點上，作業可以提交給任何一個分佈式調度器。其核心是採用隨機調度模型，利用二次冪採樣原理針對每個任務隨機採樣出兩個服務節點，選擇任務等待隊列最短的一個作爲調度結果，也可以採用異步預定的方式進行資源調度。實驗證明近似最優解能夠有效的滿足大規模毫秒調度性能的需求。

1.5 混合式調度器

出現背景：針對一些特定的混合任務調度場景，某些任務需要比較快的調度響應，而其他任務不需要很快的調度響應，但是需要保證調度質量。
基本原理:設計兩條資源請求和任務調度路徑，保留兩層調度的優點，同時兼顧分佈式調度器的優勢。對於沒有資源偏好且響應要求高的任務採用分佈式調度器，對於資源調度質量要求較高的採用中央資源管理器進行資源分配。
優點：（1）能夠針對不同類型的任務進行不同方式的調度；（2）爲應用層提供靈活的接口和性能保障；
缺點：複雜化了計算框架層的業務邏輯；調度系統內部也需要針對兩種不同的調度器進行協同處理；
典型調度系統：
- Mercury:微軟的混合調度機制，中心式調度器對調度質量要求較高的作業進行公平的資源分配，分佈式調度器對時間敏感和吞吐率要求高的作業進行調度。
- Tracil在Sparrow基礎上增加了訪問控制模型，結合QoS感知對負載進行建模和性能評估指定訪問控制策略，確保任務可以快速獲取到資源並執行，提升系統併發度和響應時間提高集羣資源利用率。

1.6 總結

目前主流的開源調度系統比較（結構，資源維度，多調度器，支持可插拔，優先級搶佔，重調度，資源超售，資源評估，避免干擾）：

Kubernetes：單層，支持多維資源，可插拔，資源超售
Swarm：單層，支持多維資源
YARN：單層/兩層，CPU和內存，多調度器，可插拔
Mesos:兩層，多維，多調度器，可插拔，資源超售
Nomad：共享狀態，多維，可插拔
Sparrow：完全分佈式，固定槽位
Borg:優先級搶佔，重調度，資源超售，資源評估
Omega：支持除了避免干擾的所有特徵
Apollo：多調度器，可插拔，優先級搶佔，重調度
選用何種調度架構需要根據具體的應用場景結合不同調度框架的特點進行判斷。目前調度系統存在的問題主要包括：功能缺失、資源利用率不佳、任務特徵不可預測、性能干擾降低執行效率、調度器性能較弱。

spark其實就是對borg系統+DGA計算模式的實現，包括了集羣的資源管理和調度、存儲系統實現、DGA計算模式實現；所以當我們在看spark源碼時候會被它幾萬行代碼和各種的依賴包給搞糊塗。因爲它已經是一個完整系統，當你把這個系統是怎麼構成的解剖開來，劃分成幾個部件模塊，再去閱讀代碼會發現依然複雜但是代碼組織是分層次有章可循的；也慢慢可以理解爲什麼spark包括那些模塊。