Google的云计算平台
Google的云计算技术实际上是针对Google特定的网络应用程序而定制的。针对内部网络数据规模超大的特点，Google提出了一整套基于分布式并行集群方式的基础架构，利用软件的能力来处理集群中经常发生的节点失效问题。
从2003年开始，Google连续几年在计算机系统研究领域的最顶级会议与杂志上发表论文，揭示其内部的分布式数据处理方法，向外界展示其使用的云计算核心技术。从其近几年发表的论文来看，Google使用的云计算基础架构模式包括四个相互独立又紧密结合在一起的系统。包括Google建立在集群之上的文件系统Google File System，针对Google应用程序的特点提出的Map/Reduce编程模式，分布式的锁机制Chubby以及Google开发的模型简化的大规模分布式数据库BigTable。
Google File System 文件系统
为了满足Google迅速增长的数据处理需求，Google设计并实现了Google文件系统(GFS，Google File System)。GFS与过去的分布式文件系统拥有许多相同的目标，例如性能、可伸
缩性、可靠性以及可用性。然而，它的设计还受到Google应用负载和技术环境的影响。主要体现在以下四个方面:
1. 集群中的节点失效是一种常态，而不是一种异常。由于参与运算与处理的节点数目非常庞大，通常会使用上千个节点进行共同计算，因此，每时每刻总会有节点处在失效状态。需要通过软件程序模块，监视系统的动态运行状况，侦测错误，并且将容错以及自动恢复系统集成在系统中。
2. Google系统中的文件大小与通常文件系统中的文件大小概念不一样，文件大小通常以G字节计。另外文件系统中的文件含义与通常文件不同，一个大文件可能包含大量数目的通常意义上的小文件。所以，设计预期和参数，例如I/O操作和块尺寸都要重新考虑。
没有过不去的坎
3. Google文件系统中的文件读写模式和传统的文件系统不同。在Google应用(如搜索)中对大部分文件的修改，不是覆盖原有数据，而是在文件尾追加新数据。对文件的随机写是几乎不存在的。对于这类巨大文件的访问模式，客户端对数据块缓存失去了意义，追加操作成为性能优化和原子性(把一个事务看做是一个程序。它要么被完整地执行，要么完全不执行)保证的焦点。
4. 文件系统的某些具体操作不再透明，而且需要应用程序的协助完成，应用程序和文件系统API的协同设计提高了整个系统的灵活性。例如，放松了对GFS一致性模型的要求，这样不用加重应用程序的负担，就大大简化了文件系统的设计。还引入了原子性的追加操作，这样多个客户端同时进行追加的时候，就不需要额外的同步操作了。
总之，GFS是为Google应用程序本身而设计的。据称，Google已经部署了许多GFS集群。有的集群拥有超过1000个存储节点，超过300T的硬盘空间，被不同机器上的数百个客户端连续不断地频繁访问着。
图1给出了Google File System的系统架构，一个GFS集群包含一个主服务器和多个块服务器，被多个客户端访问。文件被分割成固定尺寸的块。在每个块创建的时候，服务器分配给它一个不变的、全球惟一的64位块句柄对它进行标识。块服务器把块作为linux文件保存在本地硬盘上，并根据指定的块句柄和字节范围来读写块数据。为了保证可靠性，每个块都会复制到多个块服务器上，缺省保存三个备份。主服务器管理文件系统所有的元数据，包括名字空间、访问控制信息和文件到块的映射信息，以及块当前所在的位置。GFS客户端代码被嵌入到每个程序里，它实现了Google文件系统 API，帮助应用程序与主服务器和
块服务器通信，对数据进行读写。客户端跟主服务器交互进行元数据操作，但是所有的数据操作的通信都是直接和块服务器进行的。客户端提供的访问接口类似于POSIX接口，但有一定的修改，并不完全兼容POSIX标准。通过服务器端和客户端的联合设计，Google File System能够针对它本身的应用获得最大的性能以及可用性效果。
MapReduce分布式编程环境
为了让内部非分布式系统方向背景的员工能够有机会将应用程序建立在大规模的集群基础之上，Google还设计并实现了一套大规模数据处理的编程规范Map/Reduce系统。这样，非分布式专业的程序编写人员也能够为大规模的集群编写应用程序而不用去顾虑集群的可靠性、可扩展性等问题。应用程序编写人员只需要将精力放在应用程序本身，而关于集群的处理问题则交由平台来处理。
good luck什么意思
Map/Reduce通过“Map(映射)”和“Reduce(化简)”这样两个简单的概念来参加运算，用户只需要提供自己的Map函数以及Reduce函数就可以在集群上进行大规模的分布式数据处理。
2199什么意思 据称，Google的文本索引方法，即搜索引擎的核心部分，已经通过Map Reduce的方法进行了改写，获得了更加清晰的程序架构。在Google内部，每天有上千个Map Reduce的应用程序在运行。
关于MapReduce的详细介绍
MapReduce是Google提出的一个软件架构，用于大规模数据集（大于1TB）的并行运算。概念"Map（映射）"和"Reduce（化简）"，和他们的主要思想，都是从函数式编程语言借来的，还有从矢量编程语言借来的特性。
当前的软件实现是指定一个Map（映射）函数，用来把一组键值对映射成一组新的键值对，指定并发的Reduce（化简）函数，用来保证所有映射的键值对中的每一个共享相同的键组。
映射和化简
pick
boker 简单说来，一个映射函数就是对一些独立元素组成的概念上的列表（例如，一个测试成绩的列表）的每一个元素进行指定的操作（比如，有人发现所有学生的成绩都被高估了一
phd是什么意思分，他可以定义一个“减一”的映射函数，用来修正这个错误。）。事实上，每个元素都是被独立操作的，而原始列表没有被更改，因为这里创建了一个新的列表来保存新的答案。这就是说，Map操作是可以高度并行的，这对高性能要求的应用以及并行计算领域的需求非常有用。
而化简操作指的是对一个列表的元素进行适当的合并（继续看前面的例子，如果有人想知道班级的平均分该怎么做？他可以定义一个化简函数，通过让列表中的奇数(odd)或偶数(even)元素跟自己的相邻的元素相加的方式把列表减半，如此递归运算直到列表只剩下一个元素，然后用这个元素除以人数，就得到了平均分）。虽然他不如映射函数那么并行，但是因为化简总是有一个简单的答案，大规模的运算相对独立，所以化简函数在高度并行环境下也很有用。
childhood 分布和可靠性
MapReduce通过把对数据集的大规模操作分发给网络上的每个节点实现可靠性；每个节点会周期性的把完成的工作和状态的更新报告回来。如果一个节点保持沉默超过一个预设的时间间隔，主节点（类同Google档案系统中的主服务器）记录下这个节点状态为死亡，
并把分配给这个节点的数据发到别的节点。每个操作使用命名文件的原子操作以确保不会发生并行线程间的冲突；当文件被改名的时候，系统可能会把他们复制到任务名以外的另一个名字上去。（避免副作用）。
化简操作工作方式很类似，但是由于化简操作在并行能力较差，主节点会尽量把化简操作调度在一个节点上，或者离需要操作的数据尽可能近的节点上了；这个特性可以满足Google的需求，因为他们有足够的带宽，他们的内部网络没有那么多的机器。
用途
在Google，MapReduce用在非常广泛的应用程序中，包括“分布grep，分布排序，web连接图反转，每台机器的词矢量，web访问日志分析，反向索引构建，文档聚类，机器学习，基于统计的机器翻译……”值得注意的是，MapReduce实现以后，它被用来重新生成Google的整个索引，并取代老的ad hoc程序去更新索引。
MapReduce会生成大量的临时文件，为了提高效率，它利用Google档案系统来管理和访问这些文件。
2011年，Google发表Snappy压缩函式库开源项目；Snappy是Google MapReduce的一部分，以减少Network I/O 或 Disk I/O提升效能。
proceed
分布式大规模数据库管理系统BigTable
构建于上述两项基础之上的第三个云计算平台就是Google关于将数据库系统扩展到分布式平台上的BigTable系统。很多应用程序对于数据的组织还是非常有规则的。一般来说，数据库对于处理格式化的数据还是非常方便的，但是由于关系数据库很强的一致性要求，很难将其扩展到很大的规模。为了处理Google内部大量的格式化以及半格式化数据，Google构建了弱一致性要求的大规模数据库系统BigTable。据称，现在有很多Google的应用程序建立在BigTable之上，例如Search History、Maps、Orkut和RSS阅读器等。
图2给出了在BigTable模型中的数据模型。数据模型包括行列以及相应的时间戳，所有的数据都存放在表格中的单元里。BigTable的内容按照行来划分，将多个行组成一个小表，保存到某一个服务器节点中。这一个小表就被称为Tablet。美国女议员
以上是Google内部云计算基础平台的三个主要部分，除了这三个部分之外，Google还建立了分布式程序的调度器，分布式的锁服务等一系列相关的云计算服务平台。
benefited
BigTable: 数据库实现的典范
一般来说，数据库的技术专家大多数时间都在研究一些具体的算法等问题，对一个数据库系统（或一个数据存储系统）从总体上如何实现的问题却不太做考虑，这方面的学术资料也就比较少。
当要开发一个新的数据库系统或数据存储系统时，最难决定的就是各种技术应该如何选择的问题。比如，应该使用面向属性还是面向记录的存储模型、应该使用基于锁还是多版本的并发控制、应该对数据进行本地更新还是将修改记录在别处、如何进行数据分区、如何做索引、需要提供什么样的并发控制和事务功能等等。每个地方都有很多选择，即使你知道这些选择是如何实现的，各种选择有什么优缺点，你还是很难选择。但今天看了BigTable的论文后发现BigTable实在算得上是数据库实现的典范，BigTable中采用的所有技术都来自于数据库领域的已有研究成果，但BigTable最成功的是很多技术的选择、取舍都恰到好处。
BigTable中最重要的选择是将数据存储分为两部分，主体部分是不可变的，以SSTable的格式存储在GFS中，最近的更新则存储在内存（称为memtable）中。读操作需要根据SSTable和memtable还综合决定要读取的数据的值。这一技术在数据库系统中不太常用，但其实也有很多研究。最早的应该是LSM Tree，这一索引结构会在内存中缓存对传统B+树索引的更新，隔一段时间后再将内存中的更新合并后主索引中去，在合并的时候就可以对键值进行排序，这样就将对索引的随机更新转换为顺序更新，提高了性能。Stonebraker设计的C-Store系统也采用这一架构。这一技术的使用案例还有很多，比如MySQL的InnoDB
存储引擎中inrt buffer，MySQL新的事务型存储引擎Falcon（只缓存记录更新，不缓存索引更新）。新的SSD硬盘的顺序写性能很高，但随机写性能很差，因此SSD更新时也不会更新原数据，而是将新数据顺序写在一块集中的位置，这就是来自于数据库System R中的影子页技术。使用不可变的存储的好处是多方面的，可以使用非常激进的压缩算法，可以不需要考虑并发控制的问题。假如BigTable不采用这一选择，整个系统的设计都会完全不同，而且实现将会严重复杂化。
