北京大学硕士研究生学位论文.docx

1、北京大学硕士研究生学位论文北京大学硕士研究生学位论文题目：Bighive：一个针对时间维度优化的分布式结构化数据存储系统姓 名： 涂启琛 学 号： 10648182 院 系： 信息科学与技术学院 专 业： 计算机系统结构 研究方向：计算机网络与分布式系统 导师姓名： 李晓明 教授 二00九 年 六 月版权声明任何收存和保管本论文各种版本的单位和个人，未经本论文作者同意，不得将本论文转借他人，亦不得随意复制、抄录、拍照或以任何方式传播。否则，引起有碍作者著作权之问题，将可能承担法律责任。摘要“中国Web信息博物馆”(Web InfoMall)4，是一个针对中国互联网信息的搜集、存储与历史浏览服务

2、的海量信息系统，5 年来已经积累超过25 亿中国互联网上出现过的网页，数据量已经超过30TB。随着数据量的持续增长，现有的Infomall存储和服务系统已不能满足要求，使得其中的数据存储和访问变得越来越困难。为解决这一问题，本文首先分析了Infomall数据特征及其访问特性。在数据上，InfoMall中网页历史数据规模庞大，具有空间和时间两个方面的维度，我们发现数据在这两个维度上无界增长，表现出高度的不平衡性。其次，在访问上，InfoMall中的所有请求都带有时间和空间两方面维度的约束。本文工作通过具体分析Web InfoMall的数据和访问特点，针对访问性能优化而设计了一种带时间索引的数据存

3、储格式TSFile，实验表明其对InfoMall数据存储和访问需求的有效性。在此基础上，我们设计并实现一个的分布式结构化数据存储系统Bighive，并评测验证了其可行性。不失一般性，本文所研究的针对时间维度优化的分布式结构化数据存储技术，不仅能处理好InfoMall中的数据，也能很好的作为一个通用的结构化数据存储系统。关键词：Bigtable、中国网页信息博物馆、分布式、结构化数据、存储系统Bighive: An Optimized Distributed Data Storage System on time dimensionAbstractChinese Web Museum (Web

4、InfoMall)4 is a system for crawling, storing and exhibiting all the web pages being on or once been on the web. For the past 5 years, the system has stored 2.5 billion web pages, and the overall data size is more than 30TB. As its load continues growing, the storage and access of data become more an

5、d more difficult. Since the current system cannot meet our daily request due to the specific character of its data distribution, an optimized distributed data storage system is in urgent need.The present Chinese Web Museum has several problems. First, the overall data has a huge size on both space a

6、nd time dimensions with rapid growth. Second, all requests to this system suffer great limitations on the above 2 dimensions.To resolve the problems mentioned above, this paper propose a brand-new data storage format called TSFile, qualify its suitableness for the InfoMall. After that, The paper des

7、cribes the design, implementation and evaluation of Bighive, and discusses issues related to the system in detail.Keywords: Bigtable, Chinese Web Museum, Distributed System, Structured Data, Storage System目录第一章 引言 - 6 -1.1 工作背景与动机 - 6 -1.2 问题描述 - 7 -1.3 术语定义 - 8 -1.4 本文结构 - 9 -第二章 相关工作与研究 - 10 -2.1

8、相关系统 - 10 -2.2 近期相关研究 - 12 -第三章 数据模型与存储设计 - 13 -3.1 数据模型 - 13 -3.1.1 Web InfoMall的数据特征 - 13 -3.1.2 Web InfoMall的访问特征 - 15 -3.1.3 Bigtable存储方案在InfoMall应用上的不足 - 17 -3.2 Bighive存储设计 - 17 -3.2.1 带时间维度索引的存储格式(TSFile) - 18 -3.2.2 Tablet管理 - 22 -3.2.3 TSFile的有效性 - 23 -第四章 Bighive设计与实现 - 25 -4.1 体系结构 - 25 -

9、4.2 Debby 和Tablet元数据的管理 - 25 -4.3 Tianwang File System和后台数据的存储 - 27 -4.4 Master主控节点 - 28 -4.4.1 启动流程 - 29 -4.4.2 主要功能 - 30 -4.4.3 负载均衡 - 30 -4.5 TabletServer服务节点 - 31 -4.5.1 节点初始化 - 32 -4.5.2 Write-Log和Checkpoint - 33 -4.5.3 缓存管理 - 37 -4.5.4 Tablet分裂 - 38 -4.6 客户端(Client)接口与实现 - 39 -4.7 错误处理与恢复 - 41

10、 -第五章 实验 - 43 -5.1 随机读实验 - 43 -5.2 可扩展性实验 - 44 -5.3 Scan实验 - 45 -第六章 总结与未来工作 - 47 -6.1 本文贡献 - 47 -6.2 未来工作 - 47 -图表目录图表 3-1 InfoMall中网页的版本数 - 14 -图表 3-2 InfoMall中网页抓取时间的间隔 - 15 -图表 3-3 TSFile结构 - 19 -图表 3-4 索引详细结构 - 20 -图表 3-5 块的查找算法 - 22 -图表 3-6 网页不同版本数时TSFile查找与顺序查找的性能对比 - 23 -图表 3-7 不同网页版本数目所占的比例

11、 - 24 -图表 4-1 系统总体结构图 - 25 -图表 4-2 Master中的元数据 - 29 -图表 4-3 TabletServer数据的写操作流程 - 33 -图表 5-1 随机读响应时间 - 43 -图表 5-2客户端数目与总的随机读速度 - 44 -图表 5-3 系统可扩展性 - 45 -图表 5-4 Scan读取效率 - 46 -第一章 引言1.1 工作背景与动机随着现代社会向信息化的快速推进，数据的海量性在各方面的体现越来越突出，从网络流量数据，到移动通信用户行为记录；从搜索引擎的日志数据，到银行的客户操作记录，等等。这些海量信息与生俱来的数字化与网络化性质，在给人们带来

12、了改善服务机遇的同时也提出了许多新的技术挑战，结构化数据的存储和访问就是其中的问题之一。以往当人们需要存储结构化数据时，数据库通常是首选的解决方案，在数据规模不大时，其可以提供便捷、稳定的服务。然而随着数据量的增长，特别是当Web时代来临后，针对动辄TB级的庞大数据，传统的数据库在处理海量的数据时显的力不从心。针对这种情况，以Google为代表的搜索引擎公司做出了巨大努力，开发了一系列的数据处理基础设施来存储和处理这些海量数据，这也引发了现在工业界所谓的云计算(Cloud Computing)的热潮。代表性的系统包括Goolge的Google File System(GFS)1、Map-Red

13、uce2、Bigtable3等。所谓云计算，狭义的讲可以认为是一种数据处理的基础设置，其有以下几个特征: 第一，超大规模。“云”应该具有相当的规模，规模不仅仅指服务器的数量规模，也是指处理的数据规模。Google分布在世界各地的机房中拥有上百万台服务器，Amazon、IBM、Microsoft、Yahoo等公司的“云”中也至少拥有几十万台服务器。这些“云”中存储和处理着P量级的数据。第二， 虚拟化(Virtualization)。所谓虚拟化是指用户可以在任意位置、使用各种终端获取所需的服务。而提供服务的应用程序则在“云”中某处运行，用户无需了解、也不用关心应用运行的细节。第三，高可靠性(Rel

14、iability)。“云”的内部使用数据的多副本容错、计算节点同构可互换等措施来保障服务的高可靠性，使用云计算比使用本地计算更加可靠。第四，可扩展性(Scalability )。“云”的规模可以动态配置和伸缩，以满足应用和用户规模增长的需要。并且随着“云”规模的增长，计算和存储能力也随之线性增加。“中国Web信息博物馆”(亦称Web InfoMall)4，是北京大学网络实验室在973 项目支持下从2002年1月18日正式投入运行的针对中国互联网信息的搜集、存储与历史浏览服务的海量信息系统，它平均每天搜集约150万网页，几年来已经积累超过25亿中国互联网上出现过的网页，数据量已经超过30TB，目

15、前全部存放在北京大学网络实验室维护的一个海量数据仓储系统中，并通过 提供初步的历史网页浏览服务。然而随着InfoMall数据的急剧增长，存储和利用这些数据越来越困难，具体表现在:1. 数据的存储变得越来越困难，随着硬盘的增多，不可避免地会有磁盘出错，处理这些错误需要耗费大量时间和精力。2. 数据的利用也越来越困难，由于数据散落在很多台服务器上，对数据的访问需要涉及到大量的编程工作，使得分析人员的精力不能集中在分析数据的逻辑上。从宏观上来看，InfoMall的海量数据源于目前还在不断膨胀的Web规模，存储并利用海量的数据内容也是当前的热点研究问题。Google的Bigtable就是其中代表性的系

16、统，它是一个大规模的结构化数据存储系统，能够实现空间维度和小范围时间维度上的高性能数据访问，比较接近我们的实际需求，将成为本系统在技术上的主要借鉴对象。本文的工作是实现一种通用的并且针对InfoMall系统需求做优化调整的存储系统。1.2 问题描述首先，作为一个结构化数据的存储系统，本系统需要解决以下三个方面的问题。 如何表达数据。数据的表达方式直接影响到系统的目标和用户对系统的理解，不同的系统表达方式有很大不同，如关系型数据库中通常用表格(Key-Column)，而Bekeley DB5则采用Key-Value对。在本系统中，数据具有时间轴上的特性(见第三章具体分析)，因此如何把时间纬度的信

17、息加入其中是研究的问题之一。 如何有效的组织和存储这些数据。好的组织和存储数据方式可以有效的利用存储空间。并且本系统中，数据有增量的特点，不可避免地会导致数据的移动和重组，在考虑组织和存储时，需要尽量保证这一过程的高效。另外，作为一个分布式的存储系统，如何把数据划分开分配到各个服务节点上去也是数据组织面临的问题之一，好的划分可以有效的平衡各个服务节点的负载，保证服务的质量。 如何高效的访问这些数据。访问数据的效率高低直接影响到数据的利用，它是整个存储系统的最终目的。在实际应用中，有些系统宁可浪费一些存储空间来保证高效的访问。在系统中，不同的访问类型具有不同的特点，并且它们对数据组织和资源分配的

18、需求可能会有矛盾，当不能保证所有的访问都有效时，我们需要具体问题具体分析，找出主要和次要的访问方式，在保证主要访问类型高效的同时尽量保证次要访问类型的高效。其次，分布式系统的设计和实现本身有很多难点，比如，如何保证系统的一致性；如何保持系统的可用性；如何提高系统的可扩展性；如何平衡各台机器的负载；如何调度各种资源；如何处理系统错误等等。再者，由于本文工作的一个重要目标是为了支持中国网页信息博物馆的建设(Web InfoMall), 而InfoMall的数据和访问有其自身的特点，因此如何针对这些特点做出相应的优化策略，使得InfoMall的使用和访问更加有方便和高效也是本文的工作重点之一。1.3

19、 术语定义Column-Orient DBMS指的是列优先存储的数据库，与之相对的Row-Orient DBMS是指行优先存储的数据库。Tianwang File System(TFS)624, 是一个类Google File System(GFS)的分布式文件系统，Debby是一个类似Google Chubby7的分布式锁系统，提供一个全局的锁以及存储少量元数据的服务。本系统中有一台负责全局调度的节点，称为Master；集群中负责存储数据的节点称为TabletServer。SSFile是Bigtable中的一种存储格式，Block是组成SSFile的数据块。TSFile是本文的一种存储格式，

20、Block同样指其中的数据块。1.4 本文结构本文第一章介绍工作背景和动机，同时也描述了当前面临的问题。第二章介绍了一些相关的系统以及最近的研究，主要是一些数据库系统和类Bigtable系统。第三章介绍Web InfoMall的数据和访问特征以及目前系统的不足，并且给出了本系统的存储设计方案及评测。第四章介绍整个系统的设计与实现，以及在实现中遇到的具体问题及解决方案。第五章是对系统的一些评测和实验，包括随机读、Scan读和系统吞吐率等；第六章是总结与未来工作。第二章 相关工作与研究2.1 相关系统Google File SystemGoogle的GFS是一个可扩展的分布式文件系统，用于大型的、

21、分布式的、对大量数据进行访问的应用。与传统的分布式文件系统NFS8，AFS9不同，GFS具有以下特征： 硬件错误不再被当作异常，而是将其作为常见的情况加以处理。 按照传统的标准，文件都非常大。 大部分文件数据是通过追加(Append)新数据完成的，而不是改写(Write)已存在的数据。 数据的读取主要是连续流方式的读操作和对少量数据的随机方式的读操作。相关数据库系统传统的数据库管理系统一直是存储结构化数据的主流产品，此类研究较多，产品较成熟，如Oracal、SQLServer、Mysql等等，这里不作叙述。然而传统的数据库系统都是面向行存储的，即系统会把同一行的数据存储在一起，这对于稀疏的数据

22、表格来说是非常浪费空间和时间的。C-Store10是一个针对读优化的数据库管理系统。与传统的面向行优先存储(Row-Oriented)的关系型数据库不同的是，C-Store存储时是按照列优先存储(Column-Oriented)，即把同一列的数据优先存储在一起，并且在此基础上对读操作进行了优化11。类Bigtable系统Bigtable1是Google开发的一个分布式结构化数据存储系统，此后的一系列类Bigtable的系统都以其为原型。不同于传统的关系型数据库，它是建立在GFS(Google File System)、Chubby等基础设施之上的存储系统，实现了一种新型的数据模型，具有重要的参

23、考价值。在Bigtable中，每个Table是一个多维的稀疏表。为了管理巨大的Table，系统把表格进行水平分割，分割后的表单元称为Tablet。每个Tablet大概有100-200 MB，每个机器存储100个左右的Tablet。Bigtable中存储数据的格式称之为SSFile，它按照列优先的方式进行存储。SSFile文件不可修改，一旦创建后，要想写入新的数据，只能重新合并生成一个更大的SSFile文件。系统底层的数据存储在GFS上，由于GFS是一种分布式的文件系统，本身就可以提供一定的负载均衡能力。在数据模型上，它在关系数据模型的基础上作了改进。Bigtable同样使用一个表格来表达数据，

24、但是这个表格是一个稀疏的，长期存储的，多维度的，排序的映射表。表的索引是行关键字(Row Key)，列(Column)关键字(Key)和时间戳(Timestamp)，每个值是一个自解释的字符数组，用户在表格中存储数据，每一行都有且仅有一个可排序的主键和任意多的列。由于是稀疏存储的，所以同一张表里面的每一行数据都可以有截然不同的列。列名字的格式是:，都是由字符串组成，每一张表有一个family集合，这个集合是固定不变的，相当于表的结构，只能通过改变表结构来改变。但是label值相对于每一行来说都是可以改变的。在Bigtable中，不仅行（row）的数量可以任意增减，同时列（column）的数量在

25、一定约束条件下也可以扩展，而且在每个单元(cell）还引入一个时间标签，可以存储多个不同时间版本的网页数据。在事务支持上，Bigtable不提供跨行的事务支持。Bigtable在Google的各个产品中应用广泛，取得了巨大成功，在其之后，出现了很多类似的系统。在开源社区，HBase12是开源的云计算平台Hadoop13下的子项目，它是基于HDFS的一个Bigtable的开源实现，实现语言是Java。Hypertable14也是一个类似的项目,C+实现。这些系统总的来说架构上与Bigtable相类似，虽然在实现细节上各有特点，但都可以归结为类Bigtable系统。除了Bigtabe外，各大公司也

26、纷纷开始研究了适合自身需求的存储系统，如Amazon的Dynamo15，Yahoo的PNUTS16，它们在实现上都各有特点。Dynamo主要是针对线上的数据服务，特别是针对写进行优化，保证数据的写入一定成功；而PNUTS为了保证操作的低延迟，在一定程度上牺牲了数据的一致性。这些系统共同之处在于从自身应用的需求出发，进而对某方面的性能进行优化。2.2 近期相关研究近期，对结构化数据存储的研究各有侧重。有的研究侧重于研究基础设施的底层架构，如文献17 研究的是如何给此类分布式基础设施软件再提供一种基础服务，它主要的贡献在于提出了一种叫做”Mini Transaction”的技术来保证系统的可靠性和

27、稳定性。另外一些研究侧重在数据的物理存储方面，如文献18阐述了面向列的存储和面向行的存储究竟有多大不同。还有一些研究是针对系统本身的优化，如文献19主要研究的是针对类Bigtable这种把表水平划分开的系统，在批量插入(Bulk insertion)的情况下，如何采样输入数据来预测表的分裂，并且根据现有服务器的负载提前预测每个待插入数据最终所在的机器位置，以降低表的分裂带来的网络和磁盘的负载。这个问题在本文的后续工作同样需要加以思考。第三章 数据模型与存储设计数据模型和存储的设计是本文研究的首要问题。与Bigtable系统相类似，本系统首先需要面对的是巨大、稀疏、可排序的表格数据，并且Bigt

28、able已经给出了很好的解决模型。在此基础上，本系统更多地考虑支持Web InfoMall的数据特点。因此，我们的设计宗旨是在不妨碍通用性的情况下，更多地针对InfoMall数据和访问特点加以优化。3.1 数据模型3.1.1 Web InfoMall的数据特征Web InfoMall的数据不同于通用的存储系统所针对的数据，它有其自身的独特性。1. Web InfoMall网页历史数据规模庞大，具有空间和时间两个方面的维度，并且在这两个维度上无界增长。在空间维度上，由于Web的增长，会不断有新的URL加入；在时间维度上，有些URL对应的网页内容会经常发生变化，出现较多版本。所谓新的版本是指页面内

29、容已经改变，如果被Crawler抓回的页面内容没有变化，InfoMall系统不会存储此页面。截止2008年为止，中国的网页数目已接近百亿, 而这个数目还在不断增长。2. Web InfoMall网页数据在两个维度上均表现出高度的不均衡性。在空间维度上，由于互联网结构本身的特点，大站点和小站点的网页数目相差很大。在时间维度上，少量页面会有非常多的版本，大多数页面的版本数很少。这也是由网站的特点和Crawler本身的机制所决定的,对于某个特定站点来说，其首页可能每天都在发生变化，而内部子页面的内容则很少改动。下图描述的是InfoMall截止2008年12月为止，其内部网页版本数的分布状况。图表 3

30、-1 InfoMall中网页的版本数可以看出InfoMall中URL与网页版本数之间是一个近似Power-Law关系。大部分的网页的版本数都非常少；少量的网页有很多的版本数。这也可以反映出大多数的网页从产生到消亡的过程中，它的内容都没有变过。而有少量的URL对应的网页改动频率非常频繁。这也与人们对网页生命周期的研究相符。这个特点对本系统存储的设计是一个重要的启发，即我们必须要满足好大部分有少量版本的网页的存取需求，在此基础上处理那些极端多版本的网页。3. Web InfoMall是持续不断的增量存储过程。由于Web的持续增长和Crawler程序的持续抓取，网页数据将会分批、持续地加入到系统中来

31、。加入的网页中一部分是新产生的页面，它们没有历史版本；另一部分页面的URL已经存在，抓回来的是URL的新的版本。无论哪种情况，要处理增量的网页无外乎两种方式，第一种方式是和原先的网页做合并，生成一批新的数据，这种办法的优点是新生成耗费的数据可以按照系统的要求组织和存储，缺点是数据的移动和重组需要大量的资源；第二种方式是单独存储，同时维护多批数据，优点是只需要存储当前的数据，但是由于数据的组织较为杂乱，对数据的访问将会较为困难(见本文下一节对InfoMall系统访问特征的分析)。下图描绘的是InfoMall中网页抓取的间隔。图表 3-2 InfoMall中网页抓取时间的间隔在图中，横轴是该URL对应网页的内容发生变化的时间间隔，单位为周，纵轴是URL的数目。可以看出，大部分网页内容的变化时间间隔都是1周或者几周之内，小部分的变化间隔是几十周、上百周。也就是说，对于大部分内容发生变化的URL而言，它的变化都是在短时间内完成的。这个特点对我们的缓存设计具有重要的作用，它意味着增加了一个版本的网页在很短的时间内可能会再次增加版本。3.1.2 Web InfoMall的访问特征由于InfoMall的数据有极大的研究价值，如何更好的利用上这些庞大的数据是一个极具挑战的课题，也是整个系统设计的目点所在。根据目前对InfoMall的研究情况来分析，对其