爬虫是一个相对来说比较容易上手的技术，也许你画个几分钟就可以将一整个网页上的数据得到，但是如果对于大规模的爬虫就是另外一回事了，这个并不是1*n的问题这么简单的，在这里面还会产生很多别的问题。
这是一个大规模爬虫的流程图：
先检查是否有API：
API是网站官方提供的数据接口，如果通过调用API采集数据，则相当于在网站允许的范围内采集，这样既不会有道德法律风险，也没有网站故意设置的障碍；不过调用API接口的访问则处于网站的控制中，网站可以用来收费，可以用来限制访问上限等。整体来看，如果数据采集的需求并不是很独特，那么有API则应优先采用调用API的方式。
数据结构的分析和存储：
爬虫需求要十分清晰，具体表现为需要哪些字段，这些字段可以是网页上现有的，也可以是根据网页上现有的字段进一步计算的，这些字段如何构建表，多张表如何连接等。值得一提的是，确定字段环节，不要只看少量的网页，因为单个网页可以缺少别的同类网页的字段，这既有可能是由于网站的问题，也可能是用户行为的差异，只有多观察一些网页才能综合抽象出具有普适性的关键字段——这并不是几分钟看几个网页就可以决定的简单事情，如果遇上了那种臃肿、混乱的网站，可能坑非常多。
对于大规模爬虫，除了本身要采集的数据外，其他重要的中间数据（比如页面Id或者url）也建议存储下来，这样可以不必每次重新爬取id。
数据库并没有固定的选择，本质仍是将Python里的数据写到库里，可以选择关系型数据库MySQL等，也可以选择非关系型数据库MongoDB等；对于普通的结构化数据一般存在关系型数据库即可。sqlalchemy是一个成熟好用的数据库连接框架，其引擎可与Pandas配套使用，把数据处理和数据存储连接起来，一气呵成。
数据流的分析：
对于要批量爬取的网页，往上一层，看它的入口在哪里；这个是根据采集范围来确定入口，比如若只想爬一个地区的数据，那从该地区的主页切入即可；但若想爬全国数据，则应更往上一层，从全国的入口切入。一般的网站网页都以树状结构为主，找到切入点作为根节点一层层往里进入即可。
值得注意的一点是，一般网站都不会直接把全量的数据做成列表给你一页页往下翻直到遍历完数据，比如链家上面很清楚地写着有24587套二手房，但是它只给100页，每页30个，如果直接这么切入只能访问3000个，远远低于真实数据量；因此先切片，再整合的数据思维可以获得更大的数据量。显然100页是系统设定，只要超过300个就只显示100页，因此可以通过其他的筛选条件不断细分，只到筛选结果小于等于300页就表示该条件下没有缺漏；最后把各种条件下的筛选结果集合在一起，就能够尽可能地还原真实数据量。
明确了大规模爬虫的数据流动机制，下一步就是针对单个网页进行解析，然后把这个模式复制到整体。对于单个网页，采用抓包工具可以查看它的请求方式，是get还是post，有没有提交表单，欲采集的数据是写入源代码里还是通过AJAX调用JSON数据。
同样的道理，不能只看一个页面，要观察多个页面，因为批量爬虫要弄清这些大量页面url以及参数的规律，以便可以自动构造；有的网站的url以及关键参数是加密的，这样就悲剧了，不能靠着明显的逻辑直接构造，这种情况下要批量爬虫，要么找到它加密的js代码，在爬虫代码上加入从明文到密码的加密过程；要么采用下文所述的模拟浏览器的方式。
数据的采集：
之前用R做爬虫，不要笑，R的确可以做爬虫工作；但在爬虫方面，Python显然优势更明显，受众更广，这得益于其成熟的爬虫框架，以及其他的在计算机系统上更好的性能。scrapy是一个成熟的爬虫框架，直接往里套用就好，比较适合新手学习；requests是一个比原生的urllib包更简洁强大的包，适合作定制化的爬虫功能。requests主要提供一个基本访问功能，把网页的源代码给download下来。一般而言，只要加上跟浏览器同样的Requests Headers参数，就可以正常访问，status_code为200，并成功得到网页源代码；但是也有某些反爬虫较为严格的网站，这么直接访问会被禁止；或者说status为200也不会返回正常的网页源码，而是要求写验证码的js脚本等。
下载到了源码之后，如果数据就在源码中，这种情况是最简单的，这就表示已经成功获取到了数据，剩下的无非就是数据提取、清洗、入库。但若网页上有，然而源代码里没有的，就表示数据写在其他地方，一般而言是通过AJAX异步加载JSON数据，从XHR中找即可找到；如果这样还找不到，那就需要去解析js脚本了。
解析工具：
源码下载后，就是解析数据了，常用的有两种方法，一种是用BeautifulSoup对树状HTML进行解析，另一种是通过正则表达式从文本中抽取数据。
BeautifulSoup比较简单，支持Xpath和CSSSelector两种途径，而且像Chrome这类浏览器一般都已经把各个结点的Xpath或者CSSSelector标记好了，直接复制即可。以CSSSelector为例，可以选择tag、id、class等多种方式进行定位选择，如果有id建议选id，因为根据HTML语法，一个id只能绑定一个标签。
正则表达式很强大，但构造起来有点复杂，需要专门去学习。因为下载下来的源码格式就是字符串，所以正则表达式可以大显身手，而且处理速度很快。
对于HTML结构固定，即同样的字段处tag、id和class名称都相同，采用BeautifulSoup解析是一种简单高效的方案，但有的网站混乱，同样的数据在不同页面间HTML结构不同，这种情况下BeautifulSoup就不太好使；如果数据本身格式固定，则用正则表达式更方便。比如以下的例子，这两个都是深圳地区某个地方的经度，但一个页面的class是long，一个页面的class是longitude，根据class来选择就没办法同时满足2个，但只要注意到深圳地区的经度都是介于113到114之间的浮点数，就可以通过正则表达式"11[3-4].d+"来使两个都满足。
数据整理：
一般而言，爬下来的原始数据都不是清洁的，所以在入库前要先整理；由于大部分都是字符串，所以主要也就是字符串的处理方式了。
字符串自带的方法可以满足大部分简单的处理需求，比如strip()可以去掉首尾不需要的字符或者换行符等，replace()可以将指定部分替换成需要的部分，split()可以在指定部分分割然后截取一部分。
如果字符串处理的需求太复杂以致常规的字符串处理方法不好解决，那就要请出正则表达式这个大杀器。 Pandas是Python中常用的数据处理模块，虽然作为一个从R转过来的人一直觉得这个模仿R的包实在是太难用了。Pandas不仅可以进行向量化处理、筛选、分组、计算，还能够整合成DataFrame，将采集的数据整合成一张表，呈现最终的存储效果。
写入数据库：
如果只是中小规模的爬虫，可以把最后的爬虫结果汇合成一张表，最后导出成一张表格以便后续使用；但对于表数量多、单张表容量大的大规模爬虫，再导出成一堆零散的表就不合适了，肯定还是要放在数据库中，既方便存储，也方便进一步整理。
写入数据库有两种方法，一种是通过Pandas的DataFrame自带的to_sql()方法，好处是自动建表，对于对表结构没有严格要求的情况下可以采用这种方式，不过值得一提的是，如果是多行的DataFrame可以直接插入不加索引，但若只有一行就要加索引否则报错，虽然这个认为不太合理；另一种是利用数据库引擎来执行SQL语句，这种情况下要先自己建表，虽然多了一步，但是表结构完全是自己控制之下。Pandas与SQL都可以用来建表、整理数据，结合起来使用效率更高。
写入数据库有两种思路，一种是等所有的数据都爬完，集中一次向量化清洗，一次性入库；另一种是爬一次数据清洗一次就入库。表面上看前者效率更高，但是对于大规模爬虫，稳定性也是要考虑的重要因素，因为在长久的爬虫过程中，总不可避免会出现一些网络错误，甚至如果出现断网断电的情况，第一种情况下就全白费了，第二种情况下至少已入库的不会受影响，并且单次的清洗和入库是很快的，基本不怎么费时间，所以整体来看推荐第二种思路。
提升爬虫的效率：
对于大规模爬虫，效率是一个核心问题。单个网页爬取可能很大，一旦网页数量级大增之后，任务量也会大增，同时方式下的耗时也会大增。没有公司或人个愿意爬个几十万上百万的页面还要等几个月，因此优化流程、提高效率是非常必要的。
尽量减少访问次数。单次爬虫的主要耗时在于网络请求等待响应，所以能减少访问就少访问，既减少自己的工作量，也减轻网站的压力，还降低被封的风险。首先要做的就是流程优化，尽可能精简流程，一些数据如果可以在一个页面内获取而不必非要在多个页面下获取，那就只在一个页面内获取。然后去重也是非常重要的手段——网站并不是严格意义的互不交叉的树状结构，而是多重交叉的网状结构，所以从多个入口深入的网页会有很多重复，一般根据url或者id进行唯一性判别，爬过的就不再继续爬了。最后，值得深思的一点就是，是不是所有的数据都需要爬？对于那些响应慢，反爬机制很严格的网站，爬少量的都困难，爬大量的时间成本就会高到难以接受，这种情况下怎么办？举一个例子，对于气象数据，已知的一点是时间、空间越接近的地方数据就越接近，那么你爬了一个点的气象数据之后，100米以内的另一个点就可以不用再爬，因为可预期一定是跟之前的点差不多；这个时候就可以采用机器学习的方法，爬取一部分数据作为训练数据，其他的进行预测，当对数据的准确性要求不是特别高，当模型的性能比较好，采用机器学习模型预测就可以省下大部分爬虫的工作。虽然专业的爬虫工程师懂机器学习的可能不多，但这正是复合型人才的优势。
大量爬虫是一个IO阻塞的任务，因此采用多进程、多线程或者协程的并发方式可以有效地提高整理速度。个人推荐用协程，速度比较快，稳定性也比较好。
即使把各种法子都用尽了，单机单位时间内能爬的网页数仍是有限的，面对大量的页面队列，可计算的时间仍是很长，这种时候就必须要用机器换时间了，这就是分布式爬虫。首先，分布式不是爬虫的本质，也不是必须的，对于互相独立、不存在通信的任务就可手动对任务分割，然后在多台机器上分别执行，减少每台机器的工作量，耗时就会成倍减少。比如有100W个页面待爬，可以用5台机器分别爬互不重复的20W个页面，相对单机耗时就缩短了5倍。但是如果存在着需要通信的状况，比如一个变动的待爬队列，每爬一次这个队列就会发生变化，即使分割任务也就有交叉重复，因为各个机器在程序运行时的待爬队列都不一样了——这种情况下只能用分布式，一个Master存储队列，其他多个Slave各自来取，这样共享一个队列，取的时候互斥也不会重复爬取。scrapy-redis是一款用得比较多的分布式爬虫框架。