[译文]致电商数据科学工作者：爬取千亿产品页面的心得

如今，网络爬取已经变得十分简单。有许多开源库/框架，可视化抓取工具和数据提取工具，可以很容易地从网站上抓取数据。 然而，当你想大规模爬取网站时，事情很快开始变得非常棘手。

在此系列文章中，我们将与你分享自2010年来爬取超过1000亿产品页面的经验与心得，带你深入领略大规模爬取电商网站产品页面时遇到的挑战，并向你展示一些解决问题的最佳实践。

本文作为系列文章的开篇，将对大规模爬取产品数据的挑战与经验做一个总体的介绍。

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

对于那些有兴趣大规模搜索网络而又正在决定是否应该在内部建立一个专门的网络抓取团队或将其外包给专门的网络抓取公司的人，请务必查看我们的免费指南，Enterprise Web Scraping：大规模刮刮Web指南。

 

大规模爬取的要点

不同于标准web应用的爬取，大规模电商页面爬取具有独特的挑战，使得爬取工作变得异常困难。其核心问题可以归结为爬取速度和数据质量。

因为时间总是有限的，大规模爬取要求你的爬虫在不牺牲数据质量的情况下快速地运行，这使得爬取过程变得十分困难。

 

挑战1：快速迭代和不断变化的网站格式

这可能是显而易见的问题，也可能不是最有意思的挑战，但快速更新和不断变化的网站格式是迄今为止在大规模提取数据时将面临的最大挑战。 并不一定是因为任务的复杂性，而是您将花费在处理它上面的时间和资源非常多。

如果你曾花过一点时间构建电子商务网站的爬虫的话，你就会知道，在电商网站，低质量的代码简直是泛滥成灾。不仅仅是HTML格式问题和一些偶然的字符编码问题，我们曾经遇到过形形色色的问题，包括使用不当的HTTP响应码，破碎的JavaScripts代码以及Ajax的错误使用。例如：

· 商店在换页展示商品的时候，突然删除页面或者在网站升级时在404错误处理程序时，返回200的HTTP状态码

· 错误转义的JSON数据，导致某些页面的Javascript代码异常，以至于你不得不用正则表达式去获取数据

· 过度滥用Ajax异步请求，导致你不得不渲染页面来获取数据，导致爬取速度变慢。或者你需要模拟API的调用，然而这会导致开发成本的增加。

这些异常的代码不仅让你写爬虫非常痛苦，而且还会导致可视化爬虫和自动化数据提取工具的失效。

当你大量爬取数据时，你不仅面临着数以百计的有问题的页面代码，而且还要应对网页不断迭代的问题。一般而言，每过2-3个月，你的目标网站都会有一定程度的更新，导致你的爬虫覆盖率和爬取质量下降。

这听起来不是什么大问题，但是当数量达到一定程度，麻烦也会与日俱增。比如Scrapinghub的一个大型电商爬虫项目有大约4000个爬虫，目标网站大约有1000个左右的电商网站，那么每天都大约会有20-30的爬虫会报错失效。

多语言多地区导致的网站的页面布局变化，A/B分割测试和包装/定价变体也是常常导致爬虫失效的问题。

 

没有简单的解决办法

不幸的是，并没有能够完美解决这些问题的银色子弹。大量的时间以及资源需要被投入到项目中去。以之前的项目为例，一个那样的项目需要18个全职的爬虫工程师和3个尽责的QA工程师，保证客户端总是有可靠的数据反馈。

不过，有了这些经验，你的团队将会学到如何创建更稳定的爬虫，来检测和处理目标网站格式的错误（陋习）。

与其针对所有可能的不同格式的目标网页编写多组爬虫，不如采用一个超大的可以处理多种规则和规模的爬虫。爬虫可配置项越多就越稳定。

尽管这些规则使你的爬虫非常复杂（我们的一些爬虫有上千行代码）但是这会确保你的爬虫能更容易维护。

随着众多公司需要以天为周期提取产品数据，等你们的工程师修复一个有缺陷的爬虫需要好几天，这可不是一个美妙的选项。当这种情况发生时，Scrapinghub采用一种基于机器学习的数据提取工具。这种工具能够根据爬虫失效的反馈信息不断自我修复，能够自动定位目标网站的有效字段（比如产品名称、价格、币种、图片、库存等等），并返回期望的结果。

在接下来的几周里，我们将会发布该工具以及教程文章，以便你可以将机器学习的功能应用到数据挖掘工作中去。当然，如果你希望更早获得使用也可以联系我们的销售团队。

 

挑战2：可扩展架构

你将面临的下一个挑战是如何构建一个可扩展的爬虫架构：随着请求数量的与日俱增，如何保证性能不降级。

在大规模提取产品数据时，一个简单的网络爬虫只能连续地抓取和抓取数据，不会削减它。 通常，串行的爬虫会一个接着一个地在循环中发请求，每个请求需要2-3秒才能完成。

如果您的爬虫只需要每天发出<40,000个请求（每2秒请求一次等于每天43200个请求），这种方法就可以了。 但是，超过这一数量后，您将需要转而使用一种新的爬虫结构，该体系结构允许您每天抓取数百万个请求，而不会降低性能。

由于这个主题需要单独写一篇文章来阐述，因此在接下来的几周内，我们将发布一篇专门的文章，讨论如何设计和构建自己的高吞吐量抓取架构。 然而对于本节的其余部分，我们将讨论一些更高级别的原则和最佳实践。

正如我们讨论的，大量爬取数据时，速度是很关键的。你需要保证在给定的时间内能找到并爬取所需的产品页面数据（通常是一天）。因此你需要做到以下几点：

 

将产品数据的发现与提取分离

为了实现大量爬取，你必须将发现数据的爬虫与提取数据的爬虫分离。

数据发现爬虫的目标应该是导航到目标产品类别（或“货架”），并为数据提取爬虫存储该类别中产品的URL。 当产品发现爬虫将产品URL添加到队列时，产品提取爬虫会从该产品页面中抓取目标数据。

这可以借助于Scrapinghub开发的前沿开源爬虫软件Frontera等来实现。 虽然Frontera最初设计用于Scrapy，但它完全可以与任何其他爬虫框架或独立项目一起使用。 在本指南中，我们将分享如何使用Frontera进行大规模爬取。

 

为数据提取分配更多的资源

因为每个产品类别（或“货架”）可能包含10到100中产品，而且爬取产品数据比仅仅爬取URL要消耗更多地资源，所以通常数据发现爬虫比数据提取爬虫更快。在这种情况下，你需要为每个数据发现爬虫配合多个数据提取爬虫。一个经验法则是为每个~100,000页的桶创建一个单独的提取爬虫。

 

挑战3：保持高吞吐量

大规模爬虫可以简单地和F1赛车类比。F1赛车的目标是尽可能地削减自身重量，并且极尽全力地将引擎的马力用于提速。大规模爬虫也一样。

在提取大量数据时，你始终在寻找最小化请求周期时间的方法，并最大限度在可用硬件资源条件下下提高爬虫性能。 所有这一切都是为了能在每个请求上减少几毫秒的时间。

要做到这一点，你的团队需要深入了解您正在使用的Web抓取框架，代理管理和硬件，以便你可以调整它们以获得最佳性能。 你还需要关注：

 

爬虫效率

大规模爬取时，你应始终专注于仅仅提取所需的确切数据，请求数越少越好。 任何其他请求或数据提取都会降低您抓取网站的速度。 在设计爬虫时，请记住以下提示：

·  只使用不包含头的浏览器（如Splash或Puppeteer）来渲染javascript作为最后的手段。 使用不包含头的浏览器渲染javascript是非常耗费资源的，并且会严重影响您可以抓取的速度。

·  如果您可以从货架页面（比如产品名称，价格，评级等）获取所需数据而无需请求每个产品页面，则不要请求产品页面。

·  除非你真的需要，否则不要请求或提取图像。

挑战4：反爬虫手段

如果你大量爬取电商网站，那么必然会遇到反爬虫手段。

对于大多数较小的网站，他们的爬虫手段通常是非常基本的（封禁超额请求IP的）。 然而，亚马逊等大型电子商务网站利用Distil Networks，Incapsula或Akamai等复杂的反爬虫反制措施，使得提取数据变得更加困难。

 

代理

考虑到这一点，任何大规模刮削产品数据的项目的第一个也是最重要的要求是使用代理IP。 在大规模搜索时，您需要一个相当大的代理列表，并且需要实现必要的IP轮换，请求限制，会话管理和黑名单逻辑，以防止代理被封禁。

除非您已经或者愿意委托一个庞大的团队来管理您的代理，否则您应该将这部分抓取过程外包出去。 目前有大量的代理服务提供不同级别的服务。

但是，我们建议直接让代理供应商一个简单的终端代理配置，而把内部复杂的代理管理隐藏起来。大规模爬虫是很消耗资源的，没必要在代理管理基础架构上重复造轮子。

这是大多数大型电子商务公司使用的方法。 许多世界上最大的电商公司都使用Scrapinghub开发的智能下载器Crawlera，完全外包代理管理。 当您的抓取工具每天发出2000万个请求时，专注于分析不管理代理的数据会更有意义。

除此之外

不幸的是，仅仅使用代理服务不足以保证你能骗过较大电商网站的反爬虫系统。越来越多的网站开始采用更精细的反爬虫系统，来监控你的爬虫行为，以与真正的人类访问者区分。

这些反爬虫系统不仅会使电子商务网站变得更加困难，而且如果反制不得当，克服它们会严重影响您的抓取工具的性能。

这些反爬虫系统中的很大一部分使用Javascript来确定请求是来自爬虫还是人（Javascript引擎检查，字体枚举，WebGL和Canvas等）。

然而正如之前所提到的，大规模爬虫时你需要限制无头浏览器如Splash或Puppeteer的使用，因为渲染Javascript非常消耗资源和时间，使得你的爬虫速度降低。

这意味着为了确保你可以从爬虫获得必要的吞吐量来提供每日产品数据，您通常需要精心反向工程网站上使用的反爬虫系统，并设计爬虫以反制它们，从而无需使用无头浏览器。

 

挑战5：数据质量

从一个数据科学家的视角来看，一个数据爬取项目最重要的考虑永远是爬取数据的质量。大规模爬取中数据质量尤为重要。

当每天提取数百万数据时，通常无法手动验证所有数据是否干净且完好无损。 脏或不完整的数据很容易进入您的数据源并破坏您的数据分析工作。

在爬取同一商店（不同语言，地区等）商品的多个版本或不同商店中的产品时尤其如此。

除了在爬虫架构的设计开发阶段仔细的QA过程之外，爬虫的代码还经过相互评审和测试，以确保以最可靠的方式提取所需的数据。 而确保最高数据质量的最佳方法是开发自动化QA监控系统。

作为任何数据提取项目的一部分，你需要规划和开发一个监控系统，该系统将提醒您任何数据是否存在不一致以及是否有爬虫发生错误。 在Scrapinghub，我们开发了基于机器学习的算法，旨在检测：

·  数据验证错误 - 每个数据项都有定义有一定模式的数据类型和值。我们的数据验证算法将会标记所有与预期不一致的数据类型以告知QA团队，以便他们人工确认并进行警报验证或将其标记为错误。

· 产品差异错误 - 从同一网站（不同语言，地区等）的多个版本中抓取相同的产品数据时，很多变量和本来期望的固定值（如产品重量或尺寸）可能会有所不同。 这可能是网站反爬虫的对策导致一个或多个爬虫抓到伪造信息的结果。 同样，您需要有适当的算法来识别和标记任何此类事件。

· 基于体量的不一致性 - 另一个关键的监控脚本是检测返回的记录数量的任何异常变化的脚本。 这可能表示网站已进行了更改，或者你的抓取工具抓取到了伪造信息。

· 网站更改 - 目标网站发生的结构性更改是抓取工具崩溃的主要原因。 我们有专门的监控系统来积极地监控这个问题。 该工具会对目标站点执行频繁检查，以确保自上次爬网以来没有任何更改。 如果找到更改，它会发送相同的通知。

我们将在后面的文章中讨论所有这些，专门讨论自动化质量保证。

 

总结

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

而这只是本系列的第一篇文章，所以如果您有兴趣阅读下一篇文章，请务必关注我们的电子邮件列表。

对于那些有兴趣大规模爬取网站而又正在决定是否应该在内部建立一个专门的网络抓取团队或将其外包给专门的网络抓取公司的人，请务必查看我们的指南，《企业级网络爬虫：大规模爬取Web指南》。

在Scrapinghub，我们专注于将非结构化Web数据转换为结构化数据。如果你想了解更多关于如何在你的企业中使用网络抓取产品数据的信息，请随时联系我们的销售团队。无论是初创公司还是财富100强的公司，他们都会向你介绍我们提供的服务。

在Scrapinghub，我们总是喜欢聆听读者对我们内容的看法以及你可能遇到的任何问题。 因此，请在下面留下评论，说明你对文章的看法以及你的工作内容。

 

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

免费体验云安全(易盾)内容安全、验证码等服务

更多网易技术、产品、运营经验分享请点击。