1、电子工业出版社云计算(第二版)配套课件,解放军理工大学 刘鹏 教授主编 华东交通大学 刘鹏 制作,第2章 Google云计算原理与应用,云计算（第二版）购买网址： 当当网 京东商城,姊妹力作实战Hadoop购买网址： 当当网 京东商城,提 纲, Google文件系统GFS 分布式数据处理MapReduce 分布式锁服务Chubby 分布式结构化数据表Bigtable 分布式存储系统Megastore 大规模分布式系统的监控基础架构Dapper Google应用程序引擎, 系统架构 容错机制 系统管理技术,Google业务 全球最大搜索引擎、Google Maps、Google Earth、Gm
2、ail、YouTube等,数据量巨大，且面向全球用户提供实时服务,Google云计算平台技术架构 文件存储，Google Distributed File System，GFS 并行数据处理MapReduce 分布式锁Chubby 分布式结构化数据表BigTable 分布式存储系统Megastore 分布式监控系统Dapper,秘密武器：云计算平台！,GFS设计动机,Google需要一个支持海量存储的文件系统 购置昂贵的分布式文件系统与硬件？,为什么不使用当时现存的文件系统？Google所面临的问题与众不同不同的工作负载，不同的设计优先级（廉价、不可靠的硬件）需要设计与Google应用和负载相
3、符的文件系统,是否可以在一堆廉价且不可靠的硬件上构建可靠的分布式文件系统？,GFS将容错的任务交给文件系统完成，利用软件的方法解决系统可靠性问题，使存储的成本成倍下降。GFS将服务器故障视为正常现象，并采用多种方法，从多个角度，使用不同的容错措施，确保数据存储的安全、保证提供不间断的数据存储服务,GFS架构是怎样的？,系统架构,Client（客户端）：应用程序的访问接口 Master（主服务器）：管理节点，在逻辑上只有一个，保存系统的元数据，负责整个文件系统的管理 Chunk Server（数据块服务器）：负责具体的存储工作。数据以文件的形式存储在Chunk Server上,实现机制,客户端首
4、先访问Master节点，获取交互的Chunk Server信息，然后访问这些Chunk Server，完成数据存取工作。这种设计方法实现了控制流和数据流的分离。Client与Master之间只有控制流，而无数据流，极大地降低了Master的负载。Client与Chunk Server之间直接传输数据流，同时由于文件被分成多个Chunk进行分布式存储，Client可以同时访问多个Chunk Server，从而使得整个系统的I/O高度并行，系统整体性能得到提高。,GFS特点有哪些？,GFS特点, 系统架构 容错机制 系统管理技术,Master容错,Master,Name Space，文件系统目录结
5、构,Chunk与文件名的映射,Chunk副本的位置信息(默认有三个副本),Name Space，文件系统目录结构,Chunk与文件名的映射,Chunk副本的位置信息,Master,单个Master，对于前两种元数据，GFS通过操作日志来提供容错功能,第三种元数据信息保存在各个Chunk Server上，Master故障时，磁盘恢复,GFS还提供了Master远程的实时备份,防止Master彻底死机的情况,Chunk Server容错,采用副本方式实现Chunk Server容错 每一个Chunk有多个存储副本（默认为三个），分布存储在不同的Chunk Server上用户态的GFS不会影响Chu
6、nk Server的稳定性 副本的分布策略需要考虑多种因素，如网络的拓扑、机架的分布、磁盘的利用率等 对于每一个Chunk，必须将所有的副本全部写入成功，才视为成功写入,尽管一份数据需要存储三份，好像磁盘空间的利用率不高，但综合比较多种因素，加之磁盘的成本不断下降，采用副本无疑是最简单、最可靠、最有效，而且实现的难度也最小的一种方法。,Simple, and good enough!, GFS中的每一个文件被划分成多个Chunk，Chunk的默认大小是64MB Chunk Server存储的是Chunk的副本，副本以文件的形式进行存储每个Chunk又划分为若干Block（64KB），每个Blo
7、ck对应一个32bit的校验码，保证数据正确（若某个Block错误，则转移至其他Chunk副本）, 系统架构 容错机制 系统管理技术,大规模集 群安装技术,故障检测技术,节点动态加入技术,节能技术,新的Chunk Server加入时 ，只需裸机加入，大大减少GFS维护工作量,GFS构建在不可靠廉价计算机之上的文件系统，由于节点数目众多，故障发生十分频繁,Google采用了多种机制降低服务器能耗，如采用蓄电池代替昂贵的UPS,系统管理技术,GFS集群中通常有非常多的节点，需要相应的技术支撑,小结,简单的，就是最好的！,讨论,GFS有什么问题吗？,产生背景 编程模型 实现机制 案例分析,MapRe
8、duce 一种处理海量数据的并行编程模式，用于大规模数据集（通常大于1TB）的并行运算。 “Map（映射）”、“Reduce（化简）”的概念和主要思想，都是从函数式编程语言和矢量编程语言借鉴,适合非结构化和结构化的海量数据的搜索、挖掘、分析与机器智能学习等,Google拥有海量数据，并且需要快速处理,计算问题简单，但求解困难待处理数据量巨大（PB级），只有分布在成百上千个节点上并行计算才能在可接受的时间内完成如何进行并行分布式计算？如何分发待处理数据？如何处理分布式计算中的错误？,简单的问题，计算并不简单！,Jeffery Dean设计一个新的抽象模型， 封装并行处理、容错处理、本地化计算、负
9、载均衡的细节，还提供了一个简单而强大的接口 这就是MapReduce,Google MapReduce 架构设计师 Jeffrey Dean,产生背景 编程模型 实现机制 案例分析,MapReduce运行模型,Map函数对一部分原始数据进行指定的操作。每个Map操作都针对不同的原始数据，因此Map与Map之间是互相独立的，这使得它们可以充分并行化 Reduce操作对每个Map所产生的一部分中间结果进行合并操作，每个Reduce所处理的Map中间结果是互不交叉的，所有Reduce产生的最终结果经过简单连接就形成了完整的结果集,Map: (in_key, in_value) (keyj, valu
10、ej) | j = 1k Reduce: (key, value1,valuem) (key, final_value),开发者需编写 两个主要函数,Map输入参数：in_key和in_value，它指明了Map需要处理的原始数据 Map输出结果：一组对，这是经过Map操作后所产生的中间结果,Map: (in_key, in_value) (keyj, valuej) | j = 1k Reduce: (key, value1,valuem) (key, final_value),开发者需编写 两个主要函数,Reduce输入参数：（key, value1,valuem）Reduce工作：对这些
11、对应相同key的value值进行归并处理Reduce输出结果：（key, final_value），所有Reduce的结果并在一起就是最终结果,怎么用MapReduce计算一个大型文本文件中各单词出现次数？,产生背景 编程模型 实现机制 案例分析,MapReduce操作执行流程图,操作过程,（1）输入文件分成M块，每块大概16M64MB（可以通过参数决定），接着在集群的机器上执行分派处理程序（2）M个Map任务和R个Reduce任务需要分派，Master选择空闲Worker来分配这些Map或Reduce任务（3）Worker读取并处理相关输入块，Map函数产生的中间结果对暂时缓冲到内存 （4）
12、中间结果定时写到本地硬盘，分区函数将其分成R个区。中间结果在本地硬盘的位置信息将被发送回Master，然后Master负责把这些位置信息传送给Reduce Worker,操作过程,（5）当Master通知执行Reduce的Worker关于中间对的位置时，它调用远程过程，从Map Worker的本地硬盘上读取缓冲的中间数据。当Reduce Worker读到所有的中间数据，它就使用中间key进行排序，这样可使相同key的值都在一起（6）Reduce Worker根据每一个唯一中间key来遍历所有的排序后的中间数据，并且把key和相关的中间结果值集合传递给用户定义的Reduce函数。Reduce函数
13、的结果写到一个最终的输出文件（7）当所有的Map任务和Reduce任务都完成的时候，Master激活用户程序。此时MapReduce返回用户程序的调用点,MapReduce容错,Master周期性地给Worker发送ping命令，若没有应答，则认为Worker失效，终止其任务调度，把该任务调度到其他Worker上重新执行,Master会周期性地设置检查点（checkpoint），并导出Master的数据。一旦某个任务失效，系统就从最近的一个检查点恢复并重新执行,MapReduce容错,产生背景 编程模型 实现机制 案例分析,假设有一批海量的数据，每个数据都是由26个字母组成的字符串，原始的数据
14、集合是完全无序的，怎样通过MapReduce完成排序工作，使其有序（字典序）呢？,排序通常用于衡量分布式数据处理框架的数据处理能力,对原始的数据进行分割（Split），得到N个不同的数据分块,每一个数据分块都启动一个Map进行处理。采用桶排序的方法，每个Map中按照首字母将字符串分配到26个不同的桶中,按照首字母将Map中不同桶中的字符串集合放置到相应的Reduce中进行处理。具体来说就是首字母为a的字符串全部放在Reduce1中处理，首字母为b的字符串全部放在Reduce2，以此类推, Paxos算法 Chubby系统设计 Chubby中的Paxos Chubby文件系统 通信协议 正确性与
15、性能,一种建议性的锁而不是强制性的锁；具有更大的灵活性,GFS使用Chubby选取一个GFS主服务器 Bigtable使用Chubby指定一个主服务器并发现、控制与其相关的子表服务器 Chubby还可以作为一个稳定的存储系统存储包括元数据在内的小数据 Google内部还使用Chubby进行名字服务（Name Server）,ChubbyGoogle设计的提供粗粒度锁服务的一个文件系统，它基于松耦合分布式系统，解决了分布的一致性问题,Paxos算法,Paxos算法 Leslie Lamport最先提出的一种基于消息传递（Messages Passing）的一致性算法，用于解决分布式系统中的一致性
16、问题,分布式系统一致性问题就是如何保证系统中初始状态相同的各个节点在执行相同的操作序列时，看到的指令序列是完全一致的，并且最终得到完全一致的结果,一个最简单的方案在分布式系统中设置一个专门节点，在每次需要进行操作之前，系统的各个部分向它发出请求，告诉该节点接下来系统要做什么。该节点接受第一个到达的请求内容作为接下来的操作，这样就能够保证系统只有一个唯一的操作序列,方案存在什么缺陷？,Paxos算法,缺陷专门节点失效，整个系统就很可能出现不一致。为了避免这种情况，在系统中必然要设置多个专门节点，由这些节点来共同决定操作序列,Paxos算法,proposers提出决议（Value，系统接下来执行的
17、指令） acceptors批准决议 learners获取并使用已经通过的决议,Paxos算法,（1）决议只有被proposers提出后才 能批准,（2）每次只批准一个决议,（3）只有决议确定被批准后learners 才能获取这个决议,保证数据的一致性,Paxos算法,P1：每个acceptor只接受它得到的第一个决议,系统约束条件,P1表明一个acceptor可以收到多个决议，为区分，对每个决议进行编号，后到的决议编号大于先到的决议编号 ；约束条件P1不是很完备 ！,P2：一旦某个决议得到通过，之后通过的决议必须和该决议保持一致,P2a：一旦某个决议v得到通过，之后任何acceptor再批准的
18、决议必须是v,P2a和P1是有矛盾的 !,P2b：一旦某个决议v得到通过，之后任何proposer再提出的决议必须是v,P1和P2b保证条件（2），彼此之间不存在矛盾。但是P2b很难通过一种技术手段来实现它，因此提出了一个蕴涵P2b的约束P2c,P2c：如果一个编号为n的提案具有值v，那么存在一个“多数派”，要么它们中没有谁批准过编号小于n的任何提案，要么它们进行的最近一次批准具有值v,Paxos算法,决议通过的两个阶段,准备阶段：proposers选择一个提案并将它的编号设为n，然后将它发送给acceptors中的一个“多数派”。Acceptors 收到后，如果提案的编号大于它已经回复的所有
19、消息，则acceptors将自己上次的批准回复给proposers，并不再批准小于n的提案,批准阶段：当proposers接收到acceptors 中的这个“多数派”的回复后，就向回复请求的acceptors发送accept请求，在符合acceptors一方的约束条件下，acceptors收到accept请求后即批准这个请求,解决一致性问题算法：为了减少决议发布过程中的消息量，acceptors将这个通过的决议发送给learners 的一个子集，然后由这个子集中的learners 去通知所有其他的learners；特殊情况：如果两个proposer在这种情况下都转而提出一个编号更大的提案，那么
20、就可能陷入活锁。此时需要选举出一个president，仅允许 president提出提案, Paxos算法 Chubby系统设计 Chubby中的Paxos Chubby文件系统 通信协议 正确性与性能,系统设计目标,Chubby系统设计,高可用性和高可靠性；首要目标，在保证这一目标的基础上再考虑系统的吞吐量和存储能力,高扩展性；将数据存储在价格较为低廉的RAM，支持大规模用户访问文件,支持粗粒度的建议性锁服务；提供这种服务的根本目的是提高系统的性能,服务信息的直接存储；可直接存储包括元数据、系统参数在内的有关服务信息,支持通报机制；客户可以及时地了解到事件发生,支持缓存机制；通过一致性缓存将
21、常用信息保存在客户端，避免了频繁地访问主服务器,Chubby系统设计,Chubby中还添加了一些新的功能特性；这种设计主要是考虑到以下几个问题,03,02,01,开发者初期很少考虑系统的一致性，但随着开发进行，问题会变得越来越严重。单独的锁服务可以保证原有系统架构不会发生改变，而使用函数库很可能需要对系统架构做出大幅度的改动,系统中很多事件发生是需要告知其他用户和服务器，使用一个基于文件系统的锁服务可以将这些变动写入文件中。有需要的用户和服务器直接访问这些文件即可，避免因大量系统组件之间事件通信带来系统性能下降,基于锁的开发接口容易被开发者接受。虽然在分布式系统中锁的使用会有很大的不同，但是和
22、一致性算法相比，锁显然被更多的开发者所熟知,Chubby系统设计,Paxos算法实现过程中需要一个“多数派”就某个值达成一致，本质上就是分布式系统中常见的quorum机制；为保证系统高可用性，需要若干台机器，但使用单独锁服务的话一台机器也能保证这种高可用性,Chubby设计过程中一些细节问题值得关注： 在Chubby系统中采用了建议性的锁而没有采用强制性的锁。两者的根本区别在于用户访问某个被锁定的文件时，建议性的锁不会阻止访问，而强制性的锁则会阻止访问，实际上这是为了方便系统组件之间的信息交互 另外，Chubby还采用了粗粒度（Coarse-Grained）锁服务而没有采用细粒度（Fine-G
23、rained）锁服务，两者的差异在于持有锁的时间，细粒度的锁持有时间很短,Chubby系统设计,Chubby基本架构：客户端和服务器端，两者通过远程过程调用（RPC）来连接 客户端每个客户应用程序都有一个Chubby程序库（Chubby Library），所有应用都是通过调用这个库中相关函数来完成 服务器一端Chubby单元，一般由五个称为副本（Replica）服务器组成，它们配置上完全一致，且系统刚开始时处于对等地位, Paxos算法 Chubby系统设计 Chubby中的Paxos Chubby文件系统 通信协议 正确性与性能,Chubby中的Paxos,单个Chubby副本结构,容错日志
24、对数据库正确性提供重要支持；一致性由Paxos算法保证；副本之间通过特定的Paxos协议通信，同时本地文件中保存与Chubby中相同的日志数据,容错数据库快照（Snapshot）和记录数据库操作重播日志（Replay-log）；每一次的数据库操作最终都将提交至日志中；本地文件中也保存着一份数据库数据副本,Chubby构建在这个容错的数据库之上，Chubby利用这个数据库存储所有的数据。Chubby的客户端通过特定的Chubby协议和单个的Chubby副本进行通信,Chubby中的Paxos,容错日志的API,Content Title,Content Title,Chubby中Paxos算法过
25、程,2、协调者从客户提交的值中选择一个，accept消息广播给所有的副本，其他的副本收到广播后，选择接受或者拒绝这个值，并将决定结果反馈,3、协调者收到大多数副本接受信息后，认为达到了一致性，接着向相关副本发送一个commit消息,1、选择一副本为协调者（Coordinator）,Chubby中的Paxos,Chubby设计者借鉴了Paxos的两种解决机制：给协调者指派序号或限制协调者可以选择的值 指派序号的方法 （1）在一个有n个副本系统中，为每个副本分配一个id ，其中 0irn-1。则副本的序号，其中k的初始值为0 （2）某个副本想成为协调者之后，它就根据规则生成一个比它以前的序号更大的
26、序号（实际上就是提高k的值），并将这个序号通过propose消息广播给其他所有的副本 （3）如果接受到广播的副本发现该序号比它以前见过的序号都大，则向发出广播的副本返回一个promise消息，并且承诺不再接受旧的协调者发送的消息。如果大多数副本都返回了promise消息，则新的协调者就产生了 限制协调者可以选择的值 Paxos强制新的协调者必须选择和前任相同的值,Chubby中的Paxos,Chubby做了一个重要优化来提高系统效率在选择某一个副本作为协调者之后就长期不变，此时协调者就被称为主服务器（Master）客户端的数据请求由主服务器完成，Chubby保证在一定时间内有且仅有一个主服务器
27、，这个时间就称为主服务器租约期（Master Lease）客户端需要确定主服务器的位置，可向DNS发送一个主服务器定位请求，非主服务器的副本将对该请求做出回应 Chubby对于Paxos论文中未提及的一些技术细节进行了补充，所以Chubby的实现是基于Paxos，但其技术手段更加的丰富，更具有实践性, Paxos算法 Chubby系统设计 Chubby中的Paxos Chubby文件系统 通信协议 正确性与性能,Chubby文件系统,Chubby系统本质上就是一个分布式的、存储大量小文件的文件系统，它所有的操作都是在文件的基础上完成Chubby最常用的锁服务中，每一个文件就代表一个锁，用户通过
28、打开、关闭和读取文件，获取共享（Shared）锁或独占（Exclusive）锁选举主服务器过程中，符合条件的服务器都同时申请打开某个文件并请求锁住该文件成功获得锁的服务器自动成为主服务器并将其地址写入这个文件夹，以便其他服务器和用户可以获知主服务器的地址信息,Chubby文件系统,Chubby的文件系统和UNIX类似例如在文件名“/ls/foo/wombat/pouch”中，ls代表lock service，这是所有Chubby文件系统的共有前缀；foo是某个单元的名称；/wombat/pouch则是foo这个单元上的文件目录或者文件名 Google对Chubby做了一些与UNIX不同的改变例
29、如Chubby不支持内部文件的移动；不记录文件的最后访问时间；另外在Chubby中并没有符号连接（Symbolic Link，又叫软连接，类似于Windows系统中的快捷方式）和硬连接（Hard Link，类似于别名）的概念 在具体实现时，文件系统由许多节点组成，分为永久型和临时型，每个节点就是一个文件或目录。节点中保存着包括ACL（Access Control List，访问控制列表）在内的多种系统元数据,实例号：新节点实例号必定大于旧节点的实例号,元数据包含以下四种单调递增64位编号,内容生成号：文件内容修改时该号增加,锁生成号：锁被用户持有时该号增加,ACL生成号：ACL名被覆写时该号增
30、加,Chubby文件系统,Chubby文件系统,用户打开某个节点的同时会获取一个类似于UNIX中文件描述符（File Descriptor）的句柄，这个句柄由以下三个部分组成,Chubby文件系统,在实际执行中，为了避免所有的通信都使用序号带来系统开销增长，Chubby引入了sequencer的概念 sequencer实际上就是一个序号，只能由锁的持有者在获取锁时向系统发出请求来获得。这样一来Chubby系统中只有涉及锁的操作才需要序号，其他一概不用。 在文件操作中，用户可以将句柄看做一个指向文件系统的指针,常用句柄函数及其作用, Paxos算法 Chubby系统设计 Chubby中的Paxo
31、s Chubby文件系统 通信协议 正确性与性能,Chubby客户端与服务器端的通信过程,从左到右的水平方向表示时间在增加，斜向上的箭头表示一次KeepAlive请求，斜向下的箭头则是主服务器的一次回应 M1、M2、M3表示不同的主服务器租约期；C1、C2、C3则是客户端对主服务器租约期时长做出的一个估计 KeepAlive是周期发送的一种信息，它主要有两方面的功能：延迟租约的有效期和携带事件信息告诉用户更新,故障处理,客户端租约过期,客户端向主服务器发出一个KeepAlive请求（上图1） 如果有需要通知的事件时则主服务器会立刻做出回应，否则等到客户端的租约期C1快结束的时候才做出回应（图2
32、），并更新主服务器租约期为M2 客户端接到回应后认为该主服务器仍处于活跃状态，于是将租约期更新为C2并立刻发出新的KeepAlive请求（图3） 宽限期内，客户端不会立刻断开其与服务器端的联系，而是不断地做探询，当它接到客户端的第一个KeepAlive请求（图4）时会拒绝（图5） 客户端在主服务器拒绝后使用新纪元号来发送KeepAlive请求（图6） 新的主服务器接受这个请求并立刻做出回应（图7） 如果客户端接收到这个回应的时间仍处于宽限期内，系统会恢复到安全状态，租约期更新为C3。如果在宽限期未接到主服务器的相关回应，客户端终止当前的会话,故障处理,主服务器出错,正常情况下旧的主服务器出现故
33、障后系统会很快地选举出新的主服务器，新选举需要经历以下九个步骤：（1）产生一个新的纪元号以便今后客户端通信时使用，这能保证当前的主服务器不必处理针对旧的主服务器的请求（2）只处理主服务器位置相关的信息，不处理会话相关的信息（3）构建处理会话和锁所需的内部数据结构（4）允许客户端发送KeepAlive请求，不处理其他会话相关的信息（5）向每个会话发送一个故障事件，促使所有的客户端清空缓存（6）等待直到所有的会话都收到故障事件或会话终止（7）开始允许执行所有的操作（8）如果客户端使用了旧的句柄则需要为其重新构建新的句柄（9）一定时间段后（1分钟），删除没有被打开过的临时文件夹,如果这一过程在宽限期
34、内顺利完成，则用户不会感觉到任何故障的发生，也就是说新旧主服务器的替换对于用户来说是透明的，用户感觉到的仅仅是一个延迟,系统实现时，Chubby还使用了一致性客户端缓存（Consistent Client-Side Caching）技术，这样做的目的是减少通信压力，降低通信频率 在客户端保存一个和单元上数据一致的本地缓存，需要时客户可以直接从缓存中取出数据而不用再和主服务器通信当某个文件数据或者元数据需要修改时，主服务器首先将这个修改阻塞；然后通过查询主服务器自身维护的一个缓存表，向对修改的数据进行了缓存的所有客户端发送一个无效标志（Invalidation）客户端收到这个无效标志后会返回一个
35、确认（Acknowledge），主服务器在收到所有的确认后才解除阻塞并完成这次修改,这个过程的执行效率非常高，仅仅需要发送一次无效标志即可，因为对于没有返回确认的节点，主服务器直接认为其是未缓存, Paxos算法 Chubby系统设计 Chubby中的Paxos Chubby文件系统 通信协议 正确性与性能,一致性,每个Chubby单元是由五个副本组成的，这五个副本中需要选举产生一个主服务器，这种选举本质上就是一个一致性问题。实际执行过程中，Chubby使用Paxos算法来解决主服务器产生后客户端的所有读写操作都是由主服务器来完成的读操作很简单，客户直接从主服务器上读取所需数据即可写操作就会涉
36、及数据一致性的问题；为了保证客户的写操作能够同步到所有的服务器上，系统再次利用了Paxos算法,安全性,Chubby用ACL形式安全保障措施。系统有三种ACL名：写ACL名（Write ACL Name）、读ACL名（Read ACL Name）和变更ACL名（Change ACL Name）只要不被覆写，子节点都是直接继承父节点的ACL名 ACL同样被保存在文件中，它是节点元数据的一部分，用户在进行相关操作时首先需要通过ACL来获取相应的授权,Chubby的ACL机制,用户chinacloud提出向文件CLOUD中写入内容请求。CLOUD首先读取自身的写ACL名fun，接着在fun中查到了c
37、hinacloud这一行记录，于是返回信息允许chinacloud对文件进行写操作，此时chinacloud才被允许向CLOUD写入内容。其他的操作和写操作类似,性能优化,为满足系统高可扩展性，Chubby目前已经采取了一些措施：比如提高主服务器默认的租约期、使用协议转换服务将Chubby协议转换成较简单的协议、客户端一致性缓存等；除此之外，Google的工程师们还考虑使用代理（Proxy）和分区（Partition）技术 代理可以减少主服务器处理KeepAlive以及读请求带来的服务器负载，但是它并不能减少写操作带来的通信量 使用分区技术的话可以将一个单元的命名空间（Name Space）划
38、分成N份。除了少量的跨分区通信外，大部分的分区都可以独自地处理服务请求。通过分区可以减少各个分区上的读写通信量，但不能减少KeepAlive请求的通信量,设计动机与目标 数据模型 系统架构 主服务器 子表服务器 性能优化,设计动机与目标,需要存储的数据种类繁多：Google目前向公众开放的服务很多，需要处理的数据类型也非常多。包括URL、网页内容、用户的个性化设置在内的数据都是Google需要经常处理的,海量的服务请求：Google运行着目前世界上最繁忙的系统，它每时每刻处理的客户服务请求数量是普通的系统根本无法承受的,商用数据库无法满足Google的需求：一方面现有商用数据库设计着眼点在于通
39、用性，根本无法满足Google的苛刻服务要求；另一方面对于底层系统的完全掌控会给后期的系统维护、升级带来极大的便利,设计动机,设计动机与目标,基本目标,高可用性,Bigtable设计的重要目标之一就是确保几乎所有的情况下系统都可用,广泛的适用性,Bigtable是为了满足系列Google产品而非特定产品存储要求,简单性,底层系统简单性既可减少系统出错概率，也为上层应用开发带来便利,很强的可扩展性,根据需要随时可以加入或撤销服务器,设计动机与目标 数据模型 系统架构 主服务器 子表服务器 性能优化,数据模型,Bigtable是一个分布式多维映射表，表中的数据通过一个行关键字（Row Key）、一
40、个列关键字（Column Key）以及一个时间戳（Time Stamp）进行索引 Bigtable对存储在其中的数据不做任何解析，一律看做字符串 Bigtable的存储逻辑可以表示为： (row:string, column:string, time:int64)string,Bigtable数据模型,数据模型,行Bigtable的行关键字可以是任意的字符串，但是大小不能超过64KB。Bigtable和传统的关系型数据库有很大不同，它不支持一般意义上的事务，但能保证对于行的读写操作具有原子性（Atomic）表中数据都是根据行关键字进行排序的，排序使用的是词典序。一个典型实例，其中n.www就是
41、一个行关键字。不直接存储网页地址而将其倒排是Bigtable的一个巧妙设计。这样做至少会带来以下两个好处 同一地址域的网页会被存储在表中的连续位置，有利于用户查找和分析 倒排便于数据压缩，可以大幅提高压缩率,数据模型,列 Bigtable并不是简单地存储所有的列关键字，而是将其组织成所谓的列族（Column Family），每个族中的数据都属于同一个类型，并且同族的数据会被压缩在一起保存。引入了列族的概念之后，列关键字就采用下述的语法规则来定义：族名：限定词（family：qualifier）族名必须有意义，限定词则可以任意选定图中，内容（Contents）、锚点（Anchor）都是不同的族。
42、而和my.look.ca则是锚点族中不同的限定词族同时也是Bigtable中访问控制（Access Control）基本单元，也就是说访问权限的设置是在族这一级别上进行的,数据模型,时间戳Google的很多服务比如网页检索和用户的个性化设置等都需要保存不同时间的数据，这些不同的数据版本必须通过时间戳来区分。图2中内容列的t3、t5和t6表明其中保存了在t3、t5和t6这三个时间获取的网页。Bigtable中的时间戳是64位整型数，具体的赋值方式可以采取系统默认的方式，也可以用户自行定义为了简化不同版本的数据管理，Bigtable目前提供了两种设置：一种是保留最近的N个不同版本，图中数据模型采取
43、的就是这种方法，它保存最新的三个版本数据。另一种就是保留限定时间内的所有不同版本，比如可以保存最近10天的所有不同版本数据。失效的版本将会由Bigtable的垃圾回收机制自动处理,设计动机与目标 数据模型 系统架构 主服务器 子表服务器 性能优化,系统架构,一个分布式的任务调度器，主要被用来处理分布式系统队列分组和任务调度,系统架构,在Bigtable中Chubby主要有以下几个作用： （1）选取并保证同一时间内只有一个主服务器（Master Server） （2）获取子表的位置信息 （3）保存Bigtable的模式信息及访问控制列表 另外在Bigtable的实际执行过程中，Google的Ma
44、pReduce 和Sawzall也被用来改善其性能,系统架构,Bigtable主要由三个部分组成：客户端程序库（Client Library）、一个主服务器（Master Server）和多个子表服务器（Tablet Server）客户访问Bigtable服务时，首先要利用其库函数执行Open()操作来打开一个锁（实际上就是获取了文件目录），锁打开以后客户端就可以和子表服务器进行通信和许多具有单个主节点分布式系统一样，客户端主要与子表服务器通信，几乎不和主服务器进行通信，这使得主服务器的负载大大降低主服务主要进行一些元数据操作以 及子表服务器之间负载调度问题， 实际数据是存储在子表服务器上,谢 谢！,http:/,
