MapReduce調度器

本文轉載自查看原文 2015-11-02 16:44 2163 Spark

1. 先進先出（FIFO）調度器

　　先進先出調度器是Hadoop的默認調度器。就像這個名字所隱含的那樣，這種調度器就是用簡單按照“先到先得”的算法來調度任務的。例如，作業A和作業B被先后提交。那么在執行作業B的任務前，作業A中的所有map任務都應該已經執行完成。

　　配置：調度器類型的配置是在mapred-site.xml文件中，將mapred.jobtracker.taskscheduler參數設置為我們想要使用的調度器的類名，FIFO調度器的類名是org.apache.hadoop.mapred.jobQueueTaskScheduler。當然，如果想用FIFO調度器，並不需要在配置文件中明確指定，因為默認的就是FIFO調度器。

2. 公平調度器

　　公平調度器，有時也叫公平共享調度器或FS調度器，是默認FIFO調度器的一種替代調度器。開發公平調度器的目的是解決FIFO調取器在大流量多用戶環境中所滋生的一些問題。

　　公平調度是將資源分配給應用程序的方法，使所有的應用程序得到的平均值，資源隨時間的相等份額。 Hadoop的下一代系統能夠調度多個資源類型。默認情況下，公平調度器調度僅在內存中實現公平調度。它可以被配置為內存和CPU調度，利用資源優勢公平的概念。此方法有由Ghodsi等人開發的。在應用程序使用的集群中，當有一個單一的應用程序運行時。當其他應用程序提交后，即釋放被分配給新的應用程序的資源，這樣每個應用程序對最終得到的資源量大致相當。不同於默認Hadoop的調度，形成應用程序的隊列，這讓短暫的應用程序在合理的時間內完成，而不會餓死長時間運行的應用程序。它也是一種合理的方式來共享多個用戶之間的集群資源。最后在公平共享的同時還能配合的應用程序優先級作為權重來確定總的資源為每個應用程序應該得到的資源數。

調度組織進一步應用到“隊列”，並在這些隊列之間分享資源??。默認情況下，所有用戶共享一個單一的隊列，命名為“ default”。如果一個應用程序專門列出一個隊列在一個容器資源請求，該請求被提交到該隊列。它也可以分配基於包括通過配置請求中的用戶名的隊列。在每個隊列調度策略用於共享運行的應用程序之間的資源。默認的是基於存儲器的公平共享，但是FIFO和多資源具有優勢資源公平也可以配置。隊列可以被安排在一個層次結構來划分資源，並與重量配置為共享集群中的特定比例。

除了提供公平共享，公平調度器允許分配最低保證分享的隊列，這是保證某些用戶，組或生產應用程序總能得到足夠的資源是有效的。當隊列中包含的應用程序，它得到至少為其最小的份額，但是當隊列並不需要它的全面保證份額，則超出部分拆分其他正在運行的應用程序之間。這讓調度保障能力的同時有效地利用資源，當這些隊列不包含應用程序的隊列。

公平調度器讓默認情況下運行的所有應用程序，但它也可以通過配置文件限制運行的每個用戶和每個隊列的應用程序的數量。這可能是有用的，當一個用戶必須同時提交上百的應用程序，或在總體上提高性能，如果同時運行了太多的應用程序會導致創建太多的中間數據或過多的上下文切換。限制應用程序不會造成任何其后提交的應用程序失敗，只能等待調度的隊列中，直到一些用戶的較早的應用程序完成的。

層次化隊列同可插入是策略

公平調度器支持分級隊列。所有隊列下降從一個名為“根”的隊列。可利用的資源分布在根隊列中的典型公平調度的時尚子節點。然后，子節點分發分配給他們自己的子節點以同樣的方式的資源。應用程序可能只被安排在隊列。隊列可以通過將他們作為父母的子元素中的公平調度器分配的文件被指定為其他隊列中的孩子節點。

隊列的名字開始與它的父母的名字，以間隔作為分隔符。因此，一個根隊列在名為“隊列”的隊列，將被稱為“root.queue1”，和一個名為“母公司1”隊列在名為“隊列”隊列會被稱為“root.parent1.queue2”。當提及隊列名稱的根部分是可選的，所以隊列1可以被稱為只是“隊列1”，並且一個隊列2可以被簡稱為“parent1.queue2”。

此外，公平調度器允許設置為每個隊列不同的自定義策略，以允許共享隊列的資源，任何用戶想要的方式。自定義策略可以通過擴展來構建 org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy。FifoPolicy，FairSharePolicy（默認）和DominantResourceFairnessPolicy是內置的，並可以很容易地使用。

某些加載項尚不支持其存在，在原來（MR1）公平調度。其中，是使用自定義的政策管轄優先權“提升”過某些應用程序。

將應用程序自動加載到隊列

公平調度器允許管理員配置策略，自動將應用程序提交到合適的隊列中。放置可以依賴於提交者和應用程序通過請求隊列中的用戶和組。策略由一組規則按順序應用到傳入的應用程序進行分類的。每項規則會將應用程序放入一個隊列，拒絕它，或者繼續到下一個規則。請參考下面的配置文件格式如何配置這些策略。

安裝

要使用公平調度器首先在yarn-site.xml配置相應的調度類：

  	<name>yarn.resourcemanager.scheduler.class</name>
  	<value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
	</property>

配置

	自定義公平調度器通常需要修改兩個文件。首先，調度范圍的選項可以通過添加在您現有的配置目錄在yarn-site.xml文件配置屬性進行設置。第二，在大多數情況下，用戶希望創建一個配置文件列表的隊列存在，它們各自的權重和容量。配置文件被裝入每10秒，允許改變要在程序進行調度方式。

可以放置在yarn-site.xml屬性

yarn.scheduler.fair.allocation.file
- 路徑配置文件。分配文件是一個XML清單描述隊列和它們的屬性，除了某些政策的默認值。此文件必須在下一節中描述的XML格式。如果使用相對路徑，則該程序文件中搜索的類路徑（這通常包括Hadoop的conf目錄下）。默認為公平scheduler.xml。
yarn.scheduler.fair.user-as-default-queue
- 是否使用與分配作為默認隊列名稱關聯的用戶名，在未指定隊列名稱的事件。如果設置為“false”或取消，所有工作都具有共享的缺省隊列，命名為“默認”。默認為true。如果隊列放置策略中給出了配置文件，則忽略此屬性。
yarn.scheduler.fair.preemption
- 是否使用搶占。需要注意的是搶占實驗是在當前版本中。默認為false。
yarn.scheduler.fair.sizebasedweight
- 是否將股份分配給基於其規模的個體應用，而不是提供一個平等的份額，所有的應用程序無論大小。如果設置為true，應用程序是由一加應用程序的總內存要求的自然對數，以2。默認值的自然對數除以假加權。
yarn.scheduler.fair.assignmultiple
- 是否允許多個容器分配在一個心跳。默認為false。
yarn.scheduler.fair.max.assign
- 如果assignmultiple是true，容器可以在一個心跳被分配的最大金額。默認為-1，這台沒有限制。
yarn.scheduler.fair.locality.threshold.node
- 對於要求容器在特定節點上的應用程序，調度機會，因為最后一個容器分配數接受安置在另一個節點上之前的等待時間。表現為介於0和1之間的浮點數，其中，作為簇大小的一小部分，是調度機會的數量讓人欲罷不能。-1.0手段的默認值不傳遞任何調度的機會。
yarn.scheduler.fair.locality.threshold.rack
- 對於要求容器上特定機架的應用，調度機會，因為最后一個容器分配數接受安置在另一架前等待。表現為介於0和1之間的浮點數，其中，作為簇大小的一小部分，是調度機會的數量讓人欲罷不能。-1.0手段的默認值不傳遞任何調度的機會。
yarn.scheduler.fair.allow-undeclared-pools

如果這是true，新的隊列可以在提交申請時被創建，無論是因為它們是由提交者指定為應用程序的隊列中，或者因為它們是由用戶的默認隊列屬性放在那里。如果此為假，任何時間的應用程序將被放置在一個未在該分配文件中指定一個隊列，它被放置在“默認”的隊列來代替。默認為true。如果隊列放置策略中給出了配置文件，則忽略此屬性。
配置文件格式

配置文件必須是XML格式。該格式包含了五種類型的元素：

隊列中的元素，它們代表的隊列。每一個都可以包含下面的屬性：
- minResources：最少的資源隊列有權在形式的“X MB，Y vcores”。對於單資源公平性的政策，在vcores值將被忽略。如果一個隊列的最低份額不滿意，將根據之前同一母公司提供可用資源的任何其他隊列。當下資源的公平策略隊列被認為是不滿意的，如果它的內存使用量低於其最低內存份額。就失去優勢資源公平性，一個隊列被認為是不滿意的，如果它的使用，它的相對於所述簇的容量優勢資源低於它的最低份額該資源。如果多個隊列不滿意在這種情況下，資源進入隊列有關的資源使用情況和最小值之間的最小比率。注意，有可能是一個隊列，即低於其最小可能不會立即起床到最小，當它提交的申請，因為已經運行的作業可以利用這些資源。
- maxResources：最大的資源隊列是允許的，在形式的“X MB，Y vcores”。對於單資源公平性的政策，在vcores值將被忽略。隊列永遠不會被分配一個容器，將其放在總使用量超過此限制。
- maxRunningApps：從隊列限制的應用程序的數量，同時運行
- 重量：與其他隊列非按比例分擔集群。權值默認為1，而與體重2隊列應收取約兩倍的資源作為一個與默認權重隊列。
- schedulingPolicy：設置任何隊列的調度策略。允許的值是“先進先出”/“公平”/“DRF”或 ??擴展任何類org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy。默認為“公平”。如果“先進先出”，應用程序與先前提交時間以偏愛的容器，但后來提交的應用程序可以同時運行，如果有剩余的空間集群在滿足前面的應用程序的請求后。
- aclSubmitApps：用戶和/或可以提交應用程序的隊列組的列表。請參考下面的ACL部分在此列表的格式和隊列是如何工作的ACL的詳細信息。
- aclAdministerApps：用戶和/或組可管理一個隊列的列表。目前唯一的行政行為是殺一個應用程序。請參考下面的ACL部分在此列表的格式和隊列是如何工作的ACL的詳細信息。
- minSharePreemptionTimeout：秒數隊列是根據它的最小份額的時候，才試圖搶占容器，以使資源從其他隊列。
用戶元件，它代表設置管用戶個性化的行為。它們可以包含一個屬性：maxRunningApps上運行的應用程序對特定用戶數量的限制。
一個userMaxAppsDefault元素，它設置默認運行的應用程序的限制是不是另有規定的限制的任何用戶。
一個fairSharePreemptionTimeout元素，幾秒鍾的隊列號是其公平份額下的時候，才嘗試搶占容器，以使資源從其他隊列。
一個defaultQueueSchedulingPolicy元素，它設置為隊列默認的調度策略; 如果所指定的每個隊列的schedulingPolicy元素覆蓋。默認為“公平”。
一個queuePlacementPolicy元素，其中包含告訴調度程序如何進入的應用程序放置到隊列規則元素的列表。規則的應用，因為它們列出的順序。規則可能需要的參數。所有規則接受“創造”的說法，這表示規則是否可以創建一個新的隊列。“創建”默認為true; 如果設置為false，該規則將放在未在配置文件中配置一個隊列的應用程序，我們繼續到下一個規則。最后一條規則必須是一個永遠無法發出繼續。有效的規則是：
- 規定：應用程序被放置到它要求隊列中。如果應用程序要求沒有隊列，也就是說，它指定了“default”，我們繼續。
- 用戶：應用程序被放置到一個與誰提交它的用戶的名稱隊列。
- primaryGroup：應用程序被放置到一個隊列，誰提交它的用戶的主組的名稱。
- secondaryGroupExistingQueue：應用程序被放置到一個有一個與誰提交了用戶的次要組名的隊列。符合配置的隊列中的第一次要組將被選中。
- 默認：應用程序被放置到一個名為“默認”的隊列。
- 拒絕：應用程序被拒絕。
這里有一個例子配置文件中給出：

<?xml version="1.0"?>
<allocations>
  <queue name="sample_queue">
    <minResources>10000 mb,0vcores</minResources>
    <maxResources>90000 mb,0vcores</maxResources>
    <maxRunningApps>50</maxRunningApps>
    <weight>2.0</weight>
    <schedulingPolicy>fair</schedulingPolicy>
    <queue name="sample_sub_queue">
      <aclSubmitApps>charlie</aclSubmitApps>
      <minResources>5000 mb,0vcores</minResources>
    </queue>
  </queue>
  
  <user name="sample_user">
    <maxRunningApps>30</maxRunningApps>
  </user>
  <userMaxAppsDefault>5</userMaxAppsDefault>
  
  <queuePlacementPolicy>
    <rule name="specified" />
    <rule name="primaryGroup" create="false" />
    <rule name="default" />
  </queuePlacementPolicy>
</allocations>

請注意，為了與原來的FairScheduler兼容性，“ queue”元素可以代替其命名為“pool”的元素。

隊列的訪問控制列表（ACL）

隊列的訪問控制列表（ACL）允許管理員控制誰可以采取行動，特別是隊列。它們被配置成與aclSubmitApps和aclAdministerApps特性，這可以為每個隊列被設置。目前只支持行政行為被殺死的應用程序。誰可以管理一個隊列中任何人也可以提交申請了。這些屬性需要像“用戶1，用戶2組1，組2”或“組1，組2”的格式值。如果它的用戶或組是在該隊列的訪問控制列表或任何該隊列的祖先ACL在一個隊列動作將被允許。所以，如果隊列2是內部隊列1，而user1的隊列1的ACL，和user2是在隊列2的ACL，那么這兩個用戶可以向隊列2。

根隊列的ACL是“*”，其中，因為ACL是傳下來的默認值，也就是說，每個人都可以提出來，並從每個隊列殺應用程序。要開始限制訪問，修改root隊列的ACL來的東西比“*”等。

管理

公平調度器提供了通過兩個機制來管理支持在運行時：

它可以通過編輯配置文件來修改最小的股票，限制，重量，搶占超時和隊列調度策略在運行時。它看到后，它被修改調度程序將重新載入該文件10-15秒。
當前的應用程序，隊列和公平共享可以通過ResourceManager的Web界面進行審查，在http://ResourceManager URL/cluster/scheduler。
以下字段可以看出，Web界面上顯示每個隊列信息：
使用資源 - 資源分配給隊列容器內的總和。
運行的應用程序數 - 應用程序在已收到至少一個容器隊列的數目。
等待的應用程序數 - 在隊列中的應用尚未收到任何容器的數量。
最小的資源 - 這是保證隊列的配置最少的資源。
最大的資源 - 被允許的隊列配置的最大資源。
公平共享 - 資源的隊列的公平份額。隊列可能當其他隊列不使用它們被分配的資源超出了他們的公平份額。隊列的資源消耗在於等於或低於其公平份額將永遠不會有它的容器搶占。
除此之外ResourceManager中通常會顯示每個應用程序的信息，Web界面，包括應用程序的公平份額。