1、本篇将主要介绍 Google的十个核心技术，而且可以分为四大类：1. 1. 分布式基础设施：GFS，Chubby 和 Protocol Buffer。 2. 分布式大规模数据处理：MapReduce 和 Sawzall。 3. 分布式数据库技术：BigTable 和数据库 Sharding。 4. 数据中心优化技术：数据中心高温化，12V 电池和服务器整合。 分布式基础设施GFS由 于搜索引擎需要处理海量的数据，所以 Google的两位创始人 Larry Page和 Sergey Brin在创业初期设计一套名为“BigFiles”的文件系统，而GFS（全称为“Google File Syste
2、m”）这套分布式文件系统则是“BigFiles”的延续。首先，介绍它的架构，GFS 主要分为两类节点：1. 1. Master 节点：主要存储与数据文件相关的元数据，而不是Chunk（数据块）。元数据包括一个能将 64位标签映射到数据块的位置及其组成文件的表格，数据块副本位 置和哪个进程正在读写特定的数据块等。还有 Master节点会周期性地接收从每个Chunk节点来的更新（”Heart- beat”）来让元数据保持最新状态。 2. Chunk节点：顾名思义，肯定用来存储 Chunk，数据文件通过被分割为每个默认大小为 64MB的 Chunk的方式存储，而且每个 Chunk有唯一一个 64位标
3、签，并且每个 Chunk都会在整个分布式系统被复制多次，默认为 3次。 下图就是 GFS的架构图：图 1. GFS的架构图（参片15）接着，在设计上，GFS 主要有八个特点：1. 1. 大文件和大数据块：数据文件的大小普遍在 GB级别，而且其每个数据块默认大小为 64MB，这样做的好处是减少了元数据的大小，能使 Master节点能够非常方便地将元数据放置在内存中以提升访问效率。 2. 操作以添加为主：因为文件很少被删减或者覆盖，通常只是进行添加或者读取操作，这样能充分考虑到硬盘线性吞吐量大和随机读写慢的特点。 3. 支 持容错：首先，虽然当时为了设计方便，采用了单 Master的方案，但是整个
4、系统会保证每个 Master都会有其相对应的复制品，以便于在 Master 节点出现问题时进行切换。其次，在 Chunk层，GFS已经在设计上将节点失败视为常态，所以能非常好地处理Chunk节点失效的问题。 4. 高吞吐量：虽然其单个节点的性能无论是从吞吐量还是延迟都很普通，但因为其支持上千的节点，所以总的数据吞吐量是非常惊人的。 5. 保护数据：首先，文件被分割成固定尺寸的数据块以便于保存，而且每个数据块都会被系统复制三份。 6. 扩展能力强：因为元数据偏小，使得一个 Master节点能控制上千个存数据的 Chunk节点。 7. 支持压缩：对于那些稍旧的文件，可以通过对它进行压缩，来节省硬盘
5、空间，并且压缩率非常惊人，有时甚至接近 90%。 8. 用户空间：虽然在用户空间运行在运行效率方面稍差，但是更便于开发和测试，还有能更好利用 Linux的自带的一些 POSIX API。 现 在 Google内部至少运行着 200多个 GFS集群，最大的集群有几千台服务器，并且服务于多个 Google服务，比如 Google 搜索。但由于 GFS主要为搜索而设计，所以不是很适合新的一些 Google产品，比 YouTube、Gmail 和更强调大规模索引和实时性的 Caffeine 搜索引擎等，所以 Google已经在开发下一代GFS，代号为“Colossus”，并且在设计方面有许多不同，比如
6、：支持分布式 Master节点来提升高可用性并能支撑更多文件，chunk 节点能支持 1MB大小的chunk以支撑低延迟应用的需要。Chubby简 单的来说，Chubby 属于分布式锁服务，通过 Chubby，一个分布式系统中的上千个 client都能够对于某项资源进行“加锁”或者“解锁”，常用于 BigTable的协作工作，在实现方面是通过对文件的创建操作来实现“加锁”，并基于著名科学家 Leslie Lamport的 Paxos算法。Protocol BufferProtocol Buffer，是 Google内部使用一种语言中立，平台中立和可扩展的序列化结构化数据的方式，并提供 java
7、、c+ 和 python这三种语言的实现，每一种实现都包含了相应语言的编译器以及库文件，而且它是一种二进制的格式，所以其速度是使用 xml进行数据交换的 10 倍左右。它主要用于两个方面：其一是 RPC通信，它可用于分布式应用之间或者异构环境下的通信。其二是数据存储方面，因为它自描述，而且压缩很方便，所以 可用于对数据进行持久化，比如存储日志信息，并可被 Map Reduce程序处理。与 Protocol Buffer比较类似的产品还有 Facebook的 Thrift，而且 Facebook号称 Thrift在速度上还有一定的优势。分布式大规模数据处理MapReduce首 先，在 Googl
8、e数据中心会有大规模数据需要处理，比如被网络爬虫（Web Crawler）抓取的大量网页等。由于这些数据很多都是 PB级别，导致处理工作不得不尽可能的并行化，而 Google为了解决这个问题，引入了 MapReduce 这个编程模型，MapReduce 是源自函数式语言，主要通过“Map（映射）“和“Reduce（化简）“这两个步骤来并行处理大规 模的数据集。Map 会先对由很多独立元素组成的逻辑列表中的每一个元素进行指定的操作，且原始列表不会被更改，会创建多个新的列表来保存 Map的处理结 果。也就意味着，Map 操作是高度并行的。当 Map工作完成之后，系统会先对新生成的多个列表进行清理（
9、Shuffle）和排序，之后会这些新创建的列表 进行 Reduce操作，也就是对一个列表中的元素根据 Key值进行适当的合并。下图为 MapReduce的运行机制：图 2. MapReduce的运行机制（参19）接 下来，将根据上图来举一个 MapReduce的例子：比如，通过搜索 Spider将海量的 Web页面抓取到本地的 GFS 集群中，然后 Index系统将会对这个 GFS集群中多个数据 Chunk进行平行的 Map处理，生成多个 Key为 URL，value 为html页面的键值对 （Key-Value Map），接着系统会对这些刚生成的键值对进行 Shuffle（清理），之后系统会
10、通过 Reduce操作来根据相同的 key值（也就是 URL）合并这些键 值对。最后，通过 MapReduce这么简单的编程模型，不仅能用于处理大规模数据，而且能将很多繁琐的细节隐 藏起来，比如自动并行化，负载均衡和机器宕机处理等，这样将极大地简化程序员的开发工作。MapReduce 可用于包括“分布grep，分布排序，web 访问日志分析，反向索引构建，文档聚类，机器学习，基于统计的机器翻译，生成 Google的整个搜索的索引“等大规模数据处理工作。Yahoo也推出 MapReduce 的开源版本 Hadoop，而且 Hadoop在业界也已经被大规模使用。SawzallSawzall 可以被
11、认为是构建在 MapReduce之上的采用类似 Java语法的DSL（Domain-Specific Language），也可以认为它是分布式的 AWK。它主要用于对大规模分布式数据进行筛选和聚合等高级数据处理操作，在实现方面，是通过解释器将其转化 为相对应的 MapReduce任务。除了 Google的 Sawzall之外，yahoo 推出了相似的 Pig语言，但其语法类似于 SQL。分布式数据库技术BigTable由 于在 Google的数据中心存储 PB级以上的非关系型数据时候，比如网页和地理数据等，为了更好地存储和利用这些数据，Google 开发了一套数据库系 统，名为“BigTabl
12、e”。BigTable 不是一个关系型的数据库，它也不支持关联（join）等高级 SQL操作，取而代之的是多级映射的数据结 构，并是一种面向大规模处理、容错性强的自我管理系统，拥有 TB级的内存和 PB级的存储能力，使用结构化的文件来存储数据，并每秒可以处理数百万的读写操 作。什么是多级映射的数据结构呢？就是一个稀疏的，多维的，排序的 Map，每个Cell由行关键字，列关键字和时间戳三维定位Cell 的 内容是一个不解释的字符串，比如下表存储每个网站的内容与被其他网站的反向连接的文本。 反向的 URL n.www是这行的关键字；contents 列存储网页内容，每个内容有一个时间戳，因为有两个
13、反向连接，所以 archor的 Column Family有两列：anchor: 和 anchhor:my.look.ca。Column Family 这个概念，使得表可以轻松地横向扩展。下面是它具体的数据模型图：图 3. BigTable数据模型图（参4）在 结构上，首先，BigTable 基于 GFS分布式文件系统和 Chubby分布式锁服务。其次 BigTable也分为两部分：其一是 Master节点，用来 处理元数据相关的操作并支持负载均衡。其二是 tablet节点，主要用于存储数据库的分片tablet，并提供相应的数据访问，同时 tablet 是基于名为 SSTable的格式，对压缩
14、有很好的支持。图 4. BigTable架构图（参15）BigTable 正在为 Google六十多种产品和项目提供存储和获取结构化数据的支撑平台，其中包括有 Google Print， Orkut，Google Maps，Google Earth 和Blogger等，而且 Google至少运行着 500个 BigTable集群。随着 Google内部服务对需求的不断提高和技术的不断地发展，导致原先的BigTable已经无法满足用户的需求，而 Google 也正在开发下一代 BigTable，名为“Spanner（扳手）”，它主要有下面这些 BigTable所无法支持的特性：1. 1. 支持多
15、种数据结构，比如 table，familie，group 和coprocessor等。 2. 基于分层目录和行的细粒度的复制和权限管理。 3. 支持跨数据中心的强一致性和弱一致性控制。 4. 基于 Paxos算法的强一致性副本同步，并支持分布式事务。 5. 提供许多自动化操作。 6. 强大的扩展能力，能支持百万台服务器级别的集群。 7. 用户可以自定义诸如延迟和复制次数等重要参数以适应不同的需求。 数据库 ShardingSharding 就是分片的意思，虽然非关系型数据库比如 BigTable在 Google的世界中占有非常重要的地位，但是面对传统 OLTP应用，比如广告系 统，Google
16、还是采用传统的关系型数据库技术，也就是 MySQL，同时由于 Google所需要面对流量非常巨大，所以 Google在数据库层采用了分 片（Sharding）的水平扩展（Scale Out）解决方案，分片是在传统垂直扩展（Scale Up）的分区模式上的一种提升，主要通过时间，范围和面向服务等方式来将一个大型的数据库分成多片，并且这些数据片可以跨越多个数据库和服务器来实现水平 扩展。Google整套数据库分片技术主要有下面这些优点：1. 1. 扩展性强：在 Google生产环境中，已经有支持上千台服务器的MySQL分片集群。 2. 吞吐量惊人：通过巨大的 MySQL分片集群能满足巨量的查询请求
17、。3. 全球备份：不仅在一个数据中心还是在全球的范围，Google 都会对 MySQL的分片数据进行备份，这样不仅能保护数据，而且方便扩展。 在 实现方面，主要可分为两块：其一是在 MySQL InnoDB基础上添加了数据库分片的技术。其二是在 ORM层的 Hibernate的基础上也添加了相关的分片技术，并支持虚拟分片（Virtual Shard）来便于开发和管理。同时 Google也已经将这两方面的代码提交给相关组织。数据中心优化技术数据中心高温化大 中型数据中心的 PUE（Power Usage Effectiveness）普遍在 2左右，也就是在服务器等计算设备上耗 1度电，在空调等辅
18、助设备上也要消耗一度电。对一些非常出色的数据中心，最多也 就能达到 1.7，但是 Google通过一些有效的设计使部分数据中心到达了业界领先的 1.2，在这些设计当中，其中最有特色的莫过于数据中心高温化，也就 是让数据中心内的计算设备运行在偏高的温度下，Google 的能源方面的总监 Erik Teetzel在谈到这点的时候说：“普通的数据中心在 70华氏度（21 摄氏度）下面工作，而我们则推荐 80华氏度（27摄氏度）“。但是在提高数据中心 的温度方面会有两个常见的限制条件：其一是服务器设备的崩溃点，其二是精确的温度控制。如果做好这两点，数据中心就能够在高温下工作，因为假设数据中心的 管理员
19、能对数据中心的温度进行正负 1/2度的调节，这将使服务器设备能在崩溃点 5度之内工作，而不是常见的20度之内，这样既经济，又安全。还有，业界传 言 Intel为 Google提供抗高温设计的定制芯片，但云计算界的顶级专家 James Hamilton认为不太可能，因为虽然处理器也非常惧怕热量，但是与内存和硬盘相比还是强很多，所以处理器在抗高温设计中并不是一个核心因素。同时他也 非常支持使数据中心高温化这个想法，而且期望将来数据中心甚至能运行在 40摄氏度下，这样不仅能节省空调方面的成本，而且对环境也很有利。12V电池由 于传统的 UPS在资源方面比较浪费，所以 Google在这方面另辟蹊径，采
20、用了给每台服务器配一个专用的 12V电池的做法来替换了常用的 UPS，如果主电 源系统出现故障，将由该电池负责对服务器供电。虽然大型 UPS可以达到 92%到 95%的效率，但是比起内置电池的 99.99%而言是非常捉襟见肘的，而且由于能量守恒的原因，导致那么未被 UPS充分利用的电力会被转化成热能，这将导致用于空调的能耗相应地攀升，从而 走入一个恶性循环。同时在电源方面也有类似的“神来之笔”，普通的服务器电源会同时提供 5V和 12V的直流电。但是Google设计的服务器电源只输出 12V 直流电，必要的转换在主板上进行，虽然这种设计会使主板的成本增加 1美元到 2美元，但是它不仅能使电源能在接近其峰值容量的情况下运行，而且在铜线 上传输电流时效率更高。服务器整合谈 到虚拟化的杀手锏时，第一个让人想到肯定是服务器整合，而且普遍能实现1:8的整合率来降低各方面的成本。有趣的是，Google 在硬件方面也引入类似服 务器整合的想法，它的做法是在一个机箱大小的空间内放置两台服务器，这些做的好处有很多，首先，减小了占地面积。其次，通过让两台服务器共享诸如电源等设 备，来降低设备和能源等方面的投入。http:/
