Google云计算架构剖析

Google拥有全球最大的搜索引擎，以及Google Maps、Google Earth、Gmail、YouTube等大规模业务。这些应用的共性在于数据量极其庞大，且要面向全球用户提供实时服务，因而Google必须解决海量数据存储和快速处理的问题。在长期的探索和实践中，Google研发出了一种让多大百万台的廉价计算机协同工作的技术，即云计算技术。Google云计算平台是建立在大量服务器集群上的，Node是最基本的处理单元，其总体技术架构如图1-7所示。在Google云计算平台的技术架构中，除了少量负责特定管理功能的节点(如GFS master、Chubby和Scheduler等)，所有的节点都是同构的，即同时运行BigTable Server、GFS chunkserver和MapReduce Job等核心功能模块。

图1-7 Google云计算系统系统架构图

Google云计算拥有分布式文件系统GFS、海量数据并行处理“MapReduce”技术、分布式锁服务Chubby、大规模分布式系统监控技术Dapper、海量非结构化数据存储技术BigTable、MySQL Sharding以及数据中心优化等关键技术。Google公司还于2008年推出了Google App Engine（GAE），即一个基于云环境的开发和部署平台。它将Google的基础设施以云服务的形式提供给用户，通过GAE用户可以直接在Google的全球分布式基础设施上开发并部署应用程序，而不用购买和维护硬件设施。下面对GFS、Mapreduce、BigTable三大核心技术以及GAE Web开发平台做简要介绍。

u   数据存储技术——GFS

网页搜索业务需要海量的数据存储，同时还需要满足高可用性、高可靠性和经济性等要求。为此，Google开发了分布式文件系统(google file system)。GFS支持海量数据处理，高并发访问、硬件故障自动恢复，并实现了一次写入、多次读取的数据处理模式。

GFS由一个master和大量chunkserver构成，如图1-8所示。master存放文件系统的所有元数据，包括名字空间、存取控制、文件分块信息、文件块的位置信息等。为了保证数据的可靠性，GFS文件系统采用了冗余存储的方式。同时，为了保证数据的一致性，对于数据的所有修改需要在所有的备份上进行，并用版本号的方式来确保所有备份处于一致的状态。为避免大量读操作使master成为系统瓶颈，客户端不直接通过master读取数据，而是从master获取目标数据块的位置信息后，直接和chunkserver交互进行读操作。GFS的写操作将控制信号和数据流分开，即客户端在获取master的写授权后，将数据传输给所有的数据副本，在所有的数据副本都收到修改的数据后，客户端才发出写请求控制信号，在所有的数据副本更新完数据后，由主副本向客户端发出写操作完成控制信号。通过服务器端和客户端的联合设计，GFS对应用支持达到了性能与可用性的最优化。

 

图1-8 GFS系统架构

u  数据管理技术——BigTable

由于Google的许多应用需要管理大量的结构化以及半结构化数据，需要对海量数据进行存储、处理与分析，且数据的读操作频率远大于数据的更新频率等，为此Google开发了弱一致性要求的大规模数据库系统——BigTable。BigTable针对数据读操作进行了优化，采用基于列存储的分布式数据管理模式以提高数据读取效率。BigTable的基本元素是行、列、记录板和时间戳，如图1-9所示。

图1-9 BigTable基本元素

BigTable中的数据项按照行关键字的字典序排列，每行动态地划分到Tablet中，每个服务器节点Tablet Server负责管理大约100个记录板。时间戳是一个64位的整数，表示数据的不同版本。列簇是若干列的集合，BigTable中的存取权限控制在列簇的粒度进行。BigTable系统依赖于集群系统的底层结构，一个是分布式的集群任务调度器，一个是GFS文件系统，另一个是分布式锁服务Chubby，如图1-10所示。Chubby是一个非常健壮的粗粒度锁，BigTable使用Chubby来保存Root Tablet的指针，并使用一台服务器作为主服务器，用来保存和操作元数据。当客户端读取数据时，用户首先从Chubby Server中获得Root Tablet的位置信息，并从中读取相应的元数据表Metadata Tablet的位置信息，接着从Metadata Tablet中读取包含目标数据位置信息的User Table的位置信息，然后从该User Table中读取目标数据的位置信息项。BigTable的主服务器除了管理元数据之外，还负责对Tablet Server进行远程管理与负载调配。客户端通过编程接口与主服务器进行控制通信以获得元数据，与Tablet Server进行数据通信，而具体的读写请求则由Tablet Server负责处理。BigTable是客户端和服务器端的联合设计，使得性能能够最大程度地符合应用的需求。

图1-10 BigTable的存储服务体系结构

u  编程模型——MapReduce

Google构造了MapReduce编程框架来支持并行计算，应用程序编写人员只需将精力放在应用程序本身，关于如何通过分布式的集群来支持并行计算，包括可靠性和可扩展性，则交由平台来处理，从而保证了后台复杂的并行执行和任务调度向用户和编程人员透明。

MapReduce是一种处理和产生大规模数据集的编程模型，同时也是一种高效的任务调度模型，它通过“Map(映射)”和“Reduce(化简)”这样两个简单的概念来构成运算基本单元，程序员在Map函数中指定对各分块数据的处理过程，在Reduce函数中指定如何对分块数据处理的中间结果进行归约，就能完成分布式的并行程序开发。当在集群上运行Map-Reduce程序时，程序员不需要关心如何将输入的数据分块、分配和调度，同时系统还将处理集群内节点失败以及节点间通信的管理等。图1-11给出了一个MapReduce程序的具体执行过程。

图1-11 MapReduce程序的具体执行过程

MapReduce模型具有很强的容错性，当worker节点出现错误时，只需要将该worker节点屏蔽在系统外等待修复，并将该worker上执行的程序迁移到其他worker上重新执行，同时将该迁移信息通过master发送给需要该节点处理结果的节点。MapReduce使用检查点的方式来处理master出错失败的问题，当master出现错误时，可以根据最近的一个检查点重新选择一个节点作为master并由此检查点位置继续运行。

u  Google App Engine

Google App Engine是一个PasS平台，它可以让开发人员在Google的基础架构上开发、部署和运行网络应用程序。在GAE上构建和维护应用程序将变得简单，并且应用可以根据访问量和数据存储需求的增长轻松地进行扩展。

GAE的整体架构如图1-12所示，它主要由应用运行时环境（App Engine Runtime）、沙盒（Security Sandbox）、Google账户、App Engine服务、数据库等组件构成。应用运行时环境提供了对应用的基本支持，使应用可以在GAE上正常运行，目前支持Python和Java语言。沙盒（即安全运行环境），可以保证每个应用程序能够安全地隔离运行。GAE还为开发者提供了一个DataStore服务，它是一个分布式存储数据库，可以随着应用规模的增长自动扩展。AppEngine服务则为用户提供了网页抓取、图像API、邮件API、MemcacheAPI、用户API（Google账户）、数据库API等基本功能，极大地降低了应用开发的难度。

图1-12 Google App Engine 整体架构