百度高级架构师马如悦：我的Hadoop2.0

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了百度高级架构师马如悦：我的Hadoop2.0，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含4898字，纯文字阅读大概需要7分钟。

内容图文

当计算任务越来越多，作业提交越来越多，企业普通的做法是，在原有的系统架构上，不停地往上堆积硬件或者加服务器。的确，hadoop设计上的优秀和可扩展性可以方便的让集群管理员对集群增删机器，所以当集群计算资源紧缺，又有空闲的机器可用时，集群管理员很

当计算任务越来越多，作业提交越来越多，企业普通的做法是，在原有的系统架构上，不停地往上堆积硬件或者加服务器。的确，hadoop设计上的优秀和可扩展性可以方便的让集群管理员对集群增删机器，所以当集群计算资源紧缺，又有空闲的机器可用时，集群管理员很容易想到给集群加机器来解决这个问题，因为集群的计算槽位增多了，Jobtracker能调度的槽位也多了，集群里能并行的map数和reduce数也增多了。

但是，当集群规模扩大到一定程度，比如3000台，再往上加机器，用户会发现，计算作业没有增多，本应该运行的更快的作业并没有比预期的快，有时候甚至跟加机器前跑的一样，集群的槽位是变多了，但是被调度用来跑 task的槽位总是用不满，jobtracker的cpu使用率始终保持100%，但是集群的计算槽位总是达不到饱和，即使集群在最繁忙的时候，槽位的使用率也只能达到比如60%，每一个时刻总有一部分的计算槽位是空闲的但是无法往上分配task任务。

这是雅虎Hadoop当前正面临的问题，Hadoop下一步在哪？百度的Hadoop架构又当如何扩展？这是摆在所有人面前的一个重要问题。

在CSDN 第九期的TUP活动上，百度的高级架构师马如悦为广大的CTO、技术主管们分析了百度的Hadoop 2.0，并就Hadoop在百度的未来发展作了精彩的陈述。

百度高级系统架构师马如悦

百度hadoop集群现状

据马如悦透露，百度从07年开始使用Hadoop做离线处理，目前有80%的Hadoop集群用作日志处理，同雅虎面临的相同麻烦是，Hadoop在百度经过5、6年发展之后，也已经走到了一个岔路口，在百度每天的作业数千万，平均一个作业可以按1000来算，每天的数据处理量在6TB左右，以Hadoop目前所能支持的服务器性能上限来看，大大低于了系统的需求。

他表示，“目前百度的Hadoop服务器规模是1万多台，已经超过了Yahoo和Facebook，明年计划将达到2万台。以百度目前如果的Hadoop服务器配置来看，12GB内存最大能支持3000多万系统文件，如果扩张到10亿文件，内存将占用380GB。”

目前百度的服务器大部分是价格在两到三万元左右的，标配12个1TB硬盘，32GB内存，没有RAID卡，没有采用高端的服务器。但是随着Hadoop集群规模扩张后，成本正呈线性上升，能耗、散热、还有一些不需要的设备，都是需要解决的成本问题。因此百度这几年一直在走服务器定制化的路线，以此降低整个系统成本。

百度Hadoop 2.0解决方案

实际上，Yahoo最近已经公开了一篇博客，关于Hadoop重构的问题，在博客中，雅虎写道，集群的规模达到4000台机器的时候，Hadoop正遭遇到扩展性的瓶颈，MapReduce的JobTracker需要彻底改革，以解决其可扩展性，内存消耗，线程模型，可靠性和性能的几个缺陷。

而百度也在对其Hadoop集群进行技术革新，马如悦称其为Hadoop 2.0。

“百度的目标是10万节点，而且需要充分考虑跨机房部署的问题”，他表示“百度和雅虎在Hadoop上的研发区别在于，雅虎需要不断对Hadoop的扩展上限进行研发，而百度的研发着力点在于如果已经到了规模上限，那么需要进行拆分。”

马如悦谈到，Hadoop2.0主要是解决Hadoop主节点的Scalability的问题。Scalability现在的问题，有3000多万文件，内存占用12GB。如果扩张10亿文件，内存占用380GB。负载的话，集群规模扩大后，这种压力是3000台左右。

“存储一般分为块式存储，做云计算公司挂在一些虚拟机，挂到本地作为本地系统。上面还有分布式对象存储，很多用来存储像淘宝图片都是用分布式对象去存储。上面是分布式文件系统可以做很多工作，用户应用起来会好很多，但是他的扩展性会差很多。”

“将存储设备拆分成两层进行分别管理”，马如悦说道“这是Hadoop 2.0解决方案的理论原理。为了解决Hadoop的扩展性问题，在数据存储上，百度专门设立了一个对账管理层，目的在于将文件对象管理服务做到水平扩展，当某一用户将数据放在上面后可以给一个唯一标识，用户可以有自己的选择，“对账管理层的关键在于文件对象管理服务可以实现水平扩展，但难点在于扩展性的问题”。

他表示，在此架构中，由于NameSpace（名称空间）全在文件对象管理中，因此到逻辑对象中的负载降了很多，这就很便于做未来的扩展性设计。

1、分布式存储对象是S3，这是没有树状结构的NameSpace，二层命名空间从kb到GB都可以实现支持，这是百度线上评估的负载，内存10亿文件，10亿快文件约66GB，目录约1GB。

2、原来90GB只能支持1亿文件，而现在66GB可以支持到10亿文件

3、大规模耗能操作放到了对象管理层之上，因为是水平扩展，所以压力不大。

4、Namespace只占容量的13.7%。

Hadoop并非万能

在马如悦看来，业界对于分布式存储架构还存在着一些误区，比如，大家通常认为Hadoop集群规模越大越好。

“Hadoop集群规模不是越大越好，Mapreduce的好处在于共享，资源利用充分，但实现的前提在于底层的HDFS副本的放置策略，目前来看，Hadoop的放置策略不是很好。1000台机器，如果同时宕掉三台，一定会有副本丢失，这是Hadoop不好的地方，如果从1000台服务器中挑选三台机器，会发现相同的块有三四个。这是HDFS不好的地方。”

“如果将1000台服务器分成十组，每组100台机器，建议用户不要将数据分布于所有机器上”，马如悦表示，“100台就可以满足副本文件的存储需求。如果三个机器放到任何一个组里都不会丢数据。但是对百度来说，一旦真的丢失数据——10G、20G问题都差不多，一样严重。平常三个副本宕机正好撞到在一个小组的几率毕竟很少，因此，Hadoop现有放置副本不是最好，假设放置均匀库，理想中放置副本是需要要随机放置的。”

而Hadoop目前另一个缺陷在于数据的层次化管理，很多数据读取很高，写入却很小，因此对数据的时效性要求很高，并且要求能海量处理几PB的数据，这是Hadoop目前不太容易实现的。

内容总结

以上是互联网集市为您收集整理的百度高级架构师马如悦：我的Hadoop2.0全部内容，希望文章能够帮你解决百度高级架构师马如悦：我的Hadoop2.0所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

---