分布式网络爬虫构建参考

本文转自csdn

设计和实现高水平分布式网络爬虫

摘要：纵 观网络搜索引擎和其他特殊的搜索工具一样，依赖网络蜘蛛区获得大规模的网页进行索引和分析。这样的网络爬虫会与数以百万计的主机在一定时期或者一周内进行 交互。因此随之产生的健壮性、灵活性和可管理性等问题。另外，I/O性能、网络资源和操作系统的限制也会在设计高性能爬虫的时候进行合理的考虑。

    本 论文描述和设计了分布式网络爬虫运行在工作站上。网络爬虫的能够在一秒钟之内爬取几百页网页，并防止崩溃或者其他不可预测的事情。并且能够满足大部分的网 络爬虫的应用。我们设计了这个系统的软件架构，讨论其性能瓶颈，并且用足够的技术去实现其高性能。我们将实验结果附加在后面。

1 简介

   万 维网于1993年的几千个网页，增长到了现在的20亿网页。因此爆炸性的规模的增长，WEB搜索开始成为挖掘信息最为重要的手段。这些搜索引擎靠网络爬虫 大规模的手机网页，通过超级链接遍历网页并在大容量的数据库中检索网页并稍微为用户执行高效的查询检索。很多人多年来一直在关注WEB搜索技术，包括爬取 策略、存储、索引和排序技术，还有重要的量化工作如WEB结构分析和WEB图。

   因 此高性能的爬虫系统需要顺序的下载成千上万的WEB网页。实际上搜索引擎之间主要的区别在于大小和她们使用的数据库，附加上质量和排序函数的响应时间。尽 管最大的搜索引擎，例如google或者altavista，目前仅仅能够覆盖一部分WEB网页，并且大部分她们的数据是几个月前已经过时的。（我们注意 到，爬取速度并非是唯一的搜索引擎的瓶颈，查询的规模和响应时间也是主要的问题）。

  大 规模搜索引擎的网络爬虫有两个问题。首先，要有良好的爬取策略，这个策略就是决定什么样的网页首先爬取。其次，她能够拥有优异的体系结构趋在每秒钟之内下 载大规模的网页，并且能够防止崩溃、可管理、对资源的考虑和WEB服务器。这里第一个问题引发了学术的研究兴趣，包括首先爬取重要的网页，爬取特殊的话题 和特殊类型的网页，重新爬取被刷新的网页，或者一定时间段内的爬虫的排序。

  相 反的，第二个问题的工作确实很少的。显然的，所有的搜索引擎系统都有高度优化的爬虫，尽管这些系统的细节通常是保密的。唯一的公布细节的就是 Mercator，这个是被AltaVista使用的。（另外谷歌的第一版的设计细节也公布了，和Internet Archive的系统）这些很容易构 建一个缓慢的爬虫下载少量的网页。构建一个高性能的系统能够每秒下载数百万计的网页，在设计上提出了巨大的挑战。

  大 部分近期的网络爬虫策略并不关注这些性能问题，相反，尽量减少网页被下载的必须网页数，或者最大化获取网页的利益。（一个例外是考虑系统的性能关注于爬虫 的，在于构建通用的数据库系统，尽管这种体系的效率仍然低于大规模网络爬虫）。以上应用的考虑均是非常有限的贷款下。然而，在大规模的搜索引擎，我们需要 合并的良好的爬取策略和优化的体系设计。

  在 这篇论文中，我们描述和设计实现了一个基于网络工作站的优化系统。爬取策略和我们的工作是正交的。我们描述这个系统使用典型的简单的宽度优先搜索，尽管系 统可以使用其他的办法。我们主要的兴趣在于I/0和网络效率方面，并且在分布式的爬取的可扩展性上包括爬取速度和参与的节点。我们使用爬虫去获取大规模的 数据集，去提供给WEB搜索技术例如索引、查询过程和链接分析。我们注意到高性能爬虫并没有被学术研究者重视，尽管有些群体做了一系列的实验。这里依旧有 许多有趣的问题在实际的海量数据集应该受到学术界的更加重视。

1.1 爬行程序应用

每个爬虫爬取网页的方法都是一道亮丽的风景线。我们现在描述一些爬虫典型的爬去策略：

  宽度优先爬取：为了构建主要的搜索引擎或者大规模的网络存档栈，高性能爬虫的爬取开始于小的网页集合，并且遍历其他超级链接，采用宽度优先的方式。实际上，网页并不是严格按照宽度优先遍历的，因为会使用各种各样的爬取策略，比如对于一个WEB站点进行修剪，或者优先爬取更重要的网页。

  重 新更新爬取：最初爬取的网页，可能会被周期性的重新爬取并检查是否有更新。在这个简单的例子里，这里可以被另外一个宽度优先搜索的爬虫所实现，或者简单的 请求所有的收藏库里的URL。然而，各种各样的启发式算法可以被应用去爬取更为重要的网页、站点或者域。好的重新爬取策略对于有线带宽的爬虫来说至关重 要，有人对此一直进行重点的研究。

  聚集爬取：更 多的特定的爬虫会使用一定的爬取策略集中爬行特定的网页。例如特殊的MP3/、语言、图像 ，或者计算机科技文章 等等 的网页。相比于启发式规则，更多 的方法被使用去分析链接结构和机器学习技术。聚焦爬虫能够发现很多有兴趣的网页而不必要浪费很大的带宽。因此，大部分前边的爬虫并不是高性能的爬虫，尽管 相对于宽度搜索来说，聚焦爬虫可以支持大规模特定的存取。

随机爬取和抽样：有几种技术来研究随即的爬取策略在WEB图上去抽取盒评价搜索引擎的大小和质量。

爬取隐藏网页：很 多的需要被访问的数据是存放在后台数据库中，仅仅能够被post或者填充表格的方法来被访问。近来，人们开始关注自动的访问这些数据。所以叫做“隐藏信 息”。很多方法开始被提出来。上述爬虫经过扩展都可以做出这种系统来。我们注意，然而，还有很多其他的挑战区访问隐藏的网页。搞笑的front end也 许不是问题。

1.2基本的爬虫架构

  上 面说了那么多，我们可以设计一个灵活的系统来满足不同的应用需求和策略的工作任务。注意这里和上述所言有很大的不用。例如，一个宽度优先的爬虫会追踪一个 已经被爬取了的网页；这里会用到一个url 数据段主流在磁盘上。基于链接分析的爬虫，另一方面，可能会运用额外的数据结构去实现已经被爬取的WEB的图 结构。并且会用一个分类器去判断网页的相关性，但是这个结构可能不会很大。另一方面，在各种情况下，会有一定数量的通用任务需要被完成。这些就 是：robot exclusion,爬取速度控制，DNS轮训。

  简 单的来说，我们将我们的爬虫设计分为两个主要部分，分别为：应用爬取和系统爬取。应用爬取就是考虑到已经爬取的网页来决定什么样的网页被请求，并且启发一 个URL流。系统爬取就是下载网页并支持应用爬取来做分析和存储。爬取系统式在robot协议、速度控制和DNS轮训下受到控制的。应用的实现爬行策略例 如“宽度优先”或者“主题”，因此，去实现主体爬虫而不是宽度爬虫，我们需要使用相同的爬虫系统但是应用配置则不同了。

图 1 基本的爬虫架构

 

  首 先，实现爬虫系统可能是繁琐的。但是在实现高性能的案例上则是错误的，因为每秒会有成千上万的网页会被下载。实际上，我们的爬虫系统可以进行克隆来实现更 高的性能。爬虫系统的应用爬取和系统爬取部分又可以分别克隆。集中不同的应用可以提交给同样的爬虫系统，展示出设计的另外一种动机。更多的细节在 图 2. 我们注意到对于应用的分割，并不是被其他系统所采用的，并不鲜明特殊的任务。本论文主要集中于宽度优先爬虫作为我们的应用爬取。

1.2 爬虫的需求

  现在我们开始讨论一个良好的爬虫的必要条件，并且一些必要的实现方法。我们将会在以下章节中去讲他。

   灵活性：这个系统将会满足各种配置去完成特定的或者全能的任务，并且配置的修改必须最小。

   低消耗和高性能：系统必须能够每秒至少下载几百张网页，并且拥有低的硬件代价。注意磁盘访问的效率能够是至关重要的对于主要的数据结构来说，例如URL可见性结构和爬取边界，这些事越来越占用主存。当下载几百万网页后就会出现这些问题。

   健壮性：这 里有几个方面。首先，机器会同数百万台服务器进行连接，它必须能够容忍错误的HTML，各种奇怪的服务器的行为和配置，和其他奇形怪状的问题。我们的目标 是进行小心的异常处理，如果必要的话忽略掉网页和、甚至奇怪行为的服务器，因为其他的应用我们可以下载任何网页集合。其次，既然一个爬虫，既然一个爬虫可 能爬行数个星期或者数月，系统需要容忍失败和崩溃或者网路干扰，丢失数据。因此，系统的状态需要保存在磁盘上。我们得出结论并不需要严格ACID性质。相 反的，我们决定周期性的同步所有的磁盘，或者重新爬取有限数量的网页经历一个崩溃后。

  Etiquette和速度控制：robot.txt是 一个非常重要的标准型惯例。她提供给我们什么样的URL可以爬取，或者监视整个爬虫。另外，我们需要去控制访问的速度以几种方式。我们必须去避开单个服务 器造成过于巨大的负载，我们是通过每30秒以后才在访问这个站点的方式去避免过度负载。控制速度在域的级别上也是适宜的，并不能够重载过多的小域名。原因 后面在讲。最后，自从我们在一个大学的环境里，我们连接共享很多其他的用户，我们需要控制总体的下载速率在下载高峰期，在以后使用告诉下载在避开高峰期的 时候，限制是被大学的路由器所局限的。

  可扩展性和可配置性：一 个适宜的接口是必须的，这个用来监视爬虫的行为。包括速度、主机和网页的统计，和主要数据集的大小等。管理者能够去调整速度，关闭系统，增加或者删除配 置，强制检查点，或者增加主机或者域名去黑白名单 等等。经过崩溃或者关闭，系统软件行为可能依据不同的机器而改变。实际上，以下略去不译。

1.4 论文内容

  本 论文设计和实现了一种分布式网络爬虫，她运行在网络工作站上面。爬虫的规模至少每秒数百万网页被下载，而且要避免系统的崩溃和其她的事件。并能够完成多样 性的任务。我们提出系统的软件架构，描述性能的瓶颈，描述高效的技术实现高性能。我们也要提前试验报告爬虫的运行结果。

  论文是如下组织的。第二章描述我们系统的架构和主要构成。第三部分描述数据结构和算法技术，而且是以更详细的方法论述的。第四部分描述了实验结果，第五部分进行对比分析，第六部分提出一些结论性的评价。

2 系统架构

  现在我们开始更为详细的介绍我们的分布式爬虫。如同以前提出的一样，我们将系统分为两个主要的部分：crawling system and crawling application.爬 取系统本身也是由几个不同的模块所组成的，特别是爬行管理，一个或者更多的下载器，一个或者更多的DNS解析器。所有的这些部件，加上爬行应用系统，能够 运行在不同的机器或者不同的操作系统上，并且能够克隆增加系统性能。爬行管理系统负责检索URL输入流，并将其送到下载器和DNS，同时碱性robot规则的处理和爬行速度的控制。一个下载器就是高性能的异步HTTP客户机能够同时下载数百万的网页。当DNS优化DNS 桩（带来）给本地DNS服务器提供查询。

  一个小的有三个下载器的配置如图2所示，同时也表现了主要的系统的数据流的方向。这个配置是非常类似于我们曾经使用过的爬虫。图2可以同时使用3到5个工作站，能够实现每秒峰值250到400速率的网页每秒下载。我们更加详细的讨论在以后。

  我们系统的通信是使用两种方式：经过socket的小规模通信，和经由文件系统的大规模数据流。使用NFS文件系统使得设计特别的灵活并且可以重新设置系统的分区和磁盘。以下不译。

2.1 爬行管理

   爬 行管理是整个系统的中心部件，并且这个模块是首先开始启动的。随后，其他的部件开始启动并且在管理系统中注册。管理模块是唯一对于其他模块来说是可见的， 并且同时可以进行并行的操作，随后将会解释这些。当不同模块的应用进行交互的时候，管理模块需要接受应用模块的URL流，并且每一种请求都有其优先级，并 且指向一个拥有海量URL的文件，这是经由NFS文件系统来访问其他文件的。管理模块会对请求进行排队，最后下载响应的网页，尽管这些可以被缩水版的中央 数据结构来实现。总体上，管理模块的目标就是最大限度的下载网页，并且最大限度的排序其应用。重新排序请求能够减轻WEB服务器的负担。这种策略会 在 3.5中讲解。

  当下载URL的请求文件，管理查询DNS服务器区查询其IP地址，除非最近的地址已经存入高速缓存中。管理模块于是请求robots.txt在WEB服务器的根目录。除非这里已经有了一个文件的拷贝。这个部分最初是由设计成应用模块的独立的模块并且拥有较高的优先级。但是现在他加入到管理模块的进程中来，并且robot文件写入分离的目录，以便于被分析和管理。见图2.最后经过分析robots文件的结果提交给下载模块，确认有一定的下载间隔来做到优雅爬行的需要。

  管理模块也负责控制总体的下载速度，平衡下载器和DNS的负载，通过监视和调整DNS和下载速率。管理模块周期性的对数据结构作快照，如果崩溃以后，有限数量的网页可能需要重新爬行，管理模块的数据结构如 3.4 部分所说。

2.2 下载和DNS域名解析器

  下载器的设置，是用Python语言实现的，获取网页的文件通过不同服务器的1000条连接，并对这些数据进行poll轮训，数据被装入文件。自从下载器经常 要超过数百个网页每秒，大规模的网页写入磁盘操作。我们注意到网页写入这些数据文件是数据结构无关的。因此，非常重要的是那一条URL被下载或者未被下载，追踪这些是很重要的。管理器能够增加下载速度通过改变当前的连接。

2.3 应用爬虫

  本论文的爬虫是宽度优先爬行的，在我们的实例中的URLs主要是几百所美国大学的URL，他们被送进爬行管理器。应用部分开始分析下载网页的超级链接，并检查这些超链接是否曾经被访问过。如果没有被访问过，将这些URL批量送给管理器，每次要几百、千条。下载文件开始压缩和存储在仓库里。爬行应用使用的是红黑树。

   数据结构和性能方面稍后在3.2节讨论。我们注意到下面的两点：首先，因为每一个网页都包含大约平均8条超级链接，这些URL的存取将成为问题。其次，任何被解析的超链接可能几天后才被下载。因此，这里没有理由让管理器即时插入新的请求给动态的数据结构。

2.4 系统规模

  我 们的一个目标就是设计一个性能能够扩展的工作站上运行的爬虫并且使他们运行额外的设置。从图 2来说，我们简单的增加了下载器和DNS解析器来改进性能。 我们评价单独的管理器能够快速的满足8个下载器的管理要求，可能会要求2到3个DNS解析器。我们还要创建一个二级爬行管理，于是应用部分可以分裂为两个 管理部分。然而，第一个瓶颈是在应用爬虫中，我们要能够处理多大400个网页每一秒钟。这一目标是可以改变的通过更为优化的手段，最后可以划分应用为几个 机器。

 

  图 3展示了我们系统的可能的规模，使用两个爬行管理，一共有8个下载器和3个DNS域名解析器，并且还有4个应用部件。我们指出我们还没有测试系统的性能。可能被改进为20台机器且结果存放下载速率超过1500网页每一秒。

  分 裂宽度优先爬虫分为4个非常简单的部件，使用一些类似其他爬虫的技术。我们使用哈希函数分裂所有可能的URL为4个空间子集，每一个应用部分负责处理和请 求一个子集。告诉管理器不同的网页进行不同的应用，并且分别存储在不同的地方，爬取网页的类型的策略都是由应用决定的。如果在解析的时候，一个配置遇到的 超链接属于不同的子集，将其插入到适宜的子集里去（这是被哈希值所决定的）。每一个爬行管理可以分别使用两个应用部件，对于管理器，他们可能做完全不相干 的应用。确保每一台主机被映射为一个子集，这些能够避免robot爆炸和DNS的消耗。

3 实现细节和算法技术

  我们开始描述一些遇到的具体的问题和性能的瓶颈，连同一些数据结构和详细的技术。我们开始于应用和跟踪URL的线索贯穿始终。回忆起我们的宽度优先爬虫应用分析心来的下载的网页提取超链接。于是检查数据结构去查询哪一个超链接曾经被访问过。于是发送新的URL去被下载。

3.1 应用解析和网络性能

  解析的实现用的是正则表达式。注意到我们仅仅解析超链接，并不索引数据项，后者会大幅度降低系统的性能。分析URL可以交给其他应用进程或者扫描数据仓库来实现。并且这已经脱离了这篇论文的范畴。

  当开始分析的时候，NFS和网络性能考虑开始更为重要。我们经常要下载网页经由NFS存取到磁盘上去。或者存储管理拷贝他们去其他的数据仓库。因此每一个数据项开始经过网络来离开或者进入这台机器。我们的网络是由full-duplex switched快速以太网，每一网页13KB计算，大约600网页每秒会被读入出。

3.2 URL处理

  超级链接从网页文件中被提取后，经过标准化的规约，于是需要将其按照访问是否来进行快去存取。每秒分析300个网页要导致超过2000个URL需要被检索或者插入。每一个URL至少有平均长度在50字节。单纯的实现URL的数据结构很快会导致内存耗尽。

  有一些好的办法来解决这个问题：很多系统采用Bloom filter算法，尽管这可以大幅度减少内存的占用，但是这依然是很高的对于大型分布式爬虫来说。这样还是会逐渐耗尽内存，尽管可以划分为几个数据结构分布在几台机器上。更为大型的方法是使用磁盘主流结构，然而，如何避免分布式磁盘系统的访问和查询，也是一个挑战。

  我 们的目标是完全避免随即的磁盘访问，或者至少是线性的增加URL。为了达到这个目标，我们执行查询和插入操作使用离线操作或者空操作。因此，我们使用如下 的方法，使用更为著名的技术：我们最初保存URL在红黑树中，当数据结构增长到一定的数量的时候，我们将这些被整理的URLS写入到磁盘并且转入空模式。 我们使用红黑树驻留内存，并周期性的将内存主流数据写入磁盘。归并操作是使用一条单独的线程来实现的。于是应用能够继续分析新的文件，并且下一步归并会在 一个小时候开始。