编者按：互联网上有浩瀚的数据资源，要想抓取这些数据就离不开爬虫。鉴于网上免费开源的爬虫框架多如牛毛，很多人认为爬虫定是非常简单的事情。但是如果你要定期上规模地准确抓取各种大型网站的数据却是一项艰巨的挑战，其中包括网站的格式经常会变、架构必须能灵活伸缩应对规模变化同时要保持性能，与此同时还要挫败网站反机器人的手段以及维护数据质量。流行的Python爬虫框架Scrapy开发者Scrapinghub分享了他们抓取一千亿个网页后的经验之谈。

现在爬虫技术似乎是很容易的事情，但这种看法是很有迷惑性的。开源的库/框架、可视化的爬虫工具以及数据析取工具有很多，从网站抓取数据似乎易如反掌。然而，当你成规模地在网站上抓东西时，事情很快就会变得非常棘手。

自年以来抓取超过亿个产品页面，我们将会通过系列文章来分享从中学到的经验教训，让你深入了解从电子商务商店中规模析取数据时所面临的挑战，并且跟你分享应对这些挑战的某些最佳实践。

本文是该系列文章的第一篇，在这里我们将提供规模抓取产品数据所面临主要挑战的概览，以及Scrapinghub从抓取亿产品页面中学到的经验教训。

成立于年的Scrapinghub是领先的数据析取公司之一，也是当今最健壮和流行的web爬虫框架Scrapy的作者。目前Scrapinghub每月抓取许多全球最大型电子商务公司的页面数超过80亿（其中30亿是产品页面）。

对于那些对规模爬取网页技术感兴趣但对要不要建立专门的web爬取团队或者外包给专门的web爬取公司的人来说，最好看看这个免费指南，企业web爬虫：规模化web爬取技术指南

规模爬取技术为什么重要？

跟标准的web爬取应用不一样的是，规模爬取电子商务产品数据有一项独特挑战使得web抓取要困难许多。

本质上这些挑战可归结为两件事情：速度和数据质量。

由于时间通常是限制因素，规模抓取要求你的爬虫要以很高的速度抓取网页但又不能拖累数据质量。对速度的这张要求使得爬取大规模产品数据变得极具挑战性。

挑战#1——草率而且总是在变的网站格式

这一点很明显但也许不是最性感的挑战，但是草率而一直在变的网站格式是目前为止你在规模析取数据时将会面临的最大挑战。这未必是因为任务的复杂性，而是由于你要投入的时间和资源。

如果你花过时间开发过电子商务商店的爬虫的话，你就会知道电子商务网站代码之草率是一种流行病。这可不仅仅是HTML完构性或者偶尔的字符编码问题。这些年来我们遇到过形形色色的问题——HTTP响应代码的误用，损坏的JavaScript代码，或者Ajax的误用：

停掉产品时移除页面的商店在网站升级后突然间会在错误处理程序返回响应码。不恰当的JSON转义破坏了部分页面的JavaScript代码（比如‘b0rk’d’），导致你需要用正则表达式来抓取那部分数据。滥用Ajax调用的商店以至于你只能靠渲染该页面（这会导致爬取慢很多）或者模仿API调用（导致要付出更多的开发努力）来获得数据。

像这样草率的代码会导致编写爬虫非常痛苦，但也会使得可视化爬取工具或者自动析取不再可行。

在规模爬取的时候，你不仅要浏览成百上千个有着草率代码的网站，还将被迫应对不断演变的网站。一条好的经验法则是要预计你的目标网站每隔2到3个月就会发生让你的爬虫工作不了的变化。

这也许看起来不像是多大的事，但是当你规模抓取时，那些事件就会累积。比方说，Scrapinghub有一个规模比较大的电子商务项目大概有个爬虫抽取约个电子商务网站，意味着每天可能会经历20到30次爬虫失败。

而且网站在不同地区、语言的变化，A/B测试以及包装/定价的派生也会制造出各种问题导致爬虫失败。

没有容易的解决方案

不幸的是，不存在银弹可以彻底解决这些问题。很多时候这只是随着规模而扩大投入更多资源到你的项目上才能解决的事情。再拿上一个例子来说吧，那个项目有18名全职的爬虫工程师以及3名专职的QA工程师来确保客户总能得到可靠的数据流。

不过，你的团队有经验以后就会学会如何开发出更加健壮的爬虫，从而检测并处置目标网站格式中的异常。

如何处理目标网站有各种布局可能的情况呢？用多个爬虫也许不是最好的做法，我们的最佳实践是只用一个产品爬虫来处理不同页面布局个各种可能规则和模式。你的爬虫可配置性越强越好。

尽管这些实践会让你的爬虫更加复杂（我们有些爬虫有好几千行），但它会确保你的爬虫更容易维护。

由于大多数公司日常都需要析取产品数据，等待几天让你的工程团队修复任何坏掉的爬虫不是可选项。当出现这些情况时，Scrapinghub会利用自己开发的基于机器学习的数据析取工具来作为后备，直到爬虫修复好。这个基于ML的析取工具会自动识别目标网站的目标字段（产品名称、价格、货币单位、图像、SKU等）并且返回想要的结果。

我们会在未来几周之内发布这项工具以及相关的指导文章，告诉大家如何将机器学习用到你的数据析取过程当中。

挑战2：可伸缩的架构

你将面临的第二个挑战是建设一个可随每日请求数增长而扩充且性能不会下降的爬虫基础设施。

在规模析取产品数据时，一个串行爬取的简单web爬虫是不堪此任的。通常一个串行的web爬虫会循环发出请求，每一项请求都要2到3秒钟完成。

如果你的爬虫每天发出的请求数不到0的话这种做法是没有问题的。然而，超过这个点你就得过渡到一种让你每天可以完成数百万请求而不会性能下降的爬虫架构。

这个话题得用一篇文章才能说得清楚，未来几周我们将发布一篇专门的文章来讨论如何设计和开发高吞吐量的爬取架构。然而，本节的剩余部分我们将讨论一些高级原则和最佳实践。

正如我们讨论过那样，在规模爬取产品数据时速度是关键。你需要确保在时间阈值范围内（通常是1天）可以找到并且爬取所有要求的产品页面。为此你需要做以下一些事情：

将产品发现与产品析取分开

为了规模爬取产品数据你需要将你的产品发现爬虫与产品析取爬虫分开。

产品发现爬虫的目标应该是让它浏览目前产品目录（或者“货架”）然后存储该目录下的产品URL供产品析取爬虫使用。

这个可以靠Scrapinghub开发的开源工具Frontera之类的爬虫前端辅助完成。尽管Frontera原先的目的是配合Scrapy使用的，但它其实完全是不可知论者，可用于任何爬虫框架或者独立项目。在这篇文章中，我们分享了如何利用Frontera来规模抓取HackerNews的东西。

分配更多资源给产品析取

由于每一个产品目录“货架”可包含10到种产品，而且析取产品数据需要的资源要比析取产品URL更多，发现爬虫通常运行要比产品析取爬虫更快。这种情况下，你需要有多个析取爬虫来对应每一个发现爬虫。一条好的经验法则是每10万个页面分配一个析取爬虫。

挑战3：维护吞吐量性能

一级方程式的目标是将车上一切不必要的载荷都剔除掉，并且以速度之名将引擎最后一丝马力都榨干，从这个意义上来说规模抓取可以跟一级方程式相比较。规模web抓取也是一样的道理。

在析取大量数据时，在现有硬件资源条件下，你总是会想方设法要寻找请求周期最小化爬虫性能最大化的手段。这一切都是希望你能给每个请求节省下来那么几微秒的时间。

为此你的团队需要对web爬取框架、代理管理以及所使用的硬件具备深刻理解，这样才能对它们进行调整以优化性能。你还需要

转载请注明:http://www.aideyishus.com/lkjg/2664.html