我一开始接触自建舆情分析系统纯粹是被逼的。团队要做竞品监测随手搜一下各类商业舆情SaaS报价一年几十万起步还不给原始数据导出的报表字段固定死了想接进自己的大屏根本没法扩展。后来在GitHub上翻开源方案陆陆续续试了几个最后固定在BettaFish上。BettaFish是一套开源的舆情分析系统核心链路是采集、存储、分析、展示自带微博、知乎、贴吧、新闻站点等内容源的采集器内置分词和情感分析能力后端用Elasticsearch做全文检索和数据聚合前端提供可视化看板。部署方式支持docker-compose一键拉起整个系统跑起来之后数据是自己的查询接口是自己的后续想怎么加工都行。这篇教程就是把我完整踩过一遍的部署过程从头到尾写清楚从环境准备、依赖安装、配置修改到启动验证和故障排查适合有一定Linux和Docker基础、想快速拥有一套私有化舆情平台的团队或个人参考。1. 为什么我最终选了BettaFish它解决的是自己造轮子的问题1.1 舆情系统的完整链路在讲具体部署之前先把这个系统要解决的链路说清楚。舆情分析和普通的爬虫不同不是能把网页抓下来就行它更像一条流水线采集层从目标网站抓取内容包括页面正文、发布时间、作者、来源等元信息还得处理分页、反爬、编码问题。清洗层去除广告、重复内容、导航栏噪音抽取正文主体。存储层把清洗后的数据归档既要支持按关键词快速检索也要支持按时间、平台、情感倾向做聚合统计。分析层分词提取关键词、计算热词权重、判断情感正负面、识别事件的扩散路径。展示层把分析结果用图表、词云、时间曲线的方式丢到前台页面上。商业SaaS平台把这条链路全包了但问题在于黑盒。拿不到中间层数据没法自己训练模型也没法把分析结果同步给内部系统。BettaFish的思路是把这条链路开源出来每个环节都能看到代码、能改配置、能接自己的算法所以它不是我第一个试的却是我最终留下的。1.2 BettaFish的架构拆解BettaFish后端主体用的是Go采集端是独立的Python进程存储检索选了Elasticsearch消息队列用ActiveMQMySQL存元数据和系统配置Redis做热点缓存前端是Vue。整套架构看起来组件多但每层职责很清晰Go API服务对外提供REST接口处理查询、统计、用户认证是所有前端请求的统一入口。Python采集器跑抓取任务把解析好的数据投递到ActiveMQ。ActiveMQ采集器和API服务之间的缓冲地带。爬虫采集速度不稳定高峰时可能瞬间涌入大量数据有队列在中间扛着Elasticsearch写入不会被打爆。MySQL存用户账号、采集源配置、事件追踪规则。Elasticsearch存舆情正文数据IK分词器支持中文分词按日期建索引支持按时间范围快速过滤。Redis缓存热词统计和登录会话。这个分层逻辑我在部署的时候体会很深。如果没有ActiveMQ采集和检索就会强耦合ES一旦慢一点采集进程就得阻塞重试整个链路就全卡住了。有队列解耦之后就算ES短暂不可用消息也会在队列里等着恢复之后继续消费这个对生产环境来说太重要了。1.3 和商业平台对比自建到底值不值我用一张表直接对比一下这样你判断要不要自建会更快对比维度商业SaaS舆情平台自建BettaFish数据所有权数据在平台侧导出受限全部在自己服务器和ES里年成本通常几十万到上百万一台服务器维护人力二次开发只提供固定API全开源可改可扩展分析能力内置较完善基础分词情感分析可替换部署时间开通即用半天到一天维护成本平台负责自己负责我的判断是如果只是临时看几个热词商业SaaS没问题如果你要长期监测、要把数据导入自己的数仓、要做行业垂类的定制分析那自建的价值非常大。BettaFish属于开源线里设计比较完整的一个既有前端看板又有API不像某些开源项目只有爬虫分析全靠自己写SQL所以我最终把它作为自建方案的基础。2. 部署前必须想清楚的几件事环境、依赖和版本匹配2.1 硬件与系统建议部署之前先别急着clone代码把服务器环境想清楚。舆情系统的资源瓶颈通常不在CPU而在内存和磁盘。CPU8核以上就够用。采集器是Python进程抓取时CPU占用不高真正吃CPU的是ES的索引构建和分词。内存建议至少16GB其中Elasticsearch建议分4GB到8GB给JVM堆MySQL和Redis各给1GBGo API服务占用不大采集器2GB足够。磁盘主要看你要存多长时间的舆情数据。按每天新增1万条文本、每条带正文约10KB计算一天约100MB一年约36GB再算上ES索引开销建议初始给500GB如果数据量大直接上1TB。索引可以按天或按月做生命周期管理后文我会详细说。系统Ubuntu 20.04/22.04 LTS、CentOS 7/9都可以。我测试时主要用Ubuntu 22.04Docker版本20.10以上docker-compose插件版即可。这里有一个比较隐蔽的点如果你的服务器内存只有8GBES的JVM堆和Lucene的文件缓存会打架。ES默认是把一半物理内存给JVM堆另外还需要大量内存做文件缓存8GB机器跑ES本身就很吃紧再加上MySQL、Redis可能刚启动没几分钟就OOM。我建议最低16GB起步如果条件不够至少也要把ES单独部署到一台机器上其他组件放另一台。2.2 一个容易被忽略的问题外部依赖为什么这么多第一次看到BettaFish的docker-compose文件很多人会被吓一跳ES、MySQL、Redis、ActiveMQ四个中间件全要上。我当时也嘀咕过一个舆情系统怎么依赖这么重。跑起来之后才理解这个设计的合理性。MySQL在系统里的定位是控制面存的是账号、采集源配置、用户设置的监测关键词这些数据必须保证强一致不能放在ES或者Redis里。Redis管的是加速面热词统计、看板上的实时计数每次都查ES太慢缓存几秒钟就够用。ActiveMQ管的是流量面采集高峰时削峰填谷。ES管的是数据面全文检索和聚合统计的真正主力。四个中间件各有各的活儿谁也不是摆设。用docker-compose把它们编排到一起其实已经是最省事的方案了不用手工一个个装、调版本、配开机自启一条命令全起来。2.3 版本匹配ES和IK分词器必须强匹配部署过程中最容易翻车的就是ES和IK分词器的版本匹配。IK分词器是ES的中文分词插件它是跟着ES版本走的ES 7.10.2对应的IK插件版本是7.10.2如果装成7.17的IKES直接启动失败。这个问题在手动安装ES时特别容易踩docker-compose方式倒还好因为镜像里已经把插件打进去了。BettaFish的compose文件里如果默认ES版本是7.x对应的IK插件一般也在镜像构建时定了不要自己手动改ES版本号除非你同时替换IK插件。另外注意JDK版本。ES 7.x自带捆绑了OpenJDK不需要你手动装JDK但如果你要单独跑ES而非用容器建议用ES自带的JDK别用系统里的高版本JDK很容易因为版本兼容问题起不来。版本组合我给你列一个参考组件版本参考说明Elasticsearch7.10.xIK插件版本需完全一致MySQL5.7/8.0建议8.0字符集选utf8mb4Redis6.x/7.x无特殊要求ActiveMQ5.15.x/5.16.x默认配置即可Go编译环境如源码编译1.17以上一般直接用发布镜像核心原则就一条不管用什么方式部署ES版本和IK分词器插件版本必须完全一致差一个小版本号都会让你卡半天。这个我后面专门写了一节排错过程这里有印象就行。3. 一步步把它跑起来源码、配置、启动与验证3.1 获取源码与项目结构到GitHub上搜索BettaFish找到官方仓库后克隆到服务器。我习惯放在/opt/bettafish下方便统一管理git clone https://github.com/你的仓库地址/BettaFish.git /opt/bettafish cd /opt/bettafish克隆下来之后先看目录结构。一般来说一个开源项目会有这么几个关键目录api/Go后端的源码和构建配置crawler/Python采集器代码里面分好了各个平台爬虫web/前端工程目录vue项目docker/docker-compose编排文件和各服务的Dockerfileconf/各类配置文件模板我先提醒一句开源项目的目录结构会随版本迭代变化别看到我这篇教程的目录名和你的仓库不一致就慌。核心思路是先README.md看启动指南再对照docker-compose.yml找服务编排配置文件模板一般在conf或docker/conf下。README永远是第一手资料教程只是帮你理解思路。3.2 配置文件的修改重点整个部署过程里配置修改是最容易踩坑的一步但也是理解这套系统最好的入口。我把配置文件分成四类一类一类说第一类收集端配置。采集器要连ActiveMQ和ES所以它的配置文件里要写ActiveMQ的连接地址、队列名、ES的地址和索引名前缀。如果你的中间件都是用docker-compose起的服务名就是主机名比如ActiveMQ服务名是activemq采集器里填tcp://activemq:61616就能连通。如果你是跨机器部署这里要改成实际IP。# crawler/conf/collector.yml示例以仓库实际配置为准 mq: broker: tcp://activemq:61616 queue: bettafish.crawler.data es: hosts: - http://elasticsearch:9200 index_prefix: bettafish_data第二类API服务配置。Go后端要连MySQL、Redis和ES还要配置JWT密钥和端口# api/conf/app.yml示例片段 server: port: 8080 mysql: dsn: bettafish:bettafish_passtcp(mysql:3306)/bettafish?charsetutf8mb4parseTimeTruelocLocal redis: addr: redis:6379 password: es: hosts: - http://elasticsearch:9200 jwt: secret: change_this_to_a_random_string这里我把所有密码都写成明文了生产环境一定要改掉。尤其jwt.secret默认值如果不变别人可以伪造Token直接登录你的后台。第三类前端环境变量。Vue前端构建时要指定API网关地址一般在web/.env.production这类文件里配置VUE_APP_API_BASE_URLhttp://你的服务器IP:8080/api如果不改这里前端构建出来的静态页面会默认请求localhost:8080你通过域名访问前端时浏览器请求会全部打到访客自己的电脑上看板数据永远加载不出来。这是新手最容易困惑的前端白屏问题源头之一。第四类docker-compose编排。打开docker-compose.yml确认端口映射没冲突。默认情况下ES9200/9300MySQL3306Redis6379ActiveMQ61616和8161API服务8080前端Nginx80或8000如果服务器上已经跑了占用这些端口的服务记得改映射。3.3 用docker-compose启动配置改完回到项目根目录执行docker-compose up -d第一次启动会拉取镜像ES镜像比较大加上IK插件可能要1GB以上耐心等一会儿。如果想看启动日志用docker-compose logs -f elasticsearch等ES的日志出现status: green之后再依次确认其他服务状态docker-compose ps正常状态应该是所有服务都显示Up健康检查为healthy。如果某个服务反复重启用docker-compose logs 服务名看报错原因。这里我建议你按依赖顺序观察启动过程先ES再MySQL、Redis、ActiveMQ最后API服务和前端。ES启动最慢因为它要加载索引和做分片恢复通常需要30秒到1分钟。API服务启动时会去连MySQL和ES如果这两个没就绪它启动后连接失败但一般服务里有重试逻辑等一会儿自己就恢复了。3.4 健康检查与首次入库验证服务全部起来之后别急着登录页面先做三个验证动作确保链路是通的。第一步确认ES索引存在curl -X GET http://localhost:9200/_cat/indices?v如果采集器还没跑过系统里应该只有少量系统索引。如果连索引都没有说明API服务还没有完成初始化去查API服务的日志。第二步确认API可访问curl http://localhost:8080/api/health返回200和类似{status:ok}的内容就正常。第三步登录前端页面。浏览器访问http://服务器IP用默认管理员账号登录。初次部署后默认账号一般是admin/admin但不同版本有差异README里会写。登录后第一件事是去设置里改密码。跑通这三步系统主体就算部署完成了。下一步真正让数据流动起来是配置采集源和监测关键词这块我在第5节展开讲。4. 上线之后我踩过的四个坑4.1 ES JVM堆内存和物理内存的冲突我第一次部署时服务器是16GB内存但docker-compose里ES的ES_JAVA_OPTS默认设成了-Xms4g -Xmx4g。启动后系统整体内存已经超过80%结果有一天采集量突然上来ES直接OOM容器被杀。后来我把策略改成限定ES堆内存为物理内存的一半但不超过8GB同时给容器加mem_limit防止ES在高峰期吃到宿主机全部内存。这里有个关键认知ES的JVM堆不是唯一的内存消耗点Lucene的底层文件缓存是堆外内存它由操作系统管理所以ES占的内存往往是JVM堆文件缓存两部分。如果堆给了8GB你再期望ES只占8GB是不可能的再加上文件缓存部分预留10GB到12GB比较稳。调整方式# docker-compose.yml services: elasticsearch: environment: - ES_JAVA_OPTS-Xms6g -Xmx6g mem_limit: 10g改完执行docker-compose up -d elasticsearch让配置生效。4.2 IK分词器版本不一致导致索引创建失败这个坑我在测试环境遇到过。当时为了优化性能把compose里的ES镜像版本从7.10.2改成了7.17.8结果API服务初始化时创建索引一直失败ES日志里报IK分词器无法加载提示找不到类或方法。原因就是我前面说的IK插件是预装在镜像里的镜像版本已经绑定了特定的IK版本ES版本一变插件就失效。这是我手贱改版本导致的但也说明了一个很常见的误解——升级ES小版本不会有问题。对于带分词插件的ES版本敏感度极高生产环境不要随便升。如果你要升级正确流程是先停ES容器重新构建一个装好对应版本IK插件的ES镜像再替换compose配置。升级完必须重建索引因为分词词库变化会导致历史数据的分词结果不一致检索时新旧文档行为会不同。4.3 采集器连不上ActiveMQ采集器第一次启动时我遇到一个问题Python进程一直在报连接ActiveMQ失败。当时检查ActiveMQ的61616端口明明已经映射出来了命令也能连通为什么Python连不上看日志才发现容器网络不是host模式采集器容器里的localhost指向采集器自己不是宿主机。compose服务之间通信应该用服务名activemq不是localhost而我在采集器配置里写的是tcp://localhost:61616容器内自然连不通。解决办法很简单配置里的broker地址改成tcp://activemq:61616。如果采机器单独跑在宿主机进程里不是容器那才写tcp://127.0.0.1:61616因为它和ActiveMQ在同一个网络命名空间。这个坑的本质是容器网络模型没想清楚docker-compose默认创建了一个内部网络服务之间通过服务名互通宿主机端口映射只是给外部访问用的。理解了这点之后排查类似问题就很快了。4.4 情感分析配额和降级策略BettaFish的情感分析功能如果走的是内置接入方案一般依赖外部NLP服务的API Key比如BosonNLP这类。免费配额用完之后情感分析接口会开始报错或者返回空值。我当时没配置好Key导致前端看板里情感倾向那一栏全是未知。这个不影响整个系统运行但是看板价值少了一大块。后来我做了两个调整一是给外部NLP服务调用加超时控制避免第三方API响应慢时拖垮Go API二是做了降级策略外部API不可用时先用简单的词典规则库兜底判断正负面虽然精度不如模型但至少不空白。如果你后续想接入本地的大模型做更细的情感判断这个链路也是可以替换的BettaFish的分析层是模块化设计改一个实现类就行。具体接口在API服务里搜情感分析相关的Service。5. 进阶用法从能跑到好用5.1 事件追踪机制的核心价值越搜越准BettaFish和其他舆情系统相比最有特色的功能是事件追踪。普通舆情只能按关键词搜索比如你搜新能源汽车所有包含这个词的内容都会涌进来里面混杂大量无关信息。事件追踪的思路是先锁定一个初始事件再根据数据中反复出现的关联词自动扩展搜索范围。举个例子你的初始关键词是某品牌召回系统会从抓回的内容里提取高频共现词比如电池起火OTA升级等然后用这些词组成新一轮搜索条件形成事件簇。这个机制对舆情演进路径的还原非常有价值能看出一个话题是怎么从首发、发酵、扩散到消退的。配置上在后台事件追踪里新建一个事件填种子关键词和时间窗口系统会自动跑。这里我给你的实际建议是种子词不要太少也别太宽泛。太少初始召回不够太宽泛比如只写汽车扩散出来的事件会乱成粥。一般填2到4个有辨识度的词比如品牌名具体产品型号效果最好。5.2 合理设置采集关键词与频率采集频率是个需要平衡的点。频率太低热点发酵的第一时间你拿不到数据频率太高采集器对目标站点压力太大容易被封IP或触发反爬机制。我的经验做法是普通新闻源每10到20分钟一轮社交媒体源每5到10分钟一轮。对应的采集配置里可以设置进程的sleep间隔不用每条都调。关键词设置上建议把账号维度、产品维度、竞品维度和风险维度分开建方便后续做分析标签。另外提醒一句采集要遵守目标平台的服务条款和数据使用规范控制合理频率不要做暴力抓取。自建舆情系统的价值在于自主可控前提是合规使用数据这个底线不能破。5.3 数据生命周期和磁盘规划ES的数据索引如果只建不删磁盘很快就满了。BettaFish一般按时间建索引比如bettafish_data-2024-01、bettafish_data-2024-02这给数据生命周期管理提供了很大便利。我建议定期执行两个动作一是把超过90天或按业务需求的索引关闭或删除二是把更早的数据做快照备份到对象存储或冷盘。# 关闭某个月之前的索引示例生产建议写成脚本配合cron执行 curl -X POST http://localhost:9200/bettafish_data-2024-01/_close关闭索引不会删数据但能释放文件句柄和内存缓存压力。需要查历史数据时再重新打开。至于哪些数据值得留我的标准是原始舆情数据建议至少保留半年到一年因为分析模型迭代后可能要回溯历史数据重新验证。快照备份可以配置es的path.repo之后调_snapshot接口这个在官方文档里讲得很细这里不展开但磁盘规划这部分一定要提前做别等磁盘报警再处理。5.4 API对接示例把BettaFish的数据接到自己的系统里是很多人自建的根本原因。它的API服务提供了关键词搜索和聚合统计接口我用Python写一个最简单调用示例import requests BASE_URL http://你的服务器IP:8080/api def search_keyword(keyword, days7): resp requests.get( f{BASE_URL}/search, params{keyword: keyword, days: days}, headers{Authorization: Bearer 你的Token} ) resp.raise_for_status() return resp.json() if __name__ __main__: result search_keyword(新能源汽车, days3) for item in result.get(data, [])[:5]: print(item[title], item[platform], item[published_at])Token的获取方式一般是调用登录接口拿到JWT然后把Token放在Authorization头里。这里要注意生产环境不要在前端页面把API Key或者Token写死走服务端中转避免泄露。5.5 把部署流程沉淀成团队SOP最后说一个运维层面的事。BettaFish这套系统不是部署完就结束了后续还需要升级、备份、扩容。我的建议是趁着部署过程记忆还新鲜把整个流程写成团队内部SOP文档至少包含下面几块环境初始化命令和参数docker-compose配置文件的改动清单默认账号修改记录ES索引生命周期管理定时任务备份恢复验证步骤这样做的价值在于三个月后你再去维护这套系统不用重新把坑踩一遍。我自己就吃过这个亏第一次部署完没有及时记文档后来ES索引磁盘满了才临时翻日志耽误了不少时间。把部署教程变成你们团队自己的运维手册比任何泛泛的最佳实践都实在。部署这套舆情分析系统说难不算难一路踩坑下来也就几小时的事说简单也不简单ES分词器、ActiveMQ连接、容器网络这些问题不懂原理的人能卡一整天。我自己反复用过这么多次之后最大的感受是这套系统的上限不在代码而在你如何配置事件追踪和关键词体系。部署只是敲门砖真正让舆情监测发挥价值的是你对业务的理解。如果你正准备搭一套私有化舆情平台按这个流程走下来半天内跑通是没有问题的。