海量存取催生-云数据库-

《海量存取催生-云数据库-》由会员分享，可在线阅读，更多相关《海量存取催生-云数据库-（4页珍藏版）》请在金锄头文库上搜索。

1、 第 1 页 共 4 页 中国计算机报/2008 年/10 月/27 日/第 C08 版 专题 如何有效地管理 Web 数据是伴随 Web 兴起就出现的热门研究课题， 而云计算 自其诞生之日起，就离不开 Web 以及对 Web 数据进行管理。 海量存取催生“云数据库”海量存取催生“云数据库” 中国人民大学信息学院 王仲远 在云计算平台下， Web 数据管理进入了一个新的阶段， 这就是对 Web 规模海量数据进行有效 管理的研究。数据库在 Web 上的应用越来越成熟，基于数据库开发的各种各样的 Web 应用服务 也越来越多。我们经常会访问的一些网站，如电子商务网站、招聘及求职信息网站、各种内容管

2、 理系统以及 SNS 网站等，其背后都有数据库存在，这些数据库就称为 Web 数据库。由于这种基 于 Web 数据库开发的网络应用逐渐兴起，导致 Web 上的数据量急剧增长。 深层网络数据集成研究 2001 年 7 月，BrightPlanet com 针对 Deep Web 的数量做了一次比较全面的统计，其发表的白 皮书称:整个 Web 上大约有 43000-96000 个 Web 数据库，以及 7500TB 的数据(约为 Surface Web 的 500 倍)。而经过数年发展，根据 UIUC 所发表的一篇 Deep Web(深层数据网络)综述估计，截至 2004 年， 全世界范围内 De

3、ep Web 的网站数量已经达到 307000 个， 其背后的数据库数量已经达到 366000-535000 个。虽然这两年没有新的权威统计报告出来，但是我们有理由相信，Web 数据库 的数量以及 Deep Web 的规模仍然是呈现上升趋势。 面对如此多的“隐藏数据” ，传统搜索引擎根据链接进行网页抓取的方式却不能完全发掘， 因为有许多数据必须是用户提交一个查询之后才会动态生成的。并且，虽然一些 Deep Web 网站 为自身流量考虑，为搜索引擎提供一些数据页面浏览的入口，造成搜索引擎也能够索引动态页面 的现象(例如我们搜索一本书的时候，常常能够在搜索结果中发现购书网站的页面)，但是根据 UI

4、UC 的统计，目前主流搜索引擎例如 Google、Yahoo 只能够覆盖到其中 32%的数据，而大部分 数据仍然不能够通过搜索访问到。因此，在 Deep Web 上进行大规模数据集成显得越来越急迫。 为此，WAMDM 实验室(网络与移动数据管理实验室)也成立了一个 Deep Web 数据集成研究 项目Jobtong 项目。 这个项目最初是研究在工作信息领域上的数据集成， 我们期望通过这种研 究，形成一套面向领域的 Deep Web 数据集成的方法。目前，此项目已不再局限于工作信息领域。 我们已经成功在多个领域快速地构造了这样的应用。 Jobtong 集成系统主要包括:底部被集成的数据源，例如

5、Deep Web 数据、XML 数据以及其他 提供接口查询的网页；多个配置文件单元，这多个配置文件单元的每一个与上述多个数据源的每 一个相对应；统一的集成单元，用于集成底层的各个数据源，它利用数据源所对应的配置文件， 采用统一的方式，对数据源中的数据进行抽取；还有本地服务器，用于保存集成起来的所有数据， 这样用户检索时，便可以直接在本地服务器上进行检索，提高效率。 这样的集成系统可以快速挖掘 Deep Web 中的数据，并将其方便地提供给用户进行检索，从 而解决对于这些海量“隐藏数据”的获取问题。据我所知，目前 Google 内部也有相关小组在做 此方面的研究，相信在不远的将来，我们也可以看到

6、 Google 对于这部分数据的处理与展现。 Google 的软件平台尝试 当然，如果仅仅能够将获取这些海量数据，但不能够进行合理的组织，那么也不能称作对这 些 Web 数据进行了有效的管理。 为此， 我们将要介绍 Google 的文件系统以及其开发的 BigTable(大 表)系统，正是这些系统，组成了一种云计算的基础软件平台的雏形。 第 2 页 共 4 页 当我们使用 Google 进行关键字搜索，享受 Google 强大搜索所带来的便捷的时候；当我们赞 叹 Google 地图搜索是如此之精确以至于能够清楚地看到我们所居住的房屋的时候；当我们已习 惯使用Google个性化主页， 让Goog

7、le按照我们的想法随心所欲地提供我们想要的资讯的时候 是否有人静下心来思考这样一个问题:在这样强大的搜索背后，究竟是什么技术在支持呢?是什么 系统在管理这样一个已超出我们所能想象的巨大的数据资源呢? 是数据库吗?不是!Google 的观点是，现有的数据库没法满足海量数据存储的需求，即使有， 存储及查找代价也会让人无法忍受。Google 每天所面对的，是成千上万台服务器，是上千 TB 的 数据，是每秒数百万的读/写。而且，在这样的情况下，还要实现高效的查询。Google 开发了自 己的文件系统Google File System(Google 文件系统，简称 GFS)。 Google File

8、System 与以往的文件系统的区别在于， Google 的文件系统是一个大规模的分布式 文件系统，它能够处理大规模的分布式数据。Google 文件系统包括 Master(控制服务器)和 Chunkserver(块服务器)，Master 定期与每一个 Chunkserver 通信，给 Chunkserver 传递指令并收集 它的状态。 与应用程序相联的GFS Client(GFS 客户端)实现了文件系统的 API并与 Master和Chunkserver 通信，以代表应用程序读和写数据。GFS Client 与 Master 的交换只限于对 Metadata(元数据)的操 作，而所有数据方面的

9、通信都是直接和 Chunkserver 联系。 Master 负责管理元数据，它主要存储文件和块的名空间、文件到块之间的映射关系以及每一 个块副本的存储位置； Chunkserver 存储块数据， 一个典型的块大小为 64MB， 它通过懒惰算法(Lazy Space Allocation)来管理存储在它上面的块。在 Chunkserver 中，一个块可能有多个备份，这样做 的目的是为了保障数据的安全性，当然，也能够实现负载均衡。 不过，Google 文件系统只是实现了对于海量数据的组织问题，它能够高效地读写这些数据， 就如同操作系统中的文件系统一样。而在操作系统中，如果要管理结构化数据的话，还

10、是需要利 用在其之上的数据库进行管理。那么，面对这些海量 Web 数据，也需要一个类似于数据库一样的 数据管理系统，于是 Google 研发了 BigTable。 BigTable，顾名思义，就是一张“大表” ，由稀疏多维表组成的面向列存储的数据管理系统。 Google 于 2004 年初开始研发， 到现在它已经运行了四年多， 基本上能够满足 Google 的需求:处理 海量数据，实现高速存储与查找。 BigTable 由行和列组成，每个单元(BigTable Cell)是一个三元组，由行、列、时间戳组成。在 一个典型的单元格中，行可以是 URLs，列可以是属性/规则，时间戳则是用来标识版本的

11、，它可 以在多个备份中，将最新的信息提供给用户。 BigTable 就如它的名字一样，是一张“大表” ，以至于为了便于管理，需要将 Bigtable 按照行 拆分成 Tablets。如果说 BigTable 是一块布，Tablets 就好像是从这块布上扯下的布条。即使这样， Tablets 也是不小的。每个 Tablet 大约有 100-200M，而每台机器大约会存储 100 个左右的 Tablets。 由于 Google 采用的是廉价的 PC 机，而不是使用高端的服务器，因此采用 Tablets，就将 BitTable 化整为零，分布式地存放在各台 PC 机上。 同时，由于采用了 Table

12、ts，也非常容易地实现了负载均衡和快速恢复。如果某台机器的某个 Tablet 经常被访问，则他可以将原来存储在它上面的其它 Tablet 转移到别的机器上，然后专门负 责这个 Tablet，而这个 Tablet 也可以完全载入内存，提高访问速度。如果某台机器坏了，不难想 象，这台机器上的 Tablets 只需要由其他 100 台机器，每台机器恢复一个 Tablet，系统就重建起来 了，因而机器损坏的影响也会降到最低。这点其实是很重要的，因为 Google 采用的是最普通的 机器。 “如果你买了一台机器，也许用三年也不会有什么太大的问题；但如果你拥有上千台机器， 你要做好每天 down 掉一台的

13、准备” 。Google 拥有许许多多的普通 PC，因此，每天都会有机器不 断损坏，也会有机器不断补充进来，在这种情况下，具有非常好的容错性是很重要的一点。 为了实现对数据的管理和恢复，日志是必不可少的。但是，如果每个 Tablet 就有一个日志， 第 3 页 共 4 页 那么一台机器上就会有许许多多的日志，对于这些日志本身的管理就将是一个巨大的工程，所以 Google 选择了同一台机器上的所有 Tablets 共享一个日志的方式。但这种方式虽然减少了日志的 个数， 却带来另一个问题:一个日志块将很快被写满， 于是系统将非常频繁地开始一个新的日志块。 看来，鱼和熊掌确实是不可兼得啊! 同时，由于

14、 Tablets 采用的是不可修改的(immutable)的 SSTables 存储方式，因此系统将产生 大量的冗余数据，面对这些冗余数据，Google 主要采取两种压缩方式进行数据压缩:BMDiff 和 Zippy。这两种压缩方式，与 Gzip 和 LZW 等压缩方式相比，在压缩率上并没有什么优势，但它 们都有一个很大的特点，这就是压缩速率和解压速率都非常快，而这正是 Google 所需要的。能 够快速地压缩以节约空间，又能快速地解压获得数据，这对 Google 来说，远比其他特性要重要 得多。 至此，一个建立在 Google File System 上的 BigTable 系统就已呈现在我

15、们面前，从这个系统 中，我们可以看到 Google 的核心理念:低价的机器、高速的处理、大量的冗余以及极强的容错能 力。 Web 2.0 引发数据剧增 当我们有了 Deep Web 的数据集成技术以及 Google 的文件系统以及 BigTable 之后， 就能够有 效地获取、组织和管理各种结构化和非结构化的数据。但是，这还不足以面对日新月异的 Web 上 产生的各种问题。其中一个重要的变化就是 Web20 的兴起。 随着网络泡沫的破灭，互联网发展也陷入了低谷。但是随着 Web2.0 概念的提出，用户突然 发现自己不仅仅能够是网站内容的浏览者，更可以是网站内容的贡献者。博客、实名网络社区、 照

16、片分享网站、视频分享网站的兴起，极大地激起了网络用户的兴趣。人们乐此不疲地在网上创 造属于自己的数据，并与其他人分享。这时，就如同当年的 Web 数据库等兴起一样，Web2.0 又 一次给 Web 带来了数据量的暴增。同时也对服务器的数据处理能力提出了更高的要求。 在这个 Web2.0 的时代，Flickr、Fotolog、YouTube 等网站的访问量，在 2006 年第一、第二 季度时已经逐渐超过传统门户网站(如 )，其中，YouTube 的访问量更是节节攀升，将传统 门户网站远远抛在后面。用户数量多以及用户参与程度高，是这些网站的特点。因此，如何有效 地为如此巨大的用户群体服务，让他们参与时能够享受方便、快捷的服务，成为这些网站不得不 解决的一个问题。这些需求，使得云计算呼之欲出。 一个直观的解决办法就是:如果一台机器完成不了这项工作，那么就让 100 台、1000 台机器 一同来完成这项工作。实际上，早在上世纪 90 年代提出的网格计算的思想，就考虑充分利用空 闲的 CPU 资源，搭建平行分布式计算。而在 1999 年出现的 SETIhome 更是成