为解决扩展性瓶颈雅虎计划重构Hadoop-MapReduce

标签: 扩展 瓶颈 雅虎 | 发表时间:2011-02-25 09:35 | 作者:(author unknown) 阿贡
出处:http://www.iteye.com

最近雅虎开发者博客发了一篇介绍Hadoop重构计划的文章。因为他们发现当集群的规模达到4000台机器的时候,Hadoop遭遇到扩展性的瓶颈,目前他们正准备开始对Hadoop进行重构。


Mapreduce面临的瓶颈


从集群大小和工作量中观察到的趋势是,MapReduce的JobTracker需要彻底改革,以解决其可扩展性,内存消耗,线程模型,可靠性和性能的几个缺陷。Mapreduce在过去5年框架不断的修复过程中发现成本在不断增加。目前Hadoop各个模块的紧耦合使得在现有设计的基础上继续改进变得举步维艰。这一点早已在社区内达成共识,所以他们正准备开始对Hadoop进行重构。不过从操作的角度来看,任何轻微的或修复Bug带来的巨大改动都会让Hadoop MapReduce强制进行全系统的升级。


下一代MapReduce构思


据该博客文章表示,新架构的主要思想是把原来JobTracker的功能一分为二:ResourceManager管理资源的分配,ApplicationMaster管理任务监控和调度。ResourceManager与原有的JobTracker类似,作为整个集群的控制中心;而ApplicationMaster则是每个application都有一个单独的实例,application是用户提交的一组任务,它可以由一个或多个job组成。每台slave运行一个NodeManager实例,功能类似于原来的TaskTracker。






1.层次化的管理


目前Hadoop的资源管理和任务调度都是在JobTracker中进行的,它需要复制所有task的资源分配和调度。而task是非常微观的调度单位,通常每个job都会产生成百上千个task,而系统同一时刻又会有大量的job同时运行,这让JobTracker的管理负担变得非常繁重。新架构将这一管理任务下放到各个ApplicationMaster,ResourceManager只管理每个application的资源分配。这样即使系统中存在很多application,ResourceManager的负担也能控制在一个合理的程度;这也是新架构最大的优势。


2.ApplicationMaster应该在Master还是Slave上运行?


新架构实际上将管理和调度的任务转移到ApplicationMaster上来,如果ApplicationMaster所在的节点挂掉,整个任务都需要重做。原来JobTracker可以跑在相对稳定的Master上,出错概率低;现在ApplicationMaster跑在好些Slave上,出错的概率就非常高了。而且新架构打破了原来简单的Master-Slave模型,节点之间的通讯和依赖关系变得更加复杂,增加了网络优化的难度。如果把ApplicationMaster全都放在Master上执行,则Master的负担会非常重(需要处理各种持续性的heartbeat和爆发性的如getTaskCompletionEvents这样的rpc请求),不过这个问题可以通过分布式的Master解决(Google已经实现)。


3.资源管理方式


原来单纯地以简单静态的slot作为资源单位确实不能很好描述集群的资源状况。新架构将更细粒度地控制CPU,内存,磁盘,网络这些资源。每个task都将在Container中执行,并只能使用其所分配到的系统资源。资源的分配可以用静态估计动态调整的方式实现。


4.支持其他编程模型


由于任务的管理和调度都由ApplicationMaster进行,ApplicationMaster又相对独立于系统的其他模块,用户甚至可以部署自己的ApplicationMaster,实现对其他编程模型的支持。这使得其他不大适合用MapReduce实现的应用程序也能在同一个Hadoop集群中运行。


可伸缩性实现


可伸缩性对当前的硬件发展趋势是非常重要的,目前MapReduce集群已经有4000台主机。然而2009年的集群中的4000台主机(8核心,16GB内存,4TB硬盘)只有2011年集群中4000台主机(16核心,48GB内存,24TB内存)一半的处理能力。此外,考虑到运营成本,迫使集群中运行6000台主机,以后可能会更多。


可用性实现


ResourceManager —— ResourceManager使用Apache的ZooKeeper实现故障转移。当ResourceManager失败时,可以通过Apache的ZooKeeper迅速恢复集群状态。在故障转移后,所有队列运行的应用程序都会重新启动。


ApplicationMaster —— MapReduce的NextGen支持为ApplicationMaster应用进行特定的检查。MapReduce的ApplicationMaster可以从失败中恢复,通过自身恢复到HDFS保存的状态。


兼容性实现


MapReduce的NextGen使用Wire-兼容协议(wire-compatible protocols)来允许不同版本的服务器和客户端进行信息交换。在未来的版本中,这一特性将一直保留,以保证集群升级后仍然兼容。


集群实现


MapReduce NextGen Resource使用常规的概念调度并将资源分配给各个应用程序。集群中的每台机器概念上都是由资源组成的,如内存,I/O带宽等。


支持其他的编程模型


MapReduce的NextGen提供了一个完全通用的计算框架,以支持MapReduce和其他范例。


该架构最终允许用户能够实现自定义ApplicationMaster,它可以要求ResourceManager的资源利用他们。因此,它支持多种编程,如MapReduce,MPI,Master-Worker以及Iterative models在Hadoop上。并允许为每个应用使用适当的框架。这对于应用程序(如K-Means, Page-Rank)在自定义框架外运行MapReduce。


结论


Apache的Hadoop,特别是Hadoop的MapReduce是一个非常成功的开源的处理大数据集的项目。我们建议Hadoop的MapReduce提高可用性、提高集群使用,并提供范式的编程架构以及


实现快速的发展。Yahoo将和Apache基金会一起将Hadoop在处理大数据的能力提高到一个新水平。



感谢 lzj0470 投递这篇新闻

声明:本文系JavaEye网站发布的原创新闻,严禁任何网站转载本文,否则必将追究法律责任!

已有 3 人发表留言,猛击->>这里<<-参与讨论


JavaEye推荐



相关 [扩展 瓶颈 雅虎] 推荐:

为解决扩展性瓶颈雅虎计划重构Hadoop-MapReduce

- 阿贡 - ITeye资讯频道
最近雅虎开发者博客发了一篇介绍Hadoop重构计划的文章. 因为他们发现当集群的规模达到4000台机器的时候,Hadoop遭遇到扩展性的瓶颈,目前他们正准备开始对Hadoop进行重构. Mapreduce面临的瓶颈. 从集群大小和工作量中观察到的趋势是,MapReduce的JobTracker需要彻底改革,以解决其可扩展性,内存消耗,线程模型,可靠性和性能的几个缺陷.

雅虎之殇

- ItTalks - 《商业价值》杂志
雅虎在这些年里真正欠缺的不是工程师,不是创新能力,也不是战略方向,而是创始人对公司的掌控力. 9月24日,雅虎董事长罗伊·博斯托克、联合创始人大卫·费罗和杨致远周五共同向员工发出备忘录,称公司顾问已与多方展开接触,公司将在数月内确定战略选择. 备忘录表示,雅虎的战略评估可能会耗时“数月,而非数周”.

我的瓶颈在哪里?

- 弛 - 博客园-首页原创精华区
   最近在处理一些比较复杂的问题,在解决这个问题的同时,我深刻的体会到,问题的本身,对我来讲,并不是最重要或者最紧要的(当我解决掉一个问题,其结果也只是问题不存在了). 我认为是我的思维能力或者思维方式,用最优质的方法去解决问题,这才是王道. 在平平淡淡的生活中,我们会碰到大量的问题,有的问题 凭直觉就能解决,如果碰到稍微复杂的问题,我们就不知道从什么地方入手,也就是我们找不到解决问题的方法,或者叫切入点.

常见的10种“瓶颈”

- - CSDN博客推荐文章
Working size超过可用内存. Working Size怎么理解. 肯定不是指数据库的大小,应该是在保证业务指标——响应时间、QPS的情况下,数据库使用的内存大小. 其超过可用内存后的直接影响就是系统开始使用“swap”,从而大大降低DB的性能. 所以,DB服务器要有充足的内存. 运行时间很长的查询,要是么很消耗内存、CPU,比如联合查询,要么是很消耗磁盘I/O,比如没有用到索引的“遍历”——这应该算是“事故”.

10招教你打破摄影瓶颈

- mjxian - 摄影之友
为陷入瓶颈期摄影师准备的可行建议. 作为一位作家,我深刻地理解以下这种感受 – 僵坐在电脑前,盯着闪烁的鼠标和空无一字的Word文档,这一刻灵感缺席,只能任凭恐惧和虚无肆虐. 纵有成千上万的思绪和故事就在齿边,却就是没有办法将它们形成文字. 当我拍照时,上述的同样场景也往往发生在我身上. 所以……你该去做些什么才能走出困境并打破摄影瓶颈.

寻找Linux单机负载瓶颈

- - 大CC
服务器性能上不去,是哪里出了问题?IO还是CPU. 只有找到瓶颈点,才能对症下药;. 如何寻找Linux单机负载瓶颈,遵循的原则是不要推测,我们要通过测量的数据说话;. 1.查看平均负载(top/uptime命令). 2.确认CPU、IO有无瓶颈;(使用 sar vmstat). 3.CPU负载过高时寻找流程:.

定位IO瓶颈的一些方法

- - Linux - 操作系统 - ITeye博客
IO瓶颈往往是我们可能会忽略的地方(我们常会看top、free、netstat等等,但经常会忽略IO的负载情况),今天给大家详细分享一下如何确认一台服务器的IO负载是否到达了瓶颈,以及可能优化、定位的点. 先来看一台典型的IO密集型服务器的cpu统计图:. 可以看到,CPU总使用率不高,平均1.3%,max到5.6%,虽然大部分都耗在了iowait上,但才百分之五左右,应该还没到瓶颈吧.

中国程序员的收入瓶颈

- - ITeye博客
程序员的收入是广受关注的问题,很多人从业3~5年之后就会遇到这个收入瓶颈. 尽管物价不断上涨,程序员尤其是初、中级程序员的收入不升反降. 即使上次在某个文章中看到有中国第一程序员之称的某位,月薪也只有3万,尽管这个数字已经很高了,但这个“中国第一”,也只有众多小型软件企业总监级别的收入而已. 为什么这么高水平的技术人员在公司中的位置仍然显得与日俱降.

用 Wireshark 分析 TCP 吞吐瓶颈

- - 卡瓦邦噶!
Debug 网络质量的时候,我们一般会关注两个因素:延迟和吞吐量(带宽). 延迟比较好验证,Ping 一下或者 mtr 一下就能看出来. 这篇文章分享一个 debug 吞吐量的办法. 看重吞吐量的场景一般是所谓的长肥管道(Long Fat Networks, LFN, rfc7323). 吞吐量没有达到网络的上限,主要可能受 3 个方面的影响:.

被雅虎收购之后… …

- Ray ma - 36氪
托尔斯泰说:“幸福的家庭总是相似的,不幸的家庭各有各的不幸. ”然而,对于Flickr、Delicious、MyBlogLog和Upcoming来说,他们的不幸却是一样的:被“创业杀手”雅虎收购. 收购时买卖双方都非常愉快,表示将为用户带来更加美好的东西. 然而,现实摆在那里,他们忙于克服整合问题、无休止的会议和压抑的官僚主义,使得产品发展缓慢,甚至停滞不前.