python多线程爬取世纪佳缘女生资料并简单数据分析
一. 目标
作为一只万年单身狗,一直很好奇女生找对象的时候都在想啥呢,这事也不好意思直接问身边的女生,不然别人还以为你要跟她表白啥的,况且工科出身的自己本来接触的女生就少,即使是挨个问遍,样本量也太少,毕竟每个人的标准都会有差异的。这时候想到婚恋网站,上面不就有现成的数据吗,刚好最近也在学习爬虫,如果能用爬虫把数据爬取下来,既练习了爬虫技术,又获得了想要的数据,一举两得。不如说干就干。
从接触爬虫以来,也爬过几十个网站,虽说是入门练习,没找那种数据价值很高,反爬比较严重的网站,但也有不少数据价值不错的网站,比如豆瓣电影,简书,汽车之家,房天下等,这些网站基本上也没动用什么高级一点的反爬技术,然而,在爬取世纪佳缘的时候就有点坑了,整个网站页面大部分都是js渲染出来的,而且ajax数据请求接口还挖空心思地给你玩声东击西手段,我寻思着这网站数据价值也不至于那么大,这么藏着掖着,要么是后台开发小哥闲着没事在修炼反爬仙丹,要么是事出反常必有妖,由于之前注册了个三无账号,资料都是乱写的,居然也会收到大量需要花钱才能看到的情书,所以猜测这数据之中怕是藏着什么猫腻,于是乎,除了抓取女生资料外,又多了个目标:看看数据中藏了什么秘密。
!
![](https://img2018.cnblogs.com/blog/1653958/201908/1653958-20190812232513137-1304508707.png)
二. 网页分析
在世纪佳缘主页,有个搜索入口,可以根据条件搜索女生数据。本次选取的是湖南省年龄在20-35岁,身高153-170cm的女生为爬取对象。
![](https://img2018.cnblogs.com/blog/1653958/201908/1653958-20190812232550376-771151536.png)
条件设置好以后,点击确定就可以看到发送了一条带有搜索条件参数的get请求
然而,当你以为这就能获取到搜索结果,那就大错特错了,这个请求只是一个障眼法。
以下是一大段废话,是我寻找真实请求接口的时候爬过的坑,在这里记录一下,直接看结果请跳到这里
我们用requests发送一个同样的请求试试,看看返回来的是啥
import requests
URL = "http://search.jiayuan.com/v2/index.php?key=&sex=f&stc=1:43,2:20.35,3:153.170,23:1&sn=default&sv=1&p=1&pt=864&ft=off&f=select&mt=u"
HEADERS = {
"User-Agent": "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36"
}
resp = requests.get(URL, headers=HEADERS)
with open("search.html", "w", encoding="utf8") as fp:
fp.write(resp.content.decode())
我们把返回结果保存在search.html文件中,在浏览器中打开这个html文件
![](https://img2018.cnblogs.com/blog/1653958/201908/1653958-20190812233630188-129687522.png)
可以看到并没有返回我们想要的搜索结果的数据,这个页面停留几秒钟之后会弹出一个登录框,起先以为是需要登陆才能返回搜索结果,于是把cookie加上,但是仍然返回同样的结果。事实上,这个请求除了返回一些页面通用的HTML代码外,还返回一些css文件和js文件,其中有个js文件中定义了判断是否登录的函数
![](https://img2018.cnblogs.com/blog/1653958/201908/1653958-20190812233704651-1771344595.png)
判断是否登录的大概思路是:在登陆页面输入账号密码登陆后,后台会告诉浏览器端设置一个名为PROFILE的cookie,所以判断是否登录就只需要通过js去获取这个cookie是否存在,如果存在则说明登陆过,不存在则说明没登陆。由于我们是通过requests发送的请求,直接把登陆后的cookie发送给后台服务器,虽然服务器端知道我们登陆了,但是返回来的js再次检查浏览器端的cookie时,并没有发现这个cookie(因为没有在浏览器设置)所以就不会进行后续的操作了,比如发送ajax请求获取用户信息等。
其实上面只是简单描述一下登陆检查思路,实际上世纪佳缘的登陆判断并没有这么简单,其中涉及到很多的js文件,而且这些文件相当一部分是通过document.write()的方式写入的,所以很多代码都很隐蔽,但是登陆检测不是我们的重点,我们只需要知道通过直接发送上述的get请求是获取不到我们想要的搜索结果的。
场面一度陷入了尴尬。。。
既然数据不是通过get直接返回的,数据总得有个返回方式吧,我猜肯定是js检测到用户登陆后,接着通过发送ajax请求获取到,然后再渲染到网页上的。那么接口在哪里呢?这时候首先想到的当然是抓包分析,大不了把所有请求都挨个分析一遍,肯定能揪出来。
打开fidller,把所有可疑请求挨个分析了一遍,依然没有找到我要的数据。可怕,居然能绕过抓包软件!!我虽然知道这是不大可能的事,但是此刻思维已经受到创伤。场面再次陷入尴尬。。。
既然抓包不行,那就硬着头皮再去读js源码吧,刚好是个机会来提升一下JavaScript功力。
从哪里读起呢?既然我想要知道搜索结果怎么获取的,那就先看看js是如何把搜索结果渲染出来的吧,或许从这里可以找到数据的源头。按F12,点到element栏,找到放搜索结果的div容器,然后在该元素设置一个断点,使该元素下的子元素被修改时程序运行终止(即当js试图往这个div容器渲染搜索结果列表的时候,程序中断):
![](https://img2018.cnblogs.com/blog/1653958/201908/1653958-20190812232828698-1465223187.png)
刷新网页,可以看到程序中断在jQuery.js文件中,点击运行按钮运行几步后,就进入了index_v2.js,再运行十几步后,我发现渲染出来第一条搜索结果,并且多次点击运行按钮后,有一个函数反复出现,有戏!
![](https://img2018.cnblogs.com/blog/1653958/201908/1653958-20190812232858960-925275337.png)
好了,知道了js是如何渲染搜索结果的,我们的目的还没达到,即数据是怎么请求到的。我推测既然数据是在这个js文件中渲染的,那么数据也应该是在同一个文件中获取洛,而且一般都是通过ajax方式获取,所以抱着试一试的 心态,我在这个js文件下按下ctr+f进行搜索,然后输入ajax,果然,出现了18条结果,其中第一条结果十分可疑
![](https://img2018.cnblogs.com/blog/1653958/201908/1653958-20190812232932360-261527271.png)
于是在ajax中的success的函数中设置一个断点,想看看返回response是什么,惊奇地发现,果然是我想要的数据,看来接口找到了。这不就是一个普通的ajax请求吗,赶紧再次用fidller抓包看看是不是我眼瞎漏掉了这个请求,果不其然,这个请求是抓到了的,此时想抠掉自己的双眼。。。哎,粗心导致浪费了大量时间,不过,分析js的过程中,还是学了不少新知识。
好了,找到了真正的数据请求接口,下面就来分析一下这个请求和服务器有哪些数据交互,先看向服务器发送了啥,点击WebForm看看post表单数据:
再来看看服务返回了啥:
返回结果中可以看到count、pagetotal、realuid等字眼,分别表示搜索结果的总条数、总页面数、用户id号,其中用户id号就是我们下文要用到的构造用户详情页url的材料。在每条用户信息中我们还可以看到年龄,身高,教育程度等信息,但是这些信息不是我们需要的,除了搜索结果总条数,总页面数外,我们需要的只有用户id,有了用户id就可以构造详情页url,在详情页里面也有这些信息,到时候再去统一获取。这里可以看到返回21792条用户数据,但是这么多用户数据不是一次返回的,而是按页返回的,每页返回23条,所以我们需要一页一页的爬取这些用户的id号。
三. 开始爬虫
本次使用的是requests库+多线程的方式,python多线程在多核CPU下被说成是鸡肋,不过在爬虫这种I/O密集型的应用场合还是有用武之地的,我们把爬取结果以多行json数据的形式保存在文件中。
我们先来整理一下爬虫思路,上面通过向服务器发送post请求,获取了每页的用户id号,也知道了页面总数和用户总数,因此,可以构造两个爬虫,一个爬取所有页面的用户id号,保存在一个队列里面,另一个从队列里面取出id号构造详情页url,然后爬取详情页并解析我们需要的数据。
第一次开启爬虫的时候,开了10个线程,可能是爬的太快了,导致ip被封了,于是花了10块钱从淘宝上买了10个代理,添加到列表里面,每次发送请求的时候从列表中随机选一个代理,另外,程序会去捕获ConnectionError,如果出现这个错误,就说明这个代理不可用了,从而需要把它从列表中移除。
-
爬取所有用户id
这个就很容易了,先构造一个CrawlGirlId类,这个类继承threading.Thread,开启这个爬虫后,直接向服务器发送post表单数据,只要每次修改其中的页码参数就ok了,先上代码
class CrawlGirlId(threading.Thread):
session = None
user_id_queue = None
page_queue = Queue()
POST_SEARCH_URL = "http://search.jiayuan.com/v2/search_v2.php"
def __init__(self, formdata):
super(CrawlGirlId, self).__init__()
self.formdata = formdata.copy() # 浅复制,因为每个线程都需要修改formdata["p"],如果共享同一个的话会出乱子
def run(self):
global craw_pages_finished
while True:
try:
page = str(self.page_queue.get(False)) # false,在队列为空时产生Empty异常
self.formdata["p"] = page
except Empty:
craw_pages_finished = True # 爬取所有页面的id号结束
print("craw pages finished: %s" % threading.current_thread())
break
else:
proxy = random.choice(proxies)
try:
page_resp = self.session.post_str(url=self.POST_SEARCH_URL, data=self.formdata, proxies=proxy)
except ConnectionError:
with global_lock:
proxies.remove(proxy) # 说明这个代理无效或被封,移除
else:
self.parse_girl_id(page_resp)
time.sleep(0.5)
def parse_girl_id(self, page_resp):
ret = re.sub(r"##jiayser##/{0,2}", "", page_resp)
ret_dict = json.loads(ret)
userinfo = ret_dict["userInfo"]
for i in range(0, len(userinfo)):
uid = userinfo[i]["realUid"]
self.uid_queue.put(uid) # block 默认为True,即如果队列满了则阻塞至队列有空位
@classmethod
def init_spider(cls, session, formdata, uid_queue):
cls.uid_queue = uid_queue
cls.session = session
while True:
if cls.get_first_page(formdata):
break
@classmethod
def get_first_page(cls, formdata):
formdata["p"] = "1"
proxy = random.choice(proxies)
try:
resp = cls.session.post_str(url=cls.POST_SEARCH_URL, data=formdata, proxies=proxy)
except ConnectionError:
with global_lock:
proxies.remove(proxy) # 说明这个代理无效或被封,移除
return False
else:
ret = re.sub(r"##jiayser##/{0,2}", "", resp)
ret_dict = json.loads(ret)
userinfo = ret_dict["userInfo"]
for i in range(1, len(userinfo)): # 第一个是本人信息,剔除
uid = userinfo[i]["realUid"]
cls.uid_queue.put(uid) # block 默认为True,即如果队列满了则阻塞至队列有空位
page_total = int(ret_dict["pageTotal"]) - 5 # 减去5是防止页面总数在爬取过程中减少,所以这个值动态获取其实更好
count = ret_dict["count"]
print("page_total: %s, count: %s" % (page_total, count))
for page in range(2, page_total): # 从第二页开始,第一页已经获取了
cls.page_queue.put(page)
return True
这个代码看起来有点长,但是逻辑很简单,之所以长是因为最后面的那个get_first_page函数,这个函数的作用也很简单,就是解析第一页的内容(即第一次post请求返回的数据),第一页单独处理,首先是因为第一页的第一个用户其实返回的是本人的信息,这个是不需要爬取的,所以第一页需要把第一条信息剔除,我觉得这个剔除的逻辑单独挑出来写比较好一点,其次是因为我们需要知道总页面是多少,才能知道爬虫爬到那一页就要停止,这是首先需要解决的问题,所以这两个逻辑放在一起就形成了get_first_page函数。get_first_page函数是在init_spider函数中调用的,这个函数其实就是类的初始化,因为这个类的实例会共享一些变量,所以把这些设置为类变量,并在该函数中初始化。
其余代码都很好理解了,把每页的用户id都保存到一个队列中。
-
爬取详情页
点开一个详情页,就可以知道用户详情页的url格式为域名+用户id+一个固定参数。这个就很好办了,用户id在上面已经获取了,只需要字符串拼接一下就很容易得出详情页url了。
同样是构建一个类CrawlDetailPage,继承自threading.Thread
class CrawlDetailPage(threading.Thread): DETAIL_URL = "http://www.jiayuan.com/%s?fxly=search_v2" lock = threading.Lock() error_lock = threading.Lock() def __init__(self, user_id_queque, session, f, t_name): super(CrawlDetailPage, self).__init__(name=t_name) self.user_id_queque = user_id_queque # 往url队列贴了个标签而已,实际上并不会新建一个队列,所以内存占用不会增加 self.session = session self.fp = f self.item = {} def run(self): global craw_finished while not craw_finished: try: user_id = self.user_id_queque.get(True, timeout=0.5) except Empty: if craw_pages_finished: craw_finished = True print("id empty: %s" % threading.current_thread()) else: print("%s 正在爬取id=%s小姐姐资料" % (threading.current_thread(), user_id)) detail_url = self.DETAIL_URL % user_id proxy = random.choice(proxies) try: resp = self.session.get_str(url=detail_url, proxies=proxy) except ConnectionError: with global_lock: proxies.remove(proxy) # 说明这个代理无效或被封,移除 else: self.item = { "user_id": user_id, } self.parse_detail(resp) time.sleep(0.5) # print("id=%s小姐姐资料爬取完毕" % user_id) print("exit craw: %s" % threading.current_thread()) def parse_detail(self, resp): try: html_element = etree.HTML(resp) # 解析网页代码 member_main_info = html_element.xpath("//div[@class='member_info_r yh']")[0] nickname = member_main_info.xpath("//div[@class='member_info_r yh']/h4/text()")[0] main_info = member_main_info.xpath("//div[@class='member_info_r yh']/h6/text()")[0] age = main_info.split("岁")[0] marriage = main_info.split(",")[1] # 注意这里是中文的逗号 base_info = member_main_info.xpath("//div[@class='member_info_r yh']//div[@class='fl pr']//text()") degree = base_info[1] height = base_info[4] # cars = base_info[7] salary = base_info[10] house = base_info[13] weight = base_info[16] # nation = base_info[22] other_info = html_element.xpath("//div[@class='content_705']/div[9]")[0] hometown = other_info.xpath(".//ul[1]/li[1]/div//text()")[0] requirment = html_element.xpath("//div[@class='content_705']/div[5]//li//div/text()") age_boy = requirment[0] height_boy = requirment[1] degree_boy = requirment[3] marriage_boy = requirment[5] hometown_boy = requirment[6] item_info = { "nickname": nickname, "age": age, "marriage": marriage, "degree": degree, "height": height, # "cars": cars, "salary": salary, "house": house, "weight": weight, # "nation": nation, "hometown": hometown, "age_boy": age_boy, "height_boy": height_boy, "degree_boy": degree_boy, "marriage_boy": marriage_boy, "hometown_boy": hometown_boy, } self.item.update(item_info) with self.lock: self.fp.write((json.dumps(self.item, ensure_ascii=False) + "\n")) except Exception as e: # 记录错误信息 with self.error_lock: with open("error.txt", "a", encoding="utf8") as fp: fp.write(str(e) + "\r\n" + resp + "\r\n\r\n")
逻辑也很简单粗暴,run方法里面从用户id队列(user_id_queque)中取一个id出来,构造详情页url,然后随机选取一个代理,发送post请求即可获得详情页面,parse_detail函数就是解析要想的数据然后写入文件了,这没啥好说的。
-
开启多线程爬虫
上面构建了两个爬虫,第一个爬取id的爬虫一次就能解析出二十多个id,第二个爬虫一次只能爬取一个详情页,所以第一个爬虫开启一个线程就够用了,第二个爬虫我开了10个线程,总共爬下来花了66分钟,一共爬了1.8w+条小姐姐信息,不过看起来这么多,其中就有很大的猫腻,这个后面再来看。
由于后面数据简单分析是用的jupyter notebook,这里不方便贴代码,所以就把爬虫代码和数据分析代码一起放到了GitHub上。
四. 简单数据分析
数据拿到了,终于可以窥探小姐姐的小秘密了,激动的我赶紧把近两万行数据整体从上到下滑了一遍,不滑不知道,一滑下一跳,刚开始滑动的时候,小姐姐的昵称长长短短看得眼花缭乱,越到后面越不对劲,咋的总有几个相同的影子在眼睛里晃来晃去,仔细一看,不得了,原来存在大量相同的昵称,而且id号和其他信息都一样,这明显是重复的数据
![](https://img2018.cnblogs.com/blog/1653958/201908/1653958-20190812233135282-2057506792.png)
难道是程序重复爬取了?这应当不应该啊,所有需要爬取的页面都是放在同一个队列之中,是用循环生成的从第一页到最后一页的独一无二的整数,从队列中弹出后就应该没有了,所以应该不至于一个页面被重复爬取,那要么就是不同页面存在相同的用户id,于是在浏览器中一直翻到一百多页,果然发现大量重复的信息。
-
数据读取和去重
知道了数据造假后,我想知道到底有多少是不重复的,于是打开jupyter notebook,用pandas去一下重就知道了,把这近2w的数据按行读到一个列表中,然后构造出DataFrame对象,再统计一下数据总数
![](https://img2018.cnblogs.com/blog/1653958/201908/1653958-20190812233202945-57091032.png)
总数18451,没毛病
去重后
居然2w变成2k,造假了近10倍,一个全国闻名的婚恋网站居然玩这种把戏!可怕!
-
简单分析女生对男生最低身高要求与自身身高的关系
我们都知道女生很看重男生身高,所以我比较好奇,女生对男生预期的最低身高要求与女生自身身高有什么关系呢?于是我把女生对男生最低身高要求提取出来单独为一列,并把女生从低到高排序后然后按女生身高group一下,这样就能获取到女生每个身高段对应的所有的预期男生最低身高值(比如所有162cm的女生,要求的男生最低身高组成一个集合),求出女生每个身高段预期男生最低身高的平均值和中位值,以女生身高为横坐标,女生预期的男生最低身高值为纵坐标,画图如下:
绿色代表女生自身身高值,可以看到身高越是低的女生,对身高差越有要求,但是一般也在12cm左右,这是不是证明了网传的12cm最佳身高差的说法是有一定市场的。女生越高,对身高差就没那么大要求了。
好了,写了一天终于完工了。
爬虫和jupyter代码都放在GitHub: