不同應用之間的資源排程
standalone叢集 預設是simple fifo scheduler，也就是說允許接入的應用使用全量的cpu和mem。如果想要在多使用者下限制，需要設定參數來控制每個應用占有的資源數，比如system.setproperty("spark.cores.max","10"), system.setproperty("spark.executor.memory ","10g")
在standalone模式，yarn模式，和粗粒度的mesos模式下，都是使用static partition的方式，設定每個應用占用的cpu和mem數
mesos還有一種模式(預設細粒度的模式)是dynamic sharing cpu cores，但是mem還是固定獨立配置設定的。這種模式可能會帶來不可預估的延遲，因為每個node要取回自己的core來work的時候，需要等待釋放。
以上模式裡都不包含可以共享mem的方式。如果要共享記憶體裡的資料的話，一方面可以用shark的jdbc接口，處理sql的時候同時共享某些rdd；另一方面，在未來的釋出版本裡，tachyon會提供另一種方式共享rdds。
同一個應用下的資源排程
在同一個sparkcontext裡，jobs是可以并行跑的，spark的排程器是線程安全的。
但是預設的排程器處理jobs是fifo的。每個job有若幹個stages(map和reduce的階段)，如果前面的stage把mem和cpu占滿了，那後續來的job裡的stage可能就卡住不能跑了。是以spark-0.8裡出了fair scheduler這個新的排程模式，對jobs的tasks采用輪詢的方式，短的任務在長任務跑的情況下也可以得到資源并行進行，适合多使用者使用的情況
fair scheduler提供pool的概念，pool可以設定weight。比如在一個線程上設定(啟動一個sparkcontext前)
指定了一個叫pool1的pool，之後該線程下進行的jobs就都屬于這個pool了。且預設的pool平均分享cpu和mem總量(weight預設是1，可以調)，每個pool内的job按fifo模式(pool内job之間是fifo或fair是可以設定的)。這樣的話，比如5個user每人一個預設的pool，那麼大家享有的資源量是一樣的，各自執行的任務還是會按先後順序執行。pool除了可以設定weight和改變内部mode外，還可以設定minshare，指這個pool可以額外分享幾個cpu
cores，預設是0。fair scheduler每次都會嘗試去滿足active pools的minshare量。
以上每個pool的參數和pool名字(種類)可以在一個xml裡聲明，然後在啟動context的時候使用：
下圖為源碼裡和這部分相關的類圖：
(全文完)