试运行脚本说明――抓取全过程… 1

一、系统架构… 3

二、Nutch的安装测试… 6

关于 Nutch 的 segread TOOL. 7

关于 nutch analyze db. 9

Nutch中分词的嵌入… 11

Nutch中文问题… 11

Nutch中爬取网页过程中url的过滤问题… 12

Nutch中的插件结构… 12

类剖析… 15

UTF-8. 15

org.apache.nutch.io.DataOutputBuffer. 16

Segments数据的读取… 16

FetchedSegments类 – 通过hit读取所有数据… 16

NutchBean中索引加载顺序… 16

Nutch查询服务器配置方法… 17

Nutch中脚本命令与类的对应关系… 18

Nutch中查询处理… 18

SEWM评测跑程序参考步骤… 18

Trie-based approximate autocomplete implementation with support for ranks and synonyms

Posted by Kelvin on 01 Jul 2009 at 02:30 am | Tagged as: programming

The problem of auto-completing user queries is a well-explored one.

For example,
Type less, find more: fast autocompletion search with a succinct index
http://stevedaskam.wordpress.com/2009/06/07/putting-autocomplete-data-structure-to-the-test/
http://suggesttree.sourceforge.net/
http://sujitpal.blogspot.com/2007/02/three-autocomplete-implementations.html

However, there’s been little written about supporting synonyms and approximate matching for the purpose of autocompletion.

The approach for autocompletion I’ll be discussing in this article supports the following features:

- given a prefix, returns all words starting with that prefix
- approximate/fuzzy prefix matching based on k-errors / edit distance / Levenstein distance, with the operations: substitution, insert and delete (though adjacent transpositions would be trivial to add)
- support for ranks (i.e. a number associated with a word that affects ranking, like number of search results for a given phrase)
- support for synonyms

The search algorithm is independent of dictionary size, and dependent on k (edit distance) and length of prefix.

Data Structures

The data structure used is a trie. Words are broken into characters. Each character forms a node in a tree.

To support synonyms, a pointer is added to terminal nodes which points to the canonical word of the synonym ring.

To support ranks, a pointer is added to terminal nodes with the value of the rank. At search time, nodes are sorted first by edit distance, then by rank.

Implementation

At index-time, as mentioned above, a trie is built from input words/lexicon. No other preprocessing is done.

At search-time, dynamic programming (DP) is applied on a depth-first traversal of the trie, to collect all the “active sub-tries” of the trie which are less than k errors from the given prefix.

Where traditional DP uses a m x n matrix for its DP table where m and n are the 2 strings to be compared, we instantiate a single (prefix length + max k) x (prefix length) matrix for the entire trie, where prefix is the string for which we want to produce autocomplete results for.

Why (prefix length + max k) x (prefix length) ?

1. We don’t need to compare full strings because we’re only interested in collecting active sub-tries which satisfy the k-errors constraint.

2. For cases where the length of the word to be evaluated is greater than the length of the prefix, evaluations of the word should be performed up to prefix length + maximum k. This is to take into account the scenario where the first k characters of a word, when deleted, satisfy the edit distance constraint. e.g. prefix of hamm and word bahamm, with k=2.

Cutoff optimizations

Each level of the trie has a non-decreasing value of k (edit distance).

Therefore when k > maximum k, we can proceed to reject the entire sub-trie of that node. In other words, given the prefix hamm, and maximum k of 1, when we encounter hen which has k=2, we can discard any children of hen because their k-values will be >= 2.

Collecting autocomplete results

With a list of active sub-tries, we will then proceed to collect all terminal strings, sort them by edit distance and rank, and return the top n results.

Further explorations

1. Implementing adjacent transpositions
2. Implementing Ukkonen’s cutoff algorithm for DP (not to be confused with Ukkonen’s algorithm for constant-time creation of suffix trees)
3. Comparing performance of tries vs compact tries (where non-branching nodes are collapsed)

一般来说，搜索引擎这样一个软件系统都是事先收集好网页，存储在本地硬盘上，然后再进行预处理、索引。可以想象如果等用户查询时再爬取成千上万的网页，再一个个分析处理，是不可能满足搜索引擎的响应时间要求的。^[1]一般搜索引擎都是使用一种叫网络爬虫（也叫网络爬虫和网络机器人）的程序来完成这项工作，下面我们讲介绍这样一个程序的原理以及其实现。

2.2 网络爬虫介绍

互联网其实就是一张大图，我们可以把每一个网页当作一个节点，把那些超链接（Hyperlinks)当作连接网页的弧。网页中那些蓝色的、带有下划线的文字背后其实藏着对应的网址，当你点下去的的时候，浏览器是通过这些隐含的网址转到相应的网页中的。这些隐含在文字背后的网址称为“超链接”。有了超链接，我们可以从任何一个网页出发，用图的遍历算法，自动地访问到每一个网页并把它们存起来。完成这个功能的程序叫做网络爬虫，或者在一些文献中称为“机器人“（Robot)。世界上第一个网络爬虫是由麻省理工学院 (MIT)的学生马休.格雷（Matthew Gray)在 1993 年写成的。他给他的程序起了个名字叫“互联网漫游者”(“www wanderer”)。以后的网络爬虫越写越复杂，但原理是一样的。

那么网络爬虫如何下载整个互联网。假定我们从一家门户网站的首页出发，先下载这个网页，然后通过分析这个网页，可以找到藏在它里面的所有超链接，也就等于知道了这家门户网站首页所直接连接的全部网页，诸如雅虎邮件、雅虎财经、雅虎新闻等等。我们接下来访问、下载并分析这家门户网站的邮件等网页，又能找到其他相连的网页。我们让计算机不停地做下去，就能下载整个的互联网。

2.2.1 搜集的策略

最长见一种方式就是所谓的“爬行”。我们在遍历互联网这张大图时，既可以从某个网页节点（或节点集）开始深度优先遍历，也可以广度优先遍历。由图论知识我们可以知道， 遍历时必须记录下已经访问过的节点（避免重复），在网络爬虫中，我们使用一个称为“哈希表”(Hash Table)的列表而不是一个记事本纪录网页是否下载过的信息。下面我们要介绍的爬虫WebLech就是采取这一策略。

由于不可能抓取所有的网页，有些网络爬虫对一些不太重要的网站，设置了访问的层数。这也让有些网站上一部分网页能够在搜索引擎上搜索到，另外一部分不能被搜索到。对于网站设计者来说，扁平化的网站结构设计有助于搜索引擎抓取其更多的网页。

       另外一种可行的方式是使用最佳优先遍历循环的收集。首先我们应该有一个初始的种子URL集合，爬虫爬取这些种子URL后，解析出这些网页中的包括的URL，并加入到系统维护的一个URL集合S中，然后再对S中的链接进行分析（去重，判断起重要程度，标记其爬行周期等），再用某种算法优先生成一个待爬行的网页集合D，再重复这一过程，循环爬取网页。下面我们要介绍的Nutch爬虫就是采取这一策略。

       最后还有一种方式就是让网站拥有者主动向搜索引擎提交它们的网址，系统在一定时间内定向去爬取这些网站。一般来说该种策略都是与以上两种方法配合使用，目前常见的是广度优先和最佳优先方法。

2.2.2 信息指纹在爬虫中的应用

       在哈希表中以字符串的形式直接存储网址，既费内存空间，又浪费查找时间。现在的网址一般都较长，比如，如果在 Google 或者百度在查找数学之美，对应的网址长度在一百个字符以上。下面是百度的链接
http://www.baidu.com/s?ie=gb2312&bs=%CA%FD%D1%A7%D6%AE%C3%C0&sr=&z=&cl=3&f=8&wd=%CE%E2%BE%FC+%CA%FD%D1%A7%D6%AE%C3%C0&ct=0

假定网址的平均长度为一百个字符，那么存贮 200 亿个网址本身至少需要 2 TB，即两千 GB 的容量，考虑到哈希表的存储效率一般只有 50%，实际需要的内存在 4 TB以上。即使把这些网址放到了计算机的内存中，由于网址长度不固定，以字符串的形式查找的效率会很低。因此，我们如果能够找到一个函数，将这 200 亿个网址随机地映射到128 二进位即 16 个字节的整数空间，比如将上面那个很长的字符串对应成一个如下的随机数:
893249432984398432980545454543，这样每个网址只需要占用 16 个字节而不是原来的一百个。这就能把存储网址的内存需求量降低到原来的 1/6。这个16 个字节的随机数，就称做该网址的信息指纹（Fingerprint)。可以证明，只要产生随机数的算法足够好，可以保证几乎不可能有两个字符串的指纹相同，就如同不可能有两个人的指纹相同一样。由于指纹是固定的 128 位整数，因此查找的计算量比字符串比较小得多。网络爬虫在下载网页时，它将访问过的网页的网址都变成一个个信息指纹，存到哈希表中，每当遇到一个新网址时，计算机就计算出它的指纹，然后比较该指纹是否已经在哈希表中，来决定是否下载这个网页。这种整数的查找比原来字符串查找,可以快几倍到几十倍。^[2]

2.3 网页的维护与更新

1）、批量搜集

批量搜集，就是每次搜集替换上一次的内容。由于每次都是重新来一次，对度大规模搜索引擎来说，搜集的时间通常会花几周。这样做的好处是系统实现比较简单，主要缺点是“时新性”不高，还有重复收集带来的带宽消耗。

2）、增量搜集

       增量搜集，开始时搜集一批，往后只是：1、搜集新出现的网页；2、搜集在上次搜集后有改变的网页；3、删除上次搜集后不存在的网页

2.4 爬虫程序设计中要注意的问题

Ÿ 网站的速度

Ÿ  DNS缓存

Ÿ 不可到达的站点处理

Ÿ 网页的存储－网页的长期存储

Ÿ 搜集的效率－多进程或多线程，分布式搜集

Ÿ 避免重复收集

Ÿ 更新周期控制

Ÿ 搜集重要网页

2.5 网站与网络爬虫

网络爬虫需要抓取网页，不同于一般的访问，如果控制不好，则会引起网站服务器负担过重。2005年4月，淘宝网（http://www.taobao.com）就因为雅虎搜索引擎的网络爬虫抓取其数据引起淘宝网服务器的不稳定。网站是否就无法和网络爬虫交流呢？其实不然，有多种方法可以让网站和网络爬虫进行交流。一方面让网站管理员了解网络爬虫都来自哪儿，做了些什么，另一方面也告诉网络爬虫哪些网页不应该抓取，哪些网页应该更新。

每个网络爬虫都有自 己的名字，在抓取网页的时候，都会向网站标明自己的身份。网络爬虫在抓取网页的时候会发送一个请求，这个请求中就有一个字段为User－agent，用于标识此网络爬虫的身份。例如Google网络爬虫的标识为GoogleBot，Baidu网络爬虫的标识为BaiDuSpider，Yahoo网络爬虫的 标识为Inktomi Slurp。如果在网站上有访问日志记录，网站管理员就能知道，哪些搜索引擎的网络爬虫过来过，什么时候过来的，以及读了多少数据等等。如果网站管理员发现某个爬虫有问题，就通过其标识来和其所有者联系。下面是博客中国（http://www.blogchina.com）2004年5月15日的搜索引擎访问日志：网络爬虫进入一个网站，一般会访问一个特殊的文本文件Robots.txt，这个文件一般放在网站服务器的根目录下，如： http://www.blogchina.com/robots.txt。网站管理员可以通过robots.txt来定义哪些目录网络爬虫不能访问，或 者哪些目录对于某些特定的网络爬虫不能访问。例如有些网站的可执行文件目录和临时文件目录不希望被搜索引擎搜索到，那么网站管理员就可以把这些目录定义为 拒绝访问目录。Robots.txt语法很简单，例如如果对目录没有任何限制，可以用以下两行来描述：

User-agent: *

Disallow:

当然，Robots.txt只是一个协议，如果网络爬虫的设计者不遵循这个协议，网站管理员也无法阻止网络爬虫对于某些页面的访问，但一般的网络爬虫都会遵循这些协议，而且网站管理员还可以通过其它方式来拒绝网络爬虫对某些网页的抓取。

网络爬虫在下载网页的时候，会去识别网页的HTML代码，在其代码的部分，会有META标识。通过这些标识，可以告诉网络爬虫本网页是否需要被抓取，还可以告诉网络爬虫本网页中的链接是否需要被继续跟踪。例如：表示本网页不需要被抓取，但是网页内的链接需要被跟踪。

关于Robots.txt的语法和META Tag语法，有兴趣的读者查看文献[4] 现在一般的网站都希望搜索引擎能更全面的抓取自己网站的网页，因为这样可以让更多的访问者能通过搜索引擎找到此网站。为了让本网站的网页更全面被抓取到，网站管理员可以建立一个网站地图，即Site Map。许多网络爬虫会把sitemap.htm文件作为一个网站网页爬取的入口，网站管理员可以把网站内部所有网页的链接放在这个文件里面，那么网络蜘蛛可以很方便的把整个网站抓取下来，避免遗漏某些网页，也会减小对网站服务器的负担。

Nutch/Lucene的存取机制与结构分析

2007-12-04 00:08