大家比较熟悉使用各种搜索引擎，但是，还有一种更主动和专门的搜索技术：网络爬虫。
1 爬虫技术研究综述
引言
随着网络的迅速发展，万维网成为大量信息的载体，如何有效地提取并利用这些信息成为一个巨大的挑战。搜索引擎(Search Engine)，例如传统的通用搜索引擎AltaVista，Yahoo!和Google等，作为一个辅助人们检索信息的工具成为用户访问万维网的入口和指南。但是，这些通用性搜索引擎也存在着一定的局限性，如：
(1) 不同领域、不同背景的用户往往具有不同的检索目的和需求，通用搜索引擎所返回的结果包含大量用户不关心的网页。
(2) 通用搜索引擎的目标是尽可能大的网络覆盖率，有限的搜索引擎服务器资源与无限的网络数据资源之间的矛盾将进一步加深。
(3) 万维网数据形式的丰富和网络技术的不断发展，图片、数据库、音频/视频多媒体等不同数据大量出现，通用搜索引擎往往对这些信息含量密集且具有一定结构的数据无能为力，不能很好地发现和获取。
(4) 通用搜索引擎大多提供基于关键字的检索，难以支持根据语义信息提出的查询。
为 了解决上述问题，定向抓取相关网页资源的聚焦爬虫应运而生。聚焦爬虫是一个自动下载网页的程序，它根据既定的抓取目标，有选择的访问万维网上的网页与相关 的链接，获取所需要的信息。与通用爬虫(generalpurpose web crawler)不同，聚焦爬虫并不追求大的覆盖，而将目标定为抓取与某一特定主题内容相关的网页，为面向主题的用户查询准备数据资源。
1 聚焦爬虫工作原理及关键技术概述
网 络爬虫是一个自动提取网页的程序，它为搜索引擎从万维网上下载网页，是搜索引擎的重要组成。传统爬虫从一个或若干初始网页的URL开始，获得初始网页上的 URL，在抓取网页的过程中，不断从当前页面上抽取新的URL放入队列,直到满足系统的一定停止条件，如图1(a)流程图所示。聚焦爬虫的工作流程较为复 杂，需要根据一定的网页分析算法过滤与主题无关的链接，保留有用的链接并将其放入等待抓取的URL队列。然后，它将根据一定的搜索策略从队列中选择下一步 要抓取的网页URL，并重复上述过程，直到达到系统的某一条件时停止，如图1(b)所示。另外，所有被爬虫抓取的网页将会被系统存贮，进行一定的分析、过 滤，并建立索引，以便之后的查询和检索；对于聚焦爬虫来说，这一过程所得到的分析结果还可能对以后的抓取过程给出反馈和指导。
相对于通用网络爬虫，聚焦爬虫还需要解决三个主要问题：
(1) 对抓取目标的描述或定义；
(2) 对网页或数据的分析与过滤；
(3) 对URL的搜索策略。
抓取目标的描述和定义是决定网页分析算法与URL搜索策略如何制订的基础。而网页分析算法和候选URL排序算法是决定搜索引擎所提供的服务形式和爬虫网页抓取行为的关键所在。这两个部分的算法又是紧密相关的。
2 抓取目标描述
现有聚焦爬虫对抓取目标的描述可分为基于目标网页特征、基于目标数据模式和基于领域概念3种。
基于目标网页特征的爬虫所抓取、存储并索引的对象一般为网站或网页。根据种子样本获取方式可分为：
（1） 预先给定的初始抓取种子样本；
（2） 预先给定的网页分类目录和与分类目录对应的种子样本，如Yahoo!分类结构等；
（3） 通过用户行为确定的抓取目标样例，分为：
a) 用户浏览过程中显示标注的抓取样本；
b) 通过用户日志挖掘得到访问模式及相关样本。
其中，网页特征可以是网页的内容特征，也可以是网页的链接结构特征，等等。
现有的聚焦爬虫对抓取目标的描述或定义可以分为基于目标网页特征，基于目标数据模式和基于领域概念三种。
基 于目标网页特征的爬虫所抓取、存储并索引的对象一般为网站或网页。具体的方法根据种子样本的获取方式可以分为：（1）预先给定的初始抓取种子样本；（2） 预先给定的网页分类目录和与分类目录对应的种子样本，如Yahoo!分类结构等；（3）通过用户行为确定的抓取目标样例。其中，网页特征可以是网页的内容 特征，也可以是网页的链接结构特征，等等。
作者： [...]

网络爬虫是一个自动提取网页的程序，它为搜索引擎从Internet网上下载网页，是搜索引擎的重要组成。传统爬虫从一个或若干初始网页的URL开始，获 得初始网页上的URL，在抓取网页的过程中，不断从当前页面上抽取新的URL放入队列,直到满足系统的一定停止条件。聚焦爬虫的工作流程较为复杂，需要根 据一定的网页分析算法过滤与主题无关的链接，保留有用的链接并将其放入等待抓取的URL队列。然后，它将根据一定的搜索策略从队列中选择下一步要抓取的网 页URL，并重复上述过程，直到达到系统的某一条件时停止，另外，所有被爬虫抓取的网页将会被系统存贮，进行一定的分析、过滤，并建立索引，以便之后的查 询和检索；对于聚焦爬虫来说，这一过程所得到的分析结果还可能对以后的抓取过程给出反馈和指导。
相对于通用网络爬虫，聚焦爬虫还需要解决三个主要问题：
(1) 对抓取目标的描述或定义；
(2) 对网页或数据的分析与过滤；
(3) 对URL的搜索策略。
抓取目标的描述和定义是决定网页分析算法与URL搜索策略如何制订的基础。而网页分析算法和候选URL排序算法是决定搜索引擎所提供的服务形式和爬虫网页抓取行为的关键所在。这两个部分的算法又是紧密相关的。
2 抓取目标描述
现有聚焦爬虫对抓取目标的描述可分为基于目标网页特征、基于目标数据模式和基于领域概念3种。
基于目标网页特征的爬虫所抓取、存储并索引的对象一般为网站或网页。根据种子样本获取方式可分为：
（1） 预先给定的初始抓取种子样本；
（2） 预先给定的网页分类目录和与分类目录对应的种子样本，如Yahoo!分类结构等；
（3） 通过用户行为确定的抓取目标样例，分为：

用户浏览过程中显示标注的抓取样本；
通过用户日志挖掘得到访问模式及相关样本。

其中，网页特征可以是网页的内容特征，也可以是网页的链接结构特征，等等。
现有的聚焦爬虫对抓取目标的描述或定义可以分为基于目标网页特征，基于目标数据模式和基于领域概念三种。
基 于目标网页特征的爬虫所抓取、存储并索引的对象一般为网站或网页。具体的方法根据种子样本的获取方式可以分为：（1）预先给定的初始抓取种子样本；（2） 预先给定的网页分类目录和与分类目录对应的种子样本，如Yahoo!分类结构等；（3）通过用户行为确定的抓取目标样例。其中，网页特征可以是网页的内容 特征，也可以是网页的链接结构特征，等等。
基于目标数据模式的爬虫针对的是网页上的数据，所抓取的数据一般要符合一定的模式，或者可以转化或映射为目标数据模式。
另一种描述方式是建立目标领域的本体或词典，用于从语义角度分析不同特征在某一主题中的重要程度。
3 网页搜索策略
网页的抓取策略可以分为深度优先、广度优先和最佳优先三种。深度优先在很多情况下会导致爬虫的陷入(trapped)问题，目前常见的是广度优先和最佳优先方法。
3.1 广度优先搜索策略
广 度优先搜索策略是指在抓取过程中，在完成当前层次的搜索后，才进行下一层次的搜索。该算法的设计和实现相对简单。在目前为覆盖尽可能多的网页，一般使用广 度优先搜索方法。也有很多研究将广度优先搜索策略应用于聚焦爬虫中。其基本思想是认为与初始URL在一定链接距离内的网页具有主题相关性的概率很大。另外 一种方法是将广度优先搜索与网页过滤技术结合使用，先用广度优先策略抓取网页，再将其中无关的网页过滤掉。这些方法的缺点在于，随着抓取网页的增多，大量 的无关网页将被下载并过滤，算法的效率将变低。
3.2 最佳优先搜索策略
最佳优先搜索策略按照一定的网页分 析算法，预测候选URL与目标网页的相似度，或与主题的相关性，并选取评价最好的一个或几个URL进行抓取。它只访问经过网页分析算法预测为“有用”的网 页。存在的一个问题是，在爬虫抓取路径上的很多相关网页可能被忽略，因为最佳优先策略是一种局部最优搜索算法。因此需要将最佳优先结合具体的应用进行改 进，以跳出局部最优点。将在第4节中结合网页分析算法作具体的讨论。研究表明，这样的闭环调整可以将无关网页数量降低30%~90%。
4 网页分析算法
网页分析算法可以归纳为基于网络拓扑、基于网页内容和基于用户访问行为三种类型。
4.1 基于网络拓扑的分析算法
基于网页之间的链接，通过已知的网页或数据，来对与其有直接或间接链接关系的对象（可以是网页或网站等）作出评价的算法。又分为网页粒度、网站粒度和网页块粒度这三种。
4.1.1 网页(Webpage)粒度的分析算法
PageRank 和HITS算法是最常见的链接分析算法，两者都是通过对网页间链接度的递归和规范化计算，得到每个网页的重要度评价。PageRank算法虽然考虑了用户 访问行为的随机性和Sink网页的存在，但忽略了绝大多数用户访问时带有目的性，即网页和链接与查询主题的相关性。针对这个问题，HITS算法提出了两个 关键的概念：权威型网页（authority）和中心型网页（hub）。
基于链接的抓取的问题是相关页面主题团之间的隧道现象，即很 多在抓取路径上偏离主题的网页也指向目标网页，局部评价策略中断了在当前路径上的抓取行为。文献[21]提出了一种基于反向链接（BackLink）的分 层式上下文模型（Context Model），用于描述指向目标网页一定物理跳数半径内的网页拓扑图的中心Layer0为目标网页，将网页依据指向目标网页的物理跳数进行层次划分，从外 层网页指向内层网页的链接称为反向链接。
4.1.2 网站粒度的分析算法
网站粒度的资源发现和管理策略也比网页粒度的更 简单有效。网站粒度的爬虫抓取的关键之处在于站点的划分和站点等级(SiteRank)的计算。SiteRank的计算方法与PageRank类似，但是 需要对网站之间的链接作一定程度抽象，并在一定的模型下计算链接的权重。
网站划分情况分为按域名划分和按IP地址划分两种。文献[18]讨 论了在分布式情况下，通过对同一个域名下不同主机、服务器的IP地址进行站点划分，构造站点图，利用类似PageRank的方法评价SiteRank。同 时，根据不同文件在各个站点上的分布情况，构造文档图，结合SiteRank分布式计算得到DocRank。文献[18]证明，利用分布式的 SiteRank计算，不仅大大降低了单机站点的算法代价，而且克服了单独站点对整个网络覆盖率有限的缺点。附带的一个优点是，常见PageRank 造假难以对SiteRank进行欺骗。
4.1.3 网页块粒度的分析算法
在一个页面中，往往含有多个指向其他页面的链接，这些 链接中只有一部分是指向主题相关网页的，或根据网页的链接锚文本表明其具有较高重要性。但是，在PageRank和HITS算法中，没有对这些链接作区 分，因此常常给网页分析带来广告等噪声链接的干扰。在网页块级别(Blocklevel)进行链接分析的算法的基本思想是通过VIPS网页分割算法将网 页分为不同的网页块(page block)，然后对这些网页块建立pagetoblock和blocktopage的链接矩阵，分别记为Z和X。于是，在 pagetopage图上的网页块级别的PageRank为Wp=X×Z；在blocktoblock图上的BlockRank为 Wb=Z×X。已经有人实现了块级别的PageRank和HITS算法，并通过实验证明，效率和准确率都比传统的对应算法要好。
4.2 基于网页内容的网页分析算法
基 于网页内容的分析算法指的是利用网页内容（文本、数据等资源）特征进行的网页评价。网页的内容从原来的以超文本为主，发展到后来动态页面（或称为 Hidden Web）数据为主，后者的数据量约为直接可见页面数据（PIW，Publicly [...]

Crawler和Searcher两部分尽量分开的目的主要是为了使两部分可以分布式配置在硬件平台上，例如将Crawler和Searcher分别放在两个主机上，这样可以提升性能。
爬虫，Crawler：
Crawler的重点在两个方面，Crawler的工作流程和涉及的数据文件的格式和含义。数据文件主要包括三类，分别是 web database，一系列的segment加上index，三者的物理文件分别存储在爬行结果目录下的db目录下webdb子文件夹内， segments文件夹和index文件夹。那么三者分别存储的信息是什么呢？
Web database，也叫WebDB，其中存储的是爬虫所抓取网页之间的链接结构信息，它只在爬虫Crawler工作中使用而和 Searcher的工作没有任何关系。WebDB内存储了两种实体的信息：page和link。Page实体通过描述网络上一个网页的特征信息来表征一个 实际的网页，因为网页有很多个需要描述，WebDB中通过网页的URL和网页内容的MD5两种索引方法对这些网页实体进行了索引。Page实体描述的网页 特征主要包括网页内的link数目，抓取此网页的时间等相关抓取信息，对此网页的重要度评分等。同样的，Link实体描述的是两个page实体之间的链接 关系。WebDB构成了一个所抓取网页的链接结构图，这个图中Page实体是图的结点，而Link实体则代表图的边。
一次爬行会产生很多个segment，每个segment内存储的是爬虫Crawler在单独一次抓取循环中抓到的网页以及这些网页的索引。 Crawler爬行时会根据WebDB中的link关系按照一定的爬行策略生成每次抓取循环所需的fetchlist，然后Fetcher通过 fetchlist中的URLs抓取这些网页并索引，然后将其存入segment。Segment是有时限的，当这些网页被Crawler重新抓取后，先 前抓取产生的segment就作废了。在存储中。Segment文件夹是以产生时间命名的，方便我们删除作废的segments以节省存储空间。
Index是Crawler抓取的所有网页的索引，它是通过对所有单个segment中的索引进行合并处理所得的。Nutch利用Lucene 技术进行索引，所以Lucene中对索引进行操作的接口对Nutch中的index同样有效。但是需要注意的是，Lucene中的segment和 Nutch中的不同，Lucene中的segment是索引index的一部分，但是Nutch中的segment只是WebDB中各个部分网页的内容和 索引，最后通过其生成的index跟这些segment已经毫无关系了。
Crawler工作流程：
在分析了Crawler工作中设计的文件之后，接下来我们研究一下Crawler的抓取流程以及这些文件在抓取中扮演的角色。Crawler的 工作原理主要是：首先Crawler根据WebDB生成一个待抓取网页的URL集合叫做Fetchlist，接着下载线程Fetcher开始根据 Fetchlist将网页抓取回来，如果下载线程有很多个，那么就生成很多个Fetchlist，也就是一个Fetcher对应一个Fetchlist。 然后Crawler根据抓取回来的网页WebDB进行更新，根据更新后的WebDB生成新的Fetchlist，里面是未抓取的或者新发现的URLs，然 后下一轮抓取循环重新开始。这个循环过程可以叫做“产生/抓取/更新”循环。
指向同一个主机上Web资源的URLs通常被分配到同一个Fetchlist中，这样的话防止过多的Fetchers对一个主机同时进行抓取造 成主机负担过重。另外Nutch遵守Robots Exclusion Protocol，网站可以通过自定义Robots.txt控制Crawler的 抓取。
在Nutch中，Crawler操作的实现是通过一系列子操作的实现来完成的。这些子操作Nutch都提供了子命令行可以单独进行调用。下面就是这些子操作的功能描述以及命令行，命令行在括号中。
1.       创建一个新的WebDb (admin db -create).
2.       将抓取起始URLs写入WebDB中 (inject).
3.       根据WebDB生成fetchlist并写入相应的segment(generate).
4.       根据fetchlist中的URL抓取网页 (fetch).
5.       根据抓取网页更新WebDb (updatedb).
6.       循环进行3－5步直至预先设定的抓取深度。
7.       根据WebDB得到的网页评分和links更新segments (updatesegs).
8.       对所抓取的网页进行索引(index).
9.       在索引中丢弃有重复内容的网页和重复的URLs (dedup).
10.   将segments中的索引进行合并生成用于检索的最终index(merge).
Crawler详细工作流程是：在创建一个WebDB之后(步骤1), “产生/抓取/更新”循环(步骤3－6)根据一些种子URLs开始启 动。当这个循环彻底结束，Crawler根据抓取中生成的segments创建索引（步骤7－10）。在进行重复URLs清除（步骤9）之前，每个 segment的索引都是独立的（步骤8）。最终，各个独立的segment索引被合并为一个最终的索引index（步骤10）。
其中有一个细节问题，Dedup操作主要用于清除segment索引中的重复URLs，但是我们知道，在WebDB中是不允许重复的URL存在 的，那么为什么这里还要进行清除呢？原因在于抓取的更新。比方说一个月之前你抓取过这些网页，一个月后为了更新进行了重新抓取，那么旧的segment在 没有删除之前仍然起作用，这个时候就需要在新旧segment之间进行除重。
另外这些子操作在第一次进行Crawler运行时可能并不用到，它们主要用于接下来的索引更新，增量搜索等操作的实现。这些在以后的文章中我再详细讲。
个性化设置：
Nutch中的所有配置文件都放置在总目录下的conf子文件夹中，最基本的配置文件是conf/nutch-default.xml。这个文 件中定义了Nutch的所有必要设置以及一些默认值，它是不可以被修改的。如果你想进行个性化设置，你需要在conf/nutch-site.xml进行 设置，它会对默认设置进行屏蔽。
Nutch考虑了其可扩展性，你可以自定义插件plugins来定制自己的服务，一些plugins存放于plugins子文件夹。Nutch 的网页解析与索引功能是通过插件形式进行实现的，例如，对HTML文件的解析与索引是通过HTML document parsing plugin,  parse-html实现的。所以你完全可以自定义各种解析插件然后对配置文件进行修改，然后你就可以抓取并索引各种类型的文件了。

WordPress系统本身，默认安装的情况下使用默认模板，实际上对搜索引擎并不友好，并没有针对搜索引擎进行很好的设计，下面我介绍一些技巧和方法可以使得WordPress能否对搜索引擎更为友好。
1、文章URL链接结构的优化
Permalink里面要包含postname.一般的服务器都支持mod_rewrite功能，使用这个功能可以优化Permalink（永 久链接），在Option-Permalink里的Common options里进行设置，我比较倾向于使用/%year%/%monthnum%/%postname%.html这种链接结构，一来链接目录只有两 级，利于索引，二来这种链接结构和Blogspot和Movable Type的链接结构一致，比较利于系统平滑迁移或切换。postname使用英文，如果是写英文Blog的话，系统会自动将标题的post slug做为postname.
2、文章Post Slug的优化
文章标题中最好包含文章最关键的关键字，不要使用一些没有意义的标题，对于英文Blog来讲，最好启用一个名叫SEO Slugs的插件，该插件能够自动将post slug中的the、in等“没用”的单词删除，有利于SEO.
3、文章Title的优化
WordPress默认的Title是“博客名-文章名”，这对SEO很不好，我觉得应该使用“文章名-博客名”的形式，建议安装一个名叫 All in One SEO Pack的插件，可以自动将Title进行优化，并增加Descriptions和Keywords的Meta.
4、robots.txt的优化
在博客根目录下放置一个robots.txt的文件，可以指定搜索引擎只收录指定的内容。 对于WordPress来说，有一些地址是不应该被搜索引擎索引的，比如后台程序、日志文件、FEED地址等，一个针对WordPress的robots.txt的例子如下：
User-agent： * Disallow： /wp- Disallow： /feed/ Disallow： /comments/feed Disallow： /trackback/
5、Sitemap的优化
对于Google搜索引擎来讲，使用Sitemap可以让搜索引擎更为有效的进行索引，安装一个名叫Sitemap Generator的插件可以自动完成Google Sitemap的生成，然后将这个地址提交到Google Webmaster即可。
6、防止垃圾留言评论
垃圾留言评论会影响Blog在搜索引擎中的表现，因此需要安装一个自动过滤垃圾留言评论的的插件，推荐使用Akismet.
7、相关文章
通过tag的标记来实现相关文章，不过我建议使用WordPress 2.3里面的tag系统来实现，那样效率会更高一些。
8、搜索引擎来源的优化
安装一个名叫Landing sites的插件，可以让那些从搜索引擎搜索过来的用户体验更好，通过这个插件能够选择显示给用户搜索关键字相关的文章。
9、不要轻易做变动
不要总是草率的变动自己的域名、博客名、链接结构、链接地址等，早期应该做全局的规划，中途进行大的变动是非常不明智的。

10、更新你的博客
记着经常更新，并且写出高质量的内容，这才是SEO中最关键的地方，写出高质量的文章，将会更容易实现SEO的目标。

    当搜索引擎访问一个网站时，它首先会检查该网站的根域下是否有一个叫做robots.txt的纯文本文件。Robots.txt文件用于限定搜索引擎对其网站的访问范围，即告诉搜索引擎网站中哪些文件是允许它进行检索(下载)的。这就是大家在网络上常看到的“拒绝Robots访问标准”(Robots Exclusion Standard)。下面我们简称RES。 Robots.txt文件的格式：Robots.txt文件的格式比较特殊，它由记录组成。这些记录通过空行分开。其中每条记录均由两个域组成： 　　 1) 一个User-Agent(用户代理)字符串行； 　　 2) 若干Disallow字符串行。 　　 记录格式为：<Field> “:” <value> 　　 下面我们分别对这两个域做进一步说明。 User-agent(用户代理)： 　　 User-agent行(用户代理行) 用于指定搜索引擎robot的名字，以Google的检索程序Googlebot为例，有：User-agent: Googlebot 　　 一个robots.txt中至少要有一条User-agent记录。如果有多条User-agent记录，则说明有多个robot会受到RES标准的限制。当然了，如果要指定所有的robot，只需用一个通配符”*”就搞定了，即：User-agent: * Disallow(拒绝访问声明)： 　
　在Robots.txt文件中，每条记录的第二个域是Disallow:指令行。这些Disallow行声明了该网站中不希望被访问的文件和(或)目
录。例如”Disallow:
email.htm”对文件的访问进行了声明，禁止Spiders下载网站上的email.htm文件。而”Disallow:
/cgi-bin/”则对cgi-bin目录的访问进行了声明，拒绝Spiders进入该目录及其子目录。Disallow声明行还具有通配符功能。例如
上例中”Disallow:
/cgi-bin/”声明了拒绝搜索引擎对cgi-bin目录及其子目录的访问，而”Disallow:/bob”则拒绝搜索引擎对/bob.html和
/bob/indes.html的访问(即无论是名为bob的文件还是名为bob的目录下的文件都不允许搜索引擎访问)。Disallow记录如果留空，
则说明该网站的所有部分都向搜索引擎开放。 空格 & 注释 　　 在robots.txt文件中，凡以”#”开头的行，均被视为注解内容，这和UNIX中的惯例是一样的。但大家需要注意两个问题： 　
　 1)
RES标准允许将注解内容放在指示行的末尾，但这种格式并不是所有的Spiders都能够支持。譬如，并不是所有的Spiders都能够正确理解
“Disallow: bob
#comment”这样一条指令。有的Spiders就会误解为Disallow的是”bob#comment”。最好的办法是使注解自成一行。 　　 2) RES标准允许在一个指令行的开头存在空格，象”Disallow: bob #comment”，但我们也并不建议大家这么做。 Robots.txt文件的创建： 　
　需要注意的是，应当在UNIX命令行终端模式下创建Robots.txt纯文本文件。好的文本编辑器一般都能够提供UNIX模式功能，或者你的FTP客
户端软件也“应该”能够替你转换过来。如果你试图用一个没有提供文本编辑模式的HTML编辑器来生成你的robots.txt纯文本文件，那你可就是瞎子
打蚊子——白费力气了。 对RES标准的扩展： 　　 尽管已经提出了一些扩展标准，如Allow行或Robot版本控制(例如应该忽略大小写和版本号)，但尚未得到RES工作组的正式批准认可。 附录I. Robots.txt用法举例： 　　 使用通配符”*”，可设置对所有robot的访问权限。 　　 User-agent: * 　　 Disallow: 　　 [...]

搜索引擎公司经常说核心竞争是技术，实际上这个技术是宽泛的概念，应该包括了对用户的理解、对产品的理解、技术水平。Google：“完美的搜索引擎需要做到确解用户之意，切返用户之需”。搜索做得好不好不仅仅是算法的事情，更重要的是对用户意图的理解，所以搜索引擎的竞争有两个点：1.破解用户之意 2.切返用户之需。破解用户之需是产品部门的工作。从产品经理的角度来看，对一个产品有三个工作1.需求分析 2.产品决策 3.产品的跟踪、强化。(前两个工作做好了，才能把后面的工作做好)需求分析：就是针对用户的意图，需求做分析，确解用户之意。产品决策：根据需求分析，结合技术可行性对产品做设计以最恰当的方式满足用户的需求。技术实现：根据产品需求文档，完成产品的研发。

产品管理竞争：

在搜索产品理念上做得最好的公司就是google（本文均指美国google）和百度。Google要比百度更理解搜索，百度做为追随者只需要去理解google，在此基础上再建立本地化和社区化的差异化壁垒。

百度：百度的产品部门对百度的成功起到了非常大的作用。策略方面：根据市场情况和用户需求03年前是跟随策略，大量的获取新增互联网用户和新增的搜索用户。04年后社区化策略粘住获得用户，强化产品获取早期的搜索引擎用户。执行方面：百度的主要产品设计都非常到位，抓住了用户最大的需求、产品的核心竞争力、同竞争对手产品的差异化、建立良好机制来运作产品，建立内部的产品管理流程（发现问题解决问题的流程）。内部沟通：百度产品部门不仅仅把对搜索的理解灌输到每个产品经理，还将产品意识、理念影响到了高层、项目经理、工程师、市场人员身上，在产品的设计、研发、运营整个流程上时时刻刻都具有对用户需求的理解和搜索的理念。中搜：最失败的案例。好像没有专门产品部门，很多产品都是是领导拍脑袋做产品决策。关于中搜只能用“可惜”两个字了。雅虎中国：基本上没有产品决策权，申请做一antispam都要几个月，中国雅虎只是维护yapache，程序离开yapache就都不能用了。Yisou在王航的带领下把mp3做得的确不错，可惜内部的机制决定了雅虎中国不可能有任何前景。据说雅虎在等待百度不能跨越100亿数据量索引瓶颈，实在是……谷歌：具体不清楚。但是从这一年多的表现来看和雅虎中国没有太大区别。搜狗：在叫嚷100亿数据量，唉…；对搜索的理解还停留在03年。奇虎：以前不行，近期明显感觉到产品管理能力在增强。

百
度在产品管理领域已经远远领先于竞争对手，百度拥有最强大的百度知道，可以在“发现问题”方面有各种专业用户基础、有庞大的用户群时时刻刻在监测他们的产
品的每一个细节可以最快速有效的在细节方面“发现问题”、有强大的产品部门集中了几乎中国对搜索理解最深的人才、流畅的链式管理机制可以用最快的方式解决
问题强化产品……只要百度持续把这些优势发挥，那么在这个方面无以伦比，不存在一个级别的竞争对手。

技术之争：

网页搜索技术上现在进入了一个技术的相对瓶颈期，很难在理论上和技术上有大的突破（当然也有可能在任何一天有某个人提出一种新的理论颠覆了“超链接、PR”）。所以在网页搜索的技术上最关键的是如何能够针对发现的问题去解决问题。在“网页搜索引擎的发展方向http://www.fullsearcher.com/n2006227185235735.asp”一文中有些个人的看法。其中最重要的一个方面是在自然语言处理方面，这是很多工作的基础。

网
页搜索引擎产品的一个方向就是垂直化针对不同的词汇，体现不同的维度，返回不同的结果。如在百度搜索“北京
天气”会体现一个提示性的链接、搜索软件你会发现百度做了专门的优化。在google搜索股票代码、手机号码等会有不同的提示性链接，有些词汇是有新闻链
接的有些是没有的。随着宽带的普及，这些垂直信息拼接会被网页搜引擎公司应用到网页搜索产品中，很明显这主要又是产品部门和技术部门协同才能很好完成的工
作。网页搜索会发展到越来越细节。
网页搜索引擎的存在有他存在的土壤，土壤环境是怎么样的呢？1.海量的数据，互联网上有海量的数据，并且这些数据在快速增长、不断更新2.分散的数据，这些数据存在于成千上万个网站中3.多样化的数据4.用户多样化的数据搜索需求5.用户对搜索数据的实时性要求不是非常强6.用户对这些数据有整合使用的需求，并且这种需求量很大7.能够很好的对整合来的数据进行处理，能够完整的满足用户的这种需求，提供完整的信息检索体验
垂直搜索引擎存在的土壤：1.网页搜索引擎无法对某类数据进行深度加工，提供更多的细化的服务2.网页的数据实在是太多样化了（数据种类、数据类型等），不利于满足用户细分的服务3.用户有对互联网数据进行深度采集，数据的深度加工提供更细化的服务的需求，这种需求量非常巨大4.用户对某类信息的实时性的要求比较高5.针对某类信息提供更简洁、更快速，更可依赖性更强的服务6.行业性优化
垂直搜索存在的必备条件：1.海量的数据，所选择的垂直搜索的数据必须是海量的数据，数据量和增长速度、增长量都比较大。符合搜索引擎的基本条件2.分散的数据，这种数据必须要分散在很多个不同网站。不能是仅存在于几个网站。如果仅存在于几个网站不如做元搜索了（如果信息集中在几个网站，用户可以直接去使用）3.用户对这些数据的实时性有一定要求，但是又不能是对实时性要求极高（显然，春运期间的二手火车票信息就不适合做垂直搜索，因为等采集处理完毕，那票说不定已经卖掉了。拍卖的价格信息不适合做垂直搜索，有可能还没有采集处理完毕，价格已经变化了。）4.用户对这类数据的需求量是很大的，而且需要长期使用。（搜索是需要学习、长期使用才能很好的驾驭的一种应用）5.技术上能够很好的完成信息的整合、深度加工，并且加工后能够完整的满足用户对这类数据的搜索需求，提供完整的应用体验。6.这种信息的深度采集、深度加工是网页搜索引擎完全不可以替代的。
垂直搜索选型的步骤：1.选定适合您的，您熟悉的，有一定的资源背景的几个垂直搜索的被选方案。2.查看google或百度（其它搜索引擎不行）检索关键词数据。最好能搞到连续一段时间的全部词汇（按照检索频率排序），当然这几乎不可能，进行详细的分析、统计、挖掘。搞不到只要看风云榜和百度指数了，这估计就有很大偏差了。对这些用户需求数据库进行深度分析找出用户到底要什么、互联网上缺什么。（第1步和第2步交替进行）3.分析相关行业的网站，评估用户需求、数据情况、横向竞争、纵向竞争、潜在竞争情况和可能遇到的其它问题。4.如何满足用户的需求？如何保持产品和门户网站、搜索门户等的差异化和挖掘出用户潜在的最大的需求？5.评估技术上的可行性，能否实现完整用户体验。6.如何保证产品的领先性（资源、效果、市场、技术、销售……）7.产品的市场推广方式(这点非常非常重要，如何在竞争对手反应过来之前低成本的快速抵达有效用户群是成败的关键)8.盈利模式；收入模型、成本模型第一步完成到什么程度，达到什么目标。需要多少成本第二步完成到什么程度，是否可以收支平衡或者获得投资…………9.产品的不足和先天的缺陷如何克服弥补。产品的生命周期的每一步可能出现的紧急问题如何应对。10.不要认为自己很聪明，这世界上聪明人太多了，你能想到的肯定有n个人已经想到了。 关键在于您能不能充分利用自己的资源，做好前期的调查后专注的执行。11.务必要找百度和google这类搜索引擎不愿意花大功夫去做（市场暂时不够大）、或者不可能能做的应用（受制约、有更重要的事情要做），不要把你的模式和意图暴露得太早，这个市场的竞争实在是太激烈了，中国人也都太聪明了。 务必要找和门户网站、网页搜索引擎有很大差异化，并且用户有持续的很大的需求的。理由很简单：搜索是需要持续使用才能熟练的一种产品、从门户和网页搜索引擎到您的垂直引擎的门槛很高（比多点击10次的门槛还高很多）。

网页搜索引擎的存在有他存在的土壤，土壤环境是怎么样的呢？1.海量的数据，互联网上有海量的数据，并且这些数据在快速增长、不断更新2.分散的数据，这些数据存在于成千上万个网站中3.多样化的数据4.用户多样化的数据搜索需求5.用户对搜索数据的实时性要求不是非常强6.用户对这些数据有整合使用的需求，并且这种需求量很大7.能够很好的对整合来的数据进行处理，能够完整的满足用户的这种需求，提供完整的信息检索体验
垂直搜索引擎存在的土壤：1.网页搜索引擎无法对某类数据进行深度加工，提供更多的细化的服务2.网页的数据实在是太多样化了（数据种类、数据类型等），不利于满足用户细分的服务3.用户有对互联网数据进行深度采集，数据的深度加工提供更细化的服务的需求，这种需求量非常巨大4.用户对某类信息的实时性的要求比较高5.针对某类信息提供更简洁、更快速，更可依赖性更强的服务6.行业性优化
垂直搜索存在的必备条件：1.海量的数据，所选择的垂直搜索的数据必须是海量的数据，数据量和增长速度、增长量都比较大。符合搜索引擎的基本条件2.分散的数据，这种数据必须要分散在很多个不同网站。不能是仅存在于几个网站。如果仅存在于几个网站不如做元搜索了（如果信息集中在几个网站，用户可以直接去使用）3.用户对这些数据的实时性有一定要求，但是又不能是对实时性要求极高（显然，春运期间的二手火车票信息就不适合做垂直搜索，因为等采集处理完毕，那票说不定已经卖掉了。拍卖的价格信息不适合做垂直搜索，有可能还没有采集处理完毕，价格已经变化了。）4.用户对这类数据的需求量是很大的，而且需要长期使用。（搜索是需要学习、长期使用才能很好的驾驭的一种应用）5.技术上能够很好的完成信息的整合、深度加工，并且加工后能够完整的满足用户对这类数据的搜索需求，提供完整的应用体验。6.这种信息的深度采集、深度加工是网页搜索引擎完全不可以替代的。
垂直搜索选型的步骤：1.选定适合您的，您熟悉的，有一定的资源背景的几个垂直搜索的被选方案。2.查看google或百度（其它搜索引擎不行）检索关键词数据。最好能搞到连续一段时间的全部词汇（按照检索频率排序），当然这几乎不可能，进行详细的分析、统计、挖掘。搞不到只要看风云榜和百度指数了，这估计就有很大偏差了。对这些用户需求数据库进行深度分析找出用户到底要什么、互联网上缺什么。（第1步和第2步交替进行）3.分析相关行业的网站，评估用户需求、数据情况、横向竞争、纵向竞争、潜在竞争情况和可能遇到的其它问题。4.如何满足用户的需求？如何保持产品和门户网站、搜索门户等的差异化和挖掘出用户潜在的最大的需求？5.评估技术上的可行性，能否实现完整用户体验。6.如何保证产品的领先性（资源、效果、市场、技术、销售……）7.产品的市场推广方式(这点非常非常重要，如何在竞争对手反应过来之前低成本的快速抵达有效用户群是成败的关键)8.盈利模式；收入模型、成本模型第一步完成到什么程度，达到什么目标。需要多少成本第二步完成到什么程度，是否可以收支平衡或者获得投资…………9.产品的不足和先天的缺陷如何克服弥补。产品的生命周期的每一步可能出现的紧急问题如何应对。10.不要认为自己很聪明，这世界上聪明人太多了，你能想到的肯定有n个人已经想到了。 关键在于您能不能充分利用自己的资源，做好前期的调查后专注的执行。11.务必要找百度和google这类搜索引擎不愿意花大功夫去做（市场暂时不够大）、或者不可能能做的应用（受制约、有更重要的事情要做），不要把你的模式和意图暴露得太早，这个市场的竞争实在是太激烈了，中国人也都太聪明了。 务必要找和门户网站、网页搜索引擎有很大差异化，并且用户有持续的很大的需求的。理由很简单：搜索是需要持续使用才能熟练的一种产品、从门户和网页搜索引擎到您的垂直引擎的门槛很高（比多点击10次的门槛还高很多）。

网络蜘蛛现在开源的已经有好几个了，Larbin，Nutch，Heritrix都各有用户之地，要做一个自己的爬虫要解决好多个问题，比如调度算法、更新策略、分布式存储等，我们来一一看一下。
一个爬虫要做的事主要有以下这些

从一个网页入口，分析链接，一层一层的遍历，或者从一组网页入口，或者从一个rss源列表开始爬rss；
获取每个页面的源码保存在磁盘或者数据库里；
遍历抓下来的网页进行处理，比如提取正文，消重等；
根据用途把处理后的文本进行索引、分类、聚类等操作。

以上是个人理解哦，呵呵。这些过程中，大约有如下问题
如何获取网页源或者RSS源？如
果是一般的爬虫的话，就是给几个入口页面，然后顺着超链接以遍历图的算法一个页面一个页面的爬，这种情况网页源很少，可以选择从hao123等网址大全的
网站为入口开始爬。如果做垂直搜索的话就人工去收集一些这个行业的网站，形成一个列表，从这个列表开始爬。如果是爬RSS的话，需要先收集RSS源，现在
大的门户的新闻频道和主流的博客系统都有rss的功能，可以先爬一遍网站，找出rss的链接，要获取每个链接的内容，分析是否是rss格式，如果是就把这
个链接保存到rss源数据库里，以后就专门爬这个rss源的rss。还有一种就是人工来整理，一般blog的rss都是有规律的，主域名跟一个用户名后面
再跟上一个rss的固定页面，比如http://www.abc.com/user1/rss.xml，这样就弄一个用户字典，拼接rss地址，然后用程
序去探测是否有这个页面来整理出每个网站的rss源。整理出rss源后再人工设置rss源的权重及刷新时间间隔等。
如果源页面很多，如何用多线程去有效的调度处理，而不会互相等待或者重复处理？如
果现在有500万个页面要去爬，肯定要用多线程或者分布式多进程去处理了。可以把页面进行水平分割，每个线程处理一段儿，这样每个线程之间不需要同步，各
自处理各自的就行了。比如给这500W个页面分配一个自增ID,2个线程的话就让第一个线程去爬1，3，5的网页，第二个线程去爬2，4，6的网页，这样
做多个线程间基本上能均衡，而且不会相互等待，而且不会重复处理，也不会拉掉网页。每个线程一次取出1w个页面，并记录最高的源页面ID号，处理完这一批
后再从数据库里提取大于这个源页面ID号的下1W个页面，直到抓取完本线程要处理的所有页面。1w这个值根据机器的内存可做适当的调整。为了防止抓了半截
儿死机，所以要支持断点续抓，要为每个线程的处理进度保存状态，每取一批网页都要记录本线程最大的网页ID，记录到数据库里，进程重启后可以读取这个
ID，接着抓后面的页面。
如何尽量的利用CPU，尽量的不让线程处于等待、休眠、阻塞等空闲状态？而且要尽量用少的线程以减少上下文切换。爬
虫有两个地方需要IO操作，抓网页的时候需要通过网卡访问网络，抓到网页后要把内容写到磁盘或者数据库里。所以这两个部分要用异步IO操作，这样可以不用
线程阻塞在那里等待网页抓过来或者写完磁盘文件，网卡和硬盘都支持内存直接读取，大量的IO操作会在硬件驱动的队列里排队，而不消耗任何CPU。.net
的异步操作使用了线程池，不用自己频繁的创建和销毁线程，减少了开销，所以线程模型不用考虑，IO模型也不用考虑，.net的异步IO操作直接使用了完成
端口，很高效了，内存模型也不需要考虑，整个抓取过程各线程不需要访问共享资源，除了数据库里的源页面，各管各的，而且也是每个线程分段处理，可以实现无
锁编程。
如何不采集重复的网页？去重可以使用king总监的布隆过滤器，
每个线程使用一个bitarray，里面保存本批源页面上次抓取的页面的哈希值情况，抓取下来的源页面分析链接后，去这个bitarray里判断以前有没
有抓过这个页面，没有的话就抓下来，抓过的话就不管了。假设一个源页面有30个链接把，一批10W个源页面，300w个链接的bitarray应该也不会
占太大内存。所以有个五六个线程同时处理也是没问题的。
抓下来的页面更快的保存？保存到分布式文件系统还是保存在数据库里？如
果保存到磁盘，可以每个域名创建一个文件夹，凡是这个网站的页面都放到这个文件夹下，只要文件名不一样，就不会出现冲突。如果把页面保存到磁盘，数据库有
自己的一套锁管理机制，直接用bulk
copy放数据库就行了。一般频繁的写磁盘可能会引起CPU过高，而频繁的写数据库CPU还好一些。而且sqlserver2008支持filestream类型的字段，在保存大文本字段的时候有很好的性能，并且还能使用数据库的API来访问。所以我觉得如果没有GFS那样高效成熟的分布式文件系统的话还不如存sqlserver里面呢。
如何有效的根据网页的更新频率来调整爬虫的采集时间间隔？做爬虫要了解一些HTTP协议，如果要抓的网页支持Last-Modified或者ETag头，我们可以先发个head请求来试探这个页面有没有变化来决定是否要重新抓取，但是好多网站根本就不支持这个东西，所以让爬虫也很费劲，让自己的网站也会损失更多的性能。这样我们就要自己去标注每个源页面的更新时间间隔及权重，再根据这两个值去用一定的算法制定蜘蛛的更新策略。
采集下来的数据做什么用？可以抓取一个行业的网站，在本地进行分词和索引，做成垂直搜索引擎。可以用一定的训练算法对抓取下来的页面进行自动分类，做成新闻门户。也可以用死小风行的文本相似度算法处理后进行文本聚类处理。
如何不影响对方网站的性能？现在好多网站都被爬虫爬怕了，因为有些蜘蛛弄住一个网站可劲儿的爬，爬的人家网站的正常用户都无法访问了。所以好多站长想了好多办法来对付爬虫，所以我们写爬虫也要遵循机器人协议，控制单位时间内对一个网站的访问量。

碰到的问题列表：

内容的编码问题是一个问题，需要很多功夫进行调整
HTTP访问协议的问题，譬如路径重定向，以及各种错误
robots协议支持的问题
垃圾信息处理的问题（譬如feedburner出来的RSS可能包含广告内容）
运行效率问题（用Java+JDBC在并发不多的情况下已经出现OutOfMemoryError了）
一些知名blog的历史文章尚未反向收集
在日期时间格式标准方面，有很多非标准的格式需要处理
未能很好地记录不同blog之间的引用关系
如何有效地控制RSS feed源头是一个问题
更新频率是写死的一天，没有频率计算调度
尚未提供添加新的RSS feed的界面接口
尚未实现全文检索，也没有对tag支持