作者:手机用户2502924457 | 来源:互联网 | 2023-10-14 12:19
当计算任务越来越多,作业提交越来越多,企业普通的做法是,在原有的系统架构上,不停地往上堆积硬件或者加服务器。的确,hadoop设计上的优秀和可扩展性可以方便的
当计算任务越来越多,作业提交越来越多,企业普通的做法是,在原有的系统架构上,不停地往上堆积硬件或者加服务器。的确,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目前不太容易实现的。