Google云计算核心技术大揭秘

分布式基础设施：GFS，Chubby 和 Protocol Buffer。 分布式大规模数据处理：MapReduce 和 Sawzall。 分布式数据库技术：BigTable 和数据库 Sharding。 数据中心优化技术：数据中心高温化，12V 电池和服务器整合。 分布式基础设施 GFS 由于搜索引擎需要处理海量的数据， 所以 Google 的两位创始人 Larry Page 和 Sergey Brin 在创业初期设计一套名为“BigFiles”的文件系统，而 GFS（全称为“Google File System”）这套分布式文件系统则是“BigFiles”的延续。 首先，介绍它的架构，GFS 主要分为两类节点：
1. Master 节点：主要存储与数据文件相关的元数据，而不是 Chunk（数据块）。元数据包括一个能将 64 位标签映射到数据块的位置及其组成文件的表格，数据块副本位置和哪个进程正在读写特定的数据块等。 还有 Master 节点会周期性地接收从每个 Chunk 节点来的更新（”Heart-beat”）来让元数据保持最新状 态。 2. Chunk 节点：顾名思义，肯定用来存储 Chunk，数据文件通过被分割为每个默认大小为 64MB 的 Chunk 的方式存储，而且每个 Chunk 有唯一一个 64 位标签，并且每个 Chunk 都会在整个分布式系统被复制多 次，默认为 3 次。
下图就是 GFS 的架构图：
图 1. GFS 的架构图

接着，在设计上，GFS 主要有八个特点：
1. 大文件和大数据块：数据文件的大小普遍在 GB 级别，而且其每个数据块默认大小为 64MB，这样做的好 处是减少了元数据的大小，能使 Master 节点能够非常方便地将元数据放置在内存中以提升访问效率。 2. 操作以添加为主：因为文件很少被删减或者覆盖，通常只是进行添加或者读取操作，这样能充分考虑到硬 盘线性吞吐量大和随机读写慢的特点。 3. 支持容错：首先，虽然当时为了设计方便，采用了单 Master 的方案，但是整个系统会保证每个 Master 都会有其相对应的复制品，以便于在 Master 节点出现问题时进行切换。其次，在 Chunk 层，GFS 已经 在设计上将节点失败视为常态，所以能非常好地处理 Chunk 节点失效的问题。 4. 高吞吐量：虽然其单个节点的性能无论是从吞吐量还是延迟都很普通，但因为其支持上千的节点，所以总 的数据吞吐量是非常惊人的。 5. 保护数据：首先，文件被分割成固定尺寸的数据块以便于保存，而且每个数据块都会被系统复制三份。 6. 扩展能力强：因为元数据偏小，使得一个 Master 节点能控制上千个存数据的 Chunk 节点。 7. 支持压缩：对于那些稍旧的文件，可以通过对它进行压缩，来节省硬盘空间，并且压缩率非常惊人，有时 甚至接近 90%。 8. 用户空间：虽然在用户空间运行在运行效率方面稍差，但是更便于开发和测试，还有能更好利用 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. MapReduce 的运行机制
接下来，将根据上图来举一个 MapReduce 的例 子：比如，通过搜索 Spider 将海量的 Web 页 面抓取到本地的 GFS 集群中，然后 Index 系统将会对这个 GFS 集群中多个数据 Chunk 进行平 行的 Map 处理，生成多个 Key 为 URL，value 为 html 页面的键值对（Key-Value Map）， 接着系统会对这些刚生成的键值对进行 Shuffle（清理），之后系统会通过 Reduce 操作来根据相 同的 key 值（也就是 URL）合并这些键 值对。