
本教程旨在解决scrapy爬虫在处理页面内部多层链接和分页时常见的重复数据、数据丢失及不完整问题。通过深入分析`dont_filter`参数滥用、分页逻辑缺陷以及不当的item提交时机,提供一套优化方案,包括启用scrapy内置去重、精确控制分页请求以及确保数据完整性后提交item,从而提高数据抓取的准确性和效率。
Scrapy深度爬取挑战:重复与不完整数据
在使用Scrapy进行网站深度爬取时,尤其当页面包含多层嵌套的内部链接(例如,一个事件页面链接到受害者、恶意软件和威胁源的详细页面),并且网站还采用分页机制时,开发者常常会遇到以下问题:
- 数据重复: 爬取结果中出现大量重复的记录。
- 数据丢失或跳过: 部分期望抓取的数据(如特定类型的内部链接内容)未能被正确抓取或被意外跳过。
- 数据不完整: 最终导出的数据项缺少部分字段,因为数据在不同回调函数中被分步收集,但未能在正确时机完全合并。
这些问题不仅影响数据质量,也浪费了爬取资源,降低了效率。
问题根源深度剖析
上述问题的出现,往往源于对Scrapy框架机制的误解或不当使用。以下是几个常见且关键的根源:
1. dont_filter=True的滥用
Scrapy内置了一个强大的去重过滤器,它通过记录已访问的请求URL来避免重复爬取。当你在scrapy.Request或response.follow中设置dont_filter=True时,你实际上禁用了这一重要的去重机制。这会导致:
- 重复请求: 即使某个URL之前已被访问过,Scrapy也会再次发送请求。
- 重复数据: 相同的页面内容可能被多次解析并生成重复的Item。
- 性能下降: 无谓的重复请求增加了服务器负载和爬虫自身的资源消耗。
在处理内部链接时,如果多个路径指向同一个详情页,dont_filter=True会确保这些详情页被重复访问,从而导致数据重复。
2. 不合理的分页处理机制
原始代码中处理分页的逻辑存在效率和正确性问题。它在每次parse方法运行时,都重新获取页面上的所有分页链接,并为它们全部发送请求。这种做法会导致:
- 无限循环或大量重复请求: 每次进入parse方法,都会重新请求所有已知的分页,包括当前页和之前已处理的页。
- 内存消耗: 维护和处理大量的重复请求会占用不必要的内存。
- 逻辑混乱: 难以追踪哪些页面已被处理,哪些是新页面。
正确的分页处理通常是只请求“下一页”或“未处理的页”。
3. Item提交时机不当
在Scrapy中,yield item操作意味着将一个完整的Item发送到Item Pipeline进行处理。如果在一个Item尚未收集完所有必要数据时就将其yield,或者在后续的回调函数中重复yield同一个Item的不同版本,将导致:
- 不完整数据: Item在某些字段未填充时就被提交,导致数据缺失。
- 数据重复与覆盖: 同一个逻辑上的数据项,在不同的回调函数中被yield多次,或者部分字段被覆盖,最终在输出中出现多条记录,且每条记录可能只包含部分信息。
- 复杂的状态管理: 在回调链中传递Item并通过meta参数逐步填充是可行的,但这要求严格控制yield的时机,确保只在Item完全构建完毕后才进行。
Scrapy优化策略与最佳实践
针对上述问题,以下是Scrapy爬虫优化的关键策略:
1. 启用Scrapy内置重复请求过滤
核心原则: 除非有非常明确的理由,否则不要禁用Scrapy的去重过滤器。
- 操作: 从所有scrapy.Request和response.follow调用中移除dont_filter=True参数。Scrapy默认会启用去重,确保每个URL只被请求一次。
- 优势: 自动避免重复爬取相同的页面,显著减少网络请求和数据重复。
2. 精确控制分页逻辑
核心原则: 仅请求下一页,而不是所有分页链接。
- 操作: 在parse方法中,定位当前页面的“下一页”链接。如果存在,则发送一个针对该链接的请求。
- 示例: 通常可以通过CSS选择器或XPath找到当前页的兄弟节点中的下一页链接。
import scrapy
class IcsstriveSpider(scrapy.Spider):
name = "icsstrive"
start_urls = ['https://icsstrive.com/']
baseUrl = "https://icsstrive.com"
def parse(self, response):
# 1. 提取当前页面的主内容链接并跟进
for link in response.css('div.search-r-title a::attr(href)').getall():
yield response.follow(link, self.parse_icsstrive)
# 2. 精确处理分页:查找并请求下一页
# 假设当前页的上述代码中,current_page_li.xpath("./following-sibling::li/a/@href").get() 能够准确地找到当前页码
3. 确保Item完整性后提交
核心原则: 只有当一个Item的所有预期字段都已收集完毕时,才将其yield。
针对原问题中多层嵌套链接(受害者、恶意软件、威胁源)的抓取,有两种主要策略:
策略一:简化Item结构(推荐,如果适用)
如果目标是收集主页面信息以及所有相关内部链接的列表(而不是深入每个内部链接并将其数据合并到主Item中),可以直接在主解析函数中提取这些链接及其文本,并将其作为列表添加到Item中。这种方法避免了复杂的链式回调和状态管理。
import scrapy
class IcsstriveSpider(scrapy.Spider):
name = "icsstrive"
start_urls = ['https://icsstrive.com/']
baseUrl = "https://icsstrive.com"
def parse(self, response):
# 提取当前页面的主内容链接并跟进
for link in response.css('div.search-r-title a::attr(href)').getall():
yield response.follow(link, self.parse_icsstrive)
# 分页逻辑(同上)
current_page_li = response.css('li.wpv_page_current')
next_page_link = current_page_li.xpath("./following-sibling::li/a/@href").get()
if next_page_link:
yield scrapy.Request(response.urljoin(next_page_link), callback=self.parse)
def parse_icsstrive(self, response):
# 直接从主页面提取所有相关链接和文本
victims_links = response.xpath("//div[h3[text()='Victims']]//li/a/@href").getall()
victims_text = response.xpath("//div[h3[text()='Victims']]//li//text()").getall() # 提取所有文本,可能需要进一步清洗
malware_links = response.xpath("//div[h3[text()='Type of Malware']]//li/a/@href").getall()
malware_text = response.xpath("//div[h3[text()='Type of Malware']]//li//text()").getall()
threat_source_links = response.xpath("//div[h3[text()='Threat Source']]//li/a/@href").getall()
threat_source_text = response.xpath("//div[h3[text()='Threat Source']]//li/a/text()").getall() # 仅提取链接文本
title = response.xpath('//h1[@class="entry-title"]/text()').get()
# 在所有数据收集完毕后,一次性yield完整的Item
yield {
"title": title,
"victims": victims_text,
"victims_links": victims_links,
"malware": malware_text,
"malware_links": malware_links,
"threat_source_links": threat_source_links,
"threat_source": threat_source_text
}这种方法将所有内部链接的URL和显示文本作为列表收集到主Item中,避免了对每个内部链接进行深度爬取并合并数据的复杂性。它适用于当内部链接的详细内容并非必须合并到主Item,或者只需要链接本身信息的情况。
策略二:链式回调与数据累积(适用于深度合并数据)
如果确实需要访问每个内部链接,并将其详细内容合并到主Item中,则需要更精细地管理meta参数和yield时机。
- 初始化Item: 在parse_icsstrive中创建基础Item,并提取主页面的所有信息。
- 启动链式请求: 如果有victims_url,则发起对第一个victim的请求,并将当前Item和所有剩余的URL列表(包括malwares_urls和threat_source_urls)通过meta传递。
- 逐步填充: 在parse_victims中,填充受害者信息,然后根据meta中的malwares_urls发起对第一个malware的请求,继续传递Item和剩余的URL列表。
- 最终提交: 只有在所有类型的内部链接都被处理完毕(即所有列表都为空)的最后一个回调函数中,才yield最终的、完整的Item。
这种策略需要更复杂的逻辑来管理meta中的状态和URL列表,确保每次只处理一个子链接,并在其完成后继续处理下一个类型。同时,需要处理列表为空的边缘情况,以确保Item最终能被yield。
总结与注意事项
- 去重是基石: 始终信任并利用Scrapy的内置去重机制,避免滥用dont_filter=True。
- 分页的艺术: 采用“只请求下一页”的策略,避免重复爬取和无限循环。
- Item的完整性: 明确Item的边界,只在数据完全收集后才yield。对于复杂的多层数据,考虑是直接收集链接列表,还是通过链式回调进行深度合并。如果选择深度合并,务必精心设计meta参数传递和yield时机。
- XPath/CSS选择器的精确性: 确保选择器能够准确地定位到目标数据,尤其是在处理分页和内部链接时。
- 错误处理: 在实际项目中,还应考虑网络请求失败、页面结构变化等情况,加入适当的错误处理和日志记录。
通过遵循这些优化策略,Scrapy爬虫将能更高效、准确地完成深度爬取任务,避免常见的重复数据和数据不完整问题。










