近几年,Python名声大噪,爬虫框架Scrapy更是为大众所乐道。现在就让我们拿相对成熟的Java分布式爬虫框架和Scrapy作对比,看看Scrapy距离实际使用,还有哪些需要补充的地方。
Java分布式爬虫框架
逻辑架构
模块说明
模块 | 职能 |
---|---|
信源管理层 | 管理网站的采集配置。采集配置,包括抓取链接的组成方式、结构化数据的抽取规则、衍生任务的生成逻辑等。若网站的采集配置发生变更,通知采集层;并提供相应的接口,返回变更的信息 |
采集管理层 | 管理网站的采集作业。将待采集的一次性作业或周期性作业推送到采集层;实时展示作业的执行进度,并将执行完的作业的数据由采集层同步,供用户下载 |
资源管理层 | 管理采集时所需的资源。资源,包括爬虫、网站Cookie等。若资源发生变更,通知采集层;并提供相应的接口,返回变更的信息 |
采集层作业类API | 用于管理作业的一整套流程。从获取采集场景状态开始,到推送作业,到监控作业进度,再到获取作业结果。若作业执行中,出现异常,可直接取消作业。作业完成后,可查看作业的采集概况;也可通过采集的具体数据,查看采集详情 |
采集层Captain | 规则或场景发生变更时,由Captain将变更的规则或场景新增/更新至采集层数据库,并加载至Captain内存且发布变更通知。资源发生变更时,由Captain将变更的资源同步至采集层数据库,并加载至Captain内存。Captain,除协调任务、爬虫资源和采集资源的配额外,还需监控作业的采集情况,支持断点续作 |
采集层Soldier | 接收Captain传入的规则或场景变更的通知,将变更的内容由采集层数据库同步至内存。接收Captain传入的任务,对任务进行抓取、抽取、衍生、存储、后处理等一系列操作,并将结果保存至指定位置 |
交互上,采用基于Redis的订阅发布来通知变更、采用Java Web来返回变更情况、采用基于Netty的网络通讯来双向连接Captain和Soldier。
存储上,MySQL存储采集配置,Redis存储原生任务和衍生任务,ES存储采集的数据。
Python爬虫框架Scrapy
逻辑架构
模块说明
模块 | 职能 |
---|---|
Scrapy Engine(引擎) | 负责Spider、ItemPipeline、Downloader、Scheduler中间的通讯,信号、数据传递等 |
Scheduler(调度器) | 它负责接受引擎发送过来的Request请求,并按照一定的方式进行整理排列,入队,当引擎需要时,交还给引擎 |
Downloader(下载器) | 负责下载Scrapy Engine(引擎)发送的所有Requests请求,并将其获取到的Responses交还给Scrapy Engine(引擎),由引擎交给Spider来处理 |
Spider(爬虫) | 它负责处理所有Responses,从中分析提取数据,获取Item字段需要的数据,并将需要跟进的URL提交给引擎,再次进入Scheduler(调度器) |
Item Pipeline(管道) | 它负责处理Spider中获取到的Item,并进行进行后期处理(详细分析、过滤、存储等)的地方 |
Downloader Middlewares(下载中间件) | 可以当作是一个可以自定义扩展下载功能的组件 |
Spider Middlewares(Spider中间件) | 可以理解为是一个可以自定扩展和操作引擎和Spider中间通信的功能组件(比如进入Spider的Responses和从Spider出去的Requests) |
Java分布式爬虫框架 VS Python爬虫框架Scrapy
背景知识
Netty和Scrapy的核心理念是共通的。Netty是一个高性能、异步事件驱动的NIO框架;Scrapy是一套基于Twisted的异步处理框架,而Twisted是一个事件驱动型的网络引擎。
结论
列举的Java分布式爬虫框架和Scrapy虽然核心理念共通,但采集中抽象的层面不同。Java分布式爬虫框架以采集任务为原子单位;而Scrapy是对采集任务的执行流程(抓、抽、存、衍等)为原子单位,在Java分布式爬虫框架中充当着采集层Soldier的角色。
所以,要想将Scrapy投入实际使用,还需补全Java分布式爬虫框架中除了采集层Soldier外的其它模块。