当计算任务越来越多，作业提交越来越多，企业普通的做法是，在原有的系统架构上，不停地往上堆积硬件或者加服务器。的确，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目前不太容易实现的。