1. 程式人生 > >hadoop的三種任務排程的原理

hadoop的三種任務排程的原理

Hadoop調優方式

一個MapRedcue作業是通過JobClientmasterJobTracker提交的(JobTracker一直在等待JobClient通過RPC協議提交作業),JobTracker接到JobClient的請求後把其加入作業佇列中。

Datanode節點的TaskTracker一直通過RPCJobTracker傳送heartbeat詢問有沒有任務可做,如果有則讓其派發任務過來,TaskTracker在其本地發起Task,執行任務。

注:RPCRemote Procedure Call Protocol——遠端過程呼叫協議它是一種通過網路從遠端計算機程式上請求

服務,而不需要了解底層網路技術的協議。

Hadoop Job Scheduler作業排程器,常見的有三種:

預設排程演算法

預設排程演算法FIFO 佇列策略

計算能力排程演算法Capacity Scheduler(Yahoo 開發)

公平份額排程演算法Fair Scheduler(Facebook開發)

一、FIFO先進先出:

·預設排程演算法

·所有使用者的作業都被提交到一個佇列中,然後由JobTracker先按照作業的優先順序高低,再按照作業提交時間的先後順序選擇將被執行的作業。

·優點:
排程演算法簡單,JobTracker工作負擔輕。
·缺點:
忽略了不同作業的需求差異。例如如果類似對海量資料進行統計分析的作業長期佔據計算資源,那麼在其後提交的互動型作業有可能遲遲得不到處理,從而影響到使用者的體驗。

二、Capacity Scheduler計算能力排程演算法:

·由雅虎提出的作業排程演算法

·Capacity Scheduler可以定義多個作業佇列(multiple queues),作業提交時將直接放入到一個佇列中,每個佇列中採用的排程策略是FIFO演算法。

·每個佇列都可以通過配置獲得一定數量的tasktracker資源用於處理map/reduce操作,排程演算法將按照配置檔案為佇列分配相應的計算資源量。

·該排程預設情況下不支援優先順序,但是可以在配置檔案中開啟此選項,如果支援優先順序,排程演算法就是帶有優先順序的FIFO
·不支援優先順序搶佔,一旦一個作業開始執行,在執行完之前它的資源不會被高優先順序作業所搶佔。

·對佇列中同一使用者提交的作業能夠獲得的資源百分比進行了限制以使同屬於一使用者的作業不能出現獨佔資源的情況。

Capacity Scheduler記憶體管理

·Capacity Scheduler能有效地對hadoop叢集的記憶體資源進行管理,以支援記憶體密集型應用。 作業對記憶體資源需求高時,排程演算法將把該作業的相關任務分配到記憶體資源充足的task tracker上。

·在作業選擇過程中,Capacity Scheduler會檢查空閒task tracker上的記憶體資源是否滿足作業要求。task tracker上的空閒資源(記憶體)數量值可以通過task tracker的記憶體資源總量減去當前已經使用的記憶體數量得到,而後者包含在tasktracker向job tracker傳送的週期性心跳資訊中。·關於記憶體排程的相關引數可以通過配置檔案來設定。

配置Capacity Scheduler

1、cd $HADOOP_HOME/contrib/capacity-scheduler

複製hadoop-capacity-scheduler-0.20.2-cdh3u2.jar

到$HADOOP_HOME/lib 下

2、修改$HADOOP_HOME/conf下mapred-site.xml,增加

<property>
  <name>mapred.jobtracker.taskScheduler</name>
  <value>org.apache.hadoop.mapred.CapacityTaskScheduler</value>
</property>
<property>
  <name>mapred.queue.names</name>
  <value>default,langsin</value>
</property>

3、修改$HADOOP_HOME/conf下capacity-scheduler.xml,增加屬性如下:

<property>

    <name>mapred.capacity-scheduler.queue.default.capacity</name>

    <value>100</value>

</property>

………….

<property>

    <name>mapred.capacity-scheduler.queue.langsin.capacity</name>

    <value>100</value>

</property>

選擇佇列

set mapred.job.queue.name=langsin;

三、公平排程演算法Fair Scheduler

提出背景 Facebook要處理生產型作業(資料統計分析,hive)、大批處理作業(資料探勘、機器學習)、小型互動型作業(hive查詢) 不同使用者提交的作業型在計算時間、儲存空間、資料流量和響應時間上都有不同需求。 為使hadoopmapreduce框架能夠應對多種型別作業並行執行,使得使用者具有良好的體驗,Facebook公司提出該演算法。

三、公平排程演算法Fair Scheduler

Fair Scheduler排程中,只有一個作業執行時,它將獨佔叢集所有資源。有其他作業被提交時就會有TaskTracker被釋放並分配給新提交的作業,以保證所有的作業都能夠獲得大體相同的計算資源。

·作業池

·使用者提交的作業將會放進一個能夠公平共享資源的pool()中。

·每個作業池設定了一個最低資源保障(a guaranteed minimum share),當一個池中包含job時,它至少可以獲得minimum share的資源——最低保障資源份額機制。

·池中的作業獲得一定份額的資源。

·可以通過配置檔案限制每個池中的作業數量。

·預設情況下,每個作業池中選擇將要執行的作業的策略是FIFO策略,先按照優先順序高低排序,然後再按照提交時間排序。

·作業和作業池的權值weight

·預設情況下,FairScheduler會為每一個使用者建立一個單獨的pool。所有使用者能夠獲得等量的資源份額而無論他提交了多少作業,而每個pool中,各個作業將平分分配給所在池的資源。

·實際應用中,無論是作業池還是作業,都被賦予一定的權值,並以此為依據獲得相應比例的資源。這種情況下,作業池和作業在資源分配時不是嚴格的平均分配,但這有利於根據作業的重要程度及實際需求合理分配資源

·Deficit(赤字,不足)

·FairScheduler為每個作業定義了一個deficit(赤字)指標。

·Deficit是一個作業在理想情況下的獲得的計算資源和實際中獲得的計算資源之間的差距。

·FairScheduler會每隔幾百毫秒觀察每個作業中有多少任務已經在這個時間間隔內執行,並將結果與它應得的資源份額比較,以更新該作業的deficit值。一旦有空閒的task tracker出現,首先分配給當前具有最高deficit的作業。

·例外——如果系統中存在著尚未獲得最低資源保障的作業池,那麼該池中的作業將會優先排程,而選擇池中的作業需要根據它們的deficit來決定。這樣做是為了儘可能滿足作業池最低保障資源份額的機制。

配置Fair Scheduler

1、cd $HADOOP_HOME/contrib/fairscheduler

cp*.jar $HADOOP_HOME/lib/

一般版本里,lib下包含這個包。

2、修改mapred-site.xml 增加如下:

<property>
  <name>mapred.jobtracker.taskScheduler</name>
  <value>org.apache.hadoop.mapred.FairScheduler</value>
</property>

 <property>

  <name>mapred.fairscheduler.allocation.file</name>        <value>$HADOOP_HOME/conf/fair-scheduler.xml</value>   

</property>

<!--  設定支援的佇列名 -->

<property>
  <name>mapred.queue.names</name>
  <value>default,langsin</value>
</property>

3、修改$HADOOP_HOME/conf下fair-scheduler.xml
<pool name="default">
<minMaps>9</minMaps>
<minReduces>2</minReduces>
<maxRunningJobs>20</maxRunningJobs>
<weight>1.0</weight>
<minSharePreemptionTimeout>30</minSharePreemptionTimeout>
</pool>

<pool name=“langsin">
<minMaps>90</minMaps>
<minReduces>20</minReduces>
<maxRunningJobs>20</maxRunningJobs>
<weight>2.0</weight>
<minSharePreemptionTimeout>30</minSharePreemptionTimeout>
</pool>