热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

百度高级架构师马如悦分享:我对Hadoop2.0的见解与经验

当计算任务越来越多,作业提交越来越多,企业普通的做法是,在原有的系统架构上,不停地往上堆积硬件或者加服务器。的确,hadoop设计上的优秀和可扩展性可以方便的

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


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

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

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

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

百度高级架构师马如悦:我的Hadoop2.0 - 文章图片

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

百度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需要彻底改革,以解决其可扩展性,内存消耗,线程模型,可靠性和性能的几个缺陷。

百度高级架构师马如悦:我的Hadoop2.0 - 文章图片

百度高级架构师马如悦:我的Hadoop2.0 - 文章图片

百度高级架构师马如悦:我的Hadoop2.0 - 文章图片

而百度也在对其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%。

百度高级架构师马如悦:我的Hadoop2.0 - 文章图片

百度高级架构师马如悦:我的Hadoop2.0 - 文章图片

Hadoop并非万能

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

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

百度高级架构师马如悦:我的Hadoop2.0 - 文章图片

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

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


推荐阅读
  • 第二章:Kafka基础入门与核心概念解析
    本章节主要介绍了Kafka的基本概念及其核心特性。Kafka是一种分布式消息发布和订阅系统,以其卓越的性能和高吞吐量而著称。最初,Kafka被设计用于LinkedIn的活动流和运营数据处理,旨在高效地管理和传输大规模的数据流。这些数据主要包括用户活动记录、系统日志和其他实时信息。通过深入解析Kafka的设计原理和应用场景,读者将能够更好地理解其在现代大数据架构中的重要地位。 ... [详细]
  • 从0到1搭建大数据平台
    从0到1搭建大数据平台 ... [详细]
  • 本文通过思维导图的形式,深入解析了大型网站技术架构的核心原理与实际案例。首先,探讨了大型网站架构的演化过程,从单体应用到分布式系统的转变,以及各阶段的关键技术和挑战。接着,详细分析了常见的大型网站架构模式,包括负载均衡、缓存机制、数据库设计等,并结合具体案例进行说明。这些内容不仅有助于理解大型网站的技术实现,还能为实际项目提供宝贵的参考。 ... [详细]
  • 在《Cocos2d-x学习笔记:基础概念解析与内存管理机制深入探讨》中,详细介绍了Cocos2d-x的基础概念,并深入分析了其内存管理机制。特别是针对Boost库引入的智能指针管理方法进行了详细的讲解,例如在处理鱼的运动过程中,可以通过编写自定义函数来动态计算角度变化,利用CallFunc回调机制实现高效的游戏逻辑控制。此外,文章还探讨了如何通过智能指针优化资源管理和避免内存泄漏,为开发者提供了实用的编程技巧和最佳实践。 ... [详细]
  • Python ATM与购物车项目实战:深入解析三层架构设计
    本文详细解析了Python ATM与购物车项目的三层架构设计,重点介绍了MVC(Model-View-Controller)模式的应用。在用户界面层,系统通过图形化界面与用户进行交互,接收并处理用户的输入数据,随后将这些数据传递给控制层进行进一步处理。该层不仅负责展示信息,还承担了用户请求的初步处理任务。 ... [详细]
  • 本文深入探讨了NoSQL数据库的四大主要类型:键值对存储、文档存储、列式存储和图数据库。NoSQL(Not Only SQL)是指一系列非关系型数据库系统,它们不依赖于固定模式的数据存储方式,能够灵活处理大规模、高并发的数据需求。键值对存储适用于简单的数据结构;文档存储支持复杂的数据对象;列式存储优化了大数据量的读写性能;而图数据库则擅长处理复杂的关系网络。每种类型的NoSQL数据库都有其独特的优势和应用场景,本文将详细分析它们的特点及应用实例。 ... [详细]
  • 在前一篇文章《Hadoop》系列之“踽踽独行”(二)中,我们详细探讨了云计算的核心概念。本章将重点转向物联网技术,全面解析其基本原理、应用场景及未来发展前景。通过深入分析物联网的架构和技术栈,我们将揭示其在智能城市、工业自动化和智能家居等领域的广泛应用潜力。此外,还将讨论物联网面临的挑战,如数据安全和隐私保护等问题,并展望其在未来技术融合中的重要角色。 ... [详细]
  • 作为140字符的开创者,Twitter看似简单却异常复杂。其简洁之处在于仅用140个字符就能实现信息的高效传播,甚至在多次全球性事件中超越传统媒体的速度。然而,为了支持2亿用户的高效使用,其背后的技术架构和系统设计则极为复杂,涉及高并发处理、数据存储和实时传输等多个技术挑战。 ... [详细]
  • Python 数据可视化实战指南
    本文详细介绍如何使用 Python 进行数据可视化,涵盖从环境搭建到具体实例的全过程。 ... [详细]
  • Spark与HBase结合处理大规模流量数据结构设计
    本文将详细介绍如何利用Spark和HBase进行大规模流量数据的分析与处理,包括数据结构的设计和优化方法。 ... [详细]
  • Zookeeper作为Apache Hadoop生态系统中的一个重要组件,主要致力于解决分布式应用中的常见数据管理难题。它提供了统一的命名服务、状态同步服务以及集群管理功能,有效提升了分布式系统的可靠性和可维护性。此外,Zookeeper还支持配置管理和临时节点管理,进一步增强了其在复杂分布式环境中的应用价值。 ... [详细]
  • Hadoop中NameNode与SecondaryNameNode的运行机制解析
    在Hadoop架构中,NameNode中的元数据存储位置是一个关键问题。通常,元数据会存储在内存中以提高访问效率,因为频繁的磁盘随机访问会导致性能下降。此外,NameNode还会定期将元数据的快照保存到磁盘上,以确保数据的持久性和恢复能力。SecondaryNameNode则负责定期合并这些快照和编辑日志,进一步增强系统的稳定性和可靠性。 ... [详细]
  • 在搭建Hadoop集群以处理大规模数据存储和频繁读取需求的过程中,经常会遇到各种配置难题。本文总结了作者在实际部署中遇到的典型问题,并提供了详细的解决方案,帮助读者避免常见的配置陷阱。通过这些经验分享,希望读者能够更加顺利地完成Hadoop集群的搭建和配置。 ... [详细]
  • Hadoop 2.6 主要由 HDFS 和 YARN 两大部分组成,其中 YARN 包含了运行在 ResourceManager 的 JVM 中的组件以及在 NodeManager 中运行的部分。本文深入探讨了 Hadoop 2.6 日志文件的解析方法,并详细介绍了 MapReduce 日志管理的最佳实践,旨在帮助用户更好地理解和优化日志处理流程,提高系统运维效率。 ... [详细]
  • 构建高可用性Spark分布式集群:大数据环境下的最佳实践
    在构建高可用性的Spark分布式集群过程中,确保所有节点之间的无密码登录是至关重要的一步。通过在每个节点上生成SSH密钥对(使用 `ssh-keygen -t rsa` 命令并保持默认设置),可以实现这一目标。此外,还需将生成的公钥分发到所有节点的 `~/.ssh/authorized_keys` 文件中,以确保节点间的无缝通信。为了进一步提升集群的稳定性和性能,建议采用负载均衡和故障恢复机制,并定期进行系统监控和维护。 ... [详细]
author-avatar
手机用户2502924457
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有