云计算的概念,发展现状,实现机制,Google云计算原理

 

 第1章  绪论

很少有一种技术能够像“云计算”这样，在短短的两年间就产生巨大的影响力。Google、亚马逊、IBM和微软等IT巨头们以前所未有的速度和规模推动云计算技术和产品的普及，一些学术活动迅速将云计算提上议事日程，支持和反对的声音不绝于耳。那么，云计算到底是什么？发展现状如何？它的实现机制是什么？它与网格计算是什么关系？。本章将分析这些问题，目的是帮助读者对云计算形成一个初步认识。

1.1  云计算的概念

云计算（CloudComputing）是在2007年第3季度才诞生的新名词，但仅仅过了半年多，其受到关注的程度就超过了网格计算（Grid Computing），如图1-1所示。

图1-1 云计算和网格计算在Google中的搜索趋势

然而，对于到底什么是云计算，至少可以找到100种解释，目前还没有公认的定义。本书给出一种定义，供读者参考。

云计算是一种商业计算模型，它将计算任务分布在大量计算机构成的资源池上，使用户能够按需获取计算力、存储空间和信息服务。

这种资源池称为“云”。“云”是一些可以自我维护和管理的虚拟计算资源，通常是一些大型服务器集群，包括计算服务器、存储服务器和宽带资源等。云计算将计算资源集中起来，并通过专门软件实现自动管理，无需人为参与。用户可以动态申请部分资源，支持各种应用程序的运转，无需为烦琐的细节而烦恼，能够更加专注于自己的业务，有利于提高效率、降低成本和技术创新。云计算的核心理念是资源池，这与早在2002年就提出的网格计算池（ComputingPool）的概念非常相似^[3][4]。网格计算池将计算和存储资源虚拟成为一个可以任意组合分配的集合，池的规模可以动态扩展，分配给用户的处理能力可以动态回收重用。这种模式能够大大提高资源的利用率，提升平台的服务质量。

之所以称为“云”，是因为它在某些方面具有现实中云的特征：云一般都较大；云的规模可以动态伸缩，它的边界是模糊的；云在空中飘忽不定，无法也无需确定它的具体位置，但它确实存在于某处。之所以称为“云”，还因为云计算的鼻祖之一亚马逊公司将大家曾经称为网格计算的东西，取了一个新名称“弹性计算云”（Elastic Computing Cloud），并取得了商业上的成功。

有人将这种模式比喻为从单台发电机供电模式转向了电厂集中供电的模式。它意味着计算能力也可以作为一种商品进行流通，就像煤气、水和电一样，取用方便，费用低廉。最大的不同在于，它是通过互联网进行传输的。

云计算是并行计算（ParallelComputing）、分布式计算（DistributedComputing）和网格计算（GridComputing）的发展，或者说是这些计算科学概念的商业实现。云计算是虚拟化（Virtualization）、效用计算（Utility Computing）、将基础设施作为服务IaaS（Infrastructureas a Service）、将平台作为服务PaaS（Platform as a Service）和将软件作为服务SaaS（Software as a Service）等概念混合演进并跃升的结果。

从研究现状上看，云计算具有以下特点。

1）超大规模。“云”具有相当的规模，Google云计算已经拥有100多万台服务器，亚马逊、IBM、微软和Yahoo等公司的“云”均拥有几十万台服务器。“云”能赋予用户前所未有的计算能力。

2）虚拟化。云计算支持用户在任意位置、使用各种终端获取服务。所请求的资源来自“云”，而不是固定的有形的实体。应用在“云”中某处运行，但实际上用户无需了解应用运行的具体位置，只需要一台笔记本或一个PDA，就可以通过网络服务来获取各种能力超强的服务。

3）高可靠性。“云”使用了数据多副本容错、计算节点同构可互换等措施来保障服务的高可靠性，使用云计算比使用本地计算机更加可靠。

4）通用性。云计算不针对特定的应用，在“云”的支撑下可以构造出千变万化的应用，同一片“云”可以同时支撑不同的应用运行。

5）高可扩展性。“云”的规模可以动态伸缩，满足应用和用户规模增长的需要。

6）按需服务。“云”是一个庞大的资源池，用户按需购买，像自来水、电和煤气那样计费。

（7）极其廉价。“云”的特殊容错措施使得可以采用极其廉价的节点来构成云；“云”的自动化管理使数据中心管理成本大幅降低；“云”的公用性和通用性使资源的利用率大幅提升；“云”设施可以建在电力资源丰富的地区，从而大幅降低能源成本。因此“云”具有前所未有的性能价格比。Google中国区前总裁李开复称，Google每年投入约16亿美元构建云计算数据中心，所获得的能力相当于使用传统技术投入640亿美元，节省了40倍的成本。因此，用户可以充分享受“云”的低成本优势，需要时，花费几百美元、一天时间就能完成以前需要数万美元、数月时间才能完成的数据处理任务。

云计算按照服务类型大致可以分为三类：将基础设施作为服务IaaS、将平台作为服务PaaS和将软件作为服务SaaS，如图1-2所示。

IaaS将硬件设备等基础资源封装成服务供用户使用，如亚马逊云计算AWS（Amazon WebServices）的弹性计算云EC2和简单存储服务S3。在IaaS环境中，用户相当于在使用裸机和磁盘，既可以让它运行Windows，也可以让它运行Linux，因而几乎可

图1-2  云计算的服务类型

以做任何想做的事情，但用户必须考虑如何才能让多台机器协同工作起来。AWS提供了在节点之间互通消息的接口简单队列服务SQS（Simple Queue Service）。IaaS最大的优势在于它允许用户动态申请或释放节点，按使用量计费。运行IaaS的服务器规模达到几十万台之多，用户因而可以认为能够申请的资源几乎是无限的。同时，IaaS是由公众共享的，因而具有更高的资源使用效率。

PaaS对资源的抽象层次更进一步，它提供用户应用程序的运行环境，典型的如Google App Engine。微软的云计算操作系统Microsoft Windows Azure也可大致归入这一类。PaaS自身负责资源的动态扩展和容错管理，用户应用程序不必过多考虑节点间的配合问题。但与此同时，用户的自主权降低，必须使用特定的编程环境并遵照特定的编程模型。这有点像在高性能集群计算机里进行MPI编程，只适用于解决某些特定的计算问题。例如，Google App Engine只允许使用Python和Java语言、基于称为Django的Web应用框架、调用Google App Engine SDK来开发在线应用服务。

SaaS的针对性更强，它将某些特定应用软件功能封装成服务，如Salesforce公司提供的在线客户关系管理CRM（ClientRelationship Management）服务。SaaS既不像PaaS一样提供计算或存储资源类型的服务，也不像IaaS一样提供运行用户自定义应用程序的环境，它只提供某些专门用途的服务供应用调用。

需要指出的是，随着云计算的深化发展，不同云计算解决方案之间相互渗透融合，同一种产品往往横跨两种以上类型。例如，Amazon Web Services是以IaaS发展的，但新提供的弹性MapReduce服务模仿了Google的MapReduce，简单数据库服务SimpleDB 模仿了Google的Bigtable，这两者属于PaaS的范畴，而它新提供的电子商务服务FPS和DevPay以及网站访问统计服务Alexa Web服务，则属于SaaS的范畴。

1.2  云计算发展现状

由于云计算是多种技术混合演进的结果，其成熟度较高，又有大公司推动，发展极为迅速。Google、亚马逊、IBM、微软和Yahoo等大公司是云计算的先行者。云计算领域的众多成功公司还包括VMware、Salesforce、Facebook、YouTube、MySpace等。

亚马逊研发了弹性计算云EC2（Elastic Computing Cloud）和简单存储服务S3（Simple Storage Service）为企业提供计算和存储服务。收费的服务项目包括存储空间、带宽、CPU资源以及月租费。月租费与电话月租费类似，存储空间、带宽按容量收费，CPU根据运算量时长收费。在诞生不到两年的时间内，亚马逊的注册用户就多达44万人，其中包括为数众多的企业级用户。

Google是最大的云计算技术的使用者。Google搜索引擎就建立在分布在200多个站点、超过100万台的服务器的支撑之上，而且这些设施的数量正在迅猛增长。Google的一系列成功应用平台，包括Google地球、地图、Gmail、Docs等也同样使用了这些基础设施。采用Google Docs之类的应用，用户数据会保存在互联网上的某个位置，可以通过任何一个与互联网相连的终端十分便利地访问和共享这些数据。目前，Google已经允许第三方在Google的云计算中通过Google App Engine运行大型并行应用程序。Google值得称颂的是它不保守，它早已以发表学术论文的形式公开其云计算三大法宝：GFS、MapReduce和Bigtable，并在美国、中国等高校开设如何进行云计算编程的课程。相应的，模仿者应运而生，Hadoop是其中最受关注的开源项目。

IBM在2007年11月推出了“改变游戏规则”的“蓝云”计算平台，为客户带来即买即用的云计算平台。它包括一系列自我管理和自我修复的虚拟化云计算软件，使来自全球的应用可以访问分布式的大型服务器池，使得数据中心在类似于互联网的环境下运行计算。IBM正在与17个欧洲组织合作开展名为RESERVOIR的云计算项目，以“无障碍的资源和服务虚拟化”为口号，欧盟提供了1.7亿欧元作为部分资金。2008年8月，IBM宣布将投资约4亿美元用于其设在北卡罗来纳州和日本东京的云计算数据中心改造，并计划2009年在10个国家投资3亿美元建设13个云计算中心。

微软紧跟云计算步伐，于2008年10月推出了Windows Azure操作系统。Azure（译为“蓝天”）是继Windows取代DOS之后，微软的又一次颠覆性转型——通过在互联网架构上打造新云计算平台，让Windows真正由PC延伸到“蓝天”上。Azure的底层是微软全球基础服务系统，由遍布全球的第四代数据中心构成。目前，微软已经配置了220个集装箱式数据中心，包括44万台服务器。

在我国，云计算发展也非常迅猛。2008年，IBM先后在无锡和北京建立了两个云计算中心；世纪互联推出了CloudEx产品线，提供互联网主机服务、在线存储虚拟化服务等；中国移动研究院已经建立起1024个CPU的云计算试验中心；解放军理工大学研制了云存储系统MassCloud，并以它支撑基于3G的大规模视频监控应用和数字地球系统。作为云计算技术的一个分支，云安全技术通过大量客户端的参与和大量服务器端的统计分析来识别病毒和木马，取得了巨大成功。瑞星、趋势、卡巴斯基、McAfee、Symantec、江民、Panda、金山、360安全卫士等均推出了云安全解决方案。值得一提的是，云安全的核心思想，与早在2003年就提出的反垃圾邮件网格非常接近^[5]。2008年11月25日，中国电子学会专门成立了云计算专家委员会。2009年5月22日，中国电子学会隆重举办首届中国云计算大会，1200多人与会，盛况空前。2009年11月2日，中国互联网大会专门召开了“2009云计算产业峰会”。2009年12月，中国电子学会举办了中国首届云计算学术会议。2010年5月，中国电子学会将举办第二届中国云计算大会。

1.3  云计算实现机制

由于云计算分为IaaS、PaaS和SaaS三种类型，不同的厂家又提供了不同的解决方案，目前还没有一个统一的技术体系结构，对读者了解云计算的原理构成了障碍。为此，本书综合不同厂家的方案，构造了一个供参考的云计算体系结构。这个体系结构如图1-3所示，它概括了不同解决方案的主要特征，每一种方案或许只实现了其中部分功能，或许也还有部分相对次要功能尚未概括进来。

图1-3  云计算技术体系结构

云计算技术体系结构分为四层：物理资源层、资源池层、管理中间件层和SOA（Service-OrientedArchitecture，面向服务的体系结构）构建层。物理资源层包括计算机、存储器、网络设施、数据库和软件等。资源池层是将大量相同类型的资源构成同构或接近同构的资源池，如计算资源池、数据资源池等。构建资源池更多的是物理资源的集成和管理工作，例如研究在一个标准集装箱的空间如何装下2000个服务器、解决散热和故障节点替换的问题并降低能耗。管理中间件层负责对云计算的资源进行管理，并对众多应用任务进行调度，使资源能够高效、安全地为应用提供服务。SOA构建层将云计算能力封装成标准的Web Services服务，并纳入到SOA体系进行管理和使用，包括服务接口、服务注册、服务查找、服务访问和服务工作流等。管理中间件层和资源池层是云计算技术的最关键部分，SOA构建层的功能更多依靠外部设施提供。

云计算的管理中间件层负责资源管理、任务管理、用户管理和安全管理等工作。资源管理负责均衡地使用云资源节点，检测节点的故障并试图恢复或屏蔽之，并对资源的使用情况进行监视统计；任务管理负责执行用户或应用提交的任务，包括完成用户任务映象（Image）的部署和管理、任务调度、任务执行、任务生命期管理等；用户管理是实现云计算商业模式的一个必不可少的环节，包括提供用户交互接口、管理和识别用户身份、创建用户程序的执行环境、对用户的使用进行计费等；安全管理保障云计算设施的整体安全，包括身份认证、访问授权、综合防护和安全审计等。

基于上述体系结构，本书以IaaS云计算为例，简述云计算的实现机制，如图1-4所示。

图1-4  简化的IaaS实现机制图

用户交互接口向应用以WebServices方式提供访问接口，获取用户需求。服务目录是用户可以访问的服务清单。系统管理模块负责管理和分配所有可用的资源，其核心是负载均衡。配置工具负责在分配的节点上准备任务运行环境。监视统计模块负责监视节点的运行状态，并完成用户使用节点情况的统计。执行过程并不复杂，用户交互接口允许用户从目录中选取并调用一个服务，该请求传递给系统管理模块后，它将为用户分配恰当的资源，然后调用配置工具为用户准备运行环境。

1.4  网格计算与云计算

网格（Grid）是20世纪90年代中期发展起来的下一代互联网核心技术。网格技术的开创者Ian Foster将之定义为“在动态、多机构参与的虚拟组织中协同共享资源和求解问题”^[6]。网格是在网络基础之上，基于SOA，使用互操作、按需集成等技术手段，将分散在不同地理位置的资源虚拟成为一个有机整体，实现计算、存储、数据、软件和设备等资源的共享，从而大幅提高资源的利用率，使用户获得前所未有的计算和信息能力。

国际网格界致力于网格中间件、网格平台和网格应用建设。就网格中间件而言，国外著名的网格中间件有Globus Toolkit、UNICORE、Condor、gLite等，其中GlobusToolkit得到了广泛采纳。就网格平台而言，国际知名的网格平台有TeraGrid、EGEE、CoreGRID、D-Grid、ApGrid、Grid3、GIG等。美国TeraGrid是由美国国家科学基金会计划资助构建的超大规模开放的科学研究环境。TeraGrid集成了高性能计算机、数据资源、工具和高端实验设施。目前TeraGrid已经集成了超过每秒750万亿次计算能力、30PB数据，拥有超过100个面向多种领域的网格应用环境。欧盟e-Science促成网格EGEE（Enabling Grids for E-sciencE），是另一个超大型、面向多种领域的网格计算基础设施。目前已有120多个机构参与，包括分布在48个国家的250个网格站点、68000个CPU、20PB数据资源，拥有8000个用户，每天平均处理30000个作业，峰值超过150000个作业。就网格应用而言，知名的网格应用系统数以百计，应用领域包括大气科学、林学、海洋科学、环境科学、生物信息学、医学、物理学、天体物理、地球科学、天文学、工程学、社会行为学等。

我国在十五期间有863支持的中国国家网格（CNGrid，863-10主题）和中国空间信息网格（SIG，863-13主题）、教育部支持的中国教育科研网格（ChinaGrid）、上海市支持的上海网格（ShanghaiGrid）等。中国国家网格拥有包括香港地区在内的10个节点，聚合计算能力为每秒18万亿次，目前拥有408个用户和360个应用。中国教育科研网格ChinaGrid连接了20所高校的计算设施，运算能力达每秒3万亿次以上，开发并实现了生物信息、流体力学等五个科学研究领域的网格典型应用。十一五期间，国家对网格支持的力度更大，通过973和863、自然科学基金等途径对网格技术进行了大力支持。973计划有“语义网格的基础理论、模型与方法研究”等，863计划有“高效能计算机及网格服务环境”、“网格地理信息系统软件及其重大应用”等，国家自然科学基金重大研究计划有“网络计算应用支撑中间件”等项目。

就像云计算可以分为IaaS、PaaS和SaaS三种类型一样，网格计算也可以分为三种类型：计算网格、信息网格和知识网格^[6]。计算网格的目标是提供集成各种计算资源的、虚拟化的计算基础设施。信息网格的目标是提供一体化的智能信息处理平台，集成各种信息系统和信息资源，消除信息孤岛，使得用户能按需获取集成后的精确信息，即服务点播（Service on Demand）和一步到位的服务（One Click is Enough）。知识网格^[8]研究一体化的智能知识处理和理解平台，使得用户能方便地发布、处理和获取知识。

需要说明的是，目前大家对网格的认识存在一种误解，认为只有使用Globus Toolkit等知名网格中间件的应用才是网格。我们认为，只要是遵照网格理念，将一定范围内分布的异构资源集成为有机整体，提供资源共享和协同工作服务的平台，均可以认为是网格。这是因为，由于网格技术非常复杂，必然有一个从不规范到规范化的过程，应该承认差异存在的客观性。虽然网格界从一开始就致力于构造能够实现全面互操作的环境，但由于网格处于信息技术前沿、许多领域尚未定型、已发布的个别规范过于复杂造成易用性差等原因，现有网格系统多针对具体应用采用适用的、个性化的框架设计和实现技术等，造成网格系统之间互操作困难，这也是开放网格论坛OGF（OpenGrid Forum）提出建立不同网格系统互通机制计划GIN（GridInteroperation Now）的原因。从另一个角度看，虽然建立全球统一的网格平台还有很长的路要走，但并不妨碍网格技术在各种具体的应用系统中发挥重要的作用。

网格计算与云计算的关系如表1-1所示。

表1-1 网格计算与云计算的比较

 

网 格 计 算

云 计  算

目标

共享高性能计算力和数据资源，实现资源共享和协同工作

提供通用的计算平台和存储空间，提供各种软件服务

资源来源

不同机构

同一机构

资源类型

异构资源

同构资源

资源节点

高性能计算机

服务器/PC

虚拟化视图

虚拟组织

虚拟机

计算类型

紧耦合问题为主

松耦合问题

应用类型

科学计算为主

数据处理为主

用户类型

科学界

商业社会

付费方式

免费（政府出资）

按量计费

标准化

有统一的国际标准OGSA/WSRF

尚无标准，但已经有了开放云计算联盟OCC

网格计算在概念上争论多年，在体系结构上有三次大的改变，在标准规范上花费了大量的人力，所设定的目标又非常远大——要在跨平台、跨组织、跨信任域的极其复杂的异构环境中共享资源和协同解决问题，所要共享的资源也是五花八门——从高性能计算机、数据库、设备到软件，甚至知识。云计算暂时不管概念、不管标准，Google云计算与亚马逊云计算的差别非常大，云计算只是对它们以前所做事情新的共同的时髦叫法，所共享的存储和计算资源暂时仅限于某个企业内部，省去了许多跨组织协调的问题。以Google为代表的云计算在内部管理运作方式上的简洁一如其界面，能省的功能都省略，Google文件系统甚至不允许修改已经存在的文件，只允许在文件后追加数据，大大降低了实现难度，而且借助其无与伦比的规模效应释放了前所未有的能量。

网格计算与云计算的关系，就像是OSI与TCP/IP之间的关系：国际标准化组织（ISO）制定的OSI（开放系统互联）网络标准，考虑得非常周到，也异常复杂，在多年之前就考虑到了会话层和表示层的问题。虽然很有远见，但过于理想，实现的难度和代价非常大。当OSI的一个简化版——TCP/IP诞生之后，将七层协议简化为四层，内容也大大精简，因而迅速取得了成功。在TCP/IP一统天下之后多年，语义网等问题才被提上议事日程，开始为TCP/IP补课，增加其会话和表示的能力。因此，可以说OSI是学院派，TCP/IP是现实派；OSI是TCP/IP的基础，TCP/IP又推动了OSI的发展。两者不是“成者为王、败者为寇”，而是滚动发展。

没有网格计算打下的基础，云计算也不会这么快到来。云计算是网格计算的一种简化实用版，通常意义的网格是指以前实现的以科学研究为主的网格，非常重视标准规范，也非常复杂，但缺乏成功的商业模式。云计算是网格计算的一种简化形态，云计算的成功也是网格的成功。网格不仅要集成异构资源，还要解决许多非技术的协调问题，也不像云计算有成功的商业模式推动，所以实现起来要比云计算难度大很多。但对于许多高端科学或军事应用而言，云计算是无法满足需求的，必须依靠网格来解决。

目前，许多人声称网格计算失败了，云计算取而代之了，这其实是一种错觉。网格计算已经有十多年历史，不如刚兴起时那样引人注目是正常的。事实上，有些政府主导、范围较窄、用途特定的网格，已经取得了决定性的胜利。代表性的有美国的TeraGrid和欧洲的EGEE等，这些网格每天都有几十万个作业在上面执行。未来的科学研究主战场，将建立在网格计算之上。在军事领域，美军的全球信息网格GIG已经囊括超过700万台计算机，规模超过现有的所有云计算数据中心计算机总和。

相信不久的将来，建立在云计算之上的“商业2.0”与建立在网格计算之上的“科学2.0”都将取得成功。

参考文献

[1]    MichaelArmbrust, Armando Fox, and Rean Griffith, et al. Above the Clouds: A BerkeleyView of Cloud Computing, mimeo, UC Berkeley, RAD Laboratory, 2009

[2]    Ian Foster, Carl Kesselman, and SteveTuecke. The Anatomy of the Grid: Enabling Scalable Virtual Organizations.International Journal of High Performance Computing Applications, 15(3), 2001

[3]    刘鹏. 提出一种实用的网格实现方式——网格计算池模型，2002

        http://www.chinagrid.net/show.aspx?id=1672&cid=57

[4]    Peng Liu, Yao Shi,San-li Li, Computing Pool—a Simplified and Practical Computational GridModel, the Second International Workshop on Grid and Cooperative Computing (GCC2003), Shanghai, Dec 7-10, 2003, published in Lecture Notes in Computer Science(LNCS), Vol. 3032, Heidelberg:Springer-Verlag, 2004

[5]    Peng Liu, Yao Shi, Francis C. M. Lau, Cho-Li Wang, San-Li Li,Grid Demo Proposal: AntiSpamGrid, IEEE International Conference on ClusterComputing,Hong Kong, Dec 1-4, 2003, selected as one of the excellent Grid researchprojects for the GridDemo session

[6]    李国杰. 信息服务网格——第三代Internet. 计算机世界, 2001年第40期

[7]    Foster, I.,C. Kesselman, and S. Tuecke, The Anatomy of the Grid: Enabling Scalable VirtualOrganizations. International Journal ofHigh Performance Computing Applications, 2001. 15(3): p. 200-222

[8]    H. Zhuge, The Knowledge Grid, World Scientific Publishing Co.,Singapore, 2004

 

第2章 Google云计算原理

Google拥有全球最强大的搜索引擎。除了搜索业务以外，Google还有Google Maps、Google Earth、Gmail、YouTube等各种业务，包括刚诞生的Google Wave。这些应用的共性在于数据量巨大，而且要面向全球用户提供实时服务，因此Google必须解决海量数据存储和快速处理问题。Google的诀窍在于它发展出简单而又高效的技术，让多达百万台的廉价计算机协同工作，共同完成这些前所未有的任务，这些技术是在诞生几年之后才被命名为Google云计算技术。Google云计算技术具体包括：Google文件系统GFS、分布式计算编程模型MapReduce、分布式锁服务Chubby和分布式结构化数据存储系统Bigtable等。其中，GFS提供了海量数据的存储和访问的能力，MapReduce使得海量信息的并行处理变得简单易行，Chubby保证了分布式环境下并发操作的同步问题，Bigtable使得海量数据的管理和组织十分方便。本章将对这四种核心技术进行详细介绍。

2.1 Google文件系统GFS

Google文件系统（Google File System，GFS）是一个大型的分布式文件系统。它为Google云计算提供海量存储，并且与Chubby、MapReduce以及Bigtable等技术结合十分紧密，处于所有核心技术的底层。由于GFS并不是一个开源的系统，我们仅仅能从Google公布的技术文档来获得一点了解，而无法进行深入的研究。文献[1]是Google公布的关于GFS的最为详尽的技术文档，它从GFS产生的背景、特点、系统框架、性能测试等方面进行了详细的阐述。

当前主流分布式文件系统有RedHat的GFS^[3]（Global File System）、IBM的GPFS^[4]、Sun的Lustre^[5]等。这些系统通常用于高性能计算或大型数据中心，对硬件设施条件要求较高。以Lustre文件系统为例，它只对元数据管理器MDS提供容错解决方案，而对于具体的数据存储节点OST来说，则依赖其自身来解决容错的问题。例如，Lustre推荐OST节点采用RAID技术或SAN存储区域网来容错，但由于Lustre自身不能提供数据存储的容错，一旦OST发生故障就无法恢复，因此对OST的稳定性就提出了相当高的要求，从而大大增加了存储的成本，而且成本会随着规模的扩大线性增长。

正如李开复所说的那样，创新固然重要，但有用的创新更重要。创新的价值，取决于一项创新在新颖、有用和可行性这三个方面的综合表现。Google GFS的新颖之处并不在于它采用了多么令人惊讶的技术，而在于它采用廉价的商用机器构建分布式文件系统，同时将GFS的设计与Google应用的特点紧密结合，并简化其实现，使之可行，最终达到创意新颖、有用、可行的完美组合。GFS使用廉价的商用机器构建分布式文件系统，将容错的任务交由文件系统来完成，利用软件的方法解决系统可靠性问题，这样可以使得存储的成本成倍下降。由于GFS中服务器数目众多，在GFS中服务器死机是经常发生事情，甚至都不应当将其视为异常现象，那么如何在频繁的故障中确保数据存储的安全、保证提供不间断的数据存储服务是GFS最核心的问题。GFS的精彩在于它采用了多种方法，从多个角度，使用不同的容错措施来确保整个系统的可靠性。

2.1.1  系统架构

GFS的系统架构如图2-1^[1]所示。GFS将整个系统的节点分为三类角色：Client（客户端）、Master（主服务器）和Chunk Server（数据块服务器）。Client是GFS提供给应用程序的访问接口，它是一组专用接口，不遵守POSIX规范，以库文件的形式提供。应用程序直接调用这些库函数，并与该库链接在一起。Master是GFS的管理节点，在逻辑上只有一个，它保存系统的元数据，负责整个文件系统的管理，是GFS文件系统中的大脑。Chunk Server负责具体的存储工作。数据以文件的形式存储在Chunk Server上，ChunkServer的个数可以有多个，它的数目直接决定了GFS的规模。GFS将文件按照固定大小进行分块，默认是64MB，每一块称为一个Chunk（数据块），每个Chunk都有一个对应的索引号（Index）。

图2-1  GFS体系结构

客户端在访问GFS时，首先访问Master节点，获取将要与之进行交互的Chunk Server信息，然后直接访问这些Chunk Server完成数据存取。GFS的这种设计方法实现了控制流和数据流的分离。Client与Master之间只有控制流，而无数据流，这样就极大地降低了Master的负载，使之不成为系统性能的一个瓶颈。Client与Chunk Server之间直接传输数据流，同时由于文件被分成多个Chunk进行分布式存储，Client可以同时访问多个Chunk Server，从而使得整个系统I/O高度并行，系统整体性能得到提高。

相对于传统的分布式文件系统，GFS针对Google应用的特点从多个方面进行了简化，从而在一定规模下达到成本、可靠性和性能的最佳平衡。具体来说，它具有以下几个特点。

1．采用中心服务器模式

GFS采用中心服务器模式来管理整个文件系统，可以大大简化设计，从而降低实现难度。Master管理了分布式文件系统中的所有元数据。文件划分为Chunk进行存储，对于Master来说，每个Chunk Server只是一个存储空间。Client发起的所有操作都需要先通过Master才能执行。这样做有许多好处，增加新的Chunk Server是一件十分容易的事情，Chunk Server只需要注册到Master上即可，Chunk Server之间无任何关系。如果采用完全对等的、无中心的模式，那么如何将ChunkServer的更新信息通知到每一个ChunkServer，会是设计的一个难点，而这也将在一定程度上影响系统的扩展性。Master维护了一个统一的命名空间，同时掌握整个系统内Chunk Server的情况，据此可以实现整个系统范围内数据存储的负载均衡。由于只有一个中心服务器，元数据的一致性问题自然解决。当然，中心服务器模式也带来一些固有的缺点，比如极易成为整个系统的瓶颈等。GFS采用多种机制来避免Master成为系统性能和可靠性上的瓶颈，如尽量控制元数据的规模、对Master进行远程备份、控制信息和数据分流等。

2．不缓存数据

缓存机制是提升文件系统性能的一个重要手段，通用文件系统为了提高性能，一般需要实现复杂的缓存（Cache）机制。GFS文件系统根据应用的特点，没有实现缓存，这是从必要性和可行性两方面考虑的。从必要性上讲，客户端大部分是流式顺序读写，并不存在大量的重复读写，缓存这部分数据对系统整体性能的提高作用不大；而对于Chunk Server，由于GFS的数据在ChunkServer上以文件的形式存储，如果对某块数据读取频繁，本地的文件系统自然会将其缓存。从可行性上讲，如何维护缓存与实际数据之间的一致性是一个极其复杂的问题，在GFS中各个ChunkServer的稳定性都无法确保，加之网络等多种不确定因素，一致性问题尤为复杂。此外由于读取的数据量巨大，以当前的内存容量无法完全缓存。对于存储在Master中的元数据，GFS采取了缓存策略，GFS中Client发起的所有操作都需要先经过Master。Master需要对其元数据进行频繁操作，为了提高操作的效率，Master的元数据都是直接保存在内存中进行操作；同时采用相应的压缩机制降低元数据占用空间的大小，提高内存的利用率。

3．在用户态下实现

文件系统作为操作系统的重要组成部分，其实现通常位于操作系统底层。以Linux为例，无论是本地文件系统如Ext3文件系统，还是分布式文件系统如Lustre等，都是在内核态实现的。在内核态实现文件系统，可以更好地和操作系统本身结合，向上提供兼容的POSIX接口。然而，GFS却选择在用户态下实现，主要基于以下考虑。

1）在用户态下实现，直接利用操作系统提供的POSIX编程接口就可以存取数据，无需了解操作系统的内部实现机制和接口，从而降低了实现的难度，并提高了通用性。

2）POSIX接口提供的功能更为丰富，在实现过程中可以利用更多的特性，而不像内核编程那样受限。

3）用户态下有多种调试工具，而在内核态中调试相对比较困难。

4）用户态下，Master和Chunk Server都以进程的方式运行，单个进程不会影响到整个操作系统，从而可以对其进行充分优化。在内核态下，如果不能很好地掌握其特性，效率不但不会高，甚至还会影响到整个系统运行的稳定性。

5）用户态下，GFS和操作系统运行在不同的空间，两者耦合性降低，从而方便GFS自身和内核的单独升级。

4．只提供专用接口

通常的分布式文件系统一般都会提供一组与POSIX规范兼容的接口。其优点是应用程序可以通过操作系统的统一接口来透明地访问文件系统，而不需要重新编译程序。GFS在设计之初，是完全面向Google的应用的，采用了专用的文件系统访问接口。接口以库文件的形式提供，应用程序与库文件一起编译，Google应用程序在代码中通过调用这些库文件的API，完成对GFS文件系统的访问。采用专用接口有以下好处。

1）降低了实现的难度。通常与POSIX兼容的接口需要在操作系统内核一级实现，而GFS是在应用层实现的。

2）采用专用接口可以根据应用的特点对应用提供一些特殊支持，如支持多个文件并发追加的接口等。

3）专用接口直接和Client、Master、Chunk Server交互，减少了操作系统之间上下文的切换，降低了复杂度，提高了效率。

2.1.2  容错机制

1．Master容错

具体来说，Master上保存了GFS文件系统的三种元数据。

1）命名空间（Name Space），也就是整个文件系统的目录结构。

2）Chunk与文件名的映射表。

3）Chunk副本的位置信息，每一个Chunk默认有三个副本。

首先就单个Master来说，对于前两种元数据，GFS通过操作日志来提供容错功能。第三种元数据信息则直接保存在各个ChunkServer上，当Master启动或Chunk Server向Master注册时自动生成。因此当Master发生故障时，在磁盘数据保存完好的情况下，可以迅速恢复以上元数据。为了防止Master彻底死机的情况，GFS还提供了Master远程的实时备份，这样在当前的GFS Master出现故障无法工作的时候，另外一台GFS Master可以迅速接替其工作。

2．Chunk Server容错

GFS采用副本的方式实现Chunk Server的容错。每一个Chunk有多个存储副本（默认为三个），分布存储在不同的Chunk Server上。副本的分布策略需要考虑多种因素，如网络的拓扑、机架的分布、磁盘的利用率等。对于每一个Chunk，必须将所有的副本全部写入成功，才视为成功写入。在其后的过程中，如果相关的副本出现丢失或不可恢复等状况，Master会自动将该副本复制到其他ChunkServer，从而确保副本保持一定的个数。尽管一份数据需要存储三份，好像磁盘空间的利用率不高，但综合比较多种因素，加之磁盘的成本不断下降，采用副本无疑是最简单、最可靠、最有效，而且实现的难度也最小的一种方法。

GFS中的每一个文件被划分成多个Chunk，Chunk的默认大小是64MB，这是因为Google应用中处理的文件都比较大，以64MB为单位进行划分，是一个较为合理的选择。Chunk Server存储的是Chunk的副本，副本以文件的形式进行存储。每一个Chunk以Block为单位进行划分，大小为64KB，每一个Block对应一个32bit的校验和。当读取一个Chunk副本时，Chunk Server会将读取的数据和校验和进行比较，如果不匹配，就会返回错误，从而使Client选择其他Chunk Server上的副本。

2.1.3  系统管理技术

严格意义上来说，GFS是一个分布式文件系统，包含从硬件到软件的整套解决方案。除了上面提到的GFS的一些关键技术外，还有相应的系统管理技术来支持整个GFS的应用，这些技术可能并不一定为GFS所独有。

1．大规模集群安装技术

安装GFS的集群中通常有非常多的节点，文献[1]中最大的集群超过1000个节点，而现在的Google数据中心动辄有万台以上的机器在运行。那么，迅速地安装、部署一个GFS的系统，以及迅速地进行节点的系统升级等，都需要相应的技术支撑。

2．故障检测技术

GFS是构建在不可靠的廉价计算机之上的文件系统，由于节点数目众多，故障发生十分频繁，如何在最短的时间内发现并确定发生故障的Chunk Server，需要相关的集群监控技术。

3．节点动态加入技术

当有新的ChunkServer加入时，如果需要事先安装好系统，那么系统扩展将是一件十分烦琐的事情。如果能够做到只需将裸机加入，就会自动获取系统并安装运行，那么将会大大减少GFS维护的工作量。

4．节能技术

有关数据表明，服务器的耗电成本大于当初的购买成本，因此Google采用了多种机制来降低服务器的能耗，例如对服务器主板进行修改，采用蓄电池代替昂贵的UPS（不间断电源系统），提高能量的利用率。Rich Miller 在一篇关于数据中心的博客文章中表示，这个设计让 Google 的 UPS 利用率达到99.9%，而一般数据中心只能达到92%～95%。

2.2  并行数据处理MapReduce

MapReduce是Google提出的一个软件架构，是一种处理海量数据的并行编程模式，用于大规模数据集（通常大于1TB）的并行运算。“Map（映射）”、“Reduce（化简）”的概念和主要思想，都是从函数式编程语言和矢量编程语言借鉴来的^[5]。正是由于MapReduce有函数式和矢量编程语言的共性，使得这种编程模式特别适合于非结构化和结构化的海量数据的搜索、挖掘、分析与机器智能学习等。

2.2.1  产生背景

MapReduce这种并行编程模式思想最早是在1995年提出的，文献[6]首次提出了“map”和“fold”的概念，和现在Google所使用的“Map”和“Reduce”思想是相吻合的。

与传统的分布式程序设计相比，MapReduce封装了并行处理、容错处理、本地化计算、负载均衡等细节，还提供了一个简单而强大的接口。通过这个接口，可以把大尺度的计算自动地并发和分布执行，从而使编程变得非常容易。还可以通过由普通PC构成的巨大集群来达到极高的性能。另外，MapReduce也具有较好的通用性，大量不同的问题都可以简单地通过MapReduce来解决。

MapReduce把对数据集的大规模操作，分发给一个主节点管理下的各分节点共同完成，通过这种方式实现任务的可靠执行与容错机制。在每个时间周期，主节点都会对分节点的工作状态进行标记，一旦分节点状态标记为死亡状态，则这个节点的所有任务都将分配给其他分节点重新执行。

据相关统计，每使用一次Google搜索引擎，Google的后台服务器就要进行10¹¹次运算。这么庞大的运算量，如果没有好的负载均衡机制，有些服务器的利用率会很低，有些则会负荷太重，有些甚至可能死机，这些都会影响系统对用户的服务质量。而使用MapReduce这种编程模式，就保持了服务器之间的均衡，提高了整体效率。

2.2.2  编程模型

MapReduce的运行模型如图2-2所示。图中有M个Map操作和R个Reduce操作。

简单地说，一个Map函数就是对一部分原始数据进行指定的操作。每个Map操作都针对不同的原始数据，因此Map与Map之间是互相独立的，这就使得它们可以充分并行化。一个Reduce操作就是对每个Map所产生的一部分中间结果进行合并操作，每个Reduce所处理的Map中间结果是互不交叉的，所有Reduce产生的最终结果经过简单连接就形成了完整的结果集，因此Reduce也可以在并行环境下执行。

在编程的时候，开发者需要编写两个主要函数：

Map: (in_key, in_value) à {(key_j, value_j) | j = 1…k}

Reduce: (key, [value₁,…,value_m])à (key, final_value)

Map和Reduce的输入参数和输出结果根据应用的不同而有所不同。Map的输入参数是in_key和in_value，它指明了Map需要处理的原始数据是哪些。Map的输出结果是一组<key,value>对，这是经过Map操作后所产生的中间结果。在进行Reduce操作之前，系统已经将所有Map产生的中间结果进行了归类处理，使得相同key对应的一系列value能够集结在一起提供给一个Reduce进行归并处理，也就是说，Reduce的输入参数是（key, [value₁,…,value_m]）。Reduce的工作是需要对这些对应相同key的value值进行归并处理，最终形成（key, final_value）的结果。这样，一个Reduce处理了一个key，所有Reduce的结果并在一起就是最终结果。

例如，假设我们想用MapReduce来计算一个大型文本文件中各个单词出现的次数，Map的输入参数指明了需要处理哪部分数据，以<在文本中的起始位置，需要处理的数据长度>表示，经过Map处理，形成一批中间结果<单词，出现次数>。而Reduce函数则是把中间结果进行处理，将相同单词出现的次数进行累加，得到每个单词总的出现次数。

2.2.3  实现机制

实现MapReduce操作的执行流程图^[7]如图2-3所示。

当用户程序调用MapReduce函数，就会引起如下操作（图中的数字标示和下面的数字标示相同）。

1）用户程序中的MapReduce函数库首先把输入文件分成M块，每块大概16M～64MB（可以通过参数决定），接着在集群的机器上执行处理程序。

2）这些分派的执行程序中有一个程序比较特别，它是主控程序Master。剩下的执行程序都是作为Master分派工作的Worker（工作机）。总共有M个Map任务和R个Reduce任务需要分派，Master选择空闲的Worker来分配这些Map或者Reduce任务。

图2-3  MapReduce执行流程图

3）一个分配了Map任务的Worker读取并处理相关的输入块。它处理输入的数据，并且将分析出的<key,value>对传递给用户定义的Map函数。Map函数产生的中间结果<key,value>对暂时缓冲到内存。

4）这些缓冲到内存的中间结果将被定时写到本地硬盘，这些数据通过分区函数分成R个区。中间结果在本地硬盘的位置信息将被发送回Master，然后Master负责把这些位置信息传送给Reduce Worker。

5）当Master通知Reduce的Worker关于中间<key,value>对的位置时，它调用远程过程来从Map Worker的本地硬盘上读取缓冲的中间数据。当Reduce Worker读到所有的中间数据，它就使用中间key进行排序，这样可以使得相同key的值都在一起。因为有许多不同key的Map都对应相同的Reduce任务，所以，排序是必需的。如果中间结果集过于庞大，那么就需要使用外排序。

6）Reduce Worker根据每一个唯一中间key来遍历所有的排序后的中间数据，并且把key和相关的中间结果值集合传递给用户定义的Reduce函数。Reduce函数的结果输出到一个最终的输出文件。

7）当所有的Map任务和Reduce任务都已经完成的时候，Master激活用户程序。此时MapReduce返回用户程序的调用点。

由于MapReduce是用在成百上千台机器上处理海量数据的，所以容错机制是不可或缺的。总的说来，MapReduce是通过重新执行失效的地方来实现容错的。

1．Master失效

在Master中，会周期性地设置检查点（checkpoint），并导出Master的数据。一旦某个任务失效了，就可以从最近的一个检查点恢复并重新执行。不过由于只有一个Master在运行，如果Master失效了，则只能终止整个MapReduce程序的运行并重新开始。

2．Worker失效

相对于Master失效而言，Worker失效算是一种常见的状态。Master会周期性地给Worker发送ping命令，如果没有Worker的应答，则Master认为Worker失效，终止对这个Worker的任务调度，把失效Worker的任务调度到其他Worker上重新执行。

2.2.4  案例分析

单词计数（Word Count）是一个经典的问题，也是能体现MapReduce设计思想的最简单算法之一。该算法主要是为了完成对文字数据中所出现的单词进行计数，如图2-4所示。

图2-4  单词计数

伪代码如下：

Map(K,V){

For each word w in V

         Collect(w , 1);

}

Reduce(K,V[ ]){

int count = 0;

     For each v in V

         count+= v;

     Collect(K , count);

}

下面就根据MapReduce的四个执行步骤对这一算法进行详细的介绍。

1）根据文件所包含的信息分割（Split）文件，在这里把文件的每行分割为一组，共三组，如图2-5所示。这一步由系统自动完成。

图2-5  分割过程

2）对分割之后的每一对<key,value>利用用户定义的Map进行处理，再生成新的<key,value>对，如图2-6所示。

图2-6  Map过程

3）Map输出之后有一个内部的Fold过程，和第一步一样，都是由系统自动完成的，如图2-7所示。

图2-7  Fold过程

4）经过Fold步骤之后的输出与结果已经非常接近，再由用户定义的Reduce步骤完成最后的工作即可，如图2-8所示。

图2-8  Reduce过程

2.3  分布式锁服务Chubby

Chubby是Google设计的提供粗粒度锁服务的一个文件系统，它基于松耦合分布式系统，解决了分布的一致性问题。通过使用Chubby的锁服务，用户可以确保数据操作过程中的一致性。不过值得注意的是，这种锁只是一种建议性的锁（Advisory Lock）而不是强制性的锁（Mandatory Lock），如此选择的目的是使系统具有更大的灵活性。

GFS使用Chubby来选取一个GFS主服务器，Bigtable使用Chubby指定一个主服务器并发现、控制与其相关的子表服务器。除了最常用的锁服务之外，Chubby还可以作为一个稳定的存储系统存储包括元数据在类的小数据。同时Google内部还使用Chubby进行名字服务（Name Server）。本节首先简要介绍Paxos算法，因为Chubby内部一致性问题的实现用到了Paxos算法；然后围绕Chubby系统的设计和实现展开讲解。通过本节的学习读者应该对分布式系统中一致性问题的一般性算法有初步的了解，着重掌握Chubby系统设计和实现的精髓。

2.3.1  Paxos算法

Paxos算法^[14][15]是由供职于微软的Leslie Lamport最先提出的一种基于消息传递（Messages Passing）的一致性算法。在目前所有的一致性算法中，该算法最常用且被认为是最有效的。要想了解Paxos算法，我们首先需要知道什么是分布式系统中的一致性问题，因为Paxos算法就是为了解决这个问题而提出的。简单地说分布式系统的一致性问题，就是如何保证系统中初始状态相同的各个节点在执行相同的操作序列时，看到的指令序列是完全一致的，并且最终得到完全一致的结果。在Lamport提出的Paxos算法中节点被分成了三种类型：proposers、acceptors和 learners。其中proposers 提出决议（Value），acceptors批准决议，learners获取并使用已经通过的决议。一个节点可以兼有多重类型。在这种情况下，满足以下三个条件^[15]就可以保证数据的一致性：

1）决议只有在被 proposers 提出后才能批准。

2）每次只批准一个决议。

3）只有决议确定被批准后learners才能获取这个决议。

Lamport通过约束条件的不断加强，最后得到了一个可以实际运用到算法中的完整约束条件：如果一个编号为n的提案具有值v，那么存在一个多数派，要么他们中没有人批准过编号小于n的任何提案，要么他们进行的最近一次批准具有值v。为了保证决议的唯一性，acceptors也要满足一个如下的约束条件：当且仅当 acceptors 没有收到编号大于n的请求时，acceptors 才批准编号为n的提案。

在这些约束条件的基础上，可以将一个决议的通过分成两个阶段。

1）准备阶段：proposers选择一个提案并将它的编号设为n，然后将它发送给acceptors中的一个多数派。Acceptors 收到后，如果提案的编号大于它已经回复的所有消息，则acceptors将自己上次的批准回复给proposers，并不再批准小于n的提案。

2）批准阶段：当proposers接收到acceptors 中的这个多数派的回复后，就向回复请求的acceptors发送accept请求，在符合acceptors一方的约束条件下，acceptors收到accept请求后即批准这个请求。

为了减少决议发布过程中的消息量，acceptors将这个通过的决议发送给learners 的一个子集，然后由这个子集中的learners 去通知所有其他的learners。一般情况下，以上的算法过程就可以成功地解决一致性问题，但是也有特殊情况。根据算法一个编号更大的提案会终止之前的提案过程，如果两个proposer在这种情况下都转而提出一个编号更大的提案，那么就可能陷入活锁。此时需要选举出一个president，仅允许 president提出提案。

以上只是简要地向大家介绍了Paxos算法的核心内容，关于更多的实现细节读者可以参考Lamport关于Paxos算法实现的文章。

2.3.2  Chubby系统设计

通常情况下Google的一个数据中心仅运行一个Chubby单元^[13]（Chubby cell,下面会有详细讲解），而这个单元需要支持包括GFS、Bigtable在内的众多Google服务。这种苛刻的服务要求使得Chubby在设计之初就要充分考虑到系统需要实现的目标以及可能出现的各种问题。

Chubby的设计目标主要有以下几点。

1）高可用性和高可靠性。这是系统设计的首要目标，在保证这一目标的基础上再考虑系统的吞吐量和存储能力。

2）高扩展性。将数据存储在价格较为低廉的RAM，支持大规模用户访问文件。

3）支持粗粒度的建议性锁服务。提供这种服务的根本目的是提高系统的性能。

4）服务信息的直接存储。可以直接存储包括元数据、系统参数在内的有关服务信息，而不需要再维护另一个服务。

5）支持通报机制。客户可以及时地了解到事件的发生。

6）支持缓存机制。通过一致性缓存将常用信息保存在客户端，避免了频繁地访问主服务器。

前面提到在分布式系统中保持数据一致性最常用也最有效的算法是Paxos，很多系统就是将Paxos算法作为其一致性算法的核心。但是Google并没有直接实现一个包含了Paxos算法的函数库，相反，Google设计了一个全新的锁服务Chubby。Google做出这种设计主要是考虑到以下几个问题^[13]。

1）通常情况下开发者在开发的初期很少考虑系统的一致性问题，但是随着开发的不断进行，这种问题会变得越来越严重。单独的锁服务可以保证原有系统的架构不会发生改变，而使用函数库的话很可能需要对系统的架构做出大幅度的改动。

2）系统中很多事件的发生是需要告知其他用户和服务器的，使用一个基于文件系统的锁服务可以将这些变动写入文件中。这样其他需要了解这些变动的用户和服务器直接访问这些文件即可，避免了因大量的系统组件之间的事件通信带来的系统性能下降。

3）基于锁的开发接口容易被开发者接受。虽然在分布式系统中锁的使用会有很大的不同，但是和一致性算法相比，锁显然被更多的开发者所熟知。

一般来说分布式一致性问题通过quorum机制（简单来说就是根据少数服从多数的选举原则产生一个决议）做出决策，为了保证系统的高可用性，需要若干台机器，但是使用单独的锁服务的话一台机器也能保证这种高可用性。也就是说，Chubby在自身服务的实现时利用若干台机器实现了高可用性，而外部用户利用Chubby则只需一台机器就可以保证高可用性。

正是考虑到以上几个问题，Google设计了Chubby，而不是单独地维护一个函数库（实际上，Google有这样一个独立于Chubby的函数库，不过一般情况下并不会使用）。在设计的过程中有一些细节问题也值得我们关注，比如在Chubby系统中采用了建议性的锁而没有采用强制性的锁。两者的根本区别在于用户访问某个被锁定的文件时，建议性的锁不会阻止这种行为，而强制性的锁则会，实际上这是为了便于系统组件之间的信息交互行为。另外Chubby还采用了粗粒度（Coarse-Grained）锁服务而没有采用细粒度（Fine-Grained）锁服务，两者的差异在于持有锁的时间。细粒度的锁持有时间很短，常常只有几秒甚至更少，而粗粒度的锁持有的时间可长达几天，做出如此选择的目的是减少频繁换锁带来的系统开销。当然用户也可以自行实现细粒度锁，不过建议还是使用粗粒度  的锁。

图2-9^[13]就是Chubby的基本架构。很明显，Chubby被划分成两个部分：客户端和服务器端，客户端和服务器端之间通过远程过程调用（RPC）来连接。在客户这一端每个客户应用程序都有一个Chubby程序库（Chubby Library），客户端的所有应用都是通过调用这个库中的相关函数来完成的。服务器一端称为Chubby单元，一般是由五个称为副本（Replica）的服务器组成的，这五个副本在配置上完全一致，并且在系统刚开始时处于对等地位。这些副本通过quorum机制选举产生一个主服务器（Master），并保证在一定的时间内有且仅有一个主服务器，这个时间就称为主服务器租约期（Master Lease）。如果某个服务器被连续推举为主服务器的话，这个租约期就会不断地被更新。租续期内所有的客户请求都是由主服务器来处理的。客户端如果需要确定主服务器的位置，可以向DNS发送一个主服务器定位请求，非主服务器的副本将对该请求做出回应，通过这种方式客户端能够快速、准确地对主服务器做出定位。

图2-9  Chubby的基本架构

2.3.3  Chubby文件系统

Chubby系统本质上就是一个分布式的、存储大量小文件的文件系统，它所有的操作都是在文件的基础上完成的。例如在Chubby最常用的锁服务中，每一个文件就代表了一个锁，用户通过打开、关闭和读取文件，获取共享（Shared）锁或独占（Exclusive）锁。选举主服务器的过程中，符合条件的服务器都同时申请打开某个文件并请求锁住该文件。成功获得锁的服务器自动成为主服务器并将其地址写入这个文件夹，以便其他服务器和用户可以获知主服务器的地址信息。

Chubby的文件系统^[13]和UNIX类似。例如在文件名“/ls/foo/wombat/pouch”中，ls代表lock service，这是所有Chubby文件系统的共有前缀；foo是某个单元的名称；/wombat/pouch则是foo这个单元上的文件目录或者文件名。由于Chubby自身的特殊服务要求，Google对Chubby做了一些与UNIX不同的改变。例如Chubby不支持内部文件的移动；不记录文件的最后访问时间；另外在Chubby中并没有符号连接（Symbolic Link，又叫软连接，类似于Windows系统中的快捷方式）和硬连接（Hard Link，类似于别名）的概念。在具体实现时，文件系统由许多节点组成，分为永久型和临时型，每个节点就是一个文件或目录。节点中保存着包括ACL（AccessControl List，访问控制列表，将在2.3.5节讲解）在内的多种系统元数据。为了用户能够及时了解元数据的变动，系统规定每个节点的元数据都应当包含以下四种单调递增的64位编号^[13]。

1）实例号（Instance Number）：新节点实例号必定大于旧节点的实例号。

2）内容生成号（Content Generation Number）：文件内容修改时该号增加。

3）锁生成号（Lock Generation Number）：锁被用户持有时该号增加。

4）ACL生成号（ACLGeneration Number）：ACL名被覆写时该号增加。

用户在打开某个节点时就会获取一个类似于UNIX中文件描述符（FileDescriptor）的句柄^[13]（Handles），这个句柄由以下三个部分组成。

1）校验数位（Check Digit）：防止其他用户创建或猜测这个句柄。

2）序号（Sequence Number）：用来确定句柄是由当前还是以前的主服务器创建的。

3）模式信息（Mode Information）：用于新的主服务器重新创建一个旧的句柄。

在实际的执行中，为了避免所有的通信都使用序号带来的系统开销增长，Chubby引入了sequencer的概念。sequencer实际上就是一个序号，只不过这个序号只能由锁的持有者在获取锁时向系统发出请求来获得。这样一来Chubby系统中只有涉及锁的操作才需要序号，其他一概不用。在文件操作中，用户可以将句柄看做一个指向文件系统的指针。这个指针支持一系列的操作，常用的句柄操作函数如表2-1所示。

表2-1 常用句柄函数及其作用

函数名称

作    用

Open()

打开某个文件或者目录来创建句柄

Close()

关闭打开的句柄，后续的任何操作都将中止

Poison()

中止当前未完成及后续的操作，但不关闭句柄

GetContentsAndStat()

返回文件内容及元数据

GetStat()

只返回文件元数据

ReadDir()

返回子目录名称及其元数据

SetContents()

向文件中写入内容

SetACL()

设置ACL名称

Delete()

如果该节点没有子节点的话则执行删除操作

Acquire()

获取锁

Release()

释放锁

GetSequencer()

返回一个sequencer

SetSequencer()

将sequencer和某个句柄进行关联

CheckSequencer()

检查某个sequencer是否有效

2.3.4  通信协议

客户端和主服务器之间的通信是通过KeepAlive握手协议来维持的，图2-10^[13]就是这一通信过程的简单示意图。

图2-10  Chubby客户端与服务器端的通信过程

图2-10中从左到右时间在增加，斜向上的箭头表示一次KeepAlive请求，斜向下的箭头则是主服务器的一次回应。M₁、M₂、M₃表示不同的主服务器租约期。C₁、C₂、C₃则是客户端对主服务器租约期时长做出的一个估计。KeepAlive是周期发送的一种信息，它主要有两方面的功能：延迟租约的有效期和携带事件信息告诉用户更新。主要的事件包括文件内容被修改、子节点的增加、删除和修改、主服务器出错、句柄失效等。正常情况下，通过KeepAlive握手协议租约期会得到延长，事件也会及时地通知给用户。但是由于系统有一定的失效概率，引入故障处理措施是很有必要的。通常情况下系统可能会出现两种故障：客户端租约期过期和主服务器故障，对于这两种情况系统有着不同的应对方式。

1．客户端租约过期

刚开始时，客户端向主服务器发出一个KeepAlive请求（图2-10中的1），如果有需要通知的事件时则主服务器会立刻做出回应，否则主服务器并不立刻对这个请求做出回应，而是等到客户端的租约期C₁快结束的时候才做出回应（图2-10中的2），并更新主服务器租约期为M₂。客户端在接到这个回应后认为该主服务器仍处于活跃状态，于是将租约期更新为C₂并立刻发出新的KeepAlive请求（图2-10中的3）。同样的，主服务器可能不是立刻回应而是等待C₂接近结束，但是在这个过程中主服务器出现故障停止使用。在等待了一段时间后C₂到期，由于并没有收到主服务器的回应，系统向客户端发出一个危险（Jeopardy）事件，客户端清空并暂时停用自己的缓存，从而进入一个称为宽限期（Grace Period）的危险状态。这个宽限期默认是45秒。在宽限期内，客户端不会立刻断开其与服务器端的联系，而是不断地做探询。图2-10中新的主服务器很快被重新选出，当它接到客户端的第一个KeepAlive请求（图2-10中的4）时会拒绝（图2-10中的5），因为这个请求的纪元号（Epoch Number）错误。不同主服务器的纪元号不相同，客户端的每次请求都需要这个号来保证处理的请求是针对当前的主服务器。客户端在主服务器拒绝之后会使用新的纪元号来发送KeepAlive请求（图2-10中的6）。新的主服务器接受这个请求并立刻做出回应（图2-10中的7）。如果客户端接收到这个回应的时间仍处于宽限期内，则系统会恢复到安全状态，租约期更新为C3。如果在宽限期未接到主服务器的相关回应，则客户端终止当前的会话。

2．主服务器出错

在客户端和主服务器端进行通信时可能会遇到主服务器故障，图2-10就出现了这种情况。正常情况下旧的主服务器出现故障后系统会很快地选举出新的主服务器，新选举的主服务器在完全运行前需要经历以下九个步骤^[13]。

1）产生一个新的纪元号以便今后客户端通信时使用，这能保证当前的主服务器不必处理针对旧的主服务器的请求。

2）只处理主服务器位置相关的信息，不处理会话相关的信息。

3）构建处理会话和锁所需的内部数据结构。

4）允许客户端发送KeepAlive请求，不处理其他会话相关的信息。

5）向每个会话发送一个故障事件，促使所有的客户端清空缓存。

6）等待直到所有的会话都收到故障事件或会话终止。

7）开始允许执行所有的操作。

8）如果客户端使用了旧的句柄则需要为其重新构建新的句柄。

9）一定时间段后（1分钟），删除没有被打开过的临时文件夹。

如果这一过程在宽限期内顺利完成，则用户不会感觉到任何故障的发生，也就是说新旧主服务器的替换对于用户来说是透明的，用户感觉到的仅仅是一个延迟。使用宽限期的好处正是如此。

在系统实现时，Chubby还使用了一致性客户端缓存（Consistent Client-SideCaching）技术，这样做的目的是减少通信压力，降低通信频率。在客户端保存一个和单元上数据一致的本地缓存，这样需要时客户可以直接从缓存中取出数据而不用再和主服务器通信。当某个文件数据或者元数据需要修改时，主服务器首先将这个修改阻塞；然后通过查询主服务器自身维护的一个缓存表，向所有对修改的数据进行了缓存的客户端发送一个无效标志（Invalidation）；客户端收到这个无效标志后会返回一个确认（Acknowledge），主服务器在收到所有的确认后才解除阻塞并完成这次修改。这个过程的执行效率非常高，仅仅需要发送一次无效标志即可，因为主服务器对于没有返回确认的节点就直接认为其是未缓存的。

2.3.5  正确性与性能

1．一致性

前面提到过每个Chubby单元是由五个副本组成的，这五个副本中需要选举产生一个主服务器，这种选举本质上就是一个一致性问题。在实际的执行过程中，Chubby使用Paxos算法来解决这个问题。

主服务器产生后客户端的所有读写操作都是由主服务器来完成的。读操作很简单，客户直接从主服务器上读取所需数据即可，但是写操作就涉及数据一致性的问题了。为了保证客户的写操作能够同步到所有的服务器上，系统再次利用了Paxos算法。因此，可以看出Paxos算法在分布式一致性问题中的作用是巨大的。

2．安全性

Chubby采用的是ACL形式的安全保障措施。系统中有三种ACL名^[13]，分别是写ACL名（Write ACL Name）、读ACL名（Read ACL Name）和变更ACL名（Change ACLName）。只要不被覆写，子节点都是直接继承父节点的ACL名。ACL同样被保存在文件中，它是节点元数据的一部分，用户在进行相关操作时首先需要通过ACL来获取相应的授权。图2-11是一个用户成功写文件所需经历的过程。

图2-11  Chubby的ACL机制

用户chinacloud请求向文件CLOUD中写入内容。CLOUD首先读取自身的写ACL名是fun，接着在fun中查到了chinacloud这一行记录，于是返回信息允许chinacloud对文件进行写操作，此时chinacloud才被允许向CLOUD写入内容。其他的操作和写操作类似。

3．性能优化

为了满足系统的高可扩展性，Chubby目前已经采取了一些措施^[13]。比如提高主服务器默认的租约期、使用协议转换服务将Chubby协议转换成较简单的协议。还有就是使用上面提到的客户端一致性缓存。除此之外，Google的工程师们还考虑使用代理（Proxy）和分区（Partition）技术，虽然目前这两种技术并没有实际使用，但是在设计的时候还是被包含进系统，不排除将来使用的可能。代理可以减少主服务器处理KeepAlive以及读请求带来的服务器负载，但是它并不能减少写操作带来的通信量。不过根据Google自己的数据统计表明，在所有的请求中，写请求仅占极少的一部分，几乎可以忽略不计。使用分区技术的话可以将一个单元的命名空间（Name Space）划分成N份。除了少量的跨分区通信外，大部分的分区都可以独自地处理服务请求。通过分区可以减少各个分区上的读写通信量，但不能减少KeepAlive请求的通信量。因此，如果需要的话，将代理和分区技术结合起来使用才可以明显提高系统同时处理的服务请求量。

2.4  分布式结构化数据表Bigtable

Bigtable是Google开发的基于GFS和Chubby的分布式存储系统。Google的很多数据，包括Web索引、卫星图像数据等在内的海量结构化和半结构化数据，都是存储在Bigtable中的。从实现上来看，Bigtable并没有什么全新的技术，但是如何选择合适的技术并将这些技术高效、巧妙地结合在一起恰恰是最大的难点。Google的工程师通过研究以及大量的实践，完美实现了相关技术的选择及融合。Bigtable在很多方面和数据库类似，但它并不是真正意义上的数据库。通过本节的学习，读者将会对Bigtable的数据模型、系统架构、实现以及它使用的一些数据库技术有一个全面的认识。

2.4.1  设计动机与目标

Google设计Bigtable的动机主要有如下三个方面。

1）需要存储的数据种类繁多。Google目前向公众开放的服务很多，需要处理的数据类型也非常多。包括URL、网页内容、用户的个性化设置在内的数据都是Google需要经常处理的。

2）海量的服务请求。Google运行着目前世界上最繁忙的系统，它每时每刻处理的客户服务请求数量是普通的系统根本无法承受的。

3）商用数据库无法满足Google的需求。一方面现有商用数据库的设计着眼点在于其通用性，面对Google的苛刻服务要求根本无法满足，而且在数量庞大的服务器上根本无法成功部署普通的商用数据库。另一方面对于底层系统的完全掌控会给后期的系统维护、升级带来极大的便利。

在仔细考察了Google的日常需求后，Bigtable开发团队确定了Bigtable设计所需达到的如下几个基本目标。

1）广泛的适用性。Bigtable是为了满足一系列Google产品而并非特定产品的存储要求。

2）很强的可扩展性。根据需要随时可以加入或撤销服务器。

3）高可用性。对于客户来说，有时候即使短暂的服务中断也是不能忍受的。Bigtable设计的重要目标之一就是确保几乎所有的情况下系统都可用。

4）简单性。底层系统的简单性既可以减少系统出错的概率，也为上层应用的开发带来便利。

在目标确定之后，Google开发者就在现有的数据库技术中进行了大规模的筛选，希望各种技术之间能够扬长避短，巧妙地结合起来。最终实现的系统也确实达到了原定的目标。下面就开始详细讲解Bigtable。

2.4.2  数据模型

Bigtable是一个分布式多维映射表，表中的数据是通过一个行关键字（Row Key）、一个列关键字（Column Key）以及一个时间戳（Time Stamp）进行索引的。Bigtable对存储在其中的数据不做任何解析，一律看做字符串，具体数据结构的实现需要用户自行处理。Bigtable的存储逻辑可以表示为：

(row:string, column:string, time:int64)→string

Bigtable数据的存储格式如图2-12所示^[8]。

图2-12  Bigtable数据模型

1．行

Bigtable的行关键字可以是任意的字符串，但是大小不能够超过64KB。Bigtable和传统的关系型数据库有很大不同，它不支持一般意义上的事务，但能保证对于行的读写操作具有原子性（Atomic）。表中数据都是根据行关键字进行排序的，排序使用的是词典序。图2-12是Bigtable数据模型的一个典型实例，其中com.cn.www就是一个行关键字。不直接存储网页地址而将其倒排是Bigtable的一个巧妙设计。这样做至少会带来以下两个好处。

1）同一地址域的网页会被存储在表中的连续位置，有利于用户查找和分析。

2）倒排便于数据压缩，可以大幅提高压缩率。

单个的大表由于规模问题不利于数据的处理，因此Bigtable将一个表分成了很多子表（Tablet），每个子表包含多个行。子表是Bigtable中数据划分和负载均衡的基本单位。有关子表的内容会在稍后详细讲解。

2．列

Bigtable并不是简单地存储所有的列关键字，而是将其组织成所谓的列族（Column Family），每个族中的数据都属于同一个类型，并且同族的数据会被压缩在一起保存。引入了列族的概念之后，列关键字就采用下述的语法规则来定义：

族名：限定词（family：qualifier）

族名必须有意义，限定词则可以任意选定。在图2-12中，内容（Contents）、锚点（Anchor，就是HTML中的链接）都是不同的族。而cnnsi.com和my.look.ca则是锚点族中不同的限定词。通过这种方式组织的数据结构清晰明了，含义也很清楚。族同时也是Bigtable中访问控制（Access Control）的基本单元，也就是说访问权限的设置是在族这一级别上进行的。

3．时间戳

Google的很多服务比如网页检索和用户的个性化设置等都需要保存不同时间的数据，这些不同的数据版本必须通过时间戳来区分。图2-12中内容列的t3、t5和t6表明其中保存了在t3、t5和t6这三个时间获取的网页。Bigtable中的时间戳是64位整型数，具体的赋值方式可以采取系统默认的方式，也可以用户自行定义。

为了简化不同版本的数据管理，Bigtable目前提供了两种设置：一种是保留最近的N个不同版本，图2-12中数据模型采取的就是这种方法，它保存最新的三个版本数据。另一种就是保留限定时间内的所有不同版本，比如可以保存最近10天的所有不同版本数据。失效的版本将会由Bigtable的垃圾回收机制自动处理。

2.4.3  系统架构

Bigtable是在Google的另外三个云计算组件基础之上构建的，其基本架构如图2-13所示^[11]。

图中WorkQueue是一个分布式的任务调度器，它主要被用来处理分布式系统队列分组和任务调度，关于其实现Google并没有公开。在前面已经讲过，GFS^[9]是Google的分布式文件系统，在Bigtable中GFS主要用来存储子表数据以及一些日志文件。Bigtable还需要一个锁服务的支持，Bigtable选用了Google自己开发的分布式锁服务Chubby。在Bigtable中Chubby主要有以下几个作用^[10]。

1）选取并保证同一时间内只有一个主服务器（Master Server）。

2）获取子表的位置信息。

3）保存Bigtable的模式信息及访问控制列表。

图2-13  Bigtable基本架构

另外在Bigtable的实际执行过程中，Google的MapReduce和Sawzall也被使用来改善其性能，不过需要注意的是这两个组件并不是实现Bigtable所必需的。

Bigtable主要由三个部分组成：客户端程序库（Client Library）、一个主服务器（Master Server）和多个子表服务器（Tablet Server），这三个部分在图2-13中都有相应的表示。从图2-13中可以看出，客户需要访问Bigtable服务时首先要利用其库函数执行Open()操作来打开一个锁（实际上就是获取了文件目录），锁打开以后客户端就可以和子表服务器进行通信了。和许多具有单个主节点的分布式系统一样，客户端主要与子表服务器通信，几乎不和主服务器进行通信，这使得主服务器的负载大大降低。主服务主要进行一些元数据的操作以及子表服务器之间的负载调度问题，实际的数据是存储在子表服务器上的。客户程序库的概念比较简单，这里不做讲解，下面对主服务器和子表服务器展开讲解。

2.4.4  主服务器

主服务的主要作用如图2-14所示。

图2-14  主服务器的主要作用

当一个新的子表产生时，主服务器通过一个加载命令将其分配给一个空间足够的子表服务器。创建新表、表合并以及较大子表的分裂都会产生一个或多个新子表。对于前面两种，主服务器会自动检测到，因为这两个操作是由主服务器发起的，而较大子表的分裂是由子服务发起并完成的，所以主服务器并不能自动检测到，因此在分割完成之后子服务器需要向主服务发出一个通知。由于系统设计之初就要求能达到良好的扩展性，所以主服务器必须对子表服务器的状态进行监控，以便及时检测到服务器的加入或撤销。Bigtable中主服务器对子表服务器的监控是通过Chubby来完成的，子表服务器在初始化时都会从Chubby中得到一个独占锁。通过这种方式所有的子表服务器基本信息被保存在Chubby中一个称为服务器目录（ServerDirectory）的特殊目录之中。主服务器通过检测这个目录就可以随时获取最新的子表服务器信息，包括目前活跃的子表服务器，以及每个子表服务器上现已分配的子表。对于每个具体的子表服务器，主服务器会定期向其询问独占锁的状态。如果子表服务器的锁丢失或没有回应，则此时可能有两种情况，要么是Chubby出现了问题（虽然这种概率很小，但的确存在，Google自己也做过相关测试），要么是子表服务器自身出现了问题。对此主服务器首先自己尝试获取这个独占锁，如果失败说明Chubby服务出现问题，需等待Chubby服务的恢复。如果成功则说明Chubby服务良好而子表服务器本身出现了问题。这种情况下主服务器会中止这个子表服务器并将其上的子表全部移至其他子表服务器。当在状态监测时发现某个子表服务器上负载过重时，主服务器会自动对其进行负载均衡操作。

基于系统出现故障是一种常态的设计理念（Google几乎所有的产品都是基于这个设计理念），每个主服务器被设定了一个会话时间的限制。当某个主服务器到时退出后，管理系统就会指定一个新的主服务器，这个主服务器的启动需要经历以下四个步骤^[8]。

1）从Chubby中获取一个独占锁，确保同一时间只有一个主服务器。

2）扫描服务器目录，发现目前活跃的子表服务器。

3）与所有的活跃子表服务器取得联系以便了解所有子表的分配情况。

4）通过扫描元数据表（Metadata Table），发现未分配的子表并将其分配到合适的子表服务器。如果元数据表未分配，则首先需要将根子表（Root Tablet）加入未分配的子表中。由于根子表保存了其他所有元数据子表的信息，确保了扫描能够发现所有未分配的子表。

在成功完成以上四个步骤后主服务器就可以正常运行了。

2.4.5  子表服务器

Bigtable中实际的数据都是以子表的形式保存在子表服务器上的，客户一般也只和子表服务器进行通信，所以子表以及子表服务器是我们重点讲解的概念。子表服务器上的操作主要涉及子表的定位、分配以及子表数据的最终存储问题。其中子表分配在前面已经有了详细介绍，这里略过不讲。在讲解其他问题之前我们首先介绍一下SSTable的概念以及子表的基本结构。

1．SSTable及子表基本结构

SSTable是Google为Bigtable设计的内部数据存储格式。所有的SSTable文件都是存储在GFS上的，用户可以通过键来查询相应的值，图2-15是SSTable格式的基本示意图。

图2-15  SSTable结构

SSTable中的数据被划分成一个个的块（Block），每个块的大小是可以设置的，一般来说设置为64KB。在SSTable的结尾有一个索引（Index），这个索引保存了SSTable中块的位置信息，在SSTable打开时这个索引会被加载进内存，这样用户在查找某个块时首先在内存中查找块的位置信息，然后在硬盘上直接找到这个块，这种查找方法速度非常快。由于每个SSTable一般都不是很大，用户还可以选择将其整体加载进内存，这样查找起来会更快。

从概念上来讲子表是表中一系列行的集合，它在系统中的实际组成如图2-16所示。

图2-16  子表实际组成

每个子表都是由多个SSTable以及日志（Log）文件构成的。有一点需要注意，那就是不同子表的SSTable可以共享，也就是说某些SSTable会参与多个子表的构成，而由子表构成的表则不存在子表重叠的现象。Bigtable中的日志文件是一种共享日志，也就是说系统并不是对子表服务器上每个子表都单独地建立一个日志文件，每个子表服务器上仅保存一个日志文件，某个子表日志只是这个共享日志的一个片段。这样会节省大量的空间，但在恢复时却有一定的难度，因为不同的子表可能会被分配到不同的子表服务器上，一般情况下每个子表服务器都需要读取整个共享日志来获取其对应的子表日志。Google为了避免这种情况出现，对日志做了一些改进。Bigtable规定将日志的内容按照键值进行排序，这样不同的子表服务器都可以连续读取日志文件了。一般来说每个子表的大小在100MB到200MB之间。每个子表服务器上保存的子表数量可以从几十到上千不等，通常情况下是100个左右。

2．子表地址

子表地址的查询是经常碰到的操作。在Bigtable系统的内部采用的是一种类似B+树的三层查询体系。子表地址结构如图2-17所示^[8]。

所有的子表地址都被记录在元数据表中，元数据表也是由一个个的元数据子表（Metadatatablet）组成的。根子表是元数据表中一个比较特殊的子表，它既是元数据表的第一条记录，也包含了其他元数据子表的地址，同时Chubby中的一个文件也存储了这个根子表的信息。这样在查询时，首先从Chubby中提取这个根子表的地址，进而读取

图2-17  子表地址结构

所需的元数据子表的位置，最后就可以从元数据子表中找到待查询的子表。除了这些子表的元数据之外，元数据表中还保存了其他一些有利于调试和分析的信息，比如事件日志等。

为了减少访问开销，提高客户访问效率，Bigtable使用了缓存（Cache）和预取（Prefetch）技术，这两种技术手段在体系结构设计中是很常用的。子表的地址信息被缓存在客户端，客户在寻址时直接根据缓存信息进行查找。一旦出现缓存为空或缓存信息过时的情况，客户端就需要按照图2-17所示方式进行网络的来回通信（Network Round-trips）进行寻址，在缓存为空的情况下需要三个网络来回通信。如果缓存的信息是过时的，则需要六个网络来回通信。其中三个用来确定信息是过时的，另外三个获取新的地址。预取则是在每次访问元数据表时不仅仅读取所需的子表元数据，而是读取多个子表的元数据，这样下次需要时就不用再次访问元数据表。

3．子表数据存储及读写操作

在数据的存储方面Bigtable做出了一个非常重要的选择，那就是将数据存储划分成两块。较新的数据存储在内存中一个称为内存表（Memtable）的有序缓冲里，较早的数据则以SSTable格式保存在GFS中。这种技术在数据库中不是很常用，但Google还是做出了这种选择，实际运行的效果也证明Google的选择虽然大胆却是正确的。

从图2-18^[8]中可以看出读和写操作有很大的差异性。做写操作（Write Op）时，首先查询Chubby中保存的访问控制列表确定用户具有相应的写权限，通过认证之后写入的数据首先被保存在提交日志（Commit Log）中。提交日志中以重做记录（Redo Record）的形式保存着最近的一系列数据更改，这些重做记录在子表进行恢复时可以向系统提供已完成的更改信息。数据成功提交之后就被写入内存表中。在做读操作（Read Op）时，首先还是要通过认证，之后读操作就要结合内存表和SSTable文件来进行，因为内存表和SSTable中都保存了数据。

在数据存储中还有一个重要问题，就是数据压缩的问题。内存表的空间毕竟是很有限的，当其容量达到一个阈值时，旧的内存表就会被停止使用并压缩成SSTable格式的文件。在Bigtable中有三种形式的数据压缩，分别是次压缩（Minor Compaction）、合并压缩（Merging Compaction）和主压缩（Major Compaction）。三者之间的关系如图2-19所示。

图2-18  Bigtable数据存储及读写操作

图2-19  三种形式压缩之间的关系

每一次旧的内存表停止使用时都会进行一个次压缩操作，这会产生一个SSTable。但如果系统中只有这种压缩的话，SSTable的数量就会无限制地增加下去。由于读操作要使用SSTable，数量过多的SSTable显然会影响读的速度。而在Bigtable中，读操作实际上比写操作更重要，因此Bigtable会定期地执行一次合并压缩的操作，将一些已有的SSTable和现有的内存表一并进行一次压缩。主压缩其实是合并压缩的一种，只不过它将所有的SSTable一次性压缩成一个大的SSTable文件。主压缩也是定期执行的，执行一次主压缩之后可以保证将所有的被压缩数据彻底删除，如此一来，既回收了空间又能保证敏感数据的安全性（因为这些敏感数据被彻底删除了）。

2.4.6  性能优化

上述各种操作已经可以实现Bigtable的所有功能了，但是这些基本的功能很多时候并不是很符合用户的使用习惯，或者执行的效率较低。有些功能Bigtable自身已经进行了优化，包括使用缓存、共享式的提交日志以及利用系统的不变性。这些手段在前面已经有了简单的介绍，这里不再讲解。除此之外，Bigtable还允许用户个人在基本操作基础上对系统进行一些优化。这一部分主要向读者介绍用户可以使用的几个重要优化措施。实际上这些技术手段都是一些已有的数据库方法，只不过Google将它具体地应用于Bigtable之中罢了。

1．局部性群组（Locality groups）

Bigtable允许用户将原本并不存储在一起的数据以列族为单位，根据需要组织在一个单独的SSTable中，以构成一个局部性群组。这实际上就是数据库中垂直分区技术的一个应用。结合图2-13的实例来看，在被Bigtable保存的网页列关键字中，有的用户可能只对网页内容感兴趣，那么它可以通过设置局部性群组只看内容这一列。有的则会对诸如网页语言、网站排名等可以用于分析的信息比较感兴趣，他也可以将这些列设置到一个群组中。局部性群组如图2-20所示。

图2-20  局部性群组

通过设置局部性群组用户可以只看自己感兴趣的内容，对某个用户来说的大量无用信息无需读取。对于一些较小的且会被经常读取的局部性群组，用户可以将其SSTable文件直接加载进内存，这可以明显地改善读取效率。

2．压缩

压缩可以有效地节省空间，Bigtable中的压缩被应用于很多场合。首先压缩可以被用在构成局部性群组的SSTable中，可以选择是否对个人的局部性群组的SSTable进行压缩。Bigtable中这种压缩是对每个局部性群组独立进行的，虽然这样会浪费一些空间，但是在需要读时解压速度非常快。通常情况下，用户可以采用两步压缩的方式^[8]：第一步利用Bentley & McIlroy方式（BMDiff）在大的扫描窗口将常见的长串进行压缩；第二步采取Zippy技术进行快速压缩，它在一个16KB大小的扫描窗口内寻找重复数据，这个过程非常快。压缩技术还可以提高子表的恢复速度，当某个子表服务器停止使用后，需要将上面所有的子表移至另一个子表服务器来恢复服务。在转移之前要进行两次压缩，第一次压缩减少了提交日志中的未压缩状态，从而减少了恢复时间。在文件正式转移之前还要进行一次压缩，这次压缩主要是将第一次压缩后遗留的未压缩空间进行压缩。完成这两步之后压缩的文件就会被转移至另一个子表服务器。

3．布隆过滤器（Bloom Filter）

Bigtable向用户提供了一种称为布隆过滤器^[12]的数学工具。布隆过滤器是巴顿·布隆在1970年提出的，实际上它是一个很长的二进制向量和一系列随机映射函数，在读操作中确定子表的位置时非常有用。布隆过滤器的速度快，省空间。而且它有一个最大的好处是它绝不会将一个存在的子表判定为不存在。不过布隆过滤器也有一个缺点，那就是在某些情况下它会将不存在的子表判断为存在。不过这种情况出现的概率非常小，跟它带来的巨大好处相比这个缺点是可以忍受的。

目前包括GoogleAnalytics、Google Earth、个性化搜索、Orkut和RRS阅读器在内的几十个项目都使用了Bigtable。这些应用对Bigtable的要求以及使用的集群机器数量都是各不相同的，但是从实际运行来看，Bigtable完全可以满足这些不同需求的应用，而这一切都得益于其优良的构架以及恰当的技术选择。与此同时Google还在不断地对Bigtable进行一系列的改进，通过技术改良和新特性的加入提高系统运行效率及稳定性。

参考文献

[1]    Sanjay Ghemawat, Howard Gobioff, Shun-Tak Leung. The Google FileSystem, Proceedings of 19th ACM Symposium on Operating Systems Principles,2003, 20-43

[2]    Sun “Lustre Networking: High-Performance Features and FlexibleSupport for a Wide Array of Networks”https://www.sun.com/offers/details/lustre_networking.xml

[3]    Soltis, Steven R; Erickson, Grant M; Preslan, Kenneth W (1997),“The Global File System: A File System for Shared Disk Storage”, IEEETransactions on Parallel and Distributed Systems

[4]    Schmuck, Frank; Roger Haskin (January 2002). "GPFS: AShared-Disk File System for Large Computing Clusters". Proceedings of theFAST'02 Conference on File and Storage Technologies.Monterey, California, USA

[5]    Wikipedia. http://zh.wikipedia.org/wiki/MapReduce

[6]    John Darlington, Yi-ke Guo, Hing Wing To. Structured parallelprogramming: theory meets practice. Computing tomorrow: future researchdirections in computer science book contents Pages: 49-65

[7]    Jeffrey Dean, Sanjay Ghemawant. MapReduce: Simpli_ed DataProcessing on Large Clusters

[8]    Chang F, Dean J, Ghemawat S, Hsieh WC, Wallach DA, Burrows M,Chandra T, Fikes A, Gruber RE. Bigtable: A distributed storage system forstructured data. In: Proc. of the 7th USENIX Symp. on Operating Systems Designand Implementation.Berkeley: USENIX Association, 2006.205-218

[9]    Ghemawat S, Gobioff H, Leung ST. The Google file system.In: Proc. of the 19th ACM Symp. on Operating Systems Principles. New York: ACM Press,2003. 29-43

[10]  Burrows M. The chubby lock service forloosely-coupled distributed systems. In: Proc. of the 7th USENIX Symp. onOperating Systems Design and Implementation.Berkeley: USENIX Association, 2006.335-350

[11]  陈康，郑纬民. 云计算：系统实例与研究现状。软件学报，2009，20(5)：1337-1348

[12]  BLOOM, B. H. Space/time trade-offs in hashcoding with allowable errors. CACM 13, 7 (1970), 422-426

[13]  BURROWS, M. The Chubby lock service forloosely-coupled distributed systems. In Proc. of the 7th OSDI,Nov, 2006

[14]  LAMPORT, L. The part-time parliament. ACM TOCS16,2 (1998), 133-169

[15]  LAMPORT, L. Paxos made simple. ACM SIGACT News32, 4 (2001), 18-25