Scrapinghub 成立于 2010 年,是一家领先的数据公司,当今最强大、最受欢迎的网络爬取框架 Scrapy 就是由它开发的。目前,Scrapinghub 每月为全球不少大型的电子商务公司爬取 80 亿个网页(其中有 30 亿个是产品页面)。git
与标准的爬虫应用程序不一样,大规模爬取电子商务产品数据须要面临一系列独特的挑战,这些挑战让爬取网页变得更加困难。github
这些挑战能够被归结为两类:速度和数据质量。web
由于时间一般是一个限制性的约束条件,因此在进行大规模爬取时要求爬虫以很是快的速度进行爬取,同时又不影响数据质量。这种对速度的极限要求使得爬取大量产品数据变得极具挑战性。正则表达式
很显然,凌乱的代码和不断变化的网页格式是在大规模爬取数据时将面临的最大挑战。不必定是由于任务的复杂性,而是你要在这上面所花费的时间和资源。算法
若是你作过网店的爬虫,就会知道,在网店的网页中,凌乱的代码泛滥成灾。除了 HTML 格式问题或偶尔出现的字符编码问题以外,还有其余不少问题。多年来,咱们遇到了各类各样的问题——滥用 HTTP 响应码、糟糕的 JavaScripts 或滥用 Ajax:api
网店在中止销售某些产品时会删除相应的产品页面,但在网站升级后,404 错误处理程序却返回了 200 响应码。浏览器
错误地转义了 JSON 数据,致使某些页面上的 JavaScript 代码没法正常运行(例如’b0rk'd'),你不得不使用正则表达式来爬取数据。微信
滥用 Ajax,以致于你只能在渲染页面(致使爬取变慢)或模拟 API 调用(致使更多的开发工做量)后才能抓取到你想要的信息。网络
这些凌乱的代码不只是你开发爬虫时的痛点,也会影响到那些可视化爬虫工具或自动爬取工具。架构
在进行大规模爬取时,除了要应对这些凌乱的代码,还要面临网站不断发生变化所带来的挑战。根据常规经验,目标网站通常每过 2-3 个月就会修改一次,你的爬虫就会出问题(致使爬取覆盖率或质量降低)。
这听起来可能没什么大不了的,但在进行大规模爬取时,这些问题聚沙成塔,就会带来大麻烦。Scrapinghub 的一个大型电子商务项目使用约 4,000 个爬虫爬取约 1,000 个电子商务网站,这意味着他们天天会遇到 20-30 个爬虫失败。
不一样区域和多语言网站的网页布局的变化、A/B 测试、产品套件和订价的变化也给爬虫带来了更多难题。
没有简单的解决方案
对于这些问题,并无什么万能的灵丹妙药。不少时候,在扩大规模时往项目中增长更多的资源。以上一个项目为例,该项目的团队由 18 名全职爬虫工程师和 3 名专职 QA 工程师组成,以确保可以源源不断地向客户始提供数据。
可是,从经验来看,你的团队仍然要学会如何开发更强大的爬虫,用它们来检测和处理各类诡异的网页格式。
最好是只开发一个能够处理不一样页面布局的爬虫,而不是为不一样的页面布局开发多个爬虫,爬虫的可配置下越高越好。
虽然这样会让你的爬虫变复杂(咱们的一些爬虫代码长达数千行),但也更容易维护。
大多数公司天天都须要爬取产品数据,由于工程团队要修复爬虫问题而不得不等上几天,这可不是个好主意。在出现这种状况时,Scrapinghub 使用基于机器学习的数据提取工具。这种基于 ML 的提取工具可自动识别目标网站上的目标字段(产品名称、价格、货币类型、图像、SKU 等)并返回所需的结果。
第二个挑战是构建一个可伸缩的爬虫基础架构,能够随着请求数量的增长而伸缩,而不会影响到性能。
在大规模爬取产品数据时,一个只能串行化爬取数据的简单网络爬虫是不够的。一般,串行化的爬虫在一个循环中一个接一个地发出请求,每一个请求须要 2-3 秒才能完成。
若是你的爬虫天天发出的请求少于 40,000 个(每 2 秒请求一次至关于天天 43,200 个请求),那么使用这种方法就足够了。可是,在此以后,你须要转换到一种爬虫架构,这样才能天天爬取数百万个网页,而不会下降性能。
爬取速度是大规模爬取产品数据的关键。你要确保可以在给定的时间内(一般为一天)找到并爬取全部必需的产品页面。为此,你须要执行如下操做:
实现产品发现和产品抓取的分离
要大规模爬取产品数据,须要将产品发现爬虫与产品抓取爬虫分开。
用于产品发现的爬虫主要负责导航到目标产品类别(或“货架”),并为产品提取爬虫保存该类别下的产品 URL。在产品发现爬虫将产品 URL 添加到队列后,产品抓取爬虫会从该产品页面爬取目标数据。
Scrapinghub 为此开发了 Frontera(https://github.com/scrapinghub/frontera),并将其开源,虽然 Frontera 最初被设计与 Scrapy 一块儿使用,但也能够与其余爬虫框架或独立项目一块儿使用。在这篇文章(https://blog.scrapinghub.com/2015/04/22/frontera-the-brain-behind-the-crawls/)中,咱们分享了如何使用 Frontera 大规模爬取 HackerNews。
为产品爬取分配更多资源
每一个产品类别可能包含 10 到 100 个产品,而且爬取产品数据比爬取产品 URL 更耗费资源,所以产品发现爬虫一般比产品抓取爬虫运行得更快。因此,你须要为每一个发现爬虫配备多个抓取爬虫。根据经验,大约每 100,000 个网页须要配备一个单独的抓取爬虫。
大规模爬取能够比做一级方程式赛车,你的终极目标是从车上卸掉每一克没必要要的重量,并以速度的名义榨取发动机最后那一点马力。大规模网页爬取也是如此。
在爬取大量数据时,你始终在寻找最小化请求周期时间的方法,并最大限度地提升爬虫性能,全部这些都是为了能为每一个请求减小几毫秒的时间。
你的团队须要深刻了解正在使用的爬虫框架、代理和硬件,才能调整它们以得到最佳性能。除此以外,还须要关注:
爬取效率
在进行大规模爬取时,应该尽量只爬取必要的数据。额外的请求或数据抓取都会下降爬取网站的速度。在设计爬虫时,请记住如下几点:
只在逼不得已的状况下才使用 headless 浏览器(如 Splash 或 Puppeteer)来解析 JavaScript,由于使用 headless 浏览器解析 JavaScript 至关耗费资源,会严重影响爬取的速度。
若是能够从产品页面(如产品名称、价格、评级等)获取所需数据而无需请求每一个产品页面,那么就不要请求产品页面。
除非真的须要,不然不要请求或抓取图像。
若是你正在大规模爬取电子商务网站,确定会碰到使用反机器人措施的网站。
大多数小型网站使用基本的反机器人措施(好比禁掉频繁访问的 IP 地址)。而像亚马逊这样大型的电子商务网站会使用像 Distil Networks、Incapsula 或 Akamai 这些复杂的反机器人措施,这让爬取数据变得更加困难。
代理
所以,在进行大规模产品数据爬取时,首先须要考虑使用代理。你须要大量的代理,而且须要实现 IP 轮换、请求限制、会话管理和黑名单逻辑,防止代理被禁。
除非你已经或者愿意养一个庞大的团队来管理代理,不然应该将这部分爬取过程外包出去。如今有大量的代理服务,他们提供了不一样级别的服务。
咱们的建议是与代理提供商合做,代理提供商能够为代理配置提供单个端点,并隐藏管理代理的复杂性。大规模爬取很是耗费资源,因此不该该本身重复发明轮子,好比开发和维护本身的内部代理管理基础设施。
代理以外
不过,仅仅使用代理服务还不足以确保你能够在大型的电子商务网站上规避反机器人措施,愈来愈多的网站正在使用复杂的反机器人措施来监控你的爬虫。
这些反机器人措施不只会让爬取电子商务网站变得更加困难,若是处理很差,会严重影响爬取工具的性能。
在这些反机器人措施中,有很大一部分使用 JavaScript 来判别请求是来自爬虫仍是人类(JavaScript 引擎检查、字体枚举、WebGL 和 Canvas 等)。
不过以前已经提到,在进行大规模爬取时,要尽可能限制使用 headless 浏览器(如 Splash 或 Puppeteer)来解析 JavaScript,由于它们很是耗费资源,而且会下降爬取网页的速度。
所以,为了确保爬虫的吞吐量,以便天天提供必要的产品数据,你一般须要精心对网站的反机器人措施进行反向工程,在不使用 headless 浏览器的状况下让你的爬虫搞定一切。
从数据科学家的角度来看,爬虫项目最重要的考虑因素是所提取数据的质量,而大规模爬取只会让对数据质量的关注变得更加剧要。
天天提取数百万个数据点,就没法手动验证全部数据是否干净且无缺无损。脏数据或不完整的数据很容易进入到你的数据源并破坏你的数据分析工做。
在爬取同一网站(不一样语言,地区等)或不一样网站相同产品的多个版本时,尤为须要考虑数据质量问题。
在爬虫的设计阶段,须要进行严格的 QA 过程,爬虫的代码须要通过严格的评审和测试,确保能够以最可靠的方式提取所需的数据。确保高质量数据的最佳方法是开发自动化 QA 监控系统。
做为数据爬取项目的一部分,须要规划和开发一个监控系统,在发现数据不一致或发生错误时能够发出告警。在 Scrapinghub,咱们开发了机器学习算法,用于检测:
数据验证错误——每一个数据项都有定义好的数据类型,它们的值都遵循一致的模式。咱们的数据验证算法能够标记出与数据类型的预期不一致的数据项,QA 团队将手动检查这些数据,并发出告警或将其标记为错误。
产品差别错误——从同一网站的多个版本(不一样语言、地区等)爬取相同的产品数据时,一些变量(如产品重量或尺寸)可能会有不一样的值。这多是网站的反机器人措施为爬虫提供的伪造信息。一样,你须要有适当的算法来识别和标记此类数据。
数据量不一致性——另外一个关键的监控动做是检测异常的返回数据量。若是出现异常,多是由于网站已经发生了变动,或者网站向你的爬取工具提供了伪造信息。
网站变动——目标网站发生的结构性变动是致使爬取工具崩溃的主要缘由。咱们的专用监控系统对此进行监控,它会频繁地检查目标网站,确保自上次爬取以来没有发生任何变动。若是发生变动,它会发送通知。
本文介绍了在进行大规模爬取产品数据时须要面对的一系列独特的挑战。对于那些有兴趣了解大规模网站爬取的人,能够进一步参阅 Enterprise Web Scraping: A Guide to Scraping the Web at Scale(https://info.scrapinghub.com/enterprise-web-scraping-scraping-at-scale)。
英文原文:
https://blog.scrapinghub.com/web-scraping-at-scale-lessons-learned-scraping-100-billion-products-pages