自建微信公众号文章搜索舆情系统

不止一个客户跟我提过公众号里的品牌舆情分析，我也帮客户做过一些基于关键词搜索微信文章的需求（关键词文章筛选+阅读量统计）。

对我来说，早期是通过搜狗微信搜索关键词来获取文章列表，但随着搜狗连续几次升级改版，现在已经很不好采集了，简单来说有几个比较蛋疼的问题：

不能按时间排序，导致出来的文章日期是乱序的，第一页经常能看到两三年前的文章，而对于舆情需求来说，则显得过时了。
获取到的文章是临时链接，不及时处理的话，就没法打开了，而且处理起来也比较麻烦。
返回的文章数量有限，对于一些文章搜索结果比较多的词，难以收集全。

当然了，搜狗微信搜索的好处也很明显，得益于搜狗专业的搜索引擎能力，搜索质量是很高的。

除了搜狗微信，还有像新榜，清博这类平台也提供文章搜索能力，不过我尝试后，发现搜索质量比搜狗微信差了不少，搜索结果数量也比搜狗少了不少。

微信app里的搜索数据是针对普通用户使用的，搜索结果比实际情况也要少很多。

考虑到舆情需求之后一直存在，而市面上也找不到一个非常理想的微信文章搜索服务，所以决定了自建一个！需要自建系统能提供如下功能：

文章数量要尽可能全，基本覆盖绝大多数公众号
文章搜索效果一定要好，要跟搜狗微信的搜索质量打平
主流公众号的发文更新时间要尽可能及时，其它公众号也要保持正常频率更新
可提供一年以内，按时间排序，按公众号列表指定搜索范围，同时能索引文章正文的功能

接下来简单讲述一下自建过程中比较重要的几个点：

数据采集

得益于之前积累的采集经验，在数据采集阶段，没有遇到太大问题，在收集了几批公众号biz后，通过除重一共获得了200万个公众号。

首先是对200w个公众号进行历史消息回溯，考虑到成本压力，只回溯最近3-6个月的发文，这是一个很耗时的过程，光是这一步就花了大半个月才做完，非常的不易。

由于收录的公众号数量太多，所以采用了两套采集方案：

方案1是作为保底策略，对全局公众号进行更新，更新频率由公众号的发文频率决定，比如每天都有更新的公众号，则会进行日更。月发文次数4-6次的则进行周更。

方案2则针对发文最多的公众号进行近实时发文监控（目前大概10w个），且可根据客户需求动态增加。

以上两种方案的结合，既保证了文章数量的丰富度，对实时性也有保障。

数据存储

由于公众号每日发文量在150w-200w之间（节假日或周末会少一些），数据量是相当大的，尤其是还需要存储正文（因为舆情需求不仅仅要求检索标题和摘要，对正文也需要）。所以存储成本是比较大的，我目前的存储方案是mongodb + oss。

mongodb存放热数据，包括发文记录与文章正文，经过一次优化后，将文章正文单独抽离出来放在了一个独立的数据库里，主要原因是正文只需要考虑存1年以内的，且起存储占用太大，成本太高，抽离出来单独存放能节省一点成本，不过处理复杂度会高一点。

oss存放原始文章数据，由于数据库里保存了正文，所以一般很少用到oss，之所以存下来是考虑到之后做NLP相关分析时能提供充足的语料。

文章检索

搜索部分是最核心的，尤其是舆情系统，对搜索质量要求很高，否则需要人工筛选出不合要求的文章是相当费力的。

这部分我直接使用了阿里云的opensearch，初期本来考虑的是用es自建，但测下来始终觉得搜索效果不尽人意，而且每次需要优化索引效果的时候都很痛苦，因为文章量太大了。

opensearch用起来效果会好很多，因为舆情系统的主要客户之一就是品牌商，跟电商领域联系密切，而阿里的淘宝，天猫也都是用的opensearch提供的搜索支持，所以对电商领域的搜索效果有加持，这一点也是我比较看中的。

opensearch用起来是爽不少，但缺点就是太贵，即便是用共享存储版，500G存储一个月的费用要一万多，独享版就更夸张了，且导入数据量的速度也有一定限制，估计要存放一年的数据，必须得使用独享版了。

在使用opensearch的过程中也是做了不少优化的，死命的抠成本，降低单篇文章的存储容量，节省过程中真的是按字节进行计算了。。。