多处理机与并行计算 课程论文 BigtableWord下载.docx
《多处理机与并行计算 课程论文 BigtableWord下载.docx》由会员分享，可在线阅读，更多相关《多处理机与并行计算 课程论文 BigtableWord下载.docx（15页珍藏版）》请在冰豆网上搜索。
4数据模型2
4.1行3
4.2列族4
4.3时间戳4
5组件5
5.1SSTable文件格式5
5.2Chubby分布式锁服务5
6原理与实现6
6.2Tablet的位置7
6.3Tablet分配8
6.3.1容灾处理9
6.4Tablet服务10
6.4.2数据的读取11
6.4.3数据的写入12
7性能优化13
7.1局部性群组13
7.2布隆过滤器13
8总结13
8.1实际应用13
8.1.1谷歌分析14
8.1.2谷歌地球14
8.2优点15
8.3缺点16
8.4未来发展16
9参考文献18
3绪论
背景介绍
Google是全球著名的互联网公司，拥有全球最大的谷歌搜索引擎，全球广泛使用的谷歌分析、谷歌地球、谷歌地图等核心业务。
多种不同的业务对数据存储系统提出了不同的要求，一些应用拥有巨大的数据规模，一些应用要求较低的读写延迟，甚至一些应用同时对两者提出了很高的要求，例如广泛使用的谷歌分析服务。
如何使用一种统一的方式来存储各种类型的数据是谷歌公司面临的巨大问题。
此外，谷歌每天要处理海量的服务请求，如何从海量的数据中快速寻找需要的数据，降低服务的延迟？
谷歌对数据存储系统具有很多需求，例如数据存储的可靠性，高速的数据检索与读取，要能够存储海量的数据（PB级）并且能够保存几率的多个版本。
谷歌的研究人员花费了两年半的时间设计、实现并部署了一个用于管理结构化数据的分布式的基于GFS和chubby的分布式存储系统，即Bigtable。
在设计Bigtable之初，谷歌的开发人员做了如下的假设：
●与写操作相比，数据记录读操作占绝大多数工作负载
●单个节点故障损坏是常见的
●磁盘是廉价的
●可以不提供标准接口
Bigtable的设计目的是可靠地适应PB级别的数据和成千上万台机器。
目前，Bigtable已经实现了下面的几个目标：
广泛的适用性（能够支持google系列产品的存储需求）、可扩展（能根据需要随时加入或撤销服务器）、高性能和高可用性（单个节点的损坏不会影响系统的正常运行），有超过60个Google的产品和项目在使用Bigtable，包括GoogleAnalytics、GoogleFinance、PersonalizedSearch和GoogleEarth。
这些产品使用Bigtable完成不同的工作负载需求，从面向吞吐量的批处理作业到对终端用户而言延时敏感的数据服务，实际应用证明了Bigtable具有相对Hbase等分布式系统具有高吞吐量，低延迟等特点，对全球的数据存储系统具有深远的影响。
Bigtable简介
Bigtable使用了很多数据库的实现策略。
虽然并行数据库和内存数据库已经具备可扩展性和高性能，但是Bigtable提供了一个和这些系统完全不同的接口。
Bigtable不支持完整的关系数据模型；
但Bigtable为客户提供了简单的数据模型，利用这个模型，客户可以动态控制数据的分布和格式。
也就是说，对Bigtable而言，数据是没有格式的，用户也可以自己推测底层存储数据的位置相关性。
例如树状结构，具有相同前缀的数据的存放位置接近，在读取的时候，可以把这些数据一次读取出来。
数据的下标是行和列的名字，名字可以是任意的字符串。
Bigtable将存储的数据都视为字符串，但是Bigtable本身不去解析这些字符串，客户程序通常会在把各种结构化或者半结构化的数据串行化到这些字符串里。
Bigtable具有如下的特点：
●适合大规模海量数据，PB级数据
●分布式、并发数据处理，效率极高
●易于扩展，支持动态伸缩
●适用于廉价设备
●适合于读操作，不适合写操作
●不适用于传统关系数据库
通过仔细选择数据的模式，客户可以控制数据的位置相关性。
最后，可以通过Bigtable的模式参数可以控制数据是存放在内存中、还是硬盘上。
4数据模型
Bigtable是一个稀疏的、分布式的、持久化存储的多维度排序Map，由key和value组成，Map中的key是由行关键字、列关键字以及时间戳索引组成；
Map中的每个value都是一个未经解析的字节数组。
可以看成一个有行关键字，列族，列，时间戳组成的一个四维的表格。
谷歌的研究人员对数据存储系统的种种潜在用途进行了分析之后，决定采用这样数据模型。
举个具体的例子，假设我们想要备份海量的网页及相关信息（谷歌搜索经常需要进行的过程），这些数据可以用于很多不同的项目，我们姑且称这个特殊的表为Webtable。
在Webtable里，我们使用URL作为行关键字，使用网页的各种属性作为列名，网页的内容存在“contents:
”列中，并用获取该网页的时间戳作为标识，这样就可以存储多个版本的网页数据，如图4-1所示。
图4-1Webtable示意图
图4-1展示了Webtable的一部分信息。
行名是一个反向URL，contents列存储的是网页的内容，其中contents列有三个版本，分别由时间戳t3,t11和t13标识。
4.2行
表中的行关键字是任意字符串，目前支持最大64KB的字符串，但是对大多数用户，10到100个字节就足够了。
在单一行关键字下的每一个读写操作都是原子的（不管在这一行里被读或者写的不同列的数目），这个设计决策能够使用户很容易地推测对同一个行进行并发更新操作时的系统行为。
Bigtable通过行关键字的字典顺序来维护数据。
表中的行被动态分区，每个分区成为一个Tablet，Tablet是数据分布和负载均衡的单位。
这样做的好处是，读取一定范围内的少数行会非常高效，往往只需要跟少数机器通信。
用户可以通过选择他们的行关键字来开发这种特性，这样可以为他们的数据访问获得好的本地性。
举例来说，我们在关键字com.google.maps/index.html的存储所有和谷歌地图相关的数据。
这种通过把相同的域中的网页存储在连续的区域的方式可以让一些主机和域名的分析更加有效。
列族
列关键字组成的集合叫做列族，列族是访问控制的基本单位。
存放在同一列族下的所有数据通常都属于同一个类型，可以把同一个列族下的数据压缩在一起。
列族必须先创建，然后才能在列族中任何的列关键字下存放数据；
列族创建后，其中的任何一个列关键字下都可以存放数据。
一张表中不同列族的数目要小（最多几百个），并且列族在操作中很少改变，但一张表可以有任意多个列。
列关键字的命名语法为列族：
限定词。
列族的名字必须是可打印的字符串，但是限定词可以是任意字符串。
比如，上述的Webtable有个列族language，用来存放撰写网页的语言。
我们在language列族中只使用一个列关键字，用来存放每个网页的语言标识ID。
Webtable中另一个列族是anchor；
这个列族的每一个列关键字代表单独一个锚链接，如图4-1所示。
限定词是引用该网页的站点名；
数据项内容是链接文本。
就像上面说的，列族是访问控制的基本单位，因此访问控制、磁盘和内存的计数都是在列族层面进行的。
在上述Webtable的例子中，控制权限能帮助我们管理不同类型的应用：
一些应用可以添加新的基本数据、一些可以读取基本数据并创建派生的列族、一些则只允许浏览现存数据，甚至可能因为隐私的原因不能浏览所有现存列族。
时间戳
在Bigtable中，每一个数据项都可以包含同一数据的不同版本；
这些版本通过时间戳来索引。
Bigtable时间戳是64位整数。
时间戳可由Bigtable指定，这种情况下时间戳代表精确到毫秒的实时时间，或者由用户程序明确指定。
数据项中不同版本按照时间戳倒序排列，所以最新的版本可以被先读到。
为了减轻多个版本数据的管理负担，Bigtable对每一个列族提供两个设置参数，用户可以指定只保存最后N个版本的数据，也可以只保存“足够新”的版本的数据，例如只保存最近7天写入的数据，Bigtable通过这两个参数可以对废弃版本的数据进行自动垃圾清理。
5组件
Bigtable是建立在一些其他Google基础架构之上的。
Bigtable使用Google分布式文件系统GFS存储日志和数据文件。
Bigtable集群往往运行在一个共享的机器集群中，集群中的机器还会运行其它各种各样的分布式应用程序，Bigtable的进程经常要和其它应用的进程共享机器。
Bigtable依赖集群管理系统在共享机器上调度作业、管理资源、处理机器的故障、以及监视机器的状态。
SSTable文件格式
Bigtable数据在内部使用GoogleSSTable文件格式存储。
每个Tablet有多个SSTable文件组成，SSTable文件存储在GFS上。
Bigtable依赖GFS存储数据和日志文件。
谷歌对SSTable提供了如下操作：
查询与一个指定key值相关的value，或者遍历指定key值范围内的所有键值对。
从内部看，SSTable是一连串的数据块（通常每个块的大小是64KB，但是这个大小是可以配置的）。
SSTable使用块索引来定位数据块；
在打开SSTable的时候，索引被加载到内存。
一次查找可以通过一次磁盘搜索完成：
首先执行二分查找在内存索引里找到合适数据块的位置，然后在从硬盘中读取合适的数据块。
也可以选择把整个SSTable都映射到内存中，这样就可以在不用访问硬盘的情况下执行查询搜索了。
Chubby分布式锁服务
Bigtable还依赖一个高可用的、持久化的分布式锁服务组件，叫做Chubby。
Bigtable使用Chubby完成以下各种任务：
保证在任意时间最多只有一个活动的Master；
存储Bigtable数据的引导程序的位置；
发现Tablet服务器，以及在Tablet服务器失效时进行问题处理；
存储Bigtable每张表的列族信息；
以及存储访问控制列表。
如果Chubby长时间无法访问，Bigtable就会失效。
谷歌在跨越11个Chubby服务实例的14个Bigtable集群上测量了这个影响。
Bigtable服务器时钟的平均比率是0.0047%，在这期间由于Chubby不可用而导致Bigtable中的部分数据不能访问（Chubby不能访问的原因可能是Chubby本身失效或者网络问题）。
单个集群里受Chubby失效影响最大的百分比是0.0326%。
6原理与实现
Bigtable的实现有三个主要的组件：
链接到每个客户程序的库、一个Master服务器和多个Tablet服务器。
在一个集群中可以动态地添加删除一个Tablet服务器来适应工作负载的变化，使得Bigtable具有较强的可扩展性，其系统结构图可由下图所示：
图6-1Bigtable系统结构图
在图6-1中，Master服务器主要负责以下工作：
●为Tablet服务器分配Tablet
●检测新加入的或者过期失效的Tablet服务器
●平衡Tablet服务器的负载
●探测Tablet服务器的故障与恢复
●与GFS垃圾回收进行交互，收回废弃的SSTable
除此之外，它还处理模式修改操作，例如建立表和列族。
每个Tablet服务器都管理一组Tablet，Tablet服务器处理它所管理的Tablet的读写操作，以及分割增长的过大的Tablet。
和很多单主节点（Single-Master）类型的分布式存储系统类似，客户数据都不经过Master服务器：
客户程序直接和Tablet服务器通信来进行读写操作。
由于Bigtable的客户程序不依赖Master服务器来获取Tablet的位置信息，大多数客户程序甚至完全不和Master服务器通信。
因此，在实际应用中Master服务器的负载是很轻的。
一个Bigtable集群存储了很多表，每个表包含了一组Tablet，而每个Tablet包含了某个范围内的行的所有相关数据。
初始状态下，每个表只有一个Tablet组成。
随着表中数据的增长，它被自动分割成多个Tablet，默认情况下每个Tablet的大小大约是100MB到200MB。
Tablet的位置
Bigtable使用一个三层的、类似于B+树的结构存储Tablet的位置信息。
如图6-2所示，第一层是一个存储在Chubby中的文件，它包含了RootTablet的位置信息。
RootTablet在一个特殊的元数据表包含了里所有的Tablet的位置信息。
每一个元数据Tablet包含了一组用户Tablet的位置信息。
RootTablet实际上只是元数据表的第一个Tablet，只不过对它的处理比较特殊，永远不会被分割，这保证了Tablet的位置层次不会超过三层。
图6-2Tablet定位层次图
元数据表将每个Tablet的位置信息存储在一个行关键字下，而这个行关键字是由Tablet所在的表的标识符和Tablet的最后一行编码而成的。
每一个元数据行在内存中大约存储了1KB数据。
在一个大小限制为128MB的元数据Tablet中，三层结构位置信息模式足够寻址234（1*217*217）个Tablet。
客户程序库会缓存Tablet的位置信息。
如果客户程序不知道一个Tablet的位置信息，或者发现它缓存的地址信息不正确，那么客户程序就递归移动到Tablet位置层次；
如果客户端缓存是空的，那么寻址算法需要通过三次网络来回通信寻址，这其中包括了一次Chubby读操作。
如果客户端缓存的地址信息过期了，那么寻址算法可能进行多达6次（其中的三次通信发现缓存过期，另外三次更新缓存数据）网络来回通信，因为过期的缓存只有在没有查到数据的时候才能发现。
尽管Tablet的位置信息是存放在内存里的，所以不需访问GFS，但是通常Bigtable会通过预取Tablet地址来进一步的减少访问开销。
在元数据表中还存储了次级信息，包括与Tablet有关的所有事件日志。
例如什么时候一个服务器开始为该Tablet提供服务，这些信息有助于排除故障和性能分析。
Tablet分配
每个Tablet一次分配给一个Tablet服务器。
Master服务器记录活跃的Tablet服务器、当前Tablet到Tablet服务器的分配、包括哪些Tablet还没有被分配。
当一个Tablet还没有被分配、并且有一个Tablet服务器有足够的空闲空间来装载该Tablet并且可用，Master通过给这个Tablet服务器发送一个Tablet装载请求分配该Tablet。
Bigtable使用Chubby跟踪记录Tablet服务器。
当一个Tablet服务器启动时，它在一个指定的Chubby目录下建立一个有唯一名字的文件，并且获取该文件的独占锁。
Master监控该目录（服务器目录）以便发现Tablet服务器。
如果Tablet服务器失去了Chubby上的独占锁，例如由于网络断开导致Tablet服务器丢失Chubby会话，它就停止对Tablet提供服务。
只要该文件还存在，Tablet服务器就会试图重新获得对该独占锁；
如果文件不存在了，那么Tablet服务器就永远不能再提供服务了，它会自行退出。
只要Tablet服务器终止（比如，集群的管理系统将该Tablet服务器的主机从集群中移除），它会尝试释放它持有的锁，以便Master尽快重新分配它的Tablet。
容灾处理
Master负责探测一个Tablet服务器何时不再为它的Tablet提供服务，并且尽快重新分配那些Tablet。
Master通过轮询Tablet服务器锁的状态来探测Tablet服务器何时不再为Tablet提供服务。
如果一个Tablet服务器报告它丢失了锁，或者Master最近几次尝试都无法和该服务器通信，Master就会尝试获取该Tablet服务器文件的独占锁；
如果Master能够获取独占锁，那么就说明Chubby是正常运行的，而Tablet服务器要么是宕机了、要么是不能和Chubby通信了。
因此，为了保证该Tablet服务器不能再提供服务，Master就删除该Tablet服务器在Chubby上的服务器文件。
一旦服务器文件被删除了，Master就把之前分配给该服务器的所有的Tablet放入未分配的Tablet集合中。
为了确保Bigtable集群面对Master和Chubby之间网络问题不那么脆弱，Master在它的Chubby会话过期时会主动退出。
但是不管怎样，如上所述，Master的故障不会改变现有Tablet到Tablet服务器的分配。
当集群管理系统启动了一个Master之后，Master首先要了解当前Tablet的分配状态，之后才能够修改它们。
Master在启动的时候执行以下步骤
a）Master在Chubby中获取一个唯一的Master锁，用来阻止并发的Master实例
b）Master扫描Chubby的服务器目录，获取寻找正在运行的服务器
c）Master和每一个正在运行的Tablet服务器通信，搜寻哪些Tablet已经分配到了Tablet服务器中
d）Master服务器扫描元数据表获取Tablet的集合。
只要扫描发现了一个还没有分配的Tablet，Master就将这个Tablet加入未分配的Tablet集合，该集合使该Tablet有机会参与Tablet分配。
有一种复杂情况是：
元数据Tablet还没有被分配之前是不能够扫描它的。
因此，在开始扫描之前（步骤d），如果在第三步中没有发现对RootTablet的分配，Master就把RootTablet加入到未分配的Tablet集合中。
这个附加操作确保了RootTablet会被分配。
由于RootTablet包括了所有元数据Tablet的名字，Master在扫描完RootTablet以后才了解所有元数据信息。
现存Tablet的集合只有在以下事件发生时才会改变:
●建立了一个新表或者删除了一个旧表
●两个现存Tablet合并组成一个大的Tablet、或者一个现存Tablet被分割成两个小的Tablet
Master可以跟踪这些改变，因为除了最后一个事件外的两个事件都是由它初始化的。
Tablet分割事件需要特殊处理，因为它是由Tablet服务器初始化的。
Tablet服务器通过在元数据表中为新的Tablet记录信息的方式提交分割操作。
在分割操作提交之后Tablet服务器会通知Master。
假如分割操作通知丢失（Tablet服务器或者Master宕机），Master在请求Tablet服务器装载已经被分割的Tablet的时候会探测到一个新的Tablet。
由于在元数据Tablet中发现的Tablet条目只是列举了Master请求加载的Tablet的一部分，Tablet服务器会通知Master分割信息。
Tablet服务
如图5所示，Tablet的持久化状态信息保存在GFS上。
更新操作提交到Redo日志中。
在这些更新操作中，最近提交的那些存放在一个叫做Memtable的排序的缓冲区中；
较早的更新存放在一系列SSTable中。
为了恢复一个Tablet，Tablet服务器在元数据表中读取它的元数据。
这些元数据包含组成一个Tablet的SSTable列表和一组还原点，这些点是指向包含Tablet数据的任一提交日志的指针。
Tablet服务器把SSTable的索引读进内存，之后通过应用还原点之后提交的所有更新来重构Memtable。
图6-3服务示意图
当写操作到达Tablet服务器时，Tablet服务器首先要检查这个操作格式是否正确、发送者是否有执行这个改变的权限。
权限验证是通过从一个Chubby文件里读取具有写权限的操作者列表来进行的。
有效的修改操作会记录在提交日志里。
可以采用组提交方式，当一个写操作提交后，它的内容被插入到Memtable里面。
数据的读取
当对Tablet服务器进行读操作时，Tablet服务器会作类似的完整性和权限检查。
一个有效的读操作在一个由一系列SSTable和Memtable合并的视图里执行。
由于SSTable和Memtable是按字典排序的数据结构，因此可以高效生成合并视图。
读取数据的流程如下：
1.读取本地Chubbyfile中的RootTablet的位置信息
2.读取RootTablet中的Metadata所有Tablet的位置信息（RootTablet中存储了表metadata的所有的Tablet的位置信息。
RootTablet就是Metadata表的第一个Tablet，只是RootTablet永远不会被分裂）
3.读取Metadata表的所有Tablet，这些Tablet中保存了其他所有Tablet的位置信息（每个MetadataTablet保存了一
升级会员 