从千亿页面上提取数据所总结的五大经验！

如今从网上抓取数据看似非常容易。有许多开源库和框架、可视化抓取工具和数据提取工具，可以很容易地从一个网站上抓取数据。但是，当你想大规模地搜索网站时，很快就会感觉到非常棘手。

本文中，我们将与你分享自2010年以来借助Scrapinghub从一千亿个产品页面上抓取数据时所学到的经验教训，让你深入了解从电子商务店铺大规模提取产品数据时面临的挑战，并与你分享一些应对这些挑战的最佳实践经验。

Scrapinghub成立于2010年，是数据提取公司中的佼佼者之一，也是Scrapy的缔造者——Scrapy是当今最强大、最受欢迎的网络抓取框架。目前，Scrapinghub为全球众多的大型电子商务公司每月抓取超过80亿的页面（其中30亿是产品页面）。

大规模抓取网页的要点

与标准的抓取网页应用程序不同，大规模抓取电子商务的产品数据将面临一系列独特的挑战，这使得网页抓取异常艰难。

从本质上来说，这些困难可以归结为两个方面：速度和数据质量。

通常时间是一个限制性约束，因此大规模抓取需要网络爬虫以非常高的速度抓取页面，并不会影响数据质量。这种对速度的要求造成大量抓取产品数据富有非常大的挑战性。

挑战1：杂乱且变幻无常的网页格式

杂乱且变化无常的网页格式可能是最常见的挑战，也可能不是最令人感兴趣的挑战，但它是迄今为止大规模提取数据时面临的最大挑战。这项挑战的关键不在于复杂性，而是需要花费大量时间和资源去处理。

如果你有过创建电子商务店铺爬虫经历的话，你就会知道电子商务店铺代码的杂乱无章是普遍现象。这不仅仅是HTML的格式或偶尔的字符编码问题。多年来，我们遇到了各种各样的问题，例如滥用HTTP响应代码、不完整的JavaScripts，或滥用Ajax：

• 在产品销售终止后，店铺会删除页面，且在网站升级后404错误处理程序突然返回的响应状态为200；

• 有些页面错误地转义JSON数据，导致页面上的Javascript遭到破坏，例如‘b0rk’d’等，所以必须使用正则表达式来删除这些数据；

• 店铺大量滥用Ajax调用，所以只能等页面渲染完毕（这会导致爬虫速度更慢）或模仿API调用（这会导致额外的开发工作）才能想要的拿到信息。

如此杂乱的代码会让编写爬虫工作十分痛苦，且无法使用抓取工具或自动提取工具。

在大规模抓取网页时，你不仅需要浏览几百个像这样杂乱的网站，还要处理网站的不断更新。一个经验法则是：每2-3个月目标网站的变动就会废掉你的爬虫。

可能听起来不是什么大不了的事儿，但是当你大规模抓取时，这些意外会积累成灾。例如，Scrapinghub的一个大型电子商务项目大约有4000个爬虫，需要抓取1000个电子商务网站，这意味着每天他们都有20-30只爬虫遭遇失败。

来自区域和多语言网站布局的变动，A/B分割测试和包装/定价变动也会经常给爬虫带来问题。

没有捷径

很不幸的是，没有完全解决这些问题的灵丹妙药。很多时候，我们只能随着规模扩展投入更多资源。以上述项目为例，负责项目的团队共有18名爬虫工程师和3名专职QA，以确保客户始终拥有可靠的数据。

但是，凭借经验团队可以学会如何创建更强大的爬虫，以便检测和对付网站格式的各种怪招。

最佳做法不是为目标网站可能使用的所有布局逐一编写爬虫，而是仅凭一个产品提取的爬虫就可以处理不同页面布局所使用的所有可能规则和方案。爬虫拥有的配置越多越好。

虽然这些做法会让爬虫更加复杂（我们的一些爬虫长达几千行），但可以保证爬虫更加易于维护。

由于大多数公司需要每天都抽取产品数据，所以我们无法花费几天时间等待工程团队修改遭到破坏的爬虫。对于这种情况，Scrapinghub使用一种基于数据提取工具的机器学习，我们开发了这种机器学习模型作为后备，直到爬虫被修复。这种基于机器学习的提取工具可以自动识别目标网站的目标字段（产品名称、价格、货币、图像、SKU等等），并返回所需的结果。

挑战2：可扩展性架构

你将面临的下一个挑战是：构建一个爬虫基础架构，该架构可以随着每天请求数量的增加而扩展，而不会降低性能。

当大规模提取产品数据时，简单的网页爬虫只能连续地抓取数据，而不会节选。通常，一个连续的网页抓取会循环发送请求，一个接一个，每个请求需要2-3秒才能完成。

如果爬虫每天都请求量小于4万个的话（每2秒发送一个请求，意味着每天可以发送43,200个请求），这个方法还可以。但是，一旦请求数量超过这个数，你就需要切换到每天可以发送几百万请求且不会降低性能的爬虫架构。

正如上述讨论，速度是大规模抓取产品数据的关键。你需要确保在一定时间内（通常为一天）找到并抓取所有所需的产品页面。为此，你需要执行以下操作：

从产品提取中分离产品搜索

为了大规模提取产品数据，你需要从产品提取爬虫中分离产品搜索爬虫。

产品搜索爬虫的目标应该是找到目标产品种类（或“货架”），并保存该种类下产品的URL，以供产品提取爬虫使用。当产品搜索爬虫将产品URL加到队列后，产品提取爬虫会从茶品页面上抓取目标数据。

这项工作可以借助流行的爬虫工具的辅助，例如由Scrapinghub开发的开源爬虫工具Frontera等。虽然最初设计Frontera是为了用于Scrapy，但它完全没有限制，可以与任何其他爬虫框架或独立项目一起使用。在本文中，我们将分享如何使用Frontera大量挖掘HackerNews的数据。

为产品提取分配更多资源

由于每个产品类别“货架”可以包含10到100个产品，且与提取产品URL相比，提取产品数据需要更多资源，因此搜索爬虫的速度通常比产品抽取爬虫更快。对于这种情况，你需要为每个搜索爬虫配备多个抽取爬虫。经验法则是：每100,000页需要创建一直单独的抽取爬虫。

挑战3：维持吞吐量性能

大规模抓取很像赛车Formula 1，我们的目标是为了提高速度，尽可能地减轻车身重量，并从发动机中挤出最后一部分马力。对于大规模网络抓取也是如此。

在提取大量数据时，我们必须尽可能寻找可以将周期时间降到最小、并在现有硬件资源的基础上将爬虫性能提高到最大的方法。所有这些都必须减少每个请求的时间，哪怕是几毫秒。

为此，你的团队需要深入了解正在使用的网页抓取框架、代理管理和硬件，才能更好地调优，以获取最佳性能。你还需要关注：

爬虫效率

大规模抓取的时候，我们始终应该努力在尽可能少的请求次数内提取所需的确切数据。任何额外的请求或数据提取都会降低抓取网站的速度。在设计爬虫时，请记住以下几点：

• 只是用没有头部的浏览器，如Splash或Puppeteer等，将JavaScript渲染放到最后。抓取网页时，使用没有头部的浏览器渲染JavaScript会非常耗费资源，并且会严重影响到抓取速度；

• 如果无需向每个产品页面发送请求，也可以从货架页面（例如产品名称、价钱、口碑等）获取数据，则不要请求产品页面；

• 除非有必要，否则不要请求或提取图像。

挑战4：反机器人策略

在大规模抓取电子商务网站的时候，肯定会遇到使用反机器人策略的网站。

对于大多数小型网站来说，他们的反机器人策略非常基本（禁止IP提出超额请求）。然而，对于亚马逊等大型电子商务网站说，他们会使用非常成熟的反机器人策略，例如Distil Networks、Incapsula或Akamai等，这会让提取数据变得更加困难。

代理

请记住，对于大规模抓取产品数据的项目来说，最重要的要求是使用代理IP。在大规模抓取时，你需要一个相当大的代理列表，并且需要实现必要的IP轮换、请求限制、会话管理和黑名单逻辑，以防止代理被封杀。

除非你有一个庞大的队伍管理代理，否则你应该将这部分抓取工作外包出去。外面有大量代理服务可以提供各种级别的服务。

但是，我们建议你可以与代理商合作，让他们为代理配置提供单个端点并隐藏管理代理的复杂性。大规模抓取非常耗资源，更不用想需要通过开发和维护建立自己内部的代理管理基础设施了。

大多数大型电子商务公司都采用这种方法。许多世界上最大的电子商务公司都是用Scrapinghub开发的智能下载器Crawlera，将代理管理全权外包。如果你的抓取工具每天需要发出两千万个请求的话，相较于代理管理，专注于抓住会更有意义。

超越代理

不幸的是，仅使用代理服务还不足以确保可以规避大型电子商务网站的反机器人策略。越来越多的网站开始使用成熟的反机器人策略，来监控爬虫行为，检测请求是否来自人类访问者。

这些反机器人策略不仅会给电子商务网站的抓取制造困难，而且如果处理不当，与它们的斗争还会严重影响爬虫的性能。

这些反机器人策略大多数都是用JavaScript来确定请求来自于爬虫还是人（JavaScript引擎检查、字体枚举、WebGL和Canvas等）。

但是如前所述，大规模抓取数据时，我们希望使用可编写脚本的没有头部的浏览器（如Splash或Puppeteer等），页面上的JavaScript渲染会给资源造成压力，并降低抓取网站的速度。

这意味着为了确保你的爬虫可以达到必要的吞吐量，从而提供每日的产品数据，通常你需要费尽心思对抗反网站上使用的机器人策略，并设计爬虫在不使用没有头部的浏览器的情况下也可以战胜它们。

挑战5：数据质量

从数据科学家的角度来看，网页抓取项目最重要的考虑因素是提取的数据质量。大规模抓取更加关注数据的质量。

如果每天需要提取几百万个数据点，那么手工验证所有数据是否干净完整是不可能的。一个不小心脏数据或不完整的数据就会进入数据源，并破坏数据分析工作。

当店铺有多个版本（不同语言、地区等）或从不同店铺抓取数据时，数据质量尤为重要。

除了仔细的QA流程外，创建爬虫的设计阶段，通过互相审查和测试爬虫的代码可以确保以最可靠的方式提取所需的数据。确保数据高质量的最佳方法是开发自动化QA监视系统。

作为数据提取项目的一部分，你需要计划和开发一个监控系统，来提醒你数据上出现的不一致和爬虫错误。在Scrapinghub，我们开发了机器学习算法用于检测：

• 数据验证错误：每条数据都有定义好的数据类型和需要遵循的赋值模式。如果数据项的数据类型不一致，我们的数据验证算法会通知QA团队，由他们负责手动检查数据，经过验证后返还或标记成错误。

• 产品差异错误：当从同一个网站的不同版本（不同语言、地区等）抓取同一个产品数据时，可能会有所不同，且理应固定的值（例如产品重量、尺寸等）也有可能变化。这有可能是网站的反机器人策略给出了一个或多个虚假信息。同样，你需要合适的算法来识别和标记此类数据。

• 卷上数据的不一致：另一个关键的监控脚本是检测返回的记录数量的异常变化。这可能表示网站已经做了修改，或者你的爬虫拿到的是虚假信息。

• 网站更新：目标网站的结构变化是造成爬虫崩溃的主要原因。我们有专门的监控系统，非常积极地监控这种情况。该工具会频繁地检查目标站点，确保自上次抓取以来没有任何变化。一旦发现变化，它会发出通知。

总结

如你所见，大规模抓取产品数据需要面临一系列独特的挑战。希望这篇文章可以让你更加了解这些挑战以及如何解决这些挑战。

在Scrapinghub，我们专注于将非结构化Web数据转换为结构化数据。 如果你对本文有任何想法，请在下面留言。

原文：https://blog.scrapinghub.com/web-scraping-at-scale-lessons-learned-scraping-100-billion-products-pages

作者：Ian Kerins

译者：弯月，责编：郭芮

“ 征稿啦 ”

CSDN 公众号秉持着「与千万技术人共成长」理念，不仅以「极客头条」、「畅言」栏目在第一时间以技术人的独特视角描述技术人关心的行业焦点事件，更有「技术头条」专栏，深度解读行业内的热门技术与场景应用，让所有的开发者紧跟技术潮流，保持警醒的技术嗅觉，对行业趋势、技术有更为全面的认知。

如果你有优质的文章，或是行业热点事件、技术趋势的真知灼见，或是深度的应用实践、场景方案等的新见解，欢迎联系 CSDN 投稿， 联系方式：微信（guorui_1118，请备注投稿+姓名+公司职位），邮箱（[email protected]）。

————— 推荐阅读 —————