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的业务数量级，这无疑是一个艰巨的挑战。毫无疑问，很多小公司正在羡慕的看着他们。