一、局部優先的原則
在大數據應用的場景下有一個基本的設計原則：我們通常是將計算分配到存儲數據的節點執行，而不是從節點拿到需要的數據再來進行計算。這背後的原因很容易想通，因爲這樣可以儘量減少節點之間的網絡通信，減少了數據傳輸。要知道大數據場景下的數據的規模是非常大的，動輒TB，PB，少則也有幾百幾十GB，一旦需要網絡傳輸數據帶來的開銷是非常可觀的。
我們把這個原理總結一下，可以稱爲**”局部優先“原則**，也就是說執行任務的節點越局部越好，如果在一臺物理機當中就太完美了，因爲這樣可以避免所有的數據傳輸。
我們可以簡單地根據這個原則來衡量一個集羣調度系統的能力，我們根據局部性的情況可以簡單地列出三種級別。第一種是節點局部性，也就是所有的計算都發生在一個節點當中，這樣可以避免所有的數據傳輸，這也是最佳情況。第二種要差一些叫做機架局部性，也就是說所有的計算雖然不能保證在一個節點當中執行，但是至少可以保證這些執行的機器在同一個機架當中。在機架當中的機器可以通過內部的方式傳輸數據，而不必藉助外部網絡，這樣的傳輸也要快得多。最差的情況就是節點分散在不同的機架，沒有辦法做任何加速，這種稱爲全局局部性，會帶來大量的開銷。
我們都知道一個好的集羣調度系統要把集羣當中所有機器的性能”壓榨“到極致，但實際上固定的計算消耗的計算資源基本上是穩定的。除了機器的利用率之外，另一個關鍵點就是這個。而且有時候網絡IO帶來的開銷可能比機器低使用率更可怕。
二、資源分配細節
關於資源分配可能我們直觀理解上很簡單，當有機器空閒的時候我們就分配給它任務，然後執行完了我們把資源收回，但是在實際的運用當中還存在很多細節需要我們精心設計和思考，一旦稍微有點沒想清楚可能就會造成嚴重的後果。
我們來看兩個問題，第一個問題是當我們當下新來了一個任務，但是沒有足夠資源的時候應該怎麼辦？
我們很容易想到有兩種策略，第一種策略就是什麼也不做，等。等到有任務結束了，資源釋放出來了之後，我們再執行當前這個任務。但如果我們當前的任務是一個非常緊急的任務呢？有可能現在正在執行的任務優先級並不高，但是佔用的資源又多又長，難道我們還要一直等下去嗎？
所以我們會想到還有第二者策略，就是搶。既然我們當下的資源優先級高，正在執行的任務優先級低。我們可以先從優先級低的任務當中搶一部分資源過來，先把當下重要的任務執行了再說。等優先級高的任務執行了之後再去執行優先級低的。但是很遺憾，這麼做是有問題的。技術上的問題我們先不談，等會再說，有沒有想過這麼搞的話，還會有誰願意把任務的優先級調低呢？肯定大家執行的任務都是最高優先級。到後來會發現所謂的優先級高低設置全部變成了擺設，正在運行的優先級都一樣，都是最高優先級。
關於上面的問題還有後續，我們先放一放，來看另外一個問題，這個問題是上面這個問題的衍生品。不同的任務需要的資源不同，並且需要資源的情況也不相同。比如有些任務資源多少都可以運行，比如spark或者是MapReduce，資源多就多用幾個機器，資源少就少用幾個，但是不管多少都可以跑，無非是執行的時間長短不同。但是有些任務就不是如此，比如機器學習的任務，可能一次性需要大量的資源，並且就要這麼多，少了就跑不了。那麼問題來了，當我們新來了一個任務，當下資源不足以滿足它分配需要的時候，我們是先留着不分配給它，等資源足夠了一次性分配呢，還是先分配一點，後面拿到一點資源再繼續分配呢？
你看，看起來平淡無奇的分配策略其實當中還是有很多棘手的細節。事實也的確如此，這也是爲什麼我之前說目前的集羣資源管理系統還遠遠沒有成熟纔剛剛起步的原因，因爲對於以上的問題都沒有特別好的解決方案。
三、餓死與死鎖
還記得上面的兩個問題麼，如果這兩個問題沒有回答好，那麼就會出現餓死與死鎖的情況。
餓死是指任務一直得不到調度，比如由於設置的優先級不合理。只有你一個老實孩子給自己覺得一個不太重要的任務設置了一個正常的優先級，而其他的老司機紛紛給自己的任務設置了最高優先級。由於一直有高優先級的任務被提交進來，所以你的任務被一直延後，你以爲很快就能得到結果，可能到下班你的任務還沒開始執行。在這種情況下，你要麼同流合污，也把自己的任務設置成最高優先級，要麼就只能一直等下去，或者因爲完成的工作不夠多而面臨績效以及老闆的壓力。
死鎖的情況比較容易理解，如果學過操作系統的同學應該很熟悉，原理是一樣的。打個比方，如果我們當下有AB兩個任務，這兩個任務都需要集羣2/3的資源纔可以執行。由於這兩個任務是差不多時間點提交的，而系統採取了先來先分配的原則，給這兩個任務都分配了1/2的資源。那麼這就會導致死鎖，因爲這兩個任務沒有一個能執行，也就沒有一個任務會釋放資源，所以除非人工kill掉一個，否則會一直如此持續下去。
從目前的情況來看，好像沒有一個完美的方法可以完全避免這兩種情況出現。只能架構師根據自己集羣調用的實際情況進行決策，並且還要加入一些人工干預的因素，比如在團隊當中約法三章制定一些規範和條例等等。也就是說，某種程度上來說這已經不只是一個系統的問題了，而是一個系統和團隊協調的複雜問題。
四、調度器
下面我們來看看常見的調度器的架構，常見的調度器有三種，第一種是集中式調度器，第二種是兩級調度器，最後一種是狀態共享調度器。
4.1 集中式調度器
它的設計邏輯就是集中，整個系統當中只有一個全局的中央調度器。所有的框架或者是計算任務都由中央調度器來實現。有點像是封建時候的宗族制度，整個大家族當中所有的大事小事全部由一個人來管理。顯然這樣做的弊病非常多，剛纔提到的兩個問題都需要人工干預，否則很難解決。
後來在此基礎上進行了改進，在整個中央調度器當中又加上了分支邏輯。這種調度器被稱爲多路徑調度器：
整體而言變化不大，只是多了一個條件判斷。也就是說內部實現了針對不同種類的任務執行不同的調度和分配策略。比如如果是小的碎片任務，那麼執行優先級管理，先來先得策略。如果是大的機器學習任務，只有拿到完整資源纔會執行，防止死鎖等等。
相比於單路徑集中調度而言，多路徑集中調度增加了一些靈活性，但是整體的拓展性還是遠遠不夠，並且併發能力也比較差，資源的利用率不夠高，如果規模大了，調度性能很容易成爲瓶頸。但是它勝在架構簡單，容易維護。
4.2 兩級調度器
由於集中式調度器有許多的問題，也不夠靈活，我們爲了增加它的靈活性，在此基礎上又增加了一層結構：
我們同樣有一個中央調度器來坐鎮指揮，只不過中央調度器並不會直接調度任務，而是會以一種比較粗粒度的策略將集羣當中的資源分配給框架調度器。具體調度、執行任務的邏輯在框架調度器當中。相比於中央調度器，框架調度器執行的策略會更加細粒度一些。
另外，只有中央調度器可以看到整個集羣當中所有資源的情況，框架調度器只能看到自己分配到的那一部分資源。我們比較熟悉的YARN，Mesos都是採取的這種架構。
有了框架調度器之後，我們可以在不同的框架調度器當中執行不同的策略。有助於提升整個集羣的併發能力，以及資源利用率。所以總體而言，兩級式調度器的性能要比集中式調度器好得多。
但是即使是這樣，也不是完美的。因爲中央調度器在調度的時候執行的是一種悲觀併發的策略。簡單解釋就是在執行分配的過程當中，中央調度器會嚴格按照事先制定的順序，並且會對資源加鎖來防止不同框架申請資源時導致的衝突。既然用到了悲觀鎖，顯然也會影響整體的性能。
4.3 狀態共享調度器
狀態共享調度器的架構和兩級調度器非常接近，可以簡單理解成了去掉了中央調度器的結果：
它和兩級式調度器的最大的不同就是沒有中央調度器，所有的框架調度器可以直接看到整個集羣當中的所有資源。在需要使用資源的時候，由框架調度器之間互相競爭來獲取。
並且和中央調度器不同的是，狀態共享策略當中使用的是樂觀鎖。簡單解釋一下樂觀鎖和悲觀鎖的區別。悲觀鎖往往會假設最壞的情況，比如當下獲取了資源之後，在使用結束之前有可能會有其他的線程來訪問或者是修改，所以我們需要加上鎖來避免這樣的情況發生。
樂觀鎖則相反，基於樂觀假設，也就是說系統是基於能夠順利運行不會有資源搶佔的情況發生的前提進行的。也就是說先執行，執行之後如果發生了搶佔或者其他問題，那麼再來通過重試或者其他機制來解決。
即使在高併發場景當中，資源衝突也是一個相對來說的小概率時間。如果使用悲觀鎖顯然會帶來大量的加鎖的開銷，所以基於樂觀鎖的設計會使得系統的併發性能更強。但是這也是有代價的，樂觀鎖也不是完美的，如果真的發生了大量競爭衝突的情況，競爭失敗的一方往往需要重試任務，這會帶來很多不必要的開銷，也會造成資源的浪費。
另外由於所有框架之間的搶佔是自由的，也就是說有可能會出現高優先級的框架一直搶佔資源，而低優先級的任務被餓死的情況發生。在這種機制下是沒有辦法保證任務之間的公平性的。這也是削弱中央調度器帶來的必然後果。
五、總結
我們回顧一下以上三者策略，會發現這三者策略的演進順序其實就是中央調度器被削弱的順序。想想其實很容易理解，中央調度器強大可以維護整個集羣的公平性，但是由於效率比較低，很有可能會成爲整個集羣的瓶頸。而中央調度器越弱，框架調度器的自由度越高，整個系統調度的靈活性越強，那麼也就意味着系統的性能往往越好。
有人打了一個比方非常經典，集中式調度器有些像是計劃經濟。所有一切都由國家來規劃，好處是可以保證公平，但是自由度和靈活性差，整個國家運轉和發展都不夠高效。兩級調度器有些像是大政府小市場的混合模式，政府的干預力度還是很大，但是多了一點自由性。而狀態共享器則是小政府大市場的自由競爭經濟模式，政府的干預幾乎沒有了，變成了看不見的手，這樣可以進一步提升靈活性和國家的運轉效率。但是國家的干預少了，當風險降臨的時候，也可能導致很大的問題。
轉載文章：淺談分佈式集羣資源管理系統【二】