写代码的人

Posts tagged ‘yahoo’

开源云计算:Yahoo的创新驱动力

经常有人问,Yahoo准备转向云吗?我们的回答是,不,我们已经是云了。 Yahoo不会提供Amazon或者 Google那样的公共云平台。但是,我们早就开始向数以亿计的用户提供个人云服务了:邮 箱、照片、金融服务等等。我们称之为个人云。

更重要的是 ,当业界目前更多地将云计算视为降低成本、节约能源手段的时候(这些当然也非常重要),在Yahoo,云计算已经成为一种关键性的创新驱动力。

作为全球最大的互联网公司之一,Yahoo正面临着巨大的技术挑战。公司自身拥有庞大的网络资产,超过9千万网页,6亿用户(仅Yahoo邮件就有超过3亿的用户),成百个关注点和背景各异的产品和服务,每天要通过分析一千 亿以上各种各样的事件:登录、提醒、广告点击、文章点击、论坛发贴、上传图片、打标签、购物车……每天的流量数据以PB计算,存储数据量更是以数百PB的速度增加 ……

怎样才能在如此大规模的平台上,快速从海量数据中提取有价值的信息,将最受欢迎的内容提供给对其最感兴趣的用户,满足各种各样个性化的使用模式?怎样在这种规模的平台上,将停运时间降至最低(在Yahoo,即使是短时的停运,损失都将高达数百万美元),满足用户不断变化的需求,提供更好的用户体验?怎样优化Yahoo的 现有产品与服务,提升广告商的满意度,从而提高公司的 收益?

应对这些挑战只能依靠创新,而创新又有赖于云计算 基础设施的支持。与其他公司不同的是,Yahoo在云计算方面采取了全面开源的战略。众所周知,Yahoo是开源云计算技术平台Hadoop的诞生地和主要支持力量。在过去 五年多时间里,Yahoo在Hadoop以及Pig、ZooKeeper、Hive、Howl、HBase和Oozie等相关开源项目中投入了大 约300人年,累计数千万美元,将Hadoop从一个有趣的原型发展为坚实的可扩展框架,产生了丰硕的成果。

Hadoop也已经成为Yahoo基础设施和许多重要业务流程(搜索、广告、反垃圾邮件、个性化等等)的核心组件。Hadoop在Yahoo内部已经广泛应用于多个生产环境, 涉及全球多个数据中心,超过4万台服务器(内含30万以上 的CPU核心),20多个集群。其中最大的集群包括4千台服务器,也是世界上规模最大的Hadoop集群。目前Hadoop支持着公司内部1000多个科研团队用户,每天超过20万个作业,每秒几万次请求。甚至可以说,在Yahoo各个网站上每一次点击背后都有Hadoop的功劳。Hadoop使Yahoo更多研发人员可以在更高的抽象层次工作,大大缩短了产品开发 周期,显著减少了人力和基础设施成本。

未来,Yahoo还将对Hadoop等云计算基础设施研发和社区支持继续投入。而且,我们正计划通过Hadoop和其他开源项目,将Yahoo内部所有的底层云计算基础架构逐步地全部开源。为什么我们这样大力支持开源?原因很简单,我们不认为这些云计算基础技术是什么差异化竞争优势,而且Yahoo已经从Hadoop活跃的开源社区中获益匪浅。

从Hadoop的成功故事中,我们可以总结以下几点开源的优势:

通过开源,Hadoop已经从一个内部技术成长为优秀而稳定的工业标准,从而避免了一般企业内专有技术经常遇到的被外部新标准逼向死胡同的问题。

通过开源,Hadoop社区在Yahoo之外出现了更多活跃用户,他们的贡献产生了许多对Yahoo也很重要的技术,比如HBase和Hive,最终节约了公司的成本。

通过开源,Yahoo公司能够从社区更容易地聘请到优秀的训练有素的人才,而且与许多伙伴的合作也更加顺畅。

更重要的是,通过开源,我们既能够以最经济高效地方式进行研发,实现自身的业务目标,又能够欣喜地看到自己的工作被成千上万的人用于远超出预期的各行各业,最终改变了世界,我们为此而深感自豪。

 

报告称必应1月全球市场份额首超雅虎

3月2日消息,据国外媒体报道,美国市场调查公司StatCounter日前发布一份搜索引擎市场调查报告。报告显示必应全球市场份额在今年1月份首次超越雅虎,并在2月份一直保持领先。

报告显示,必应全球市场份额在2月份达到4.37%,领先于雅虎的3.93%。谷歌则以89.94%的份额继续占据搜索引擎市场第一位。

但在美国市场,雅虎依旧以9.74%的市场份额领先于必应9.03%的份额。谷歌在美国的市场份额则为79.63%。在2009年7月,微软宣布必应将整合雅虎搜索技术,这一合作协议仅在美国、加拿大、澳大利亚、巴西以及墨西哥实行。

StatCounter CEO奥德汉·卡伦(Aodhan Cullen)表示,“必应在全球市场首次超越雅虎具有重要意义,但是要想撼动谷歌市场份额还是非常艰难的挑战。”卡伦还表示,“尽管谷歌2月份全球市场份额滑落到90%以下,但这并不表明谷歌在全球范围内失去其统治地位。”

原文链接:http://tech.163.com/11/0302/01/6U3TDDI9000915BF.html

 

雅虎计划重构 Hadoop-MapReduce,解决性能瓶颈

最近雅虎开发者博客发了一篇介绍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在处理大数据的能力提高到一个新水平。