Java+Redis+ES+Kibana对百万用户数据分析‘宝博体育官网登录’

作者：_artoria_http://tinyurl.com/quscxyl1. 前言我是一个真正的知乎小白。上班的时候，自己手头的事情处置惩罚完了，我除了在掘金摸鱼，就是在知乎逛贴。在我的认知中，知乎是一个高质量论坛，基本上种种“疑难杂症”都能在上面找到相应的专业性回覆。但平时停留在知乎的时间过多，我不知道自己是被知乎上面的精彩故事所吸引，还是为知乎上面的高深技术而着迷。

咱是理科生，不太懂过于高深的哲学，自然不会深条理地剖析自己，只能用数据来说话。于是，就有了这篇博客。相关的项目源码放在：https://github.com/zhenye163/spider-zhihu2. 博客结构图博客的结构图如上所示。

这篇博客主要讲述两件事：爬取知乎用户数据和对用户数据举行分析。这个结构图基本能够概述分析知乎用户信息的思路，详细的思路详述和技术实现细节可看博客后面的内容。3. 爬取知乎用户数据3.1 知乎用户页面剖析我的知乎主页信息预览如下：从该页面的内容来看，我当前需要爬取的知乎信息就在两个红框中。

然后每个知乎用户主页对应的URL路径应该纷歧样，这里URL中标识是我的主页就是mi-zhi-saber，这个URL标识就是知乎内里的url_token。也就是说拿到足够多的url_token，就可以自己组装URL来获取用户的信息。通太过析知乎页面结构，我们可以根据如下思路来爬取用户信息：基于用户的小我私家主页信息，爬取、剖析并生存用户信息。

上面用户主页链接对应的页面内容如下：对比这两个页面，可以推断出内里部门字段的意义（其实字段名称已经足够见名知意了）。综合思量后，我要爬取的字段及其意义如下基于用户关注的知乎用户信息，爬取、剖析并生存用户信息。我关注的知乎用户信息页面内容如下：基于关注用户的知乎用户信息，爬取、剖析并生存用户信息。

理论上，选取一个知乎大V作为根节点，迭代爬取关注者和被关注者的信息，可以拿到绝大部门的知乎用户信息。3.2 选取爬虫框架要想对知乎用户举行画像，必须拿到足够多的知乎用户数据。

简朴来说，就是说要用java爬虫爬取足够多的知乎用户数据。工欲善其事，必先利其器。常见的Java爬虫框架有许多如：webmagic,crawler4j,SeimiCrawler,jsoup等等。

这里选用的是SpringBoot + SeimiCrawler，这个方式可以险些零设置地使用爬虫爬取知乎用户数据。详细如何使用可见于SeimiCrawler官方文档，或者参考我的源码。

搜索Java知音民众号，回复“后端面试”，送你一份Java面试题宝典3.3 使用反反爬手段论坛是靠内容存活的。如果有另外一个盗版论坛大量地爬取知乎内容，然后拷贝到自己的论坛上，知乎肯定会流失大量用户。

不用想就知道，知乎肯定是接纳了一些反爬手段的。最常见的反爬手段就是User Agent识别和IP限流。简朴解释一下，就是知乎会基于用户会见记载日志，分析哪个用户（IP）用哪个浏览器（UA）会见知乎网站的，如果某个用户极其频繁地会见知乎网站，知乎就会把该用户标志为“疑似爬虫的机械人”，然后让该用户举行登录验证或直接将该用户对应的IP地址举行封禁。

然后，所谓的“反反爬手段”，就是应对上面所说的反爬手段的。我接纳的“反反爬手段”是：收集一些常用的UA，然后每次挪用接口会见知乎网站的时候会刷新所使用的UA。自己在项目中维护一个可高用的免费署理池，每次挪用接口会见知乎网站的时候会使用高可用署理池的随机一个署理。实际实践历程中，提供了免费署理的网站有：西刺署理、89免费署理、云署理等等，但实际能够使用的还是只有西刺署理。

而且西刺署理的可用数也很是少，导致署理池中可用署理数很少，使用署理池的效果不是很好，这真的是一件很沮丧的事。免费署理池的架构及其实现思路图：简述一下思路：启动项目时，会自动去爬取西刺署理网站前10页的署理（共1000个署理），并将其生存到RabbitMQ中。RabbitMQ设置有10个消费者，每个消费者会检测署理是否可用，检测完毕后会将该署理的信息及其检测效果生存到DB中。

系统设置了一个定时任务，会定时将DB中当前的所有署理再次放到RabbitMQ中，会由10个消费者检测署理是否可用，并将检测效果同时更新到DB中。如果一连3次测试署理不行用，则将该署理从DB中删除。系统设置了一个定时任务，会定时爬取西刺署理网首页的所有署理，会检测署理的可用性，并将其信息及检测效果再次生存到DB中。

这样保证DB中会定时获取更多的署理（实际原因是西刺署理可用署理太少，如果不定时获取更多署理，DB中很快就没有可用的署理了）。系统设置了一个定时任务，会自动删除redis中所有的署理。

然后再将DB中的署理按检测乐成次数举行排序，将一连乐成次数最多的前10个署理生存进redis中。这样redis中的署理就是高可用的。3.4 挪用接口爬取数据项目一定水平地屏蔽了署理池以及知乎用户数据剖析的实现温习性，以袒露接口的方式提供爬取知乎用户信息的功效。在设置好Redis/RabbitMQ情况后，乐成启动项目，等项目稳定后（需要等到redis中有高可用的署理，否则就是用本机IP直接举行数据爬取，这样的话本机IP很容易会被封）后，即可通过挪用如下接口的方式爬取知乎用户信息。

挪用接口localhost:8980/users爬取指定知乎用户的信息，修改url_token的值即可爬取差别知乎用户的信息。挪用接口localhost:8980/users/followees爬取关注指定知乎用户的用户信息，修改url_token的值即可爬取关注差别知乎用户的用户信息。

挪用接口localhost:8980/users/followers爬取指定知乎用户关注的用户信息，修改url_token的值即可爬取差别知乎用户关注的用户信息。在实际测试爬取知乎网站用户信息的历程中，如果系统只用一个牢固IP举行爬取数据，基本爬取不到10万数据该IP就会被封。

使用了署理池这种方式后，由于西刺署理网址上可用的免费署理太少了，最终爬取到167万左右数据后，署理池中基本就没有可用的IP了。不外爬取到这么多的数据已经够用了。

4. 分析知乎用户数据4.1 数据去重爬取了167万+知乎用户数据后，需要对原始数据举行简朴的清理，这里就是去重。每个知乎用户有唯一的url_token，由于这里爬取的是用户的关注者与被关注者，很容易就会有重复的数据。数据量有167万+，使用Java自带的去重容器Set/Map显着不合适（内存不够，就算内存足够，去重的效率也有待考量）。

项目中实现了一个简朴的布隆算法，能够保证过滤后的知乎用户数据绝对没有重复。布隆算法的实现思路图如下：简述布隆算法的实现思路如下：始化一个位容器（每个容器单元的值只能是0或1），并先划定好要使用映射数据用的n个hash方法，hash方法的效果对应于该位容器的一个下标。数据之前，需要先判断该容器中是否已经存过该数据。

该数据对应所有hash方法的效果，对应在位容器中的下标只要有一个下标对应的单元的值为0，则表现该容器还没有存过该数据，否则就判断为该容器之前存过该数据。数据之后，需要将该数据所有hash方法效果对应于位容器中的下标的值，都置为1。这里需要说明一下为什么要使用布隆算法以及布隆算法另有什么缺点。使用布隆算法的理由：我们是依靠url_token来判断一个用户是否重复的，但url_token的长度是不确定的，这里存放一个url_token所需要的空间按上图DB中来看基本上有10字节以上。

如果使用java容器举行去重，那么该容器至少需要的空间：10 * 1670000 byte 即约莫15.93MB（这里貌似还是可以使用java容器举行去重，但其实这里还没有思量容器中还需要存的其他信息）。而使用布隆算法，需要的空间：n * 1670000 bit ，使用的hash方法一般是3-10个左右，即一般至多只需要15.9KB左右的空间(我在项目中使用的是2 << 24 bit即16KB的容量)。如果数据量继续增大，布隆算法的优势会越来越大。算法的缺点： 地，这种hash映射存储的方式肯定会有误判的情况。

即bitSet容器中明显没有存储该数据，却认为之前已经存储过该数据。可是只要hash方法的个数以及其实现设计得合理，那么这个误判率能够大大降低（笔者水平有限，详细怎么降低并盘算误判率可自行谷歌或百度）。而且基于大数据分析来说，一定数据的缺失是可以允许的，只要保证过滤后有足够的不重复的数据举行分析就行。项目中屏蔽了布隆算法实现的庞大性，直接挪用接口localhost:8980/users/filter，即可将DB中的用户数据举行去重。

过滤之后，另有160万左右不重复的数据，说明布隆算法误判率导致的数据流失，对大量的数据来说影响是可以接受的。4.2 数据导入ElasticSearchmysql是一个用来持久化数据的工具，直接用来举行数据分析显着效果不太好（而且数据量较大时，查询效率极低），这里就需要使用越发合适的工具—ElasticSearch。简朴学习一下ElasticSearch，可以参考elasticsearch官网。设置好ElasticSearch情况，然后修改设置文件中ElasticSearch相关的设置。

挪用接口localhost:8980/users/transfer，即可将DB中的用户数据迁移到ES中。SpringBoot整合ElasticSearch很是简朴，直接在项目中导入ElasticSearch的自动设置依赖包<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-data-elasticsearch</artifactId></dependency>然后让相应的DAO层继续ElasticsearchRepository即可在项目中使用ElasticSearch。详细如何在springboot项目中使用ElasticSearch，可以参考SpringBoot-ElasticSearch官方文档，也可参考我项目中源码。

数据导入ES后，可以在head插件或者kibana插件中检察ES中的数据（head插件或kibana插件可以看去重之后导入ES中的数据有1597696条）。4.3 kibana分析知乎数据我们已经拿到足够多的用户数据了，现在需要使用kibana插件来分析数据。

我们在Management > Kibana > Index Patterns中将建立关联的索引user后，即可使用kibana插件辅助我们来分析数据。搜索Java知音民众号，回复“后端面试”，送你一份Java面试题宝典下面举几个例子来表现如何使用Kibana来分析大数据。

查询关注数在100万及以上的用户#查询关注数在100万及以上的用户GETuser/userInfo/_search{"query":{"range":{"followerCount":{"gte":1000000}}}}查询效果图如下：简朴地解释一下效果集中部门字段的意义。took是指本次查询的耗时，单元是毫秒。

hits.total表现的是切合条件的效果条数。hits._score表现的是与查询条件的相关度得分情况，默认降序排序。

聚合查询知乎用户的性别比#查询知乎用户男女性别比GET/user/userInfo/_search{"size":0,"aggs":{"messages":{"terms":{"field":"gender"}}}}查询效果图如下：直接看数据可能不太直观，我们还可以直接通过kibana插件不画相应的效果图(-1：未填，1：男， 0：女)：从效果图来看，现在知乎的男女比还不算离谱，比例靠近3:2（这里让我有点儿怀疑自己爬取的数据有问题）。聚合查询人口最集中的前10个都会#查询现居地最多的前10个都会GET/user/userInfo/_search{"size":0,"aggs":{"messages":{"terms":{"field":"home","size":10}}}}查询效果图如下：从这里的查询效果，很容易就可以看出，“深圳”和“深圳市”、“广州”和“广州市”其实各自指的都是同一地方。可是当前ES不能智能地识别并归类（ps: 可能有方法可以归类但笔者不会…）。因此这里需要后续手动地将类似信息举行处置惩罚归类。

模糊搜索全字段匹配，“模糊”搜索含有“知乎”的数据，搜索效果图如下：4.4 echarts作图从上面的kibana绘图效果来看，真的一般般。这里更推荐使用kibana收集数据，使用百度开源的数据可视化工具echarts来作图。最终的数据汇总以及echarts绘图效果图如下：关注数层级统计很显着地，绝大部门知乎用户都是“知乎小白”或者“知乎路人”。这里的“知乎超大V(1000000+)”的用户只有3个：“丁香医生”、“知乎日报”、“张佳玮”。

行业信息统计手动整理后的行业信息图如下：很显着地能够看出，大部门知乎用户所处的行业都与盘算机或者互联网相关。公司信息统计统计了泛起频率最多的前15名所属公司统计图如下：可以看到，“”、“阿里”的员工数量遥遥领先。虽然“百度”还是排名第三，但已经不在一个数量级。

（“BAT”的时代真的一去不复返了吗？）职位信息统计基于职位信息统计图，使用中文在线词云生成器优词云，生成泛起频率最多的前100名的职位词云图：可以看出，除了学生以外，许多知乎用户都从事盘算机或者软件编程相关的事情，也就是说，知乎用户中“法式猿/媛”所占的比重极其的大。大学信息统计统计了泛起频率最多的前20名结业院校统计图如下：可以看到，填写了结业院校的知乎用户（其实另有绝大部门人没有完善该信息），这些结业院校的实力和名气那是杠杠的。

专业信息统计统计了泛起频率最多的前20名专业统计图如下：可以看到，“盘算机科学与技术”和“软件工程”这两个专业的人数遥遥领先。居住都会信息统计统计了泛起频率最多的前20名居住都会统计图如下：很显着地，“帝都”和“魔都”的人数遥遥领先。（这里可以做一个相关性不大、准确度不高的推论：杭州将是下一个“新一线都会”最有力的竞争者。）5. 总结从最终的信息统计效果来看，大部门的知乎用户信息不算完善（信息比例）。

但这些统计效果图，都是基于知乎用户已经完善的信息举行整理并分析的。很显着地可以看出，已完善信息的知乎用户，基本都在蓬勃都会大公司任职，而且其中的很大一部门是“法式猿/媛”。也就是说，如果我（码农一枚）在事情中遇到什么专业难题时，在知乎中寻求到的谜底是专业可信的。

本文来源：宝博app官网-www.xiezi3158.com