1.Google的核心技术按:此为客座博文系列。投稿人吴朱华曾在IBM中国研究院从事与云计算相关的研究,现在正致力于研究云计算技术。本系列文章基于公开资料对GoogleAppEngine的实现机制这个话题进行深度探讨。在切入GoogleAppEngine之前,首先会对Google的核心技术和其整体架构进行分析,以帮助大家之后更好地理解GoogleAppEngine的实现。本篇将主要介绍Google的十个核心技术,而且可以分为四大类:分布式基础设施:GFS、Chubby和ProtocolBuffer。分布式大规模数据处理:MapReduce和Sawzall。分布式数据库技术:BigTable和数据库Sharding。数据中心优化技术:数据中心高温化、12V电池和服务器整合。1.1分布式基础设施1.1.1GFS由于搜索引擎需要处理海量的数据,所以Google的两位创始人LarryPage和SergeyBrin在创业初期设计一套名为BigFiles的文件系统,而GFS(全称为GoogleFileSystem)这套分布式文件系统则是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的自带的一些POSIXAPI。现在Google内部至少运行着200多个GFS集群,最大的集群有几千台服务器,并且服务于多个Google服务,比如Google搜索。但由于GFS主要为搜索而设计,所以不是很适合新的一些Google产品,比YouTube、Gmail和更强调大规模索引和实时性的Caffeine搜索引擎等,所以Google已经在开发下一代GFS,代号为Colossus,并且在设计方面有许多不同,比如:支持分布式Master节点来提升高可用性并能支撑更多文件,Chunk节点能支持1MB大小的chunk以支撑低延迟应用的需要。1.1.2Chubby简单的来说,Chubby属于分布式锁服务,通过Chubby,一个分布式系统中的上千个client都能够对于某项资源进行加锁或者解锁,常用于BigTable的协作工作,在实现方面是通过对文件的创建操作来实现加锁,并基于著名科学家LeslieLamport的Paxos算法。1.1.3ProtocolBufferProtocolBuffer,是Google内部使用一种语言中立、平台中立和可扩展的序列化结构化数据的方式,并提供Java、C++和Python这三种语言的实现,每一种实现都包含了相应语言的编译器以及库文件,而且它是一种二进制的格式,所以其速度是使用XML进行数据交换的10倍左右。它主要用于两个方面:其一是RPC通信,它可用于分布式应用之间或者异构环境下的通信。其二是数据存储方面,因为它自描述,而且压缩很方便,所以可用于对数据进行持久化,比如存储日志信息,并可被MapReduce程序处理。与ProtocolBuffer比较类似的产品还有Facebook的Thrift,而且Facebook号称Thrift在速度上还有一定的优势。1.2分布式大规模数据处理1.2.1MapReduce首先,在Google数据中心会有大规模数据需要处理,比如被网络爬虫(WebCrawler)抓取的大量网页等。由于这些数据很多都是PB级别,导致处理工作不得不尽可能的并行化,而Google为了解决这个问题,引入了MapReduce这个编程模型,MapReduce是源自函数式语言,主要通过Map(映射)和Reduce(化简)这两个步骤来并行处理大规模的数据集。Map会先对由很多独立元素组成的逻辑列表中的每一个元素进行指定的操作,且原始列表不会被更改,会创建多个新的列表来保存Map的处理结果。也就意味着,Map操作是高度并行的。当Map工作完成之后,系统会先对新生成的多个列表进行清理(Shuffle)和排序,之后会这些新创建的列表进行Reduce操作,也就是对一个列表中的元素根据Key值进行适当的合并。下图为MapReduce的运行机制:图2.MapReduce的运行机制(参[19])接下来,将根据上图来举一个MapReduce的例子:比如,通过搜索Spider将海量的Web页面抓取到本地的GFS集群中,然后Index系统将会对这个GFS集群中多个数据Chunk进行平行的Map处理,生成多个Key为URL,value为html页面的键值对(Key-ValueMap),接着系统会对这些刚生成的键值对进行Shuffle(清理),之后系统会通过Reduce操作来根据相同的key值(也就是URL)合并这些键值对。最后,通过MapReduce这么简单的编程模型,不仅能用于处理大规模数据,而且能将很多繁琐的细节隐藏起来,比如自动并行化,负载均衡和机器宕机处理等,这样将极大地简化程序员的开发工作。MapReduce可用于包括分布grep,分布排序,web访问日志分析,反向索引构建,文档聚类,机器学习,基于统计的机器翻译,生成Google的整个搜索的索引等大规模数据处理工作。Yahoo也推出MapReduce的开源版本Hadoop,而且Hadoop在业界也已经被大规模使用。1.2.2SawzallSawzall可以被认为是构建在MapReduce之上的采用类似Java语法的DSL(Domain-SpecificLanguage),也可以认为它是分布式的AWK。它主要用于对大规模分布式数据进行筛选和聚合等高级数据处理操作,在实现方面,是通过解释器将其转化为相对应的MapReduce任务。除了Google的Sawzall之外,yahoo推出了相似的Pig语言,但其语法类似于SQL。1.3分布式数据库技术1.3.1BigTable由于在Google的数据中心存储PB级以上的非关系型数据时候,比如网页和地理数据等,为了更好地存储和利用这些数据,Google开发了一套数据库系统,名为BigTable。BigTable不是一个关系型的数据库,它也不支持关联(Join)等高级SQL操作,取而代之的是多级映射的数据结构,并是一种面向大规模处理、容错性强的自我管理系统,拥有TB级的内存和PB级的存储能力,使用结构化的文件来存储数据,并每秒可以处理数百万的读写操作。什么是多级映射的数据结构呢?就是一个稀疏的,多维的,排序的Map,每个Cell由行关键字,列关键字和时间戳三维定位.Cell的内容是一个不解释的字符串,比如下表存储每个网站的内容与被其他网站的反向连接的文本。反向的URLcom.cnn.是这行的关键字;contents列存储网页内容,每个内容有一个时间戳,因为有两个反向连接,所以archor的ColumnFamily有两列:anchor:cnnsi.com和anchhor:my.look.ca。ColumnFamily这个概念,使得表可以轻松地横向扩展。下面是它具体的数据模型图:图3.BigTable数据模型图(参[4])在结构上,首先,BigTable基于GFS分布式文件系统和Chubby分布式锁服务。其次BigTable也分为两部分:其一是Master节点,用来处理元数据相关的操作并支持负载均衡。其二是tablet节点,主要用于存储数据库的分片tablet,并提供相应的数据访问,同时Tablet是基于名为SSTable的格式,对压缩有很好的支持。图4.BigTable架构图(参[15])BigTable正在为Google六十多种产品和项目提供存储和获取结构化数据的支撑平台,其中包括有GooglePrint、Orkut、GoogleMaps、GoogleEarth和Blogger等,而且Google至少运行着500个BigTable集群。随着Google内部服务对需求的不断提高和技术的不断地发展,导致原先的BigTable已经无法满足用户的需求,而Google也正在开发下一代BigTable,名为Spanner(扳手),它主要有下面这些BigTable所无法支持的特性:支持多种数据结构,比如table,familie,group和coprocessor等。基于分层目录和行的细粒度的复制和权限管理。支持跨数据中心的强一致性和弱一致性控制。基于Paxos算法的强一致性副本同步,并支持分布式事务。提供许多自动化操作。强大的扩展能力,能支持百万台服务器级别的集群。用户可以自定义诸如延迟和复制次数等重要参数以适应不同的需求。1.3.2数据库ShardingSharding就是分片的意思,虽然非关系型数据库比如BigTable在Google的世界中占有非常重要的地位,但是面对传统OLTP应用,比如广告系统,Google还是采用传统的关系型数据库技术,也就是MySQL,同时由于Google所需要面对流量非常巨大,所以Google在数据库层采用了分片(Sharding)的水平扩展(ScaleOut)解决方案,分片是在传统垂直扩展(ScaleUp)的分区模式上的一种提升,主要通过时间,范围和面向服务等方式来将一个大型的数据库分成多片,并且这些数据片可以跨越多个数据库和服务器来实现水平扩展。Google整套数据库分片技术主要有下面这些优点:扩展性强:在Google生产环境中,已经有支持上千台服务器的MySQL分片集群。吞吐量惊人:通过巨大的MySQL分片集群能满足巨量的查询请求。全球备份:不仅在一个数据中心还是在全球的范围,Google都会对MySQL的分片数据进行备份,这样不仅能保护数据,而且方便扩展。在实现方面,主要可分为两块:其一是在MySQLInnoDB基础上添加了数据库分片的技术。其二是在ORM层的Hibernate的基础上也添加了相关的分片技术,并支持虚拟分片(VirtualShard)来便于开发和管理。同时Google也已经将这两方面的代码提交给相关组织。1.4数据中心优化技术1.4.1数据中心高温化大中型数据中心的PUE(PowerUsageEffectiveness)普遍在2左右,也就是在服务器等计算设备上耗