数据从业者必读：抓取了一千亿个网页后我才明白，爬虫一点都不简单

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

　　如今爬虫技术彷佛是很容易的事情，但这种见解是颇有迷惑性的。开源的库/框架、可视化的爬虫工具以及数据析取工具备不少，从网站抓取数据彷佛易如反掌。然而，当你成规模地在网站上抓东西时，事情很快就会变得很是棘手。

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

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

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

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

！！！规模爬取技术为何重要？

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

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

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

挑战1——草率并且老是在变的网站格式

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

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

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

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

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

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

　　并且网站在不一样地区、语言的变化，A/B测试以及包装/订价的派生也会制造出各类问题致使爬虫失败。

没有容易的解决方案

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

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

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

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

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

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

挑战 2：可伸缩的架构

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

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

若是你的爬虫天天发出的请求数不到40000的话这种作法是没有问题的。然而，超过这个点你就得过渡到一种让你天天能够完成数百万请求而不会性能降低的爬虫架构。

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

正如咱们讨论过那样，在规模爬取产品数据时速度是关键。你须要确保在时间阈值范围内（一般是1天）能够找到而且爬取全部要求的产品页面。为此你须要作如下一些事情：

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

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

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

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

分配更多资源给产品析取

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

挑战 3：维护吞吐量性能

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

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

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

爬取效能

规模爬取时你应该始终把焦点放在以尽可能少的请求析取所需数据上。任何额外请求或者数据析取都会放缓你爬取网站的节奏。在设计你的爬虫时请记住这些提示：

• 做为最后一招，仅使用无界面浏览器，好比Splash或者Puppeteer来渲染JavaScript。用无界面浏览器渲染JavaScript同时爬取是很是耗资源的，会严重影响爬取的速度。
• 若是你能够从货架页面（好比产品名称、价格、评分等）得到所需的数据而不须要向独立的产品页面提出请求的话，那就不要向产品页面发出请求。
• 不要请求或者析取图像，除非无可奈何。

挑战 4：反机器人的对策

若是你批量抓取电子商务网站的话必定会遇到采用反机器人对策的网站。

规模小一点的网站其反机器人对策就是些基本手段（屏蔽发送请求过量的IP）。然而，较大的电子商务网站，好比Amazon等，会采用复杂的反机器人对策，好比Distil Networks、Incapsula或者Akamai等来使得析取数据困难许多。

代理

了解到这一点以后，任何项目想要规模抓取才数据，首要的基本需求就是得用代理。规模抓取数据时你须要可观的代理清单，并且须要实现必要的IP轮转、请求限制、会话管理以及黑名单逻辑来预防代理被屏蔽。

或者除非你有或者愿意用一支规模可观的团队管理你的代理，不然的话你应该把抓取流程中的这一部分外包出去。提供各类水平服务的代理服务有不少。

然而，咱们的建议是找一家可以提供单个代理配置端点而且将全部的代理管理复杂性隐藏起来的代理提供商。在没有从新发明轮子、开发和维护本身的内部代理管理基础设施的状况下规模抓取就已经很耗资源了。

大多数大型电子商务公司都采用这种作法。一些全球最大型的电子商务网站采用Scrapinghub 开发的智能下载器Crawlera，这个东西的代理管理彻底是外包的。当你的爬虫天天要发出2000万条请求时，把注意力放在分析数据而不是管理代理上会有意义得多。

代理之外

不幸的是，光靠使用代理服务并不足以确保你能规避大型电子商务网站的反机器人对策。愈来愈多的网站正在利用复杂的反机器人对策来监控你的爬虫行为，检测其是否真人访客。

这些范机器人对策不只使得爬取电子商务网站愈来愈困难，并且克服这些手段若是作得不对的话也会严重拖累爬虫性能。

这些机器人对策有很大一部分使用到了JavaScript来肯定请求是否来自于爬虫仍是人（Javascript引擎检查、字体枚举、WebGL与Canvas等）。

不过正如前面所述，规模爬取时你但愿限制可编写脚本的无界面浏览器（Splash 或者Puppeteer等）的使用，由于渲染页面的任何JavaScript都很是耗资源而且放慢爬取网站的速度。

这意味着为了确保你能取得必要的吞吐量让爬虫提交天天的产品数据，你每每须要痛苦地对目标网站采用的反机器人对策进行逆向工程，而且在不使用无界面浏览器的状况下设计你的爬虫抵消那些对策。

挑战 5：数据质量

从数据科学家的角度来讲，任何网站爬取项目最重要的考虑是析取数据的质量。规模爬取只会令这一关注变得更加剧要。

当天天都要析取数百万数据点时，想靠人工来验证数据是否干净和完整是不可能的。变脏或者不完整的数据很容易就会流入到你的数据流里面，进而破坏了数据分析的效果。

尤为是在抓取同一个的不一样版本（不一样的语言、地区等）或者不一样商店上的产品时更是如此。

在爬虫开发的设计阶段，须要进行仔细的QA流程，爬虫代码要通过同行评审和测试以确保用最可靠的方式析取到想要的数据。确保最高数据质量的最好的办法是部署一套自动化QA监控系统。

做为任何数据析取项目的一部分，你须要计划和开发一套监控系统，这套系统将提醒你任何不一致的数据以及发生的爬虫错误。Scrapinghub开发了一个机器学习算法来检测：

• 数据验证错误——每个数据项都有定义好的遵循一致模式的数据类型和值。咱们的数据验证算法会提醒项目的QA团队任何与预期数据类型不一致的数据项，而后再进行人工检查、提醒已验证或者标记为错误。
• 产品差别化错误——从同一网站的多个版本（不一样语言、地区）爬取相同产品数据时，有可能变量或者像产品重量或者尺寸这样本该是固定值的数据项也会不同。这多是网站反机器人对策向你的一到多个爬虫提供篡改信息的结果。再次地，你须要算法来识别和标记相似这样的状况。
• 基于数量的不一致性——另外一个关键的监控脚本是检测返回记录的任何异常变化。这可能预示网站已经作出改变或者你的爬虫被提供了篡改的信息。
• 网站变化——目标网站发生的结构性改变是爬虫失效的主要缘由。咱们的专用监控系统会监控到这一点。该工具会对目标网站进行频繁的检查，确保自从上次抓取以后没有发生任何变化。若是改变被发现，它也会发出通知。

总结

正如你所看到那样，规模抓取产品数据会面临一系列的独特挑战。但愿这篇文章可以让你更加意识到相关挑战，而且就如何解决这些问题得到启发。

原文连接：https://baijiahao.baidu.com/s?id=1606482126832777393&wfr=spider&for=pc

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

好文章拿来读一读。编辑：不良将。