一、Google 的云计算平台        Google的硬件条件优势，大型的数据中心、搜索引擎的支柱应用，促进Google云计算迅速发展。Google的云计算主要由MapReduce、Google文件系统(GFS)、BigTable组成。它们是Google内部云计算基础平台的3个主要部分。Google 还构建其他云计算组件，包括一个领域描述语言以及分布式锁服务机制等。Sawzall是一种建立在MapReduce基础上的领域语言，专门用于大规模的信息处理。Chubby是一个高可用、分布式数据锁服务，当有机器失效时，Chubby使用Paxos算法来保证备份。

（1）Google File System 文件系统

　　为了满足Google迅速增长的数据处理需求，Google设计并实现了Google文件系统（GFS，Google File System）。GFS与过去的分布式文件系统拥有许多相同的目标，例如性能、可伸缩性、可靠性以及可用性。然而，它的设计还受到Google应用负载和技术环境的影响。主要体现在以下四个方面:

　　1. 集群中的节点失效是一种常态，而不是一种异常。由于参与运算与处理的节点数目非常庞大，通常会使用上千个节点进行共同计算，因此，每时每刻总会有节点处在失效状态。需要通过软件程序模块，监视系统的动态运行状况，侦测错误，并且将容错以及自动恢复系统集成在系统中。

　　2. Google系统中的文件大小与通常文件系统中的文件大小概念不一样，文件大小通常以G字节计。另外文件系统中的文件含义与通常文件不同，一个大文件可能包含大量数目的通常意义上的小文件。所以，设计预期和参数，例如I/O操作和块尺寸都要重新考虑。

　　3. Google文件系统中的文件读写模式和传统的文件系统不同。在Google应用（如搜索）中对大部分文件的修改，不是覆盖原有数据，而是在文件尾追加新数据。对文件的随机写是几乎不存在的。对于这类巨大文件的访问模式，客户端对数据块缓存失去了意义，追加操作成为性能优化和原子性（把一个事务看做是一个程序。它要么被完整地执行，要么完全不执行）保证的焦点。

　　4. 文件系统的某些具体操作不再透明，而且需要应用程序的协助完成，应用程序和文件系统API的协同设计提高了整个系统的灵活性。例如，放松了对GFS一致性模型的要求，这样不用加重应用程序的负担，就大大简化了文件系统的设计。还引入了原子性的追加操作，这样多个客户端同时进行追加的时候，就不需要额外的同步操作了。

（2）MapReduce分布式编程环境

　　为了让内部非分布式系统方向背景的员工能够有机会将应用程序建立在大规模的集群基础之上，Google还设计并实现了一套大规模数据处理的编程规范Map/Reduce系统。这样，非分布式专业的程序编写人员也能够为大规模的集群编写应用程序而不用去顾虑集群的可靠性、可扩展性等问题。应用程序编写人员只需要将精力放在应用程序本身，而关于集群的处理问题则交由平台来处理。

　　Map/Reduce通过“Map（映射）”和“Reduce（化简）”这样两个简单的概念来参加运算，用户只需要提供自己的Map函数以及Reduce函数就可以在集群上进行大规模的分布式数据处理。

（3）分布式大规模数据库管理系统BigTable

　　构建于上述两项基础之上的第三个云计算平台就是Google关于将数据库系统扩展到分布式平台上的BigTable系统。很多应用程序对于数据的组织还是非常有规则的。一般来说，数据库对于处理格式化的数据还是非常方便的，但是由于关系数据库很强的一致性要求，很难将其扩展到很大的规模。为了处理Google内部大量的格式化以及半格式化数据，Google构建了弱一致性要求的大规模数据库系统BigTable。