初始Scrapy

Scrapy 是一个健壮的网络框架，它可以从各种数据源中抓取数据。作为一个普通的网络用户，你会发现自己经常需要从网站上获取数据，使用类似 Excel 的电子表格程序进行浏览（参见第 3 章），以便离线访问数据或者执行计算。而作为一个开发者，你需要经常整合多个数据源的数据，但又十分清楚获得和抽取数据的复杂性。无论难易，Scrapy 都可以帮助你完成数据抽取的行动。

以健壮而又有效的方式抽取大量数据，Scrapy 已经拥有了多年经验。使用 Scrapy，你只需一个简单的设置，就能完成其他爬虫框架中需要很多类、插件和配置项才能完成的工作。快速浏览第 7 章，你就能体会到通过简单的几行配置，Scrapy 可以实现多少功能。

从开发者的角度来说，你也会十分欣赏 Scrapy 的基于事件的架构（我们将在第 8 章和第 9 章中对其进行深入探讨）。它允许我们将数据清洗、格式化、装饰以及将这些数据存储到数据库中等操作级联起来，只要我们操作得当，性能降低就会很小。在本书中，你将学会怎样可以达到这一目的。从技术上讲，由于 Scrapy 是基于事件的，这就能够让我们在拥有上千个打开的连接时，可以通过平稳的操作拆分吞吐量的延迟。来看这样一个极端的例子，假设你需要从一个拥有汇总页的网站中抽取房源，其中每个汇总页包含 100 个房源。Scrapy 可以非常轻松地在该网站中并行执行 16 个请求，假设完成一个请求平均需要花费 1 秒钟的时间，你可以每秒爬取 16 个页面。如果将其与每页的房源数相乘，可以得出每秒将产生 1600 个房源。想象一下，如果每个房源都必须在大规模并行云存储当中执行一次写入，每次写入平均需要耗费 3 秒钟的时间（非常差的主意）。为了支持每秒 16 个请求的吞吐量，就需要我们并行运行 1600 × 3 = 4800 次写入请求（你将在第 9 章中看到很多这样有趣的计算） 。对于一个传统的多线程应用而言，则需要转变为 4800 个线程，无论是对你，还是对操作系统来说，这都会是一个非常糟糕的体验。而在 Scrapy 的世界中，只要操作系统没有问题，4800 个并发请求就能够处理。此外，Scrapy 的内存需求和你需要的房源数据量很接近， 而对于多线程应用而言，则需要为每个线程增加与房源大小相比十分明显的开销。

简而言之，缓慢或不可预测的网站、数据库或远程 API 都不会对 Scrapy 的性能产生毁灭性的结果，因为你可以并行运行多个请求，并通过单一线程来管理它们。这意味着更低的主机托管费用，与其他应用的协作机会，以及相比于传统多线程应用而言更简单的代码（无同步需求） 。