Google揭开了内部工作方式的神秘面纱。

  Google这个搜索巨人很少暴露其数据中心,但在上周,Google研究员Jeff Dean在Google I/O会议上揭秘了它的部分运行情况。

  一方面,Google使用了一些常规服务器,另外一方面,Google将1800台服务器组成了集群,这些集群服务器负责Google日常的搜索处理任务,这部分服务器的数量大约是700到1000台。

  Google并未透露拥有多少台服务器,但我们估计的数量有成千上万。Dean透露,Google将40台服务器编为一个集群,而在全球范围,Google拥有36个数据中心。每个数据中心有150个服务器集群,这意味着Google拥有的服务器数量超过20万台,不过Google服务器的数量应该远远超过这一数字,而且每天都在增长。

  无论有多少台服务器,Google取得的成就都引人瞩目。像纽约证券交易所和航空公司订票系统都使用大量的Unix服务器与软件,而Google主要使用自己的技术。

  可以肯定,许多服务器厂商对此会感到酸溜溜的,但Google明显认为,将自己的技术命运掌握在自己手中最安全。Google搜索产品与用户体验部门副总裁Marissa Mayer说,创始人Larry Page鼓励在公司中形成一种“健康的,对不可能说不”的气氛。

  为了应对Google这样的搜索规模,需要让每台机器的性能发挥到极致。虽然服务器厂商们对其高端机型中的容错性能津津乐道,但Google更乐意将钱投到容错软件上。

  Dean说:“我们的观点是,不可靠的硬件数量最好是可靠机型的两倍。你需要将可靠性放在软件层面。假如你运行1万台机器,那么每天都有一些死机。”

  Dean说,在每个服务器集群运行的头一年,一般有1千台机器会发生故障;数千块硬盘会出问题;一个“电源分配单元”(PDU)将坏掉,令500到1000台机器当机6小时;20个服务器机架将出现故障,造成40到80台机器从网络上掉线;5个服务器机架将变得不稳定,这使得机架上的服务器处理的一半信息包失去响应;一个服务器集群需要重新连接,这将影响5%的机器,影响的时间跨度一般为2天。服务器集群有50%的过热可能性,过热会让绝大多数服务器在5分钟内当机,并且耗时1到2天来重新恢复。

  虽然Google使用了一般的硬件设备,但在软件上却没有使用寻常的软件。Google要求英特尔提供专门定制的电路板。Dean还透露,Google目前为每40个服务器组成的机架配备一个机箱,而不是象一般情况那样为每个服务器配备一个机箱。

  对于服务器本身,Google喜欢多核芯片配置。尽管许多软件公司正在努力适应多核芯片时代的来临,但Google对这种芯片使用起来得心应手。Google不得不让自己的技术适应有限的硬件资源架构,因此,他们已经进入了并行处理时代。

  Dean说:“我们确实喜欢多核机器。对我们来说,多核机器用少量的机器实现了良好的连接性能。对我们而言,它们更容易使用。”

  尽管Google需要对搜索以及其它服务进行快速响应,并行处理能够完成这一任务需要,虽然有可能单个线程的速度并不快。

  Dean说:“单个线程的性能对我们来说确实没有多大关系。我们将重点主要放在并行处理问题上。”

  Google如何让这些普通的硬件发挥作用?

  答案是:用软件。

  Dean阐述了Google软件的三大核心元素:Google文件系统(GFS);Google大表(BigTable:是Google一种对于半结构化数据进行分布存储与访问的接口或服务);MapReduce算法(它是Google开发的C++编程工具,用于大于1TB数据的大规模数据集并行运算)。尽管Google依靠许多开源项目实现了企业的腾飞,但Google对这三套核心元素秘而不宣。

  Google文件系统处于这三个元素的最底层,它负责许多服务器,机器的数据存储工作。很多Google文件系统的体积都异常庞大,有好几个petabyte规模(1 petabyte相当于1百万gigabytes)。有200多个服务器集群运行有Google文件系统,其中很多集群包含了上千台机器。

  Google文件系统至少在三台名为“块服务器”(chunkservers)上存储大体积数据(一般为64MB);如果一台块服务器发生故障,那么主服务器会负责将数据恢复到新的区域。Dean说:“至少在存储层面,机器故障的处理由Google文件系统来完成。”

  为了给全部这些数据提供一些结构,Google使用了大表。象甲骨文和IBM公司的商业数据库在这里发挥不了作用,因为这些产品无法满足Google的需要,Dean说,如果要使用商业数据库的话,价格将非常的昂贵。

  Google从2004年开始设计大表,现在已经在Google 70多个项目中使用,包括Google地图,Google地球,Blogger,Google Print和核心的搜索目录。Dean说,大表管理的最大一个数据表格有6 petabytes大小,覆盖上千台机器。

  2003年,Google编写了MapReduce的第一个版本,这种算法给了Google公司一条让自己数据发挥作用的途径来。例如,MapReduce能够找出一个词语在Google搜索目录中出现的次数;一系列网页中特定词语出现的频率;链接到某个特定网站的所有网站数量等。

  有了MapReduce,Google可以编写出一个索引目录,迅速显示出与特定词语相关的网页出来。Dean说:“为了在可以接受的时间内完成这一工作,你需要在上千台机器上进行处理。”

  Google对MapReduce软件的使用正在增多。2004年,MapReduce运行了2.9万个工作任务,到2007年,已有220万个工作由MapReduce来完成。同期,MapReduce对于一个工作的平均运行响应时间从634秒下降到了395秒,MapReduce任务的数据产出量从193 terabytes上升到了14018 terabytes。

  Dean说,在任何一天,Google运行有大约10万个MapReduce工作任务;每项任务大约会占用4百台服务器,时间大约是5到10分钟。

  这是一个有趣的数学计算。假设服务器只完成MapReduce工作,每台服务器一次只完成一项任务,那么大约要耗时24小时,如果这些工作任务每个耗时5分钟,这意味着MapReduce任务要占用大约13.9万台服务器。如果耗时7.5分钟,那么需要的服务器数量增加到20.8万台;如果需要10分钟,服务器的数量增加至27.8万台。

  和Google文件系统一样,MapReduce的设计也要考虑服务器的当机问题。

  Dean说:“当一台机器当机,主服务器会了解分配给这台机器的任务是什么,然后直接指定其它机器来完成这一任务。”

  MapReduce的可靠性曾经在一个由1800台服务器组成的集群进行维护时经受住了严格考验。工作人员将其中80台机器拔掉,其它1720台机器承担起了80台机器的处理任务。Dean说:“它运行有一些慢,但全部完成了任务。”

  在2004年,Dean表示,曾经有一个1800台机器组成集群,其中1600台当机了,但整个系统经受住了考验。

  尽管Google的数据中心取得了很大的成功,但公司并不满足,他们有很长远的改进发展计划。

  对于一般的企业来说,他们只需要考虑将工作任务从一台服务器转移到另外一台,但Google面临的工作量级不同,他们希望能够将工作任务由一个数据中心自动转移到另外一个中心。

  Dean说:“我们希望自己的下一代架构是一种能够超越单个机器的系统。”

  考虑到Google的业务数量级,这无疑是一个艰巨的挑战。毫无疑问,很多小公司正在羡慕的看着他们。