MapReduce性能优化---调度
2011-10-12 19:40
225 查看
目前,很多internet服务都具有上百万的用户。这些服务产生海量的数据,如何针对海量数据进行分析和处理是目前亟待解决的问题。
Google提出了一个令人兴奋的架构。MapReduce把任务分解成小任务,这些小任务可以在普通PC集群上并行执行。这种架构的一种开源实现是yahoo!的hadoop。目前国内在用此架构的公司为百度,淘宝,腾讯等,国外Amazon,Facebook,New York Times等已在使用。
MapReduce带来的关键性好处是它自动处理错误的能力。如果集群中的一个节点宕机,MapReduce讲在另外一台机器上执行任务。如果一台在执行任务的机器处理速度很慢,成为整个任务traggler,将会在另外一台机器上运行任务副本backup task,这就是推测执行。推测执行可以提高任务44%的速度。
推测执行不是没有代价的。
1. 对比各种资源,如网络
2. 选择哪个节点来执行任务副本
3. Straggler与平均速度的对比是苦难的
Hadoop采用master/slaves的结构。出入文件存在于分布式文件系统中。Hadoop把每个job分为多个tasks,每个输入首先被用户定义的map函数map task进行处理,输出一系列key-value中间结果。当map任务结束后,执行reduce task。Slaves通过‘心跳‘机制来告知master自己是否有空闲,如果有,则会被分配一个task。这里对“心跳机制”进行简单的介绍:
hadoop的集群是基于master/slave模式,namenode和jobtracker属于master,而datanode/tasktracker属于slaves。master只有一个,而slaves有多个。
namenode与datanode之间的通信,jobtracker与tasktracker直接的通信,都是通过“心跳”完成的。
心跳的机制大概是这样的:
1) master启动的时候,会开一个ipc server在那里。
2) slave启动时,会连接master,并每隔3秒钟主动向master发送一个“心跳”,将自己的状态信息告诉master,然后master也是通过这个心跳的返回值,向slave节点传达指令。
Hadoop的调度:
总体思路---
a. 选定推测执行任务
b. 选择能快速执行的节点
c. 设置最高时限,防止超负荷
推测执行的目标是最小化job的响应时间。响应时间对那些短任务特别重要。
如果有节点有空的task可以执行,则从以下三种类型来选择一个task来分配
a. 失败的任务,给予更高的优先级
b. 为被调度安排的任务
c. 需要推测执行的任务
Hadoop通过一个进展分数来选择推测执行的任务。对于map就是读入的数据占需要输入数据的比。对于reduce,执行被分为三个部分:copy阶段,sort阶段,reduce阶段。
Eg. 对于在copy阶段一半时的分数为1/2*1/3=1/6.
对于reduce阶段一半时的进展分数为1/3+1/3+(1/2*1/3)=5/6
在多job情况下,hadoop采用FIFO的方式来调度job的执行。
Hadoop调度器的默认假设:
1. 节点处理速度一样
2. 分配推测执行task到一个空闲task slot的没有代价
3. Task进展分数与执行阶段固定
4. 同类任务mpa or reduce的不同task需要的总工作量相同
但是,对于分布式环境,各种资源都是不对称的,这和假设不吻合。Copy,sort,reduce阶段各占1/3也不公平,COPY阶段对网络传输要求高是很显然的。启动推测执行任务也需要在网络带宽,磁盘I/O等方面付出代价。还有在一个快任务执行近完成时候突然降低速度的情况也不符合假设等等
算法提出:
LATE 调度器:
思想:执行那些能够最快完成的任务。这是通过预测剩余完成时间来实现的。
可以设计多种算法来预测剩余时间,一种简单的方法是:
进 展 比: 进展分数/执行时间
剩余时间: (1-进展分数)/进展比 =(1-进展分数)/进展分数/执行时间
慢节点门限SlowNodeThreshold 已成功task和在运行task之和
推测执行上限SpeculativeCap
慢任务门限SlowTaskThreshold 用来判断是否为慢
调度核心流程---
如果有空task slot可用且在运行的task数小于speculativeCap
--如果节点总的进度小于SlowNodeThreshold,则忽略
--根据剩余时间对运行中未推测执行的task排名
--对最高排名的任务创建副本,如果该该task的进度比低于SlowTaskThreshold
当然,这个调度器也是在一个task运行一分钟后才进行评估的。根据实践,SpeculativeCap设置为可以用task slot的10%,SlowNodeThreshold和SlowThreshold设置为节点进度和task进度的25%
算法优势:
1. 降低推测执行数目,减少资源竞争,减少负荷
2. 节点选择,考虑条件(原始hadoop调度器一视同仁)
3. Task 进度不在固定值,而不是低于门限的所有task都进行推测执行
4. 加入剩余时间,鲁棒性强
本文根据Matei Zaharia Andy Konwinski 等人的文章创作。
Google提出了一个令人兴奋的架构。MapReduce把任务分解成小任务,这些小任务可以在普通PC集群上并行执行。这种架构的一种开源实现是yahoo!的hadoop。目前国内在用此架构的公司为百度,淘宝,腾讯等,国外Amazon,Facebook,New York Times等已在使用。
MapReduce带来的关键性好处是它自动处理错误的能力。如果集群中的一个节点宕机,MapReduce讲在另外一台机器上执行任务。如果一台在执行任务的机器处理速度很慢,成为整个任务traggler,将会在另外一台机器上运行任务副本backup task,这就是推测执行。推测执行可以提高任务44%的速度。
推测执行不是没有代价的。
1. 对比各种资源,如网络
2. 选择哪个节点来执行任务副本
3. Straggler与平均速度的对比是苦难的
Hadoop采用master/slaves的结构。出入文件存在于分布式文件系统中。Hadoop把每个job分为多个tasks,每个输入首先被用户定义的map函数map task进行处理,输出一系列key-value中间结果。当map任务结束后,执行reduce task。Slaves通过‘心跳‘机制来告知master自己是否有空闲,如果有,则会被分配一个task。这里对“心跳机制”进行简单的介绍:
hadoop的集群是基于master/slave模式,namenode和jobtracker属于master,而datanode/tasktracker属于slaves。master只有一个,而slaves有多个。
namenode与datanode之间的通信,jobtracker与tasktracker直接的通信,都是通过“心跳”完成的。
心跳的机制大概是这样的:
1) master启动的时候,会开一个ipc server在那里。
2) slave启动时,会连接master,并每隔3秒钟主动向master发送一个“心跳”,将自己的状态信息告诉master,然后master也是通过这个心跳的返回值,向slave节点传达指令。
Hadoop的调度:
总体思路---
a. 选定推测执行任务
b. 选择能快速执行的节点
c. 设置最高时限,防止超负荷
推测执行的目标是最小化job的响应时间。响应时间对那些短任务特别重要。
如果有节点有空的task可以执行,则从以下三种类型来选择一个task来分配
a. 失败的任务,给予更高的优先级
b. 为被调度安排的任务
c. 需要推测执行的任务
Hadoop通过一个进展分数来选择推测执行的任务。对于map就是读入的数据占需要输入数据的比。对于reduce,执行被分为三个部分:copy阶段,sort阶段,reduce阶段。
Eg. 对于在copy阶段一半时的分数为1/2*1/3=1/6.
对于reduce阶段一半时的进展分数为1/3+1/3+(1/2*1/3)=5/6
在多job情况下,hadoop采用FIFO的方式来调度job的执行。
Hadoop调度器的默认假设:
1. 节点处理速度一样
2. 分配推测执行task到一个空闲task slot的没有代价
3. Task进展分数与执行阶段固定
4. 同类任务mpa or reduce的不同task需要的总工作量相同
但是,对于分布式环境,各种资源都是不对称的,这和假设不吻合。Copy,sort,reduce阶段各占1/3也不公平,COPY阶段对网络传输要求高是很显然的。启动推测执行任务也需要在网络带宽,磁盘I/O等方面付出代价。还有在一个快任务执行近完成时候突然降低速度的情况也不符合假设等等
算法提出:
LATE 调度器:
思想:执行那些能够最快完成的任务。这是通过预测剩余完成时间来实现的。
可以设计多种算法来预测剩余时间,一种简单的方法是:
进 展 比: 进展分数/执行时间
剩余时间: (1-进展分数)/进展比 =(1-进展分数)/进展分数/执行时间
慢节点门限SlowNodeThreshold 已成功task和在运行task之和
推测执行上限SpeculativeCap
慢任务门限SlowTaskThreshold 用来判断是否为慢
调度核心流程---
如果有空task slot可用且在运行的task数小于speculativeCap
--如果节点总的进度小于SlowNodeThreshold,则忽略
--根据剩余时间对运行中未推测执行的task排名
--对最高排名的任务创建副本,如果该该task的进度比低于SlowTaskThreshold
当然,这个调度器也是在一个task运行一分钟后才进行评估的。根据实践,SpeculativeCap设置为可以用task slot的10%,SlowNodeThreshold和SlowThreshold设置为节点进度和task进度的25%
算法优势:
1. 降低推测执行数目,减少资源竞争,减少负荷
2. 节点选择,考虑条件(原始hadoop调度器一视同仁)
3. Task 进度不在固定值,而不是低于门限的所有task都进行推测执行
4. 加入剩余时间,鲁棒性强
本文根据Matei Zaharia Andy Konwinski 等人的文章创作。
相关文章推荐
- Spark性能调优--调度与分区优化
- 转: 调整 Linux I/O 调度器优化系统性能
- MapReduce性能优化_4. 诊断一般性能瓶颈
- MongoDB MapReduce 性能提升20倍的优化宝典
- [大牛翻译系列]Hadoop(13)MapReduce 性能调优:优化洗牌(shuffle)和排序阶段
- 走近伏羲,谈5000节点集群调度与性能优化
- mapreduce 性能优化,通过inputSplit分片size控制map数目
- Mysql数据库服务器性能配置优化二 -- 文件系统及IO调度算法的选择
- MapReduce性能优化_5. 诊断一般性能瓶颈
- MongoDB MapReduce 性能提升20倍的优化宝典
- 走近伏羲,谈5000节点集群调度与性能优化
- MapReduce性能优化_1. 性能测量
- Hadoop链式MapReduce、多维排序、倒排索引、自连接算法、二次排序、Join性能优化、处理员工信息Join实战、URL流量分析、TopN及其排序、求平均值和最大最小值、数据清洗ETL、分析气
- 调度、模型、同步与任务——阿里云大数据数仓建设性能优化方案
- MapReduce性能优化_6. 优化 Shuffle & Sort 阶段
- 优化多核服务器集群中MapReduce的性能和可扩展性
- Hbase框架原理及相关的知识点理解、Hbase访问MapReduce、Hbase访问Java API、Hbase shell及Hbase性能优化总结
- MapReduce中Shuffle过程剖析及性能优化
- MapReduce性能优化_7. 减小数据倾斜的性能损失
- MongoDB MapReduce 性能提升20倍的优化宝典