Hadoop调优方式

一个MapRedcue作业是通过JobClient向master的JobTracker提交的（JobTracker一直在等待JobClient通过RPC协议提交作业），JobTracker接到JobClient的请求后把其加入作业队列中。

Datanode节点的TaskTracker一直通过RPC向JobTracker发送heartbeat询问有没有任务可做，如果有则让其派发任务过来，TaskTracker在其本地发起Task,执行任务。

 

注：RPC（Remote 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>