特别报道：探秘Google数据中心内部运行

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取得的成就都引人瞩目。像纽约证券交易所和航空公司订票系统都使用大量的主干机服务器与软件，而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的业务数量级，这无疑是一个艰巨的挑战。毫无疑问，很多小公司正在羡慕的看着他们。