揭祕Apache Hadoop YARN,第五部分:使用FairScheduler 隊列屬性

原文地址:

http://blog.cloudera.com/blog/2017/02/untangling-apache-hadoop-yarn-part-5-using-fairscheduler-queue-properties/

在Part 4 ,介紹了Apache Hadoop 中的FairScheduler常用的屬性。在Part 5 中,會提供一些例子來展示這些屬性的用法,單獨或者組合使用,來滿足各種常用的需求,如應用程序優先級和組織隊列。

揭秘Apache Hadoop YARN,第五部分:使用FairScheduler 隊列屬性

示例:Best Effort隊列

摘要: 創建一個“best effort”隊列,當群集空閒時執行應用程序。

實現: 在FairScheduler中,如果一個隊列權重位0.0,只有群集中有空餘資源的時候才會去運行應用程序。換句話說,priority_jobs隊列中的所有作業將首先被分配,然後FairScheduler才會將剩下的資源分配給best_effort_jobs隊列。

<queue>

<queue>
<weight>0.0

note:

如果群集的資源被隊列充分利用起來,那麼這些隊列的作業可能需要更長時間來完成。

警告:

在CDH的早期版本中有一個錯誤,其中值0.0將不能正常工作,但像0.01這樣的值工作正常。 YARN-5077解決了該問題,位於CDH 5.7.3,CDH 5.8.2,CDH 5.9.0和更高版本中。

示例:使用maxResources保證低延遲應用程序的資源

摘要:具有運行具有特殊低延遲要求的應用程序的特殊隊列。

實現:假設我們有一個具有以下資源的集群:<memory>。通過在other_jobs隊列上設置maxResources屬性,FairScheduler為low_latency隊列留下<memory>。

<queue>
<queue>
<queue>
<maxresources>16000 gb,8000 vcores


注意:

  • 所有應用程序在other_jobs隊列中的總利用率不能超過集群的80%。
  • 通過為low_latency隊列留下約20%的集群資源,應用程序可以儘快啟動.
  • 這種情況僅作為示例提供。在許多情況下,最好使用下面的“使用搶佔的低延遲應用隊列”例子。

示例: 使用搶佔來保證資源到低延遲應用程序,而不損害利用率

摘要:擁有一個專門運行低延遲應用程序的隊列。

實現:假設我們有一個具有以下資源的集群:<memory>. 。此配置將在low_latency隊列上啟用搶佔。

<queue>
<queue>
<fairsharepreemptionthreshold>1.0
<fairsharepreemptiontimeout>1

<queue>


注意:

  • 與maxResources版本(參見上一個示例)不同,整個集群資源可用於other_jobs隊列,但是又可以搶佔other_jobs中的應用程序,以使low_latency隊列啟動應用程序運行。
  • 如果您仍希望限制low_latency隊列的總集群使用率,可以應用maxResources。
  • 稍後還有兩個優先級隊列的示例顯示如何以更復雜的方式使用搶佔。
  • 提醒:要在FairScheduler中啟用搶佔,必須在yarn-site.xml中設置此屬性:
<property>
<name>yarn.scheduler.fair.preemption
<value>true

示例:限制Ad-Hoc隊列的大小

摘要:允許子ad-hoc隊列具有maxResources設置

實現:通常,不能在ad-hoc隊列上設置屬性,因為它們沒有在fair-scheduler.xml文件中定義。通過在some_parent隊列上設置maxChildResources屬性,該隊列的任何子項(例如ad-hoc用戶隊列或ad-hoc組隊列)將等效於 8192 mb,8 vcores maxResources>設置。

<queue>
<maxchildresources>8192 mb,8 vcores

注意:

此功能是在CDH 5.9.0中引入的新功能。

示例:組織隊列

摘要:為每個組織提供其應用程序的隊列。

實現:為每個組織提供一個隊列,在這種情況下是sales, marketing, finance, 和 data science。每個團體獲得相等份額的Steady FairShare。

<queue>
<queue>
<queue>
<queue>


分層實現:sales組織有northamerica和europe子隊列。marketing組織有reports和website隊列。 data_science組織具有priority和best_effort隊列。

<queue>
<queue>
<queue>
<queue>
<queue>

<queue>
<queue>
<queue>

<queue>
<queue>
<weight>100.0

<queue>
<weight>0.0



示例:嚴格優先隊列

摘要:這是一個優先級隊列的替代方法。

實現:在前面的示例中,FairScheduler使用搶佔來強制執行100/10/1的容器分配。在此版本中,root.other和root.other.other隊列的權重為0.這具有以下效果:

1.priority1隊列中的任何作業將首先完全分配,然後將任何備用資源分配給priority2隊列中的作業。最後,之後的任何備用資源將被給予priority3隊列

2.如果每個優先級隊列都有超出集群容量的作業,則priority2隊列中的作業將僅在priority1中所有作業的總資源需求低於集群容量後開始。對於priority2隊列中的作業,優先級高於priority3隊列中的作業也是如此。

3.如果將作業添加到priority1隊列,那麼當任務從隊列priority2和priority3完成時,容器將分配給這些新作業。類似地,如果將新作業添加到priority2隊列(並且假設priority1作業保持完全分配),那麼當priority3隊列中任務完成時,這些作業將獲得容器。

<queue>
<queue>

<queue>
<weight>0
<queue>

<queue>
<weight>0
<queue>




注意:

  • 如果在所有隊列上啟用搶佔,則添加到priority1隊列中的任何作業將立即搶佔priority2和priority3中的作業。類似地,priority2隊列中的任何添加的作業將優先於priority3隊列中的作業。
  • 可以根據需要添加許多級別的層次結構,以滿足您的需求。
  • 如前面“Best Effort隊列”示例中所述,在CDH的早期版本中存在一個錯誤,其中值0.0將不能正常工作,但真正微小的值(例如0.01)工作正常。

示例:使用搶佔實現優先級

摘要:給定以下情況:(a)以容量運行的群集,以及(b)其分配低於其FairShare的“高優先級”隊列。打開搶佔保證資源在提供的超時值內可用。

實現:必須在FairScheduler中啟用搶佔,方法是在yarn-site.xml中設置以下屬性:

<property>
<name>yarn.scheduler.fair.preemption
<value>true

下面是fair-scheduler.xml中的隊列示例。如果隊列在60秒內未收到其FairShare的80%,FairScheduler將開始從some_other_queue搶佔應用程序並將資源提供給priority_queue。

<queue>
<weight>75.0
<fairsharepreemptionthreshold>0.8
<fairsharepreemptiontimeout>60

<queue>
<weight>25.0

示例:使用搶佔實現多層次的優先級

摘要:當兩個優先級級別不足以分隔作業優先級需求時,您可以使用三個級別的優先級和搶佔。

實現:high_priority和medium_priority隊列啟用搶佔。 low_priority隊列不會啟用搶佔。為了防止medium_priority隊列從high_priority隊列搶佔容器,我們還將在high_priority上設置allowPreemptionFrom屬性。

<queue>
<queue>
<weight>100.0
<fairsharepreemptionthreshold>0.9
<fairsharepreemptiontimeout>120
<allowpreemptionfrom>false

<queue>
<weight>10.0
<fairsharepreemptionthreshold>0.5
<fairsharepreemptiontimeout>600

<queue>
<weight>1.0


注意:allowPreemptionFrom屬性,在CDH 5.7.0中才引入。

為Oozie啟動器作業設置單獨的隊列

摘要:當Oozie啟動某個操作時,啟動器作業需要使用一個MapReduce應用程序主文件與一個任務實際啟動該作業。在Oozie同時啟動許多操作的情況下,隊列和或群集可能會使用Oozie Launcher MapReduce AM命中maxAMShare,這將導致死鎖,因為任何隨後的YARN應用程序無法啟動AM

解決方案是將Oozie啟動器作業放入單獨的隊列,並根據需要限制隊列。

示例:

  • 在您的Oozie工作流中,將屬性oozie.launcher.mapred.job.queue.name設置為指向Oozie啟動器隊列:
<property>
<name>oozie.launcher.mapred.job.queue.name
<value>launcher

在FairScheduler中,為啟動器作業創建隊列

<queue>
<maxrunningapps>10

note:

這不是FairScheduler的具體問題。然而,Oozie和YARN之間的這種相互作用是一個很常見的問題,這個問題在小集群上尤其常見。

將諸如maxResources或maxRunningApps之類的限制放在啟動器隊列上將有助於防止Oozie啟動器作業對群集進行死鎖。

在根或父隊列上進行硬限制

摘要:在FairScheduler中,硬限制(如maxRunningApps或maxResources)自上而下傳播。同樣,在根隊列上設置這樣的屬性將影響所有隊列。

示例:root.parent1的maxRunningApps設置為1.因此,儘管在childA和childB隊列中將maxRunningApps設置為大於1的值,但只能運行一個應用程序

<allocations>
<queue>
<queue>
<maxrunningapps>1
<queue>
<maxrunningapps>3

<queue>
<maxrunningapps>3




刪除隊列

摘要:沒有直接的方法可以通過命令行或UI刪除隊列。但是,如果更新fair-scheduler.xml配置文件並刪除文件中的隊列,則在下一個調度程序配置刷新時,將刪除隊列。

解決方案:確保隊列中的所有應用程序在實際更改配置之前具有狀態FINISHED。在MR應用程序的情況下,還要確保它們保存在JobHistoryServer中。

FairScheduler搶佔是全局的

摘要:FairScheduler中的搶佔是全局性的。調度器查看高於其FairShare的所有隊列,並去獲取這些資源,將它們分配到低於它們的FairShare的隊列。目前沒有將搶佔限制到隊列子集的形式,或者只允許從queueA到queueB的搶佔。

解決方案:allowPreemptionFrom屬性用來控制是否允許搶佔。未來版本的FairScheduler可能允許其他形式的控制或分組。

小群集但是有大量job

摘要:用戶運行小型集群並不罕見,其中活動隊列數(帶有作業)與集群中的資源量(vcores或GB)相配。這可能發生在測試群集中。在小型群集中當太多的大作業提交到同一隊列時,livelock的情況或者執行相當緩慢。

解決方案:考慮限制小型集群上的隊列數。此外,還可以通過設置maxRunningApps屬性來限制隊列中正在運行的作業數。例如:

<queue>
<maxrunningapps>5

擴展閱讀

要獲得有關Fair Scheduler的更多信息,請查看在線文檔(Apache Hadoop和Cloudera CDH 5.9.x)


分享到:


相關文章: