本文為譯文，原文鏈接https://issues.apache.org/jira/browse/YARN-1963

1.1 前言

在許多應用場景中，我們希望YARN的作業能夠按照優先級的先後順序來執行。在現有的機制下，為了滿足這個需求，只能在使用CapacityScheduler時通過創建不同資源量的隊列，（優先級越高的隊列，資源量越大），然後將作業相應地按照優先級提交到這些隊列上來運行。 然而，更加理想的方式是讓作業支持優先級屬性，並能在提交作業時指定它。YARN-1963就是來完成這一功能的，本文是這個issue的設計文檔。

1.2 問題闡述

利用YARN的Capacity Scheduler調度器的已有特性，為了支持隊列內作業優先級調度，可以做如下操作：

a. 創建多個隊列，並根據優先級高低設置這些隊列的資源量。

b. 用戶根據自己所定義的優先級將作業提交到不同的隊列上。

c. 可以根據需要，為每個隊列設置不同的訪問控制權限。

這是一種非常不靈活的方式。如果在提交作業的時候就能指定作業優先級，則會大大簡化操作流程。不同優先級的作業可以運行在同一個隊列裏，並且可以根據優先級來共享該隊列的資源。

1.3 需求闡述

a. 用戶可以為他的每個作業設定一個優先級，這個優先級會在作業提交到葉子節點時用到，並由此調度作業。

b. 其他葉子隊列的調度屬性如user-limits（用戶可提交的作業數），作業提交時間（FIFO）可以與作業優先級合理搭配：

× 一個用戶如果所提交的作業數達到上限，則即使他提交的作業優先級很高，這個作業依然需要在隊列中排隊等待執行。

× 如果兩個作業的優先級相同，則按照作業的提交時間先後順序來執行。

c. 優先級的ACL--優先級的訪問控制列表，用來限制用戶無節制地提交高優先級作業的行為。

1.4 設計要點

YARN-1963 定義了作業優先級屬性，並且能夠根據優先級來調度作業。

這個功能主要涉及三個部分：

a. 指定作業優先級：可以通過作業提交的API 方法來指定作業優先級

b. 跟據作業優先級來調度作業：在遵循作業優先級的情況下，高優先級的作業會優先被Resource Manager調度。只有高優先級作業的需求被滿足後，低優先級的作業才會被調度。

c. 訪問控制列表：用戶必須被授權可以提交哪些優先級的作業，這可以看成哪些用戶具有特定優先級的訪問權限問題。

1.5 設計細節

1.5.1 用戶如何在提交作業時指定作業優先級？

a. 使用API：以下的API可以用來設定作業優先級

application.setApplicationPriority(Priority priority)

b. 使用命令行：在提交作業時，如果是mapreduce作業，可以使用如下參數設定作業優先級：

mapreduce.job.priority

1.5.2 管理員如何設定優先級？

1. 可以設定一個集群的作業優先級

管理員可以設置一個集群所能提交的最大作業優先級。所以每個作業都有一個集群作業最大優先級屬性。管理員也可以 設置一個隊列的隊列作業默認優先級。例如

yarn.cluster.max-application-priority = 10

每個用戶都可以用這個參數設定一個作業的集群作業最大優先級屬性。

2. 可以設定隊列作業默認優先級

管理員可以設置一個隊列上默認的作業優先級。當一個作業在提交到某個隊列時，如果沒有指定作業優先級，則使用隊列作業默認優先級。設定方法如下：

yarn.scheduler.root.<queue_name>.default-application-priority=3

註意： 隊列作業優先級在capacityScheduler和FairScheduler中的設置方式是不同的。以上是capacityScheduler設置方式。

1.5.3 如何支持通過API 或者CLI 方式來設定作業的優先級屬性

1. 可以通過如下方式來設定作業優先級：

管理員和用戶可以通過一系列API（包括REST）來設定優先級：

a. 使用API來get/set一個隊列的隊列默認作業優先級

b. 使用API來get/set集群最大作業優先級

c. 使用API 來get/set一個運行中作業的優先級

CLI 同樣要支持上文提到的功能。

2. 在作業運行過程中改變作業優先級

a. 普通用戶可以使用某種API 來改變他所提交的正在運行的作業的優先級

b. 管理員有權可以改變任意作業的優先級

註意：

a. 用戶包括管理員，必須擁有相應的ACL 權限才可以改變一個作業的優先級

b. 一旦一個作業的優先級被改變了，所有等待RM的請求的優先級都會被刷新一次

1.5.4 調度器端為支持作業優先級需要做的調整

調度器端所需要做的調整要根據調度器類別fairscheduler和capacityScheduler分為兩種情況。一個簡要的設計如下所述：

每個隊列都可能運行很多作業，這些作業具有不同的優先級，調度器應該按照優先級先後來調度這些作業。

a. 通過修改capacity和fair調度器中的application-comparator 和 Ordering Policy方法，可以實現優先調度優先級高的作業。

b. 在處理APP_ATTEMPT_ADDED事件過程中，不管是capacity還是fair調度器，作業的優先級字段都可以從ApplicationSubmissionContext中獲得，並存儲到調度器端供之後的流程中使用。

1.5.5 作業優先級的訪問控制列表

用戶必須有相應的權限來提交某中優先級的作業。這可以避免所有用戶都可以任意指定max-cluster-priority的作業，從而導致作業優先級失去意義。

a. 每個隊列都有一個關於作業優先級的訪問控制列表

b. capacity調度器和fair調度器因為代碼不同，需要不同的訪問控制列表配置。

1. 如何對隊列配置作業優先級的訪問控制列表

下面介紹一個在capacity調度器裏設置隊列作業優先級的例子：

yarn.scheduler.capacity.root.<queue_name>.<priority>.acl=user1,user2

在這個配置中，只有user1，user2可以運行指定優先級的作業。

註意： 在fairscheduler中也有類似的用於設置隊列作業優先級的配置。

2. 隊列作業提交的ACL和隊列作業優先級ACL 之間的關系

隊列作業提交的ACL是控制哪些用戶有權限向該隊列提交作業。而隊列作業優先級ACL控制的是哪些用戶在該隊列上具有提交指定作業優先級的權限。隊列作業優先級的ACL中的用戶應該是隊列作業提交ACL中的用戶的一個子集。一個用戶必須出現在這兩個ACL 中才能提交作業到這個隊列上。

註意： 如果一個用戶沒有出現在隊列作業優先級ACL中（已經在隊列作業提交ACL 中），則該用戶提交的作業可以標記為Rejected。 或者另一種處理方式是使用默認的隊列作業優先級來把這個作業提交到該隊列上。具體采用哪種方式需要和contributos溝通確定。

1.5.6 從RM Web UI上展現作業優先級

　可以從ＲＭ Web UI上查看作業詳細信息，如作業優先級．

下面有幾個需要註意的地方：

　１．　MAPREDUCE-314餓死問題

　２．　搶占：如果沒有搶占，則當一個低優先級作業使用了隊列的全部資源時，同隊列上的高優先級作業必須等待低優先級作業釋放資源．這種等待時間取決於低優先級作業的運行快慢程度．一旦低優先級作業上有ｃｏｎｔａｉｎｅｒ運行完畢並釋放相應的資源，該資源不會在此時間斷內（高優先級作業完成之前）再分配給低優先級作業，而是分配給高優先級作業．基於作業優先級的搶占機制可以保證高優先級作業在指定時間內啟動，而不用等待一個不確定的時間．

[YARN-1963] 支持同一個隊列內作業按優先級調度