The Anatomy of a LargeScale Hypertextual Web Search Engine完整中文翻译.docx
《The Anatomy of a LargeScale Hypertextual Web Search Engine完整中文翻译.docx》由会员分享，可在线阅读，更多相关《The Anatomy of a LargeScale Hypertextual Web Search Engine完整中文翻译.docx（39页珍藏版）》请在冰豆网上搜索。
TheAnatomyofaLargeScaleHypertextualWebSearchEngine完整中文翻译
本文是谷歌创始人Sergey和Larry在斯坦福大学计算机系读博士时的一篇论文。
发表于1997年。
在网络中并没有完整的中文译本，现将原文和本人翻译的寥寥几句和网络收集的片段（网友xfygx和雷声大雨点大的无私贡献）整理和综合到一起，翻译时借助了，因为是技术性的论文，文中有大量的合成的术语和较长的句子，有些进行了意译而非直译。
作为Google辉煌的起始，这篇文章非常有纪念价值，但是文中提到的内容因年代久远，已经和时下最新的技术有了不少差异。
但是文中的思想还是有很多借鉴价值。
因本人水平有限，对文中内容可能会有理解不当之处，请您查阅英文原版。
大规模的超文本网页搜索引擎的分析
SergeyBrinand Lawrence Page
{sergey,page}@cs.stanford.edu
ComputerScienceDepartment, Stanford University, Stanford, CA 94305
摘要
在本文中我们讨论Google，一个充分利用超文本文件结构进行搜索的大规模搜索引擎的原型。
Google可以有效地对网络资源进行爬行搜索和索引，比目前已经存在的系统有更令人满意的搜索结果。
该原型的数据库包括2400万页面的全文和之间的链接，可通过http:
//google.stanford.edu/访问。
设计一个搜索引擎是一种具挑战性的任务。
搜索引擎索索引数以亿计的不同类型的网页并每天给出过千万的查询的答案。
尽管大型搜索引擎对于网站非常重要，但是已完成的、
对于大型搜索引擎的学术上的研究却很少。
此外，由于技术上的突飞猛进和网页的急剧增加，在当前，创建一个搜索引擎和三年前已不可同日而语。
本文提供了一种深入的描述，
与 Web 增殖快速进展今日创建 Web 搜索引擎是三年前很大不同。
本文提供了到目前为止，对于我们大型的网页所搜引擎的深入的描述，这是第一个这样详细的公共描述。
除了如何把传统的搜索技术扩展到前所未有的海量数据，还有新的技术挑战涉及到了使用超文本中存在的其他附加信息产生更好的搜索结果。
本文解决这样一个问题，如何建立一个可以利用超文本中存在的其他附加信息的实用的大型系统，同时我们也研究一下如何有效处理任何人都能发布他们想发布的包含任何信息的大量自由链接的问题。
关键字：
互联网，搜索引擎，文献检索，PageRank，Google
1.简介
（注：
本文由两个版本--较长的完整版本和一个较短的印刷的版本。
完整版本提供在网络上和会议的CD-ROM上）。
Web 给信息检索带来了新的挑战。
Web上的信息量快速增长，同时不断有毫无经验的新用户来体验Web这门艺术。
人们喜欢用超级链接来网上冲浪，通常都以象 Yahoo这样重要的网页或搜索引擎开始。
人工维护的网站列表能有效的覆盖受欢迎的流行的站点，但是它具有主观性，建立和维护的代价高，升级慢，不能包括所有深奥的主题。
基于关键词的自动搜索引擎通常返回太多的低质量的匹配。
使问题更遭的是，一些广告为了赢得人们的关注想方设法误导自动搜索引擎。
我们建立了一个大型搜索引擎解决了现有系统中的很多问题。
应用超文本结构，提供高质量的查询结果，我们的系统命名为google，取名自googol的通俗拼法，即10的100次方，这和我们的目标建立一个大型搜索引擎较好的符合。
1.1网络搜索引擎—升级换代：
1994-2000
搜索引擎技术不得不快速升级跟上成倍增长的网站数量。
1994年，第一个Web搜索引擎，WorldWideWebWorm（WWWW）拥有110，000个网页和网站可访问文档的索引。
到1994年11月，顶级的搜索引擎声称可以检索到2万 （WebCrawler）100万个网络文件（来自搜索引擎监视）。
可以预见到2000年，可检索到的网页将超过10亿。
同时，搜索引擎的访问量也会以惊人的速度增长。
在1997年的三 四月份，WorldWideWebWorm 平均每天收到1500个查询。
在1997 年11月，Altavista 声称它每天要处理大约20’百万个查询。
随着网络用户的增长，可以预见到到2000年，自动搜索引擎每天将处理上亿个查询。
我们系统的设计目标要解决许多问题，包括质量和可升级性，引入升级搜索引擎技术，把它升级到如此大量的数据上。
1.2Google：
升级与网络
建立一个能够和当今web规模相适应的搜索引擎会面临许多挑战。
抓网页技术必须足够快并且保持是最新的版本。
存储空间必须高效的存储索引和文档。
索引系统必须能够高效地处理上百亿GB的数据。
处理查询必须快，达到每秒能处理成百上千个查询
。
随着Web的不断增长，这些任务变得越来越艰巨。
然而硬件的性能和成本也在快速增长，可以部分抵消这些困难。
然而，还有几个值得例外，如磁盘的寻道时间，操作系统的效率。
在设计Google的过程中，我们既考虑了网络的增长速度，又考虑了技术的更新。
Google的设计能够很好的升级处理超大量数据集。
它能够高效地使用存储空间来存储索引。
优化的数据结构能够快速有效地存取（请参见4.2节）。
进一步，我们希望，相对于所抓取的文本文件和HTML网页的数量而言，存储和建立索引的代价尽可能的小（请参阅附录B）。
对于象Google这样的集中式系统，采取这些措施得到了良好的系统可升级性。
1.3设计目标
1.3.1 改进搜索质量。
我们的主要目标是提高Web搜索引擎的质量。
1994 年，有人认为建立全搜索索引就有可能很容易找到任何东西。
根据BestoftheWeb1994--Navigators ，“最佳导航服务应更容易找到几乎任何在网络上（已经输入的所有数据）。
”。
然而1997年的Web就迥然不同。
任何最近使用搜索引擎的用户很容易证实索索引的完整性并不是唯一影响搜索引擎结果的因素。
用户感兴趣的搜索结果往往被“垃圾结果”淹没。
实际上，到1997年11月为止，四大商业搜索引擎中只有一个能够找到它自己（使用自己的搜索自己的名字时返回的前十个结果中有它自己）。
导致这一问题的主要原因是文档的索引数目增加了好几个数量级，但是用户能够看的文档数却没有增加。
人们仍然只希望看前面的几十个搜索结果。
因此，当集合增大时，我们就需要高精确度的工具（在返回的前几十个结果中，相关文档的数量）。
由于是从成千上万个有点相关的文档中选出几十个，实际上，我们希望相关的概念就是指最好的文档。
高精确非常重要，甚至以响应（系统能够返回的有关文档的总数）为代价。
令人十分乐观的的是利用超文本链接提供的信息有助于改进搜索和其它应用[Marchiori97][Spertus97][Weiss96][Kleinberg98]。
尤其是链接结构和链接文本，为相关性的判断和高质量筛选提供了大量的信息。
Google既利用了链接结构又用到了链接文本（请参见2.1和2.2节）。
1.3.2 搜索引擎的学术研究
除了发展迅速，Web越来越商业化。
到1993年，只有1.5%的网络服务是来自.com域名。
到1997年，增长超过了60%。
同时，搜索引擎从学术领域走进商业。
到现在大多数搜索引擎被公司所有，很少发布技术细节。
这就导致搜索引擎技术很大程度上仍然是暗箱操作，并倾向做广告（请参阅附录A）。
对于Google来讲我们有一个的主要目标是推动学术领域在此方面的发展和了解。
另一个设计目标是给适合数目的人们一个实用的系统。
对我们来说应用十分重要，因为一些研究表明，现代网络系统中存在大量的有用数据。
例如，每天有数千万个查询被执行。
然而，获得这些数据却非常困难，主要因为它们被认为有商业价值。
我们的最终设计目标是构建一个体系结构，可以支持大型 Web 数据上的一种新的研究活动。
为了支持新研究，Google以压缩的形式保存了实际所抓到所有的文档。
我们设计Google的主要目标之一就是要建立一个环境使其他研究者能够很快进入这个领域，处理海量网络数据，得到满意的结果，而通过其它方法却很难得到。
系统在短时间内被建立起来，已经有几篇论文用到了Google建立的数据库，更多的在起步中。
我们的另一个目标是建立一个宇宙空间实验室似的环境，在这里研究人员甚至学生都可以对我们的海量网络数据设计或做有趣的实验。
2. 系统功能
Google搜索引擎有两个重要功能，帮助它产生高精度的搜索结果。
首先，应用Web的链接结构计算每个网页的质量等级值，这个等级称为PageRank，将在98页详细描述它。
第二点，Google利用超链接改进搜索结果。
2.1PageRank：
带来网页排序
网络的引用（链接）图形是重要的资源， 却没有被现有的大多搜索引擎使用。
我们建立了一个包含518百万个超链接的图，它是一个具有重要意义的样本。
这些图能够快速地计算网页的PageRank值，它是一个客观的标准，较好的符合人们主观的对一个网页重要程度的评价，由此对应的是，PageRank值是一个较好的区分通过网络搜索关键字获得的结果的方法。
建立的基础是通过引用判断重要性。
对于大多数的主题，一个简单的被限制为网页标题的文本匹配搜索当使用PageRank区分时得到了极好的结果（从google.stanford.edu可以得到演示）。
对于Google主系统中的全文搜索，PageRank也有很大的帮助。
2.1.1PageRank计算的描述：
文献引用理论应用到Web中，主要由引用或反向链接到给定页来计数。
这会反映了该网页的重要性和质量的近似值。
PageRank扩展了这种思想，不平等的计算所有页面上的链接并且通过一个页面上的所有链接。
PageRank定义如下:
我们假设页面T1…Tn指向网页A（例如，被引用）。
参数d是一个设定在0，1之间的制动因子。
我们通常设置d为0.85。
在下一节有更多关于d的详情，C（A）定义为网页A指向其它网页的链接数，网页A的PageRank值由下式给出：
PR（A）=（1-d）+d（PR（T1）/C（T1）+...+PR（Tn）/C（Tn））
请注意PageRank涵盖所有网页的一个概率分布得来，因此所有网页PageRank和是1。
PageRank或PR（A）可使用一个简单的迭代算法来计算，相应对应月网页链接矩阵的主特征向量。
中等规模的网站计算26万网页的 PageRank值要花费几小时。
还有一些技术细节超出了本文论述的范围。
2.1.2 直觉的解释
PageRank被看作用户行为的模型。
我们假想一个“随机上网者”；随机地给他一个网页；他漫无目的地命中网页的链接，而从来不点“返回键”；最终他觉得烦了，又从另一个随机的网页从新开始。
随机访问一个网页的可能性就是它的PageRank值。
制动因子d是随机访问一个网页烦了的可能性，随机另选一个网页。
对单个网页或一组网页，一个重要的变量加入到制动因子d中。
这允许个人可以故意地误导系统，以得到较高的PageRank值几乎变成不可能的。
我们还有其它的PageRank算法，见98页。
另外的直觉判断是一个网页有很多网页指向它，或者一些PageRank值高的网页指向它，则这个网页很重要。
直觉地，在Web中，一个网页被很多网页引用，那么这个网页值得一看。
一个网页被象Yahoo这样重要的主页引用即使一次，也值得一看。
如果一个网页的质量不高，或者是死链接，象Yahoo这样的主页不会链向它。
PageRank处理了这两方面因素，并通过网络链接递归地传递。
2.2链接描述文字
我们的搜索引擎对链接文本进行了特殊的处理。
大多数搜索引擎把链接文字和它所链向的网页联系起来。
另外，把它和链接所指向的网页联系起来。
这有几点好处。
第一，通常链接描述文字比网页本身更精确地描述该网页。
第二，链接描述文字可能链向的文档不能被文本搜索引擎检索到， 例如图像，程序和数据库。
有可能使返回的网页不能被抓到。
注意那抓不到的网页将会带来一些问题。
在返回给用户前检测不了它们的有效性。
这种情况搜索引擎可能返回一个根本不存在的网页，但是有超级链接指向它。
然而这种结果可以被挑出来的，所以此类的问题很少发生。
链接描述文字是对被引用网页的描述这个思想被用在WorldWideWebWorm 中，主要因为它有助于搜索非文本信息，能够用少量的已下载文档扩大搜索范围。
我们大量应用链接描述文字，因为它有助于提高搜索结果的质量。
有效地利用链接描述文字技术上存在一些困难，因为必须处理大量的数据。
现在我们能抓到24万个网页，已经检索到259万多个链接描述文字。
2.3其它功能
除了PageRank和应用链接描述文字外，Google还有其他几个功能。
一,它有所有命中数的位置信息，所以它可以在搜索中广泛应用邻近性。
第二，Google跟踪一些可视化外表细节，例如字的字体大小。
更大的字的权重要高于其他的。
第三，知识库存储了原始的全文html网页。
3 相关的工作
网络检索研究的历史简短。
WorldWideWebWorm（WWWW）是最早的搜索引擎之一。
后来出现了一些用于学术性的搜索引擎，现在它们中的大多数被上市公司拥有。
与Web的增长和搜索引擎的重要性相比， 有关当今搜索引擎技术的优秀论文相当少。
根据MichaelMauldin（LycosInc的首席科学家）） ，“各种各样的服务（包括Lycos）非常关注这些数据库的信息。
”虽然在搜索引擎的某些特点上做了大量工作。
具有代表性的工作有，对现有商业搜索引擎的 结果进行传递，或建立小型的个性化的搜索引擎。
最后有关信息检索系统的研究很多，尤其在有组织机构集合方面。
在下面两节，我们将讨论在信息检索系统中的哪些领域需要改进以便更好的工作在Web上。
3.1信息检索
信息检索系统诞生在几年前，并发展很好。
然而,大多数信息检索系统的研究针对的是受控制的同质集合 ，例如,主题相关的科学论文或新闻故事。
实际上，信息检索的主要基准，用小规模的、有组织结构的集合作为它们的基准。
大型文集基准只有20GB，相比之下，我们抓到的24万个网页占147GB。
在TREC上工作良好的系统，在Web上却不一定产生好的结果。
例如，标准向量空间模型企图返回和查询请求最相近的文档，把查询请求和文档都看作由出现在它们中的词汇组成的向量。
在Web环境下，这种策略常常返回非常短的文档，这些文档往往是查询词再加几个字。
例如，查询“BillClinton”，返回的网页只包含“BillClintonSucks”，这是我们从一个主要搜索引擎中看到的。
网络上有些争议，用户应该更准确地表达他们想查询什么，在他们的查询请求中用更多的词。
我们强烈反对这种观点。
如果用户提出象“BillClinton”这样的查询请求，应该得到理想的查询结果，因为这个主题有许多高质量的信息。
像所给的例子，我们认为信息检索标准需要发展，以便有效地处理Web数据。
3.2有组织结构的集合与网络的不同点
Web是完全无组织的异构的大量文档的集合。
Web 中的文档无论内在信息还是隐含信息都存在大量的异构性。
例如，文档内部就用了不同的语言（既有人类语言又有程序），词汇（
email地址，链接，邮政编 码，电话号码，产品号），类型（文本，HTML，PDF，图像，声音），有些甚至是机器创建的文件（log文件，或数据库的输出）。
可以从文档中推断出
来，但并不包含在文档中的信息称为隐含信息。
隐含信息包括来源的信誉，更新频率，质量，访问量和引用。
不但隐含信息的 可能来源各种各样，而且被检测的信息也大不相同，相差可达好几个数量级。
例如，一个重要主页的使用量，象Yahoo 每天浏览数达到上百万次，于此相比无名的历史文章可能十年才被访问一次。
很明显，搜索引擎对这两类信息的处理是不同的。
Web与有组织结构集合之间的另外一个明显区别是，事实上，向Web上传信息没有任何限制。
灵活利用这点可以发布任何 对搜索引擎影响重大的信息，使路由阻塞，加上为牟利故意操纵搜索引擎，这些已经成为一个严重的问题。
这些问题还没有被传统的封闭的信息检索系统所提出来。
它关心的是元数据的努力，这在Web搜索引擎中却不适用，因为网页中的任何文本都不会向用户声称企图操纵搜索引擎。
甚至有些公司为牟利专门操纵搜索引擎。
4 系统分析
首先，我们提供高层次的有关体系结构的讨论。
然后，详细描述重要的数据结构。
最后，主要应用：
抓网页，索引，搜索将会深度探讨。
图 1. 高层次Google体系结构
4.1Google结构概述
这一节，我们将看看整个系统工作方式的高水平综述，见图1。
本节不讨论应用和数据结构，在后几节中讨论。
为了效率大部分Google是用c或c++实现的，既可以在Solaris也可以在Linux上运行。
Google 系统中，网络爬虫（下载网页）是由几个分布式crawlers完成的。
一个URL服务器负责向crawlers提供URL列表。
抓来的网页交给存储服务器 storeserver。
然后，由存储服务器压缩网页并把它们存到知识库中。
每个网页都有一个ID，称作docID，当新URL从网页中分析出时，就被分配一个docID。
由索引器和排序器负责建立索引indexfunction。
索引器从知识库中读取文档，对其解压缩和分析。
每个文档被转换成一组词的出现情况，称作命中hits。
Hits 纪录了词，词在文档中的位置，最接近的字号，大小写。
索引器把这些hits分配到一组桶barrel中，产生经过部分排序后的索引。
索引器的另一个重要功能是分析网页中所有的链接，将有关的重要信息存在链接描述anchors文件中。
该文件包含了足够的信息，可以用来判断每个链接链出链入节点的信息，和链接文本。
URL分解器resolver阅读链接描述anchors文件，并把相对URL转换成绝对URL，再转换成docID。
为链接描述文本编制索引，并与它所 指向的docID关联起来。
同时建立由docID对组成的链接数据库。
用于计算所有文档的PageRank值。
用docID分类后的barrels，送给 排序器sorter，再根据wordID进行分类，建立反向索引invertedindex。
这个操作要恰到好处，以便几乎不需要暂存空间。
排序器还给出docID和偏移量列表，建立反向索引。
一个叫DumpLexicon的程序把这 个列表和由索引器产生的字典结合在一起，建立一个新的字典，供搜索器使用。
这个搜索器就是利用一个Web服务器，使用由DumpLexicon所生成的字典，利用上述反向索引以及页面等级PageRank来回答用户的提问。
4.2 主要数据结构
经过优化的Google数据结构，能够用较小的代价抓取大量文档，建立索引和查询。
虽然近几年CPU和输入输出速率迅速提高。
磁盘寻道仍然需要10ms。
任何时候Google系统的设计都尽可能地避免磁盘寻道。
这对数据结构的设计影响很大。
4.2.1 大文件
BigFiles是跨越多个文件系统的虚拟文件，用长度是64位的整型数据寻址。
多文件系统之间的空间分配是自动完成的。
BigFiles包也处理文件描述符的分配。
由于操纵系统不能满足我们的需要，BigFiles也支持基本的压缩选项。
4.2.2 知识库
知识库包含每个网页的全部HTML。
每个网页用zlib（见RFC1950）压缩。
压缩技术的选择既要考虑速度又要考虑压缩率。
我们选择zlib的速度而不是压缩率很高的bzip。
知识库用bzip的压缩率接近4：
1。
而用zlib的压 缩率是3：
1。
文档一个挨着一个的存储在知识库中，前缀是docID，长度，URL，见图2。
访问知识库不需要其它的数据结构。
这有助于数据一致性和升级。
用其它数据结构重构系统，我们只需要修改知识库和crawler错误列表文件。
4.2.3 文档索引
文档的索引保持每个文档有关的信息。
它是固定的宽度 ISAM（索引顺序访问模式） 索引。
每条记录包括当前文件状态，一个指向知识库的指针，文件校验和，各种统计表。
如果一个文档已经被抓到，指针指向docinfo文件，该文件的宽度可变，包含了URL和标题。
否则指针指向包含这个URL的URL列表。
这种设计考虑到简洁的数据结构，以及在查询中只需要一个磁盘寻道时间就能够访问一条记录。
还有一个文件用于把URL转换成docID。
它是URL校验和与相应docID的列表，并按照校验排序。
要想知道某个URL的docID，需要计算URL的校验和，然后在校验和文件中执行二进制查找，找到它的docID。
通过对这个文件进行合并，可以把一批URL转换成对应的docID。
URL分析器用这项技 术把URL转换成docID。
这种成批更新的模式是至关重要的，否则每个链接都需要一次查询，假如用一块磁盘，322百万个链接的数据集合将 花费一个多月的时间。
4.2.4 辞典
词典有几种不同的形式。
和以前系统的重要改进是，词典对内存的要求可以在合理的价格内。
当前实现中，一台256M内存的机器就可以把词典装入到内存中。
现在的词典包含14万词汇（虽然一些很少用的词汇没有加入到词典中）。
它执行分两部分—词汇表（串联在一起，但使用空值隔开）和指针的哈希表的列表的实现。
不同的函数词列表有一些辅助的信息，超出了本文以详细解释的范围。
4.2.5点击列表
一个命中列表对应着一个单词在一个文档中出现的位置、字体和大小写信息的列表。
命中列表占用了正向索引和反向索引的大部分空间，所以怎样尽可能有效的表示是很重要的。
我们考虑了对位置，字体和大小写信息的多种编码方式——简单编码（3个整数），压缩编码（手工优化分配比特）和霍夫曼编码（Huffmancoding）。
命中（hit）的详情见图3。
图3. 正、倒排索引和词典
我们的压缩编码每个命中用到两个字节（byte）。
有两种命中：
特殊命中（fancyhit）和普通命中（plainhit）。
特殊命中包括在URL，标题，锚文本和meta标签上的命中。
其他的都是普通命中。
一个普通的命中包括一个表示大小写的比特（bit），字体大小，和12个bit表示的单词在文件中的位置（所有比4095大的位置都被标示为4096）。
字体在文档中的相对大小用3个比特表示（实际上只用到7个值，因为111标示一个特殊命中）。
一个特殊命中包含一个大小写比特，字体大小设置为7用来表示它是一个特殊命中，4个比特用来表示特殊命中的类型，8个比特表示位置。
对于锚命中，表示位置的8个比特被分成两部分，4个比特表示在锚文本中的位置，4个比特为锚文本所在docID的哈希（hash）值。
由于一个词并没有那么多的锚文本，所以短语搜索受到一些限制。
我们期望能更新锚命中的存储方式能让位置和docID哈希值能有更大的范围。
我们使用在一个文档中的相对字体大小是因为在搜索时，你并不希望对于内容相同的不同文档，仅仅因为一个文档字体比较大而有更高的评级（rank）。
命中列表的长度存在命中的前面。
为了节省空间，命中列表的长度在正向索引中与wordID结合，在反向索引中与docID结合。
这样就将长度分别限制在8个比特和5个比特（有一些技巧可以从wordID中借用8个比特）。
如果长度超过了这个范围，会在这些比特中使用转义码，在接下来的两个字节（byte）里才存放真正的长度。
4.2.6 正向索引
正向索引实际上已经部分排序。
它被存放在一系列的桶（barrels）里面（我们用了64个）。
每个桶保存了一定范围内的wordID。
如果一个文档包含了属于某个桶的单词，它的docID将被记录在桶里面，后面接着一个wordID的列表和相应的命中列表。
这种结构需要一点多余空间，因为存储了重复的docID，由于桶的数量很小，所以存储空间的差别很小，但是它能在排序器（sorter）建立最终索引的时候大大节省时间并降低了程序复杂度。
更进一步，我们并没有存储完整的wordID，而是存储每个wo
升级会员 