按：此为客座博文系列。投稿人吴朱华曾在IBM中国研究院从事与云计算相关的研究，现在正致力于研究云计算技术。 本系列文章基于公开资料对Google App Engine的实现机制这个话题进行深度探讨。在切入Google App Engine之前，首先会对Google的核心技术和其整体架构进行分析，以帮助大家之后更好地理解Google App Engine的实现。 本篇将主要介绍Google的十个核心技术，而且可以分为四大类： 分布式基础设施：GFS、Chubby 和 Protocol Buffer。 分布式大规模数据处理：MapReduce 和 Sawzall。 分布式数据库技术：BigTable 和数据库 Sharding。 数据中心优化技术：数据中心高温化、12V电池和服务器整合。 分布式基础设施 GFS 由于搜索引擎需要处理海量的数据，所以Google的两位创始人Larry Page和Sergey Brin在创业初期设计一套名为”BigFiles”的文件系统，而GFS（全称为”Google File System”）这套分布式文件系统则是”BigFiles”的延续。 首先，介绍它的架构，GFS主要分为两类节点： Master节点：主要存储与数据文件相关的元数据，而不是Chunk（数据块）。元数据包括一个能将64位标签映射到数据块的位置及其组成文件的表格，数据块副本位置和哪个进程正在读写特定的数据块等。还有Master节点会周期性地接收从每个Chunk节点来的更新（”Heart-beat”）来让元数据保持最新状态。 Chunk节点：顾名思义，肯定用来存储Chunk，数据文件通过被分割为每个默认大小为64MB的Chunk的方式存储，而且每个Chunk有唯一一个64位标签，并且每个Chunk都会在整个分布式系统被复制多次，默认为3次。 下图就是GFS的架构图： 图1. GFS的架构图（参片[15]） 接着，在设计上，GFS主要有八个特点： 大文件和大数据块：数据文件的大小普遍在GB级别，而且其每个数据块默认大小为64MB，这样做的好处是减少了元数据的大小，能使Master节点能够非常方便地将元数据放置在内存中以提升访问效率。 操作以添加为主：因为文件很少被删减或者覆盖，通常只是进行添加或者读取操作，这样能充分考虑到硬盘线性吞吐量大和随机读写慢的特点。 支持容错：首先，虽然当时为了设计方便，采用了单Master的方案，但是整个系统会保证每个Master都会有其相对应的复制品，以便于在Master节点出现问题时进行切换。其次，在Chunk层，GFS已经在设计上将节点失败视为常态，所以能非常好地处理Chunk节点失效的问题。 高吞吐量：虽然其单个节点的性能无论是从吞吐量还是延迟都很普通，但因为其支持上千的节点，所以总的数据吞吐量是非常惊人的。 保护数据：首先，文件被分割成固定尺寸的数据块以便于保存，而且每个数据块都会被系统复制三份。 扩展能力强：因为元数据偏小，使得一个Master节点能控制上千个存数据的Chunk节点。 支持压缩：对于那些稍旧的文件，可以通过对它进行压缩，来节省硬盘空间，并且压缩率非常惊人，有时甚至接近90%。 用户空间：虽然在用户空间运行在运行效率方面稍差，但是更便于开发和测试，还有能更好利用Linux的自带的一些POSIX API。 现在Google内部至少运行着200多个GFS集群，最大的集群有几千台服务器，并且服务于多个Google服务，比如Google搜索。但由于GFS主要为搜索而设计，所以不是很适合新的一些Google产品，比YouTube、Gmail和更强调大规模索引和实时性的Caffeine搜索引擎等，所以Google已经在开发下一代GFS，代号为”Colossus”，并且在设计方面有许多不同，比如：支持分布式Master节点来提升高可用性并能支撑更多文件，Chunk节点能支持1MB大小的chunk以支撑低延迟应用的需要。 Chubby 简单的来说，Chubby 属于分布式锁服务，通过 Chubby，一个分布式系统中的上千个client都能够对于某项资源进行”加锁”或者”解锁”，常用于BigTable的协作工作，在实现方面是通过对文件的创建操作来实现”加锁”，并基于著名科学家Leslie Lamport的Paxos算法。 Protocol Buffer Protocol Buffer，是Google内部使用一种语言中立、平台中立和可扩展的序列化结构化数据的方式，并提供 Java、C++ 和 Python 这三种语言的实现，每一种实现都包含了相应语言的编译器以及库文件，而且它是一种二进制的格式，所以其速度是使用 XML 进行数据交换的10倍左右。它主要用于两个方面：其一是RPC通信，它可用于分布式应用之间或者异构环境下的通信。其二是数据存储方面，因为它自描述，而且压缩很方便，所以可用于对数据进行持久化，比如存储日志信息，并可被Map Reduce程序处理。与Protocol Buffer比较类似的产品还有Facebook的 Thrift ，而且 Facebook 号称Thrift在速度上还有一定的优势。 分布式大规模数据处理 MapReduce 首先，在Google数据中心会有大规模数据需要处理，比如被网络爬虫（Web Crawler）抓取的大量网页等。由于这些数据很多都是PB级别，导致处理工作不得不尽可能的并行化，而Google为了解决这个问题，引入了MapReduce这个编程模型，MapReduce是源自函数式语言，主要通过”Map（映射）”和”Reduce（化简）”这两个步骤来并行处理大规模的数据集。Map会先对由很多独立元素组成的逻辑列表中的每一个元素进行指定的操作，且原始列表不会被更改，会创建多个新的列表来保存Map的处理结果。也就意味着，Map操作是高度并行的。当Map工作完成之后，系统会先对新生成的多个列表进行清理（Shuffle）和排序，之后会这些新创建的列表进行Reduce操作，也就是对一个列表中的元素根据Key值进行适当的合并。 下图为MapReduce的运行机制： 图2.
See the original post here:
探索Google App Engine背后的奥秘(1)–Google的核心技术
