# Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center
## 1. Introduction
沒有一個 framework 能對所有應用都最優
* 希望在同一集群中運行多個 framework，為每個應用選擇最佳的 framework
* 將集群在 framework 之間多路復用可以提高利用率，並允許應用共享訪問大型數據集

將數據集複製到各個集群的成本可能過高，目前共享集群的兩個常見解決方案
* 靜態劃分集群並在每個分區中運行一個 framework
* 為每個 framework 分配一組虛擬機（VM）

這些解決方案既無法實現高利用率，也無法高效共享數據: 解決方案的分配 grained 與現有 framework 的 grained 不匹配
* 許多 framework（例如，Hadoop、Dryad）採用 fine-grained 資源共享模型
* 節點被細分為 slot，job 由與 slot 匹配的短 task 組成
* job 能夠實現高 data locality
* task 的短時長和每個節點上運行多個 task 的能力使得
* 短 task 還使 framework 能夠實現高利用率
* 每個 job 都能快速獲得在存儲其輸入數據的節點上運行的機會，當新節點變得可用時，job 可以快速擴展
* 由於 framework 是獨立開發的，無法在 framework 之間進行 fine-grained 共享，這使得在它們之間高效共享集群和數據變得困難

Mesos，一個資源共享層，通過為 framework 提供訪問集群資源的通用介面，實現了在不同集群計算 framework 之間的 fine-grained 共享
* 主要設計問題
* 每個 framework 將根據其編程模型、通信模式、task 依賴性、數據放置需求不同的調度需求
* 調度系統必須能夠擴展到運行數百個 job 和數百萬個 task 的數萬個節點的集群
* 因為集群中的所有應用都依賴於 Mesos，系統必須具有容錯性和高度可用性
* 方法
* 集中 scheduler
* framework 要求、資源可用性、組織策略作為輸入，並計算所有 task 的全局調度計劃。儘管這種方法可以在 framework 間優化調度，但它面臨幾個挑戰
* 複雜性
* scheduler 需要提供一個足夠表達性的 API 來捕獲所有 framework 的要求，並解決數百萬個 task 的在線優化問題
* 即使這樣的 scheduler 是可行的，其複雜性也會對其可擴展性和韌性產生負面影響
* 由於不斷開發新 framework 和現有 framework 的新調度策略，目前尚不清楚是否已經具備了完整的 framework 需求規範
* 許多現有 framework 實現了自己複雜的調度，將此功能移動到全局 scheduler 將需要昂貴的重構
* 將調度控制權委託給 framework(Mesos 採取的方法)
* 通過 resource offers 的新抽象來實現，封裝了 framework 可以在集群節點上分配以運行 task的一組資源
* Mesos 根據組織策略決定向每個 framework 提供多少資源，而 framework 則決定接受哪些資源以及在這些資源上運行哪些 task
* 儘管這種分散式調度模型不一定總能導致全局最佳調度，但在實踐中表現出色，幾乎能夠完美地滿足 framework 的 data locality 目標
* resource offers 簡單且高效的實現，使 Mesos 能夠高度可擴展並對故障具有韌性
* 好處
* 即使是僅使用一個 framework 也可以使用 Mesos 在同一集群中運行該 framework 的多個實例或多個版本
* 將是一種隔離生產和實驗 Hadoop 工作負載並推出新版本 Hadoop 的有力方法
* 使得開發和立即試驗新 framework 變得更加容易
* 在多個 framework 之間共享資源的能力使開發者能夠構建和運行針對特定問題領域的專用 framework，而不是“一刀切”的抽象。因此，framework 可以更快地發展，並為每個問題領域提供更好的支持
* 可以擴展到 50,000 個（模擬的）節點，並使用 ZooKeeper進行容錯
## 2. Target Environment
以 Facebook 的 Hadoop warehouse 作為希望支持的工作負載的例子
* 網路服務的 log 加載到 Hadoop 集群中，這些 log 被用於商業智能、垃圾郵件檢測、廣告優化等應用
* job
* 定期運行的 production job
* experimental job
* 從數小時的機器學習計算到通過 Hive 的 SQL 介面交互提交的 1-2 分鐘的臨時查詢
* 大多數 job 都是短 job ，由 fine-grained 的 map 和 reduce task 組成
* fair scheduler
* 為了滿足 job 的性能要求，為 Hadoop 分配資源
* 利用工作負載的 fine-grained 特性，在 task 層面分配資源並優化 data locality
* 意味著該集群只能運行 Hadoop job，如果用戶希望使用 MPI 而不是 MapReduce 來編寫算法，那麼用戶必須設置一個單獨的 MPI 集群並導入數 TB 的數據
* 用戶希望運行 MPI 和 MapReduce Online（streaming MapReduce）
## 3. Architecture
### 3.1 Design Philosophy
Mesos 旨在提供一個++可擴展++、++具有彈性++、++簡單++、++可靠++、++高效++的核心，以使各種 framework 能夠==共享集群==
:::info
主要設計理念是定義一個能夠在 framework 間高效共享資源的最小介面，並將 task調度和執行的控制推給各個 framework
:::
將控制權推給 framework 有兩個好處
* 允許 framework 針對集群中的各種問題（例如，實現 data locality 、處理故障）獨立發展和實施多樣化的解決方案
* 使得 Mesos 保持簡單，並且將系統所需的變更速率最小化，從而使 Mesos 更易於保持可擴展性和穩健性

Mesos 提供 low-level 介面，之後會在其上構建額外的 high-level library
* 將實現通用功能（如容錯性）放入 library 中而不是 Mesos 中，使 Mesos 保持小巧靈活，並允許 library 獨立發展
### 3.2 Overview
Mesos 的主要元件
* master process: 管理 slave daemon
* slave daemon: 在每個集群節點上運行(實際握有資源)
* framework: 在 slave 上運行 task
* scheduler: 用來註冊到 master，選擇資源並提供 task
* executor process: 在 slave 上啟動以運行 framework task

resource offers: master 通過使用 resource offers 實現跨 framework 的 fine-grained 共享
* 多個 slave 上可用資源的一個 list
* master 根據特定策略（如公平共享或優先級）決定向每個 framework 提供多少資源
* 可插拔的分配模塊
* 定義策略
* 支持多樣的跨 framework 分配政策

framework 如何被調度以運行 task
1. slave 1 向 master 報告它有 4 個 CPU 和 4GB 的 memory 可用
2. master 調用分配模塊，得知應向 framework 1 提供所有可用資源
3. master 向 framework 1 發送描述這些資源的 resource offers
4. framework 1 的 scheduler 回覆 master，提供兩個要在該 slave 上運行的 task 信息
* 第一個 task 使用 2 個 CPU 和 1GB memory ，第二個 task 使用 1 個 CPU 和 2GB memory
5. master 將 task 發送給 slave 1，slave 1 將適當的資源分配給 framework 1 的 executor， executor 隨後啟動這兩個 task
6. 由於仍有 1 個 CPU 和 1GB memory 可用，分配模塊現在可能將它們提供給 framework 2
7. 當 task 完成並釋放新資源時，resource offers 過程會重複

framework 的拒絕機制
* framework 可以拒絕不滿足其約束條件的資源，以等待滿足其需求的資源
* 使 framework 能夠支持任意複雜的資源約束，同時保持 Mesos 的簡單性和可擴展性(簡潔的介面、framework 能獨立發展)
* 問題: 效率
* framework 可能需要等待很長時間才能收到滿足其約束條件的 resource offers，Mesos 可能需要向多個 framework 發送 resource offers，才能有一個 framework 接受
* 解決
* 允許 framework 設置 filter，這些 filter 是 boolean expression，指定 framework 將始終拒絕某些資源
* filter 是 resource offers 模型的一種性能優化
* 當工作負載由 fine-grained task 組成時，即使在沒有 filter 的情況下，resource offers 模型的性能也非常出色
* 簡單策略: delay scheduling，framework 等待一段有限的時間以獲取存儲其數據的節點，在等待1-5秒的時間內幾乎可以實現最佳 data locality
### 3.3 Resource Allocation
Resource Allocation
* 利用大多數 task 很短以及僅在 task 完成時重新分配資源，通常發生得足夠頻繁，新 framework 就能迅速獲得其 share
* 例如，如果某個 framework 的 share 是集群的 10%，那麼它需要等待大約 10% 的平均 task 時長來獲得其 share

分配模塊
* 已經實現的兩個分配模塊
* 基於多資源 max-min 公平的推廣進行公平共享
* 實現了嚴格的優先級分配
* 如果集群被長 task 佔滿，例如，由於某個故障的 job 或貪婪的 framework，分配模塊會撤銷（終止） task
* 在終止 task 之前，會給其 framework 一個寬限期來進行清理
* 撤銷機制:
* guaranteed allocation: framework 可以持有而不會失去 task 的資源數量
* 分配模塊向每個 framework 提供 guaranteed allocation 來避免 framework 被終止 task
* 儘管終止 task 對許多 framework（例如，MapReduce）影響不大，但對於具有相互依賴 task 的 framework（例如，MPI）則會造成不利影響
* framework 通過 API 調用讀取其 guaranteed allocation
* 分配模塊負責確保 guaranteed allocation 可以同時滿足
* 目前，語義簡單：如果 framework 低於其 guaranteed allocation，則其 task 不應被終止；如果超過，則其 task 可能被終止
* 決定何時觸發撤銷
* 必須知道哪些已連接的 framework 在獲得 resource offer時會使用更多資源(哪些已連接的 framework 如果獲得更多的資源，會立即利用這些資源)
* framework 通過 API 調用表明它們對 resource offer的興趣

### 3.4 Isolation
利用現有的 OS 隔離機制，為運行在同一 slave 上的 framework executor 提供隔離
* 通過可插拔的 isolation module 支持多種隔離機制
* 由於這些機制是 platform 相關
* 使用 OS container 來隔離資源
* Linux Containers + Solaris Projects
* 可以限制 process tree 的 CPU、 memory 、網路頻寬、I/O 使用量
* 使用 container(雖然不完美) 已經比 Hadoop framework 要優越(只是將不同 job 的 task 運行在單獨的 process 中)
### 3.5 Making Resource Offers Scalable and Robust
++由於 task schedule 是一個分散的過程，因此需要 Resource Offers 高效且能夠應對故障++

三個機制來實現
* filter
* 簡化 + 避免通信
* 目前，支持兩種類型的 filter (也可以支持其他類型)
* 僅提供來自列表 L 的節點
* 僅提供至少具有 R 個可用資源的節點
* 可以在 master 上快速評估，任何不通過 framework filter 的資源都會被視為被拒絕的資源
* 因為 framework 可能需要時間來回應 resource offer，提供給 framework 的資源計入其在集群中的分配份額
* 促使 framework 快速回應 resource offer
* 如果 framework 在時間內沒有回應 resource offer，Mesos 會撤銷該提供並將資源重新提供給其他 framework
### 3.6 Fault Tolerance
* master
* 將 master 設計為 soft state，使新 master 能夠從 slaves 和 framework scheduler 持有的信息中完全重建其內部狀態
* master 的唯一狀態是活動的 slaves 列表、活動的 framework、正在運行的 task
* 這些信息足以計算每個 framework 使用的資源數量
* 使用 ZooKeeper 進行領導者選舉，在 hot-standby 配置中運行多個 master
* 當活動的 master 故障時，slave 和 scheduler 將連接到下一個當選的 master 並重新填充其狀態
* framework scheduler
* 允許 framework 註冊多個 scheduler，當一個 scheduler 故障時，master 會通知另一個 scheduler 接管
* framework 必須使用自己的機制在其 scheduler 之間共享狀態
* node 和 framework executor
* Mesos 會向 framework scheduler 報告節點故障和 executor 崩潰，framework 可以根據其選擇的策略來應對這些故障
### 3.7 API Summary
* callback 列出了 framework 必須實現的函數
1. `resourceOffer(offerId, offers)`
- 含義：當 Mesos master 提供資源給 framework 時調用。`offerId` 是該 resource offer的唯一標識符，`offers` 包含具體的資源詳細信息。
- 用途：framework 接收 resource offer，然後可以選擇接受或拒絕提供的資源
2. `offerRescinded(offerId)`
- 含義：當之前提供的資源被撤銷時調用。`offerId` 是被撤銷的 resource offer的唯一標識符。
- 用途：framework 處理 resource offer被撤銷的情況，可能需要更新內部狀態或重新計劃 task分配
3. `statusUpdate(taskId, status)`
- 含義：當 task 狀態發生變化時調用。`taskId` 是 task 的唯一標識符，`status` 包含 task 的新狀態
- 用途：framework 接收 task狀態更新，根據 task 的進展或結果進行相應處理（例如，重試失敗的 task 或完成後的後續步驟）
4. `slaveLost(slaveId)`
- 含義：當一個 slave 節點失聯或故障時調用。`slaveId` 是失聯或故障的 slave 節點的唯一標識符
- 用途：framework 處理 slave 節點的丟失，可能需要重新分配該節點上運行的 task 或調整資源使用計劃
1. `launchTask(taskDescriptor)`
- 含義：向 Mesos 提交一個新的 task
- 用途：framework 啟動 task，`taskDescriptor` 包含有關 task 的詳細信息，包括資源需求和可執行的二進制文件
2. `killTask(taskId)`
- 含義：請求 Mesos 終止一個正在運行的 task
- 用途：framework 終止特定的 task，`taskId` 是要終止的 task 的唯一標識符
* action 列出了 framework 可以調用的操作
1. `replyToOffer(offerId, tasks)`
- 含義：回應 Mesos 的 resource offer，告訴 Mesos 要在提供的資源上運行哪些 task
- 用途：framework 接受或拒絕 resource offer，並指定在這些資源上運行的 task，`offerId` 是 resource offer的唯一標識符，`tasks` 是要運行的 task列表
4. `setNeedsOffers(bool)`
- 含義：告訴 Mesos framework 是否需要更多的 resource offer
- 用途：framework 指示它是否需要更多的 resource offer，`bool` 值為 true 表示需要，false 表示不需要
5. `setFilters(filters)`
- 含義：設置 filter，以避免接收不符合 framework 要求的 resource offer
- 用途： framework 設置 filter，`filters` 包含過濾條件
6. `getGuaranteedShare()`
- 含義：獲取 framework 被保證的資源分配份額
- 用途：framework 查詢它在集群中被保證的資源數量，以確保其關鍵 task 的運行
5. `killTask(taskId)`
- 含義：請求 Mesos 終止一個正在運行的 task
- 用途：framework 終止特定的 task ，`taskId` 是要終止的 task 的唯一標識符
6. `sendStatus(taskId, status)`
- 含義：向 Mesos 發送指定 task 的狀態更新
- 用途：framework 更新 task 狀態，`taskId` 是 task 的唯一標識符，`status` 是 task 的新狀態
## 4. Mesos Behavior
Mesos 在不同工作負載下的行為
* 目標不是開發一個精確的系統模型，而是提供一個粗略的理解，以表徵 Mesos 分散式調度模型在不同環境中的運行效果
### 4.1 Definitions, Metrics and Assumptions
評斷 Metric
* framework ramp-up time：新 framework 達到其分配（例如，公平 share）所需的時間
* Job completion time：假設每個 framework 只有一個 job，完成該 job 所需的時間
* System utilization：整個集群的總利用率

Workload 探討
* 從 elasticity、task duration 分佈下去看
* elasticity
* 彈性 framework
* 例如，Hadoop、Dryad
* 可以根據需要擴展或縮減其資源
可以在獲得節點後立即開始使用這些節點，並在 task 完成後立即釋放這些節點
* 剛性 framework ，如 MPI，只能在獲得固定數量的資源後開始運行其 job ，並且不能動態擴展以利用新資源，或在不大幅影響性能的情況下縮減資源
* task duration 分佈
* homogeneous 分佈、heterogeneous 分佈

資源類型探討
* 區分成 mandatory 資源、preferred 資源
* mandatory 資源
* 如果一個 framework 必須獲得某個資源才能運行，則該資源是 mandatory 資源
* 例如，如果 framework 無法在沒有 GPU 的情況下運行，那麼 GPU 就是 mandatory 資源
* preferred 資源
* 如果一個 framework 在使用某個資源時表現更好，但也能使用其他等效資源運行，則該資源是 preferred 資源
* 例如， framework 可能更喜歡在本地存儲其數據的節點上運行，但它也能遠程讀取數據

Assumption
* framework 請求的 mandatory 資源數量不會超過其 guaranteed allocation
* 確保 framework 不會因等待 mandatory 資源而陷入 deadlock
* 所有 task 具有相同的資源需求，在稱為 slot 的 node 切片上運行
* 每個 framework 只運行一個 job
### 4.2 Homogeneous Tasks
定義
* 一個擁有 n 個 slot 的集群
* 一個可以獲得 k 個 slot 的 framework f
* 假設一個 task 平均 duration 為 T，假設 framework f 執行一個需要 βkT 總計算時間的 job
=>當 framework 有 k 個 slot 時，完成 job 需要 βT 的時間
* task duration 分佈: 兩種分佈
* 常數
* 所有 task 持續時間相同
* 指數分佈
* 所有 task 持續時間不同


如預期所示，具有常數 task 持續時間的彈性 framework 表現最好，而具有指數 task 持續時間的剛性 framework 表現最差。由於空間限制，我們僅在此呈現結果，推導過程見。

* Framework ramp-up time
* task duration 是常數: framework f 最多需要 T 的時間來獲得 k 個 slot
* 在 T 的時間間隔內，每個 slot 都會變得可用，這將能夠為 framework 提供其所有偏好的 k 個 slot
* task duration 是指數: 可能高達 T * ln k
* 在 T * ln k 的時間間隔內， 才會獲得足夠的可用 slot
* Job completion time
* 等於獲得資源時間 + 執行時間(大約等於 T)
* 彈性 framework 的 job
* 在常數 task duration 是 1/2T + βT
* 1/2 T 是啥不知道??
* 在指數 task duration 是 T + βT
* 在 T 時間後可以獲得所有資源
* 剛性 framework 的 job
* 在常數 task duration 下是 T + βT
* 在 T 時間後可以一次性獲得所有資源
* 在指數 task duration 下是 T * ln k + βT
* 因為 framework 平均需要 T * ln k 的時間來獲得所有 slot 並開始其 job
* System utilization
* 彈性 job 充分利用其分配的 slot
* 假設需求無限，因為 job 可以在獲得 slot 後立即使用它們
* 剛性 framework 的利用率略差
* 因為 job 在獲得全部分配之前不能開始，因此在啟動過程中浪費了一些資源
### 4.3 Placement Preferences
與擁有完整 framework 偏好信息的集中式 schedular 相比，Mesos 的效果如何？

兩種資源配置情況
* 全部每個 framework 都獲得其所有偏好 slot
* 不管初始配置如何，系統都會在最多一個 T 的時間後收斂到每個 framework 分配其偏好 slot 的狀態
* 因為在 T 的時間間隔內，所有 slot 都會變得可用，因此每個 framework 都會被提供其偏好的 slot

* 某些偏好 slot 的需求超過了供應，沒有配置可以滿足所有 framework 的偏好
* 關鍵問題是如何在 framework 之間分配偏好 slot
* 加權公平分配政策
* 假設
* p 個 slot 是 m 個 framework 所偏好的
* framework i 請求 ri 個的 slot， $\sum_{i=1}^{m} ri > p$
* framework i 的權重是其預期的總分配量 si
* 目標是將$p*\frac{si}{ (\sum_{j=1}^{m} sj)}$ 個偏好 slot 分配給 framework i
* 在 Mesos 中的挑戰是 schedular 不知道每個 framework 的偏好，但可以簡單地執行抽籤調度，以與它們預期分配成比例的概率向 framework 提供 slot
* 當一個 slot 變得可用時，以 $\frac{si}{ (\sum_{j=1}^{m} sj)}$ 的概率將該 slot 提供給 framework i
* 由於每個 framework i 平均每 T 單位時間內獲得 si 個 slot，第4.2節中的啟動時間和完成時間結果依然有效(大家都一樣獲得 slot ，雖然數量不同)
### 4.4 Heterogeneous Tasks
Heterogeneous task duration 分佈
* 考慮一種 task 負載，其中 task 要嘛很短，要嘛很長，長 task 的平均 duration 顯著長於短 task 的平均 duration
* 可能會對具有短 task 的 framework 造成影響
* 在最壞的情況下，短 task 所需的所有節點可能都被長 task 佔滿，這樣短 task 可能需要等待很長時間（相對於其執行時間）才能獲得資源
* 如果長 task 的比例不太接近 1、每個節點支持多個 slot，隨機 task 分配可以運行良好
* 例如，在每個節點有 S 個 slot 的集群中，節點被長 task 填滿的概率為 $𝜖^S$($𝜖 \times 𝜖\times \times ......\times 𝜖 = 𝜖^S$)
* 當 S 很大時（例如在多核機器的情況下），即使 $ϵ>0.5$，這個概率也很小。因此，具有短 task 的 framework 仍然可以在短時間內獲得許多偏好 slot
* framework 能夠使用的 slot 越多，至少有 k 個 slot 運行短 task 的可能性就越大
* Mesos 可以稍作擴展，以允許分配策略在每個節點上為短 task 保留一些資源
* 可以將最大 task duration 與每個節點上的一些資源關聯起來，超過該 duration 後，運行在這些資源上的 task 將被終止
* 時間限制可以在 resource offer 中向 framework 暴露，使它們可以選擇是否使用這些資源(這種方案類似於高性能計算（HPC）集群中為短作業設置單獨 queue 的常見策略)
### 4.5 Framework Incentive
incentives 是指促使 framework（及其用戶）採取某些行動或策略以提高作業響應時間和系統效率的激勵機制
* Short tasks
* framework 可以使用為短 slot 保留的任何資源
* 使用小 task 可以將因 task 丟失（無論是因為撤銷還是故障）而浪費的工作最小化
* Scale elastically
* framework 能夠在獲得資源後立即使用這些資源，而不是等待達到給定的最小分配，這將使 framework 能夠更早地開始（並完成）作業
* 彈性擴展允許 framework 有機會使用未使用的資源，因為它可以在稍後釋放這些資源，而對系統的負面影響很小
* Do not accept unknown resources
* 大多數分配政策在提供資源時會考慮 framework 擁有的所有資源

與 Mesos 提高利用率的目標非常一致
* 如果 framework 使用短 task ，Mesos 可以快速在它們之間重新分配資源，從而減少新作業的延遲和因撤銷而浪費的工作
* 如果 framework 具有彈性，它們會機會性地利用所有可以獲得的資源
* 如果 framework 不接受它們無法理解的資源，它們會將這些資源留給能夠使用的 framework

許多當前的集群計算 framework ，如 MapReduce、Dryad，已經具備這些特性，因為使用短且獨立的 task 可以簡化負載均衡和故障恢復
### 4.6 Limitations of Distributed Scheduling
發現了分散式模型的三個局限性
* Fragmentation
* 當 task 具有 Heterogeneous 資源需求時，分散的 framework 集合可能無法像集中式 schedular 那樣優化資源分配（bin packing）
* 次優資源分配(在實際情況下，尤其是在分散式調度模型中，可能無法達到最佳分配，導致一些資源未被充分利用)而浪費的空間是由最大 task 大小與節點大小之間的比例所界定的
* 運行大型節點（例如多核節點）並在這些節點內運行小型 task 的集群，即使在分散調度下也能實現高利用率
* 當集群被具有小資源需求的 task 填滿時，具有大資源需求的 framework f 可能會因為資源不足而餓死，因為每當一個小 task 完成時，f 不能接受被釋放的資源，而其他 framework 則可以
* 為了適應具有大 task 資源需求的 framework，分配模塊可以支持在每個 slave 上的 minimum offer size，並在該數量的資源可用之前不提供資源
* Interdependent framework constraints
* 有可能因為 framework 之間存在特殊的相互依賴性（例如，來自兩個 framework 的某些 task 不能共存），只有單一的全局集群分配能夠表現良好
* 罕見的
* Framework complexity
* 使用 resource offer 可能會使 framework 的調度更加複雜，然而，並不嚴重
* 無論是使用 Mesos 還是集中式 schedular，framework 都需要知道它們的偏好
* 在集中式 schedular 中，framework 需要向 schedular 表達這些偏好
* 在 Mesos 中，framework 需要用偏好來決定接受哪些 resource offer
* 現有 framework 的許多調度策略是在線算法，因為 framework 無法預測 task 時間，並且必須能夠處理故障和緩慢 task
* 這些策略很容易在 resource offer 上實現
## 5. Implementation
Mesos 系統，可以運行在 Linux、Solaris、OS X 上，並支持用 C++、Java、Python 編寫的 framework
* 為了降低實現的複雜性，使用了一個名為 libprocess 的 C++ library，提供了一種基於 Actor 的編程模型，使用高效的異步 I/O 機制（如 epoll、kqueue 等）

在 Mesos 上實現了四個 framework
* 三個現有的集群計算系統：Hadoop 、Torque 資源 schedular、 MPI 的 MPICH2 實現
* 移植過程都不需要更改這些 framework 的 API，因此所有 framework 都能運行未修改的用戶程序
* 為迭代作業構建了一個專門的 framework，Spark
### 5.1 Hadoop Port
將 Hadoop 移植到 Mesos 上運行所需的修改相對較少
* Hadoop 的 fine-grained map 和 reduce task 可以很好地映射到 Mesos task
* Hadoop 的 master (稱為 JobTracker) 和 Hadoop 的 slave(稱為 TaskTracker)自然地適合 Mesos 模型中的 framework schedular 和 executor

為了支持在 Mesos 上運行 Hadoop，利用了 Hadoop 已經擁有的可插入 API 用於編寫 job scheduler
* scheduler 連接到 Mesos，啟動 TaskTracker 作為其 executor，並將每個 Hadoop task 映射到 Mesos task
* 當 Hadoop 中有未啟動的 task 時，schedular 首先在 task 希望使用的集群節點上啟動 Mesos task，然後使用 Hadoop 的現有內部接口將 Hadoop task 發送給節點
* 當 task 完成時，executor 通過 TaskTracker 中的 API 監聽 task 完成事件來通知 Mesos

使用 delay scheduling 來實現 data locality
* 通過等待包含 task 輸入數據的節點上的 slot
* 允許重用 Hadoop 現有的邏輯來重新調度失敗的 task 和 speculative execution（straggler mitigation)
* Speculative Execution 是指在偵測到某些任務進度異常緩慢時，系統會啟動這些任務的副本（副本任務），並行執行
* 如果副本任務比原始任務更快完成，系統會使用副本任務的結果，並終止原始任務

需要改變 map 輸出數據的服務方式以適應 reduce task
* Hadoop 通常將 map 輸出文件寫入 local filesystem，然後使用 TaskTracker 中包含的 HTTP server 將這些文件提供給 reduce task
* 問題: Mesos 中的 TaskTracker 作為 executor 運行，如果不運行 task，可能 map task 的 executor 會被終止，資料都會消失，將使 reduce task 不可用 map 輸出文件
* 解決: 在集群的每個節點上提供共享文件 server 來服務本地文件
* 不僅對 Hadoop 有用，對於在每個節點上寫入數據的其他 framework 也很有用
### 5.2 Torque and MPI Ports
將 Torque 集群資源管理器移植為 Mesos 上的 framework
* 包括用 Python 編寫的 Mesos schedular 和 executor，用於啟動和管理 Torque 的不同元件
* 修改了 Torque 源碼，使其能夠根據 queue 中的作業在 Mesos 上彈性擴展和收縮
* 由於在 Torque 上運行的作業（例如 MPI）可能不具有容錯性，Torque 通過不接受超過其 guaranteed allocation 的資源來避免其 task 被撤銷

在向 Mesos master 註冊後， framework schedular 配置並啟動 Torque server ，然後定期監控 server 的 job queue
* 當 queue 為空時， schedular 釋放所有 task （到可選的最小值，設置為 0），並拒絕從 Mesos 接收到的所有 resource offer
* 一旦有作業使用標準的 qsub 命令添加到 Torque 的 queue 中， schedular 便開始接受新的 resource offer，直到 queue 空

task:
1. 在接受 resource offer 的每個節點上，executor 啟動一個 Torque 後端守護 process 並將其註冊到 Torque server 上
2. 當足夠多的 Torque 後端守護 process 註冊後，Torque server 將啟動其 queue 中的下一個作業

除了 Torque framework，還創建了一個用 Python 編寫的 Mesos MPI 封裝 framework，用於直接在 Mesos 上運行 MPI 作業
### 5.3 Spark Framework
為了測試簡單的專用 framework 能夠提供價值：iterative job，在多次迭代中重複使用數據集
* Spark 的專用 framework，專門優化
* 機器學習中使用的一個迭代算法的例子是邏輯回歸
* 旨在找到一條線來區分兩組帶標籤的數據點
1. 從一條隨機的線 w 開始
2. 在每次迭代中，計算一個目標函數的梯度(衡量線對數據點的區分效果)
* 梯度計算等於對每個數據點 x 進行評估函數f(x;w) 並將結果求和
3. 沿著這個梯度移動 w
* 在 Hadoop 中實現邏輯回歸
* 因為每次迭代依賴於前一次計算的 w，所以必須將每次迭代作為一個單獨的 MapReduce 作業運行
* 會產生開銷，因為每次迭代都必須將輸入文件重新讀入 memory

* 在 Hadoop 中實現邏輯回歸
* 整個作業可以表示為數據流 DAG，但數據在每次迭代中仍然必須從 disk 重新加載
* 在 Dryad 中在迭代之間 reuse memory 中的數據需要循環數據流
* 在 Spark 中實現邏輯回歸
* 利用 Mesos executor 的長期存在性，將數據集的一部分緩存到每個 executor 的 memory 中，然後在這些緩存的數據上運行多次迭代
* 這種緩存以容錯的方式實現：如果一個節點丟失，Spark 能夠重新計算其數據片段

使用 Mesos 的 API 為節省了撰寫程式 Spark 的 master、slave、它們之間通信協議的時間
主要需要撰寫程式的部分是 framework schedular（使用 delay scheduling 來實現 locality)、用戶 API