题 目 基于Scrapy的分布式爬虫系统的设计与实现外文翻译资料
2022-12-18 15:40:26
英语原文共 6 页,剩余内容已隐藏,支付完成后下载完整资料
外文翻译
题 目 基于Scrapy的分布式爬虫系统的设计与实现
作 者 Yuhao Fan
发表时间_____2017年_______
二O 一九 年 四 月 二 十 六 日
摘要:目前, 国内外一些大型搜索引擎只为用户提供非定制搜索服务, 单机网络爬虫无法完成艰巨的任务。本文通过对原始 Scrapy 框架的研究, 结合克拉皮和 Redis, 对原始 Scrapy 框架进行了改进, 设计并实现了基于 Web 信息的分布式爬虫系统, 并对 Bloom 进行了改进。将滤波算法应用于双滤波模块, 以减少内存消耗。从 douban 捕获的电影信息存储在 MongoDB 中, 以便对数据进行处理和分析。结果表明, 基于 Scrapy 框架的分布式爬虫系统比单机网络爬虫系统更高效、更稳定。
- 介绍
随着网络的快速发展,万维网已成为一个庞大的载体信息量,如何有效地提取和使用这些信息已经成为一个巨大的问题挑战。 传统的通用搜索引擎成为用户访问万维网门户和指南,但国内外一些大型搜索引擎只为用户提供非自定义搜索服务,单机网络爬虫无法承担艰巨的任务。 所以分布式网络爬虫,定制灵活,信息获取速度快,数据量大规模已经形成。
2. Scrapy架构概述
Scrapy使用了Twisted作为框架,Twisted有些特殊的地方是它是事件驱动的,并且比较适合异步的代码。对于会阻塞线程的操作包含访问文件、数据库或者Web、产生新的进程并需要处理新进程的输出(如运行shell命令)、执行系统层次操作的代码(如等待系统队列),Twisted提供了允许执行上面的操作但不会阻塞代码执行的方法。Twisted是一个流行的事件驱动的Python网络框架。它由五个部分。 如图1所示。Scrapy Engine:引擎负责控制所有组件之间的数据流系统,以及在发生某些操作时触发事件。调度程序:调度程序接收来自引擎的请求并将它们排入队列以供给它们引擎请求它们之后(也发动机)。下载器:下载器负责获取网页并将其提供给引擎反过来,它们将它们喂给蜘蛛。蜘蛛:蜘蛛是由Scrapy用户编写的自定义类,用于解析响应和提取项目(刮掉的物品)或其他要求。项目管道:项目管道负责处理项目由蜘蛛提取(或刮除)。 典型的任务包括清理,验证和持久性(如将项目存储在数据库中)。
图1 Scrapy 建筑
3. 分布式Web爬虫系统的设计与实现
对于分布式网络爬虫,目前,它是在网络爬虫上相互通信的导入,有两种解决方案,一种是Master-Slave模式,另一种是Peer to Peer模式。主从体系结构广泛用于控制节点负责的分布式场景中与所有独立网络爬虫进行通信。奴隶只需要从中获取请求主。下载请求后,提取的新请求将返回给主服务器。应用Redis数据库实现分布式抓取,基本思想是Scrapy爬虫获取的到的detail_request的urls都放到Redis Queue中,所有爬虫也都从指定的Redis Queue中获取requests,Scrapy-Redis组件中默认使用SpiderPriorityQueue来确定url的先后次序,这是由sorted set实现的一种非FIFO、LIFO方式。
图2主-从模式
图2主从模式在本文中,我们使用主/从模式来实现分布式Web爬行系统结合scrapy和redis数据库。新调度程序存储和调度所获取的通过redis请求并存储用于抓取的项目以供后续处理。
3.1 Redis介绍
(1)什么是redis?
Redis是Salvatore Sanfilippo编写的键值存储系统。Redis是当前比较热门的NOSQL系统之一,它是一个开源的使用ANSI c语言编写的key-value存储系统(区别于MySQL的二维表格的形式存储。)。和Memcache类似,但很大程度补偿了Memcache的不足。和Memcache一样,Redis数据都是缓存在计算机内存中,不同的是,Memcache只能将数据缓存到内存中,无法自动定期写入硬盘,这就表示,一断电或重启,内存清空,数据丢失。所以Memcache的应用场景适用于缓存无需持久化的数据。而Redis不同的是它会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件,实现数据的持久化Redis提供丰富的数据结构,包括列表,集合,有序集和散列,以及丰富的操作方法这些数据结构。
(2)redis的优点
高性能。 Redis可以读写超过105秒。速度快,因为数据存在内存中,类似于HashMap,HashMap的优势就是查找和操作的时间复杂度都是O(1);支持丰富数据类型,支持string,list,set,sorted set,hash;支持事务,操作都是原子性,所谓的原子性就是对数据的更改要么全部执行,要么全部不执行;丰富的特性:可用于缓存,消息,按key设置过期时间,过期后将会自动删除;原子性。 Redis所有操作都以“原子”为基本单位,Redis也支持“原子”。
3.2 Scrapy-Redis的基本组成
(1)连接
配置设置,连接redis数据库,dupefilter模块和调度模块调用,相关Redis访问操作以使用此模块。
(2)dupefilter
使用redis设置数据类型将请求存储到重新处理,调度程序不使用模块的dupefilter键用于调度请求,但是通过定义队列。如果它不是重复请求,那么将被存储在队列中并在弹出时进行调度。
(3)排队
目前有三种类型的队列调度:FIFO SpiderQueue,SpiderPriorityQueue和LIFO SpiderStack,默认使用SpiderPriorityQueue。
(4)piplines
Redis用于实现分布式数据处理模块。与Scrapy的Pipline不同,它接收项目来自多个爬虫的数据,并根据程序设置处理数据。
(5)调度程序
Scheduler使用Redis实现分布式数据分发模块。而不是scrapy自带调度程序组件函数,由爬网程序处理后,由调度程序访问所有URL统一管理。所有抓取工具都将从调度程序中统一获取目标URL。实现一个统一爬虫管理,避免重复爬行。 Scrapy-Redis的基本组成如图3所示。
图 3 扩展的Scrapy框架
4. Dupefilter模块优化
使用redis自己的数据类型Set来存储捕获的URL队列可以避免重复爬行。但随着URL数量的增加,集合越来越大,而redis则越来越大基于内存的数据库,导致内存非常高。 Bloom过滤器只使用一系列位来保存数据,你可以检测一个元素是否已经存在于集合中,所以这个算法有一个非常好的空间利用率。
4.1 Bloom Filter算法介绍
Bloom filter是一种节省空间的随机数据结构,它使用位数组来表示集合并判断一个元素是否属于该集合。Bloom filter 算法可用来查询某一数据是否在某一数据集合中。其长处是查询效率高、可节省空间。但其缺点是会存在一定的错误。因此Bloom filter 算法仅仅能应用于那些同意有一定错误的场合。可使用Bloom filter 算法的场合包含字典软件、分布式缓存、P2P网络和资源路由等等。Bloom Filter的效率是一定的价格:在判断元素是否属于集合时,元素可能不属于该集合这个集合误认为这个集合(误报)。因此,Bloom Filter不适合那些人“零错误”应用程序。在容忍低错误率的应用程序中,Bloom Filter提供了一个如图4所示,存储空间显着节省,错误最小。
图4 Bloom过滤器
4.2基于Bloom Filter算法流程
(1)初始化v的数组,长度为M,初始值为0。
(2)从web散列的url需要由k个散列函数处理。
(3)对于生成的k个随机数,搜索算法用于找到比特变量v。
(4)如果位向量v对应位中的k个随机位是1,那么url已经在收集,并跳回到第2步; 否则继续。
(5)将URL添加到集合中并跳回到步骤2。
5.实验结果分析
5.1 实验结果
根据豆瓣电影的原始网址,电影的基本信息被捕获分布式爬虫系统并存储在MongoDB中。 爬行的结果如图5所示。
图5 电影信息
5.2 结果分析
部署整个系统:1台服务器安装了redis和MongoDB数据库作为主服务器爬虫的节点; 安装了MongoDB数据库的1台服务器作为slave; 1个单服务器已安装MongoDB数据库。通过分析表1中的数据,我们可以看到每个节点每小时爬行一次页数1400左右。 由于网络延迟,I/O延迟等,每小时抓取的页数略有增加低于理论最大值1800.此外,两个爬行动物节点的负载是平衡的。同时结果还表明,扩展的Scrapy框架大大提高了爬行速度改进。
表1实验结果
小时 |
1小时 |
2小时 |
3小时 |
4小时 |
(单节点)页面 |
1535 |
3519 |
4589 |
6298 |
电影 |
1417 |
3412 |
4441 |
6100 |
(双节点)页面 |
3578 |
6912 |
8971 |
12568 |
电影 |
3416 |
6835 |
8701 |
11892 |
根据表2中的数据,我们可以通过Matlab得到图的图形。每个的斜率line表示爬网程序的爬网效率。 从图6中可以看出效率用于爬行的节点远远低于同时两个节点的爬行节点。 总之,分布式爬虫爬行效率远高于单爬虫。
图6速度对比图
6.结束语
在本文中,我们深入探讨了开源网络爬虫Scrapy的探索和扩展框架设计和实现分布式Web爬虫系统,但仍有很多例如,系统存在缺陷,所有URL都存储在redis数据库中,一旦存在于主节点中失败,整个系统将无法继续工作,系统的稳健性需要改进。
参考文献
[1] Brin S, Page L. Peprint of: The anatomy of a large-scale hypertextual web search engine [J].
Computer Networks,2012,56 (18):3825-3833.
[2] Lawrence S, Giles C L. Accessibility of information on web [J]. Nature,1999.
[3] Iijima S. Helical Microtubes of Graphite Carbon[J]. Nature,1991354 (6348):56—58.
[4] Boldi P, Codenotti B, Santini M, et al. UbiCrawler: a scalable fully distributed Web crawler [J].
Software Practice amp; Experience,2004,34 (8):711-726.
[5] Pinkerton B, Lazowska E, Zahorjan J. Webcralwer: Finding What People Want [J]. 2001.
剩余内容已隐藏,支付完成后下载完整资料
资料编号:[20187],资料为PDF文档或Word文档,PDF文档可免费转换为Word