Doug Cutting 访谈录 -- 关于搜索引擎的开发

作为Lucene和Nutch两 大Apach Open Source Project的始创人(其实还有Lucy, Lucene4C 和Hadoop等相关子项目)，Doug Cutting 一直为搜索引擎的开发人员所关注。他终于在为Yahoo以Contractor的身份工作4年后，于今年正式以Employee的身份加入Yahoo

下面是笔者在工作之余,翻译其一篇2年前的访谈录，原文(Doug Cutting Interview)在网上Google一下就容易找到。希望对搜索引擎开发的初学者起到一个抛砖引玉的效果。

(注：翻译水平有限，不求雅，只求信，达。希望见谅)

1。请问你以何为生？你是如何开始从事搜索引擎开发的？

我主要在家从事两个与搜索有关的开源项目的开发: Lucene和Nutch. 钱主要来自于一些与这些项目相关的一些合同中。目前Yahoo! Labs 有一部分赞助在Nutch上。这两个项目还有一些其他的短期合同 。

2。你能大概给我们讲解一下Nutch吗？以及你将在哪方面运用它？

我还是先说一下Lucene吧。Lucene其实是一个提供全文文本搜索的函数库，它不是一个应用软件。它提供很多API函数让你可以运用到各种实际应用程序中。现在，它已经成为Apache的一个项目并被广泛应用着。这里列出一些已经使用Lucene的系统。

Nutch 是一个建立在Lucene核心之上的Web搜索的实现，它是一个真正的应用程序。也就是说，你可以直接下载下来拿过来用。它在Lucene的基础上加了网 络爬虫和一些和Web相关的东东。其目的就是想从一个简单的站内索引和搜索推广到全球网络的搜索上，就像Google和Yahoo一样。当然，和那些巨人 竞争，你得动一些脑筋，想一些办法。我们已经测试过100M的网页，并且它的设计用在超过1B的网页上应该没有问题。当然，让它运行在一台机器上，搜索一 些服务器，也运行的很好。

3。在你看来，什么是搜索引擎的核心元素？也就说，一般的搜索引擎软件可以分成哪几个主要部分或者模块？

让我想想，大概是如下几块吧：

 -- 攫取(fetching)：就是把被指向的网页下载下来。
 -- 数据库：保存攫取的网页信息，比如那些网页已经被攫取，什么时候被攫取的以及他们又有哪些链接的网页等等。
 -- 链接分析：对刚才数据库的信息进行分析，给每个网页加上一些权值(比如PageRank,WebRank什么的)，以便对每个网页的重要性有所估计。不 过，在我看来，索引那些网页标记(Anchor)里面的内容更为重要。(这也是为什么诸如Google Bombing如此高效的原因)
 -- 索引(Indexing): 就是对攫取的网页内容，以及链入链接，链接分析权值等信息进行索引以便迅速查询。
 -- 搜索(Searching): 就是通过一个索引进行查询然后按照网页排名显示。

当然，为了让搜索引擎能够处理数以亿计的网页，以上的模块都应该是分布式的。也就是说，可以在多台机器上并行运行。

4。你刚才说大家可以立马下载Nutch运行在自己的机器上。这是不是说，即便那些对Apache服务器没有掌控权的网站管理员在短时间内就可以使用Nutch?

很不幸，估计他们大都没戏。因为Nutch还是需要一个Java servlet的容器(笔者注：比如Tomcat)。而这个有些ISP支持，但大都不支持。(笔者注: 只有对Apache服务器有掌控权，你才能在上面安装一个Tomcat之类的东东)

5。我可以把Lucene和Google Web API结合起来吗？或者和其他的一些我先前写过的应用程序结合起来？

有那么一帮人已经为Nutch写了一些类似Google的API, 但还没有一个融入现在的系统。估计不久的将来就行了。

6。你认为目前实现一个搜索引擎最大的障碍在哪里？是硬件，存储障碍还是排名算法？还有，你能不能告诉我大概需要多大的空间搜索引擎才能正常工作，就说我只想写一个针对搜索成千上百万的RSS feeds的一个搜索引擎吧。

Nutch 大概一个网页总共需要10kb的空间吧。Rss feeds的网页一般都比较小(笔者注: Rss feeds都是基于xml的文本网页，所以不会很大)，所以应该更好处理吧。当然Nutch目前还没有针对RSS的支持。(笔者注：实际上，API里面有 针对RSS的数据结构和解析)

7。从Yahoo! Labs拿到资金容易吗？哪些人可以申请？你又要为之做出些什么作为回报？

我是被邀请的，我没有申请。所以我不是很清楚个中的流程。

8。Google有没有表示对Nutch感兴趣？

我和那边的一些家伙谈过，包括Larry Page(笔者注: Google两个创始人之一)。他们都很愿意提供一些帮助，但是他们也无法找到一种不会帮助到他们竞争对手的合适方式。

9。你有实现你自己的PageRank或者WebRank算法系统在你的Nutch里吗？什么是你做网页排名(Ranking)的考虑？

是的，Nutch里面有一个链接分析模块。它是可选的，因为对于站内搜索来说，网页排名是不需要的。

10。我想你以前有听说过，就是对于一个开源的搜索引擎，是不是意味着同样会给那些搞搜索引擎优化(SEO)的黑客们有机可趁？

恩，有可能。
就 说利用反向工程破解的非开源搜索引擎中的最新的反垃圾信息检测算法需要大概6个月的时间。对于一个开放源码的搜索引擎来说，破解将会更快。但不管怎么说， 那些制造垃圾信息者最终总能找到破解办法，唯一的区别就是破解速度问题。所以最好的反垃圾信息技术，不管开源也好闭源也好，就是让别人知道了其中的机制之 后也能继续工作那一种。

还有，如果这六月中你是把检测出来的垃圾信息从你的索引中移除，他们无计可施，他们只能改变他们的站点。如果你的垃圾信息检测是基于对一些网站中好的和坏的例子的统计分析，你可以彻夜留意那些新的垃圾信息模式并在他们有机会反应之前将他们移除。

开源会使得禁止垃圾信息的任务稍稍艰巨一点，但不是使之成为不可能。况且，那些闭源的搜索引擎也并没有秘密地解决这些问题。我想闭源的好处就是不让我们看到它其实没有我们想象的那么好。

11。Nutch和分布式的网络爬虫Grub相比怎么样？你是怎么想这个问题的？

我能说的就是，Grub是一个能够让网民们贡献一点自己的硬件和带宽给巨大的LookSmart的爬行任务的一个工程。它只有客户端是开源，而服务端没有。所以大家并不能配置自己的Grub服务，也不能访问到Grub收集的数据。

更 一般意义的分布式网络爬行又如何？当一个搜索引擎变得很大的时候，其爬行上的代价相对搜索上需要付出的代价将是小巫见大巫。所以，一个分布式爬虫并不能是 显著降低成本，相反它会使得一些已经不是很昂贵的东西变得很复杂(笔者注：指pc和硬盘之类的硬件)。所以这不是一个便宜的买卖。

广泛的 分布式搜索是一件很有趣的事，但我不能肯定它能否实现并保持速度足够的快。一个更快的搜索引擎就是一个更好的搜索引擎。当大家可以任意快速更改查询的时 候，他们就更能在他们失去耐心之前频繁找到他们所需的东西。但是，要建立一个不到1秒内就可以搜索数以亿计的网页的广泛的分布式搜索引擎是很难的一件事， 因为其中网络有很高的延时。大都的半秒时间或者像Google展示它的查询那样就是在一个数据中心的网络延时。如果你让同样一个系统运行在千家万户的家里 的PC上，即便他们用的是DSL和Cable上网，网络的延时将会更高从而使得一个查询很可能要花上几秒钟甚至更长的时间。从而他也不可能会是一个好的搜 索引擎。

12。你反复强调速度对于搜索引擎的重要性，我经常很迷惑Google怎么就能这么快地返回查询结果。你认为他们是怎么做到的呢？还有你在Nutch上的经验看法如何？

我 相信Google的原理和Nutch大抵相同：就是把查询请求广播到一些节点上，每个节点返回一些页面的顶级查询结果。每个节点上保存着几百万的页面，这 样可以避免大多查询的磁盘访问，并且每个节点可以每秒同时处理成十上百的查询。如果你想获得数以亿计的页面，你可以把查询广播到成千的节点上。当然这里会 有不少网络流量。

具体的在这篇文章（ www.computer.org/ micro/mi2003/ m2022.pdf）中有所描述。

13。 你刚才有提到垃圾信息，在Nutch里面是不是也有类似的算法？怎么区别垃圾信息模式比如链接场(Linkfarms)(笔者注：就是一群的网页彼此互相 链接，这是当初在1999年被一帮搞SEO弄出来的针对lnktomi搜索引擎的使网页的排名得到提高的一种Spamdexing方法)和那些正常的受欢 迎的站点链接。

这个，我们还没有腾出时间做这块。不过，很显然这是一个很重要的领域。在我们进入链接场之前，我们需要 做一些简单的事情：察看词汇填充(Word stuffing)(笔者注：就是在网页里嵌入一些特殊的词汇，并且出现很多的次，甚至上百次，有些是人眼看不到的，比如白板写白字等伎俩，这也是 Spamdexing方法的一种)，白板写白字(White-on-white text)，等等。

我想在一般意义上来说(垃圾信息检测 是其中的一个子问题)，搜索质量的关键在于拥有一个对查询结果手工可靠评估的辅助措施。这样，我们可以训练一个排名算法从而产生更好的查询结果(垃圾信息 的查询结果是一种坏的查询结果)。商业的搜索引擎往往会雇佣一些人进行可靠评估。Nutch也会这样做，但很显然我们不能只接受那些友情赞助的评估，因为 那些垃圾信息制造者很容易会防止那些评估。因此我们需要一种手段去建立一套自愿评估者的信任体制。我认为一个平等评论系统(peer-review system),有点像Slashdot的karma系统, 应该在这里很有帮助。

14。你认为搜索引擎在不久的将来路在何方？你认为从一个开发者的角度来看，最大的障碍将在哪里？

很 抱歉，我不是一个想象力丰富的人。我的预测就是在未来的十年里web搜索引擎将和现在的搜索引擎相差无几。现在应该属于平稳期。在最初的几年里，网络搜索 引擎确实曾经发展非常迅速。源于1994年的网络爬虫使用了标准的信息析取方法。直到1998年Google的出现，其间更多的基于Web的方法得到了发 展。从那以后，新方法的引入大大放慢了脚步。那些树枝低的果实已被收获。创新只有在刚发展的时候比较容易，越到后来越成熟，越不容易创新。网络搜索引擎起 源于上个世纪90年代，现在俨然已成一颗摇钱树，将来很快会走进人们的日常生活中。

至于开发上的挑战，我认为操作上的可靠性将是一个大的 挑战。我们目前正在开发一个类似GFS(Google的文件系统)的东西。它是巨型搜索引擎不可缺少的基石：你不能让一个小组件的错误导致一个大的瘫痪。 你应该很容易的让系统扩展，只需往硬件池里加更多硬件而不需繁缛的重新配置。还有，你不需要一大坨的操作人员完成，所有的一切将大都自己搞定。