1)首先你要明白爬虫怎样工作。
专业领域包括成都网站制作、成都网站建设、商城开发、微信营销、系统平台开发, 与其他网站设计及系统开发公司不同,创新互联公司的整合解决方案结合了帮做网络品牌建设经验和互联网整合营销的理念,并将策略和执行紧密结合,为客户提供全网互联网整合方案。
想象你是一只蜘蛛,现在你被放到了互联“网”上。那么,你需要把所有的网页都看一遍。怎么办呢?没问题呀,你就随便从某个地方开始,比如说人民日报的首页,这个叫initial pages,用$表示吧。
在人民日报的首页,你看到那个页面引向的各种链接。于是你很开心地从爬到了“国内新闻”那个页面。太好了,这样你就已经爬完了俩页面(首页和国内新闻)!暂且不用管爬下来的页面怎么处理的,你就想象你把这个页面完完整整抄成了个html放到了你身上。
突然你发现, 在国内新闻这个页面上,有一个链接链回“首页”。作为一只聪明的蜘蛛,你肯定知道你不用爬回去的吧,因为你已经看过了啊。所以,你需要用你的脑子,存下你已经看过的页面地址。这样,每次看到一个可能需要爬的新链接,你就先查查你脑子里是不是已经去过这个页面地址。如果去过,那就别去了。
好的,理论上如果所有的页面可以从initial page达到的话,那么可以证明你一定可以爬完所有的网页。
那么在python里怎么实现呢?
很简单
import Queue
initial_page = "初始化页"
url_queue = Queue.Queue()
seen = set()
seen.insert(initial_page)
url_queue.put(initial_page)
while(True): #一直进行直到海枯石烂
if url_queue.size()0:
current_url = url_queue.get() #拿出队例中第一个的url
store(current_url) #把这个url代表的网页存储好
for next_url in extract_urls(current_url): #提取把这个url里链向的url
if next_url not in seen:
seen.put(next_url)
url_queue.put(next_url)
else:
break
写得已经很伪代码了。
所有的爬虫的backbone都在这里,下面分析一下为什么爬虫事实上是个非常复杂的东西——搜索引擎公司通常有一整个团队来维护和开发。
2)效率
如果你直接加工一下上面的代码直接运行的话,你需要一整年才能爬下整个豆瓣的内容。更别说Google这样的搜索引擎需要爬下全网的内容了。
问题出在哪呢?需要爬的网页实在太多太多了,而上面的代码太慢太慢了。设想全网有N个网站,那么分析一下判重的复杂度就是N*log(N),因为所有网页要遍历一次,而每次判重用set的话需要log(N)的复杂度。OK,OK,我知道python的set实现是hash——不过这样还是太慢了,至少内存使用效率不高。
通常的判重做法是怎样呢?Bloom Filter. 简单讲它仍然是一种hash的方法,但是它的特点是,它可以使用固定的内存(不随url的数量而增长)以O(1)的效率判定url是否已经在set中。可惜天下没有白吃的午餐,它的唯一问题在于,如果这个url不在set中,BF可以100%确定这个url没有看过。但是如果这个url在set中,它会告诉你:这个url应该已经出现过,不过我有2%的不确定性。注意这里的不确定性在你分配的内存足够大的时候,可以变得很小很少。一个简单的教程:Bloom Filters by Example
注意到这个特点,url如果被看过,那么可能以小概率重复看一看(没关系,多看看不会累死)。但是如果没被看过,一定会被看一下(这个很重要,不然我们就要漏掉一些网页了!)。 [IMPORTANT: 此段有问题,请暂时略过]
好,现在已经接近处理判重最快的方法了。另外一个瓶颈——你只有一台机器。不管你的带宽有多大,只要你的机器下载网页的速度是瓶颈的话,那么你只有加快这个速度。用一台机子不够的话——用很多台吧!当然,我们假设每台机子都已经进了最大的效率——使用多线程(python的话,多进程吧)。
3)集群化抓取
爬取豆瓣的时候,我总共用了100多台机器昼夜不停地运行了一个月。想象如果只用一台机子你就得运行100个月了...
那么,假设你现在有100台机器可以用,怎么用python实现一个分布式的爬取算法呢?
我们把这100台中的99台运算能力较小的机器叫作slave,另外一台较大的机器叫作master,那么回顾上面代码中的url_queue,如果我们能把这个queue放到这台master机器上,所有的slave都可以通过网络跟master联通,每当一个slave完成下载一个网页,就向master请求一个新的网页来抓取。而每次slave新抓到一个网页,就把这个网页上所有的链接送到master的queue里去。同样,bloom filter也放到master上,但是现在master只发送确定没有被访问过的url给slave。Bloom Filter放到master的内存里,而被访问过的url放到运行在master上的Redis里,这样保证所有操作都是O(1)。(至少平摊是O(1),Redis的访问效率见:LINSERT – Redis)
考虑如何用python实现:
在各台slave上装好scrapy,那么各台机子就变成了一台有抓取能力的slave,在master上装好Redis和rq用作分布式队列。
代码于是写成
#slave.py
current_url = request_from_master()
to_send = []
for next_url in extract_urls(current_url):
to_send.append(next_url)
store(current_url);
send_to_master(to_send)
#master.py
distributed_queue = DistributedQueue()
bf = BloomFilter()
initial_pages = ""
while(True):
if request == 'GET':
if distributed_queue.size()0:
send(distributed_queue.get())
else:
break
elif request == 'POST':
bf.put(request.url)
好的,其实你能想到,有人已经给你写好了你需要的:darkrho/scrapy-redis · GitHub
4)展望及后处理
虽然上面用很多“简单”,但是真正要实现一个商业规模可用的爬虫并不是一件容易的事。上面的代码用来爬一个整体的网站几乎没有太大的问题。
但是如果附加上你需要这些后续处理,比如
有效地存储(数据库应该怎样安排)
有效地判重(这里指网页判重,咱可不想把人民日报和抄袭它的大民日报都爬一遍)
有效地信息抽取(比如怎么样抽取出网页上所有的地址抽取出来,“朝阳区奋进路中华道”),搜索引擎通常不需要存储所有的信息,比如图片我存来干嘛...
及时更新(预测这个网页多久会更新一次)
如你所想,这里每一个点都可以供很多研究者十数年的研究。虽然如此,
“路漫漫其修远兮,吾将上下而求索”。
所以,不要问怎么入门,直接上路就好了:)
知乎现在登录貌似每次都会有密码了,修改如下:
import requests
from xtls.util import BeautifulSoup
INDEX_URL = 'xxx
LOGIN_URL = 'xxx'
CAPTCHA_URL = 'xxx'
def gen_time_stamp():
return str(int(time.time())) + '%03d' % random.randint(0, 999)
def login(username, password, oncaptcha):
session = requests.session()
_xsrf = BeautifulSoup(session.get(INDEX_URL).content).find('input', attrs={'name': '_xsrf'})['value']
data = {
'_xsrf': _xsrf,
'email': username,
'password': password,
'remember_me': 'true',
'captcha': oncaptcha(session.get(CAPTCHA_URL + gen_time_stamp()).content)
}
resp = session.post(LOGIN_URL, data)
if 2 != resp.status_code / 100 or u"登陆成功" not in resp.content:
raise Exception('captcha error.')
return session
其中,oncaptcha为一个回调函数(需要自己实现的),接受的参数为验证码的二进制内容,返回的为验证码内容。
P.S.你可以自己做识别验证码,或者手动输入,其中最简单的oncaptcha为:
def oncaptcha(data):
with open('captcha file save path', 'wb') as fp:
fp.write(data)
return raw_input('captcha : ')
先检查是否有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都可以用来建表、整理数据,结合起来使用效率更高。