接到这个需求的时候项目群里的第一句话是“帮我们盯着网上都在怎么说这个景区。”起初我想得挺简单——写个爬虫抓评论做个词云再画个折线图这不就完了吗实际做下来才发现一套能稳定跑的 Python 大数据舆情分析系统难的从来不是某一个环节而是把采集、清洗、存储、计算、展示串成一条不崩的流水线。这篇文章就把这次系统开发实战的完整思路、选型依据和踩坑记录拆开讲一遍给正在做毕业设计或者想在公司内部搭业务舆情平台的读者一个能直接参考的模板。先说清楚边界这里说的舆情指的是景区口碑、品牌评论、活动传播效果这类商业反馈监控不是别的场景。数据全部来自公开接口或平台允许访问的公开页面不涉及任何需要绕过访问控制的目标。技术上从 Python 爬虫、数据清洗、情感分析到可视化大屏都会讲到代码结构不复杂但对数据量从几千条到几百万条的过渡路径我会做比较详细的说明。1. 需求确认与模块拆解先回答“老板说的舆情到底是什么”1.1 舆情分析的本质是三个问题做系统之前没有比“确认需求”更重要的事。老板说“我要做舆情分析”真实想知道的往往是三件事有没有人讨论我、讨论的内容是什么、讨论的人是夸还是骂。落到技术指标上就是声量趋势、关键词和主题、情感倾向。业务问题技术指标输出物讨论热度怎么样声量、帖子数、评论数时间趋势曲线都在具体聊什么关键词、主题聚类词云、主题榜、负面归因口碑是好是坏情感得分、情绪标签正负占比、负面明细哪个渠道影响力大来源分布、转发层级渠道饼图、来源漏斗这四个问题几乎能覆盖 80% 的商业舆情需求。刚开始千万不要和老板讨论“数据湖”、“实时数仓”先把这几个问题用最简单的图表回答出来项目就成功了一半。如果一开始就把目标定成“全网所有平台、所有言论、实时预警”系统大概率会死在开发阶段。1.2 需求优先级怎么排序我的做法是把需求砍成三期。一期只做公开评论采集、基础情感分析、日报表二期再做多渠道扩展、分钟级异常预警、负面自动归因三期才考虑离线数仓、用户画像和内部业务数据打通。这么排不是偷懒而是因为舆情系统交付后最容易被问的问题是“你的数据准不准”。如果一期连核心链路都没跑稳直接上二期三期信任感根本建立不起来。先在一个渠道把数据采集、清洗、情感分析、可视化整个闭环跑通再横向复制到其他渠道才是性价比最高的路径。我见过不少团队一上来就搭 Hadoop 集群、Spark 任务、Flink 实时流结果连口径都没定义清楚最后全是跑给领导看的空架子。2. 整体架构与技术选型按数据量级做加法不搞全家桶2.1 模块划分与实际数据流整个系统按数据流向可以分成六个层次采集层、清洗层、存储层、分析层、服务层、展示层。一条链路大概是Scrapy 把评论抓下来写到 MongoDB异步任务从 MongoDB 读原始文本做清洗和情感分析统计结果落到 MySQLFlask 读 MySQL 提供 JSON 接口前端 ECharts 拉接口画大屏。Redis 在中间负责去重、任务调度和缓存。这样做的好处是每一层都能独立替换。比如情感分析模块一开始用轻量模型后期想换成深度学习模型只需要替换分析层不牵扯采集和展示。存储层也是同理MongoDB 存原始数据MySQL 存统计结果哪天数据量大到单机撑不住把 Mongo 换成 HBase 或把 HDFS 接进来对上层分析逻辑的影响能降到最低。2.2 关键选型对照表模块候选方案最终选型原因采集框架Scrapy / requests多线程 / PlaywrightScrapy自带去重、中间件、并发控制生态成熟任务队列Redis List / RabbitMQ / KafkaRedis List团队没人力维护 KafkaRedis 初期完全够用原始数据存储MySQL / MongoDB / HBaseMongoDB原始文本字段不固定JSON 结构扩展方便统计结果存储MySQL / PostgreSQLMySQL团队熟悉SQL 查报表方便情感分析SnowNLP / 微调BERT / 商用APISnowNLP规则修正初期数据量不大成本低后期可替换展示端FlaskECharts / DjangoECharts / 商用大屏平台FlaskECharts轻量、和 Python 分析代码同语言改起来快很多人会问为什么不上 Hadoop 和 Spark我做过一个估算。假设系统日增 5 万条评论每条原始字段平均 2KB保留一年总数据量大约 36GB单机 MySQL 和 MongoDB 完全扛得住。只有当日增量到百万级、需要长期保存几亿条原文或者要做分钟级实时分析时再考虑 Spark、Kafka 这批组件。数据量是被算出来的不是靠感觉拍出来的。2.3 基础环境版本项目用的 Python 3.9Scrapy 2.8MongoDB 4.4MySQL 8.0Redis 6.0Flask 2.2SnowNLP 0.12.3。这些不是最新版本都是线上验证过的稳定组合。做数据类项目稳定性比追新版本重要特别是 SnowNLP 这种依赖训练语料的库版本变了可能直接导致已训练的模型文件不兼容。3. 数据采集层实战从公开页面到干净语料的四道关3.1 第一关采集策略与访问频率控制采集的原则是“只抓公开数据遵守平台规则”。反爬不是完全靠伪装和绕验证码更多是靠合理的频率控制。一个最简单的请求封装如下import time import requests class CommentCollector: def __init__(self, api_url, interval1.0): self.api_url api_url self.session requests.Session() self.session.headers.update({ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120 Safari/537.36 }) self.interval interval def fetch(self, params): resp self.session.get(self.api_url, paramsparams, timeout10) resp.raise_for_status() time.sleep(self.interval) return resp.json() # 示例抓取某个公开评论接口实际路径以目标平台开放规则为准 collector CommentCollector(https://example.com/api/comments, interval0.8) data collector.fetch({page: 1, size: 50})如果换成 Scrapy则重点调这几个配置# settings.py DOWNLOAD_DELAY 1.0 CONCURRENT_REQUESTS_PER_DOMAIN 8 COOKIES_ENABLED False RETRY_ENABLED True RETRY_TIMES 3 DOWNLOAD_TIMEOUT 15很多新手一上来就把并发调到 32、64结果请求响应反而慢甚至触发限流。我的习惯是先从 DOWNLOAD_DELAY2 开始观察监控指标再逐步压到 0.5。舆情采集是长期任务跑得久比跑得快更重要。3.2 第二关清洗、去重与表情符号处理公开评论里最多的是 HTML 标签、URL、用户名、无意义的空格换行。清洗要保留的是“人说的核心话”。一个随手能用的清洗函数长这样import re import hashlib def clean_text(raw: str) - str: raw re.sub(r[^], , raw) # 去HTML标签 raw re.sub(rhttps?://\S, , raw) # 去URL raw re.sub(r[\w\u4e00-\u9fa5], , raw) # 去用户 raw re.sub(r\s, , raw) return raw.strip() def get_dedup_key(text: str) - str: 返回归一化文本的MD5指纹用于去重 return hashlib.md5(text.encode(utf-8)).hexdigest() # Redis去重 def try_dedup(redis_conn, text: str) - str | None: fp get_dedup_key(text) ok redis_conn.set(fcomment:fp:{fp}, 1, nxTrue, ex7 * 24 * 3600) return text if ok else None这里有个细节经常被忽略表情符号不能一律删掉。、、这类 emoji 直接承载了用户情绪删掉等于丢掉重要特征。正确做法是单独把 emoji 抽取出来作为情感辅助字段。清洗后的文本拿去算情感emoji 标签拿去修正置信度两路特征都比只保留纯文本要好。3.3 第三关增量更新与失败重试增量采集的关键是记住“上次跑到哪里”。最普通的方案是把游标存到 Redis比如记录最后一页的翻页游标或者最后一条评论的时间戳定时任务启动时先读取然后从这个位置继续。这里我用 APScheduler 做调度每 10 分钟跑一次增量任务失败的任务进入重试队列。网络请求不可能永远成功所以重试策略必须带指数退避。我习惯用 tenacity 库from tenacity import retry, stop_after_attempt, wait_exponential retry(stopstop_after_attempt(3), waitwait_exponential(multiplier0.5, min1, max10)) def request_with_retry(url, params): resp requests.get(url, paramsparams, timeout10) resp.raise_for_status() return resp.json()有个容易被忽视的点不要把原始 HTML 直接存数据库。清洗后的纯文本、抽取出的图片链接、发布账号、发布时间、所属渠道这些字段才有长期价值。原始 HTML 只会占用大量磁盘空间后期查询还慢。4. 情感分析与主题聚合模型选型、调参和偏差修正4.1 SnowNLP 的情感得分能不能直接用SnowNLP 是很多 Python 入门者接触情感分析时用的第一个库接口简单一个sentiments属性就能输出 0 到 1 的得分。但它的训练语料集中在电商评论领域直接拿去做旅游、餐饮、美妆评论分析偏差会很明显。比如“住在山里非常安静孩子玩得很开心”这种句式模型打得还行但“人巨多排队俩小时进去十分钟就出来了”这种典型差评模型很容易给成中性。正确的做法是采集一批目标领域语料重新训练。手动标注 1500 条正面、1500 条负面然后from snownlp import sentiment sentiment.train(data/travel_neg.txt, data/travel_pos.txt) sentiment.save(travel_model.marshal)使用的时候把模型路径传进去from snownlp import SnowNLP s SnowNLP(排队两小时风景也就那样, pathtravel_model.marshal) print(s.sentiments)这里提醒一句不同版本的 SnowNLP 对path参数的支持可能有差异。我在项目里是在进程启动时全局加载一次避免每条评论都重新读模型文件浪费 I/O。训练语料不是越多越好但要覆盖目标业务的典型表达。比如做景区舆情就得多收集“缆车排队”、“门票贵”、“停车难”、“民宿踩雷”这类句子否则模型永远学不到领域里的负面表达。4.2 规则层修正处理否定词、程度副词和领域惯用语光靠模型不够。我们实际测试中发现带有否定词的句子经常被预测错最具代表性的就是“这个景点一点都不冷清”。“冷清”在旅游评论里是负面词模型看到它就容易打低分但实际上加上“不”字整句话变成正面。规则层做的事情很简单在模型分数基础上根据否定词、程度副词、领域惯用语做修正。negations {不, 没, 不太, 并不, 一点也不} boosters {非常, 太, 超级, 极其, 真的} attenuators {有点, 稍微, 略显} def rule_adjust(text: str, base_score: float) - float: # 领域正话直接用白名单拉高分数 if any(w in text for w in [不冷清, 不坑, 没踩雷, 值得再来]): return min(1.0, base_score * 1.3 0.2) # 出现否定词且模型分偏低反转或拉高 for w in negations: if w in text and base_score 0.45: return max(0.0, 1 - base_score) # 程度副词增强/减弱 if any(w in text for w in boosters): return min(1.0, base_score * 1.15) if any(w in text for w in attenuators): return max(0.0, base_score * 0.9) return base_score这个规则肯定不完美但它能把误判率降一个量级。重点是规则要小步迭代每星期抽样几百条预测结果把典型错例加进规则或语料里慢慢补。比起一开始就上深度学习模型这种“轻量模型规则兜底”的组合在小团队场景下更容易维护。4.3 主题聚合先用 TF-IDF 顶住别急着上 LDA主题模型 LDA 在小语料上极不稳定换一次随机种子结果可能完全变样。我们在项目一期直接放弃了 LDA改成“TF-IDF 提取关键词 人工规则做负面归因”。负面归因就是把差评按维度分类比如景区场景可以分成交通、住宿、票务、卫生、服务、体验。这样老板看到的不只是“今天有 200 条负面”而是“今天负面集中在停车难和排队时间长”。用 jieba 做分词后再用 TF-IDF 提取关键词import jieba from sklearn.feature_extraction.text import TfidfVectorizer def jieba_tokenizer(text): return [w for w in jieba.cut(text) if w.strip() and len(w) 1] corpus [停车场离景区大门太远, 门票涨价就算了还排长队, 工作人员态度很差] # 示例 tfidf TfidfVectorizer(tokenizerjieba_tokenizer, max_features2000) matrix tfidf.fit_transform(corpus) feature_names tfidf.get_feature_names_out() top sorted(zip(matrix.sum(axis0).A1, feature_names), reverseTrue)[:20] print([word for _, word in top])负面归因的分类器不用写得太复杂。先人工给 1000 条负面样本打上类别标签再用关键词规则覆盖 80% 的常见场景剩下 20% 留给人工去补规则。这样的可解释性反而比黑盒分类模型好运营同学也能自己维护规则库。5. 存储层设计MySQL、MongoDB、Redis 各管哪一段5.1 原始数据与统计结果的分工原始评论全部进 MongoDB因为来源平台不同、字段差异大。有的带图片链接有的带地理位置有的有转发数如果一开始就把 schema 定死在 MySQL后期加字段就是一场灾难。MongoDB 文档模型天然适合这种半结构化数据。MySQL 只存结构化统计结果和查询频繁的字段。比如每条评论的最终情感分、情感标签、发布时间、来源渠道、关键词、所属省份。这样报表查询走 MySQL全文检索和复杂字段的备份走 MongoDB各司其职。建表语句参考CREATE TABLE comment_sentiment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, source VARCHAR(32) NOT NULL, comment_id VARCHAR(64) NOT NULL, url_hash CHAR(32) NOT NULL, sentiment_score DECIMAL(3, 2) NOT NULL, sentiment_label VARCHAR(16) NOT NULL, keywords VARCHAR(512), province VARCHAR(32) DEFAULT NULL, publish_time DATETIME NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_url_hash (url_hash), KEY idx_source_time (source, publish_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里有两个关键点。第一个是url_hash必须加唯一索引这是数据库层的最后一道去重保障防止同一个评论在爬虫重试后重复入库。第二个是utf8mb4字符集不用它的话 emoji 保存会直接报错或者变成问号。5.2 统计任务怎么设计不容易跑死最容易犯的错是在一条大 SQL 里对整张表做全量聚合。数据量一旦过了百万行那种SELECT COUNT(*) ... GROUP BY会把 MySQL 拖垮。我的做法是先把原始评论按天导出或者按小时聚合聚合结果存到daily_stats表报表只读这张小表。日报、周报、月报都从日统计表继续向上卷而不是每次从原始表重新算。如果后续数据量真的涨到需要分布式计算再把原始数据导出成 JSON 文件放到 HDFS用 Spark 做离线任务。一段示例是from pyspark.sql import SparkSession spark SparkSession.builder.master(yarn).appName(daily_comment_stat).getOrCreate() df spark.read.json(hdfs:///data/comments/*.json) df.createOrReplaceTempView(comments) spark.sql( SELECT source, sentiment_label, COUNT(*) AS cnt FROM comments WHERE publish_time 2025-01-01 GROUP BY source, sentiment_label ).show()但我会反复提醒自己迁移到 Spark 不是技术先进性问题而是成本和收益问题。十几个人维护一个 Spark 集群如果只是为了跑每天几百万行的 group by确实不划算。6. 可视化与预警把统计结果变成能直接指挥行动的看板6.1 Flask 聚合接口设计大屏不是直接把数据库表放出来而是把业务问题翻译成接口。我做了三个核心接口/api/overview返回总体声量、正负面数量/api/trend返回按天趋势/api/topics返回负面关键词和归因分类。一个趋势接口的示例app.get(/api/trend) def trend(): days int(request.args.get(days, 7)) sql SELECT DATE_FORMAT(publish_time, %%Y-%%m-%%d) AS d, SUM(sentiment_score 0.6) AS positive, SUM(sentiment_score 0.4) AS negative FROM comment_sentiment WHERE publish_time DATE_SUB(CURDATE(), INTERVAL %s DAY) GROUP BY d ORDER BY d rows query_db(sql, (days,)) return jsonify({code: 0, data: rows})这里有个小坑在 Python 的 MySQL 参数化查询里如果驱动不同SQL 中的%可能需要写成%%否则会被当成参数占位符。我因为这个报错过半小时排查到最后就是一行百分号的问题。前端直接使用 ECharts 的 line 图fetch(/api/trend?days7) .then(r r.json()) .then(res { const dates res.data.map(x x.d); const pos res.data.map(x x.positive); const neg res.data.map(x x.negative); chart.setOption({ xAxis: { data: dates }, series: [ { name: 正面, type: line, data: pos }, { name: 负面, type: line, data: neg } ] }); });不要把前端搞得太复杂。项目里有人提议用 Vue Element UI 重写大屏被我否了。一个只给内部看的数据大屏单页面 HTML 引入 ECharts 就够了。少一个工程化的前端项目就少一堆构建链路的维护成本。6.2 预警规则负向飙升不是看绝对值而是看异常预警是最容易做出“狼来了”效果的模块。如果简单设置“负面数量超过 100 条就报警”平时日负面向来只有二三十条的业务会被阈值拍死而如果业务旺季日正面就有一千条100 条负面反而可能是正常现象。所以我用的是三西格玛异常检测取最近 7 天同一时段的数据计算均值和标准差当当前值超过均值 3 * 标准差时触发预警。这个规则不需要机器学习模型效果却比固定阈值靠谱得多。import statistics def is_anomaly(current: float, history: list[float]) - bool: if len(history) 7: return False mean statistics.mean(history) std statistics.pstdev(history) return current mean 3 * std触发预警后的推送可以走企业微信机器人或钉钉机器人一个requests.post就够import requests def send_alert(text: str): webhook https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyYOUR_KEY data {msgtype: text, text: {content: text}} requests.post(webhook, jsondata, timeout5)预警一定要加冷却时间。我在 Redis 里存一个alert:cooldown:{rule_name}设置一小时过期防止同一个异常触发一轮又一轮的报警轰炸。没有冷却的预警系统上线第二天就会被运维关掉。7. 上线前后踩过的四个大坑现象、排查链路与修复7.1 时区错乱导致“凌晨三点爆热搜”上线第二天看趋势图发现凌晨零点到一点出现了一波巨大的声量高峰。第一反应是有人刷量后来查了原始数据才知道平台接口返回的时间字段带Z后缀也就是 UTC 时间。存库时没有统一转换直接把 UTC 当成北京时间存了进去真实发生在早上八点的评论全被挪到了凌晨。排查链路是先看趋势图发现异常时段再抓几条原始数据比对publish_time最后确认是时区问题。修复很简单统一在数据入库前转成带时区的datetime展示层再转北京时间from datetime import datetime, timezone, timedelta cst timezone(timedelta(hours8)) dt_utc datetime.fromisoformat(raw_time.replace(Z, 00:00)) dt_cst dt_utc.astimezone(cst)这个坑提醒我所有时间字段在代码里都要有一个明确的“模型”要么全存 UTC要么全存北京时间绝不允许混着用。7.2 情感模型误判“这一点都不冷清”随机抽样检查中我拿 100 条人工标注结果和模型预测结果做对比发现准确率只有 67%。仔细看错例集中在一类句式句子里有明显的负面词但前面有否定词比如“不冷清”、“不坑”、“没踩雷”。模型抓到“冷清”、“坑”、“踩雷”这些词后直接给负分。根因确认后我在规则层加了两样东西。第一是领域正面惯用语白名单第二是整个句子的否定词检测。改完后同一批样本准确率提升到 83%。要说明的是这 83% 是在样本不大、规则人工维护的前提下得出的不是模型本身变强了。但做业务系统规则兜底往往比换复杂模型见效更快。7.3 爬虫被限流后整条链路堵死系统上线第三周MongoDB 写入量突然掉到几乎为零但 Redis 队列的长度在疯狂上涨。查服务日志发现采集任务里一个慢请求占住了所有并发槽位后面排队等着的链接全部超时超时又触发无限重试把队列越堆越满。修复方法三管齐下设置DOWNLOAD_TIMEOUT让慢请求快速失败调低CONCURRENT_REQUESTS_PER_DOMAIN防止把目标站点打崩给重试次数加上限并记录失败原因。最重要的教训是采集系统必须把队列当作缓冲调度端永远要有限流机制否则一个平台的网络抖动会影响整条数据链路。7.4 服务器上没有中文字体词云全是“豆腐块”开发机上词云显示正常部署到 Linux 服务器后所有汉字变成了方框。排查了一圈不是代码问题是服务器字体库里根本没有中文字体wordcloud 库找不到能渲染汉字的字体文件。修复方式apt-get install -y fonts-wqy-zenhei然后在代码里显式指定字体路径from wordcloud import WordCloud wc WordCloud( width1200, height600, font_path/usr/share/fonts/truetype/wqy/wqy-zenhei.ttc, background_colorwhite )这类问题特别坑因为它不会报错只会默默输出一堆方框。后来我在部署检查清单里加了一条所有涉及图片生成的服务必须先确认目标机器的字体环境。8. 系统跑稳之后我才想明白的事这套舆情系统真正稳定上线之后我最大的体会是最花时间的不是写采集代码不是调情感模型而是数据标注和规则迭代。每周固定抽样本、看错例、补规则、重新评估准确率这个循环才是整个系统的护城河。换一个会写 Python 的人两三周也能把系统搭出来但只有经历了数据循环的人才知道哪些词在哪个渠道里有特殊含义。另外一个经验是别把“舆情分析”做成一个孤立的定期报表。真正有价值的是把情感分析结果和业务行为打通比如景区发现某一时段负面集中立刻推给现场运营去处理。一个能触发行动、能闭环反馈的系统才值得持续投入资源维护。后续如果要升级我会考虑接本地化部署的文本大模型做摘要和归因但前提一定是把上一阶段的准确率指标和人工审核链路先固化下来否则模型升级只会带来更多不可控的误判。 
长河君 · 2026/10/5 6:18:37 · 阅读 1.2k Python大数据舆情分析系统实战：从爬虫到可视化大屏
接到这个需求的时候项目群里的第一句话是“帮我们盯着网上都在怎么说这个景区。”起初我想得挺简单——写个爬虫抓评论做个词云再画个折线图这不就完了吗实际做下来才发现一套能稳定跑的 Python 大数据舆情分析系统难的从来不是某一个环节而是把采集、清洗、存储、计算、展示串成一条不崩的流水线。这篇文章就把这次系统开发实战的完整思路、选型依据和踩坑记录拆开讲一遍给正在做毕业设计或者想在公司内部搭业务舆情平台的读者一个能直接参考的模板。先说清楚边界这里说的舆情指的是景区口碑、品牌评论、活动传播效果这类商业反馈监控不是别的场景。数据全部来自公开接口或平台允许访问的公开页面不涉及任何需要绕过访问控制的目标。技术上从 Python 爬虫、数据清洗、情感分析到可视化大屏都会讲到代码结构不复杂但对数据量从几千条到几百万条的过渡路径我会做比较详细的说明。1. 需求确认与模块拆解先回答“老板说的舆情到底是什么”1.1 舆情分析的本质是三个问题做系统之前没有比“确认需求”更重要的事。老板说“我要做舆情分析”真实想知道的往往是三件事有没有人讨论我、讨论的内容是什么、讨论的人是夸还是骂。落到技术指标上就是声量趋势、关键词和主题、情感倾向。业务问题技术指标输出物讨论热度怎么样声量、帖子数、评论数时间趋势曲线都在具体聊什么关键词、主题聚类词云、主题榜、负面归因口碑是好是坏情感得分、情绪标签正负占比、负面明细哪个渠道影响力大来源分布、转发层级渠道饼图、来源漏斗这四个问题几乎能覆盖 80% 的商业舆情需求。刚开始千万不要和老板讨论“数据湖”、“实时数仓”先把这几个问题用最简单的图表回答出来项目就成功了一半。如果一开始就把目标定成“全网所有平台、所有言论、实时预警”系统大概率会死在开发阶段。1.2 需求优先级怎么排序我的做法是把需求砍成三期。一期只做公开评论采集、基础情感分析、日报表二期再做多渠道扩展、分钟级异常预警、负面自动归因三期才考虑离线数仓、用户画像和内部业务数据打通。这么排不是偷懒而是因为舆情系统交付后最容易被问的问题是“你的数据准不准”。如果一期连核心链路都没跑稳直接上二期三期信任感根本建立不起来。先在一个渠道把数据采集、清洗、情感分析、可视化整个闭环跑通再横向复制到其他渠道才是性价比最高的路径。我见过不少团队一上来就搭 Hadoop 集群、Spark 任务、Flink 实时流结果连口径都没定义清楚最后全是跑给领导看的空架子。2. 整体架构与技术选型按数据量级做加法不搞全家桶2.1 模块划分与实际数据流整个系统按数据流向可以分成六个层次采集层、清洗层、存储层、分析层、服务层、展示层。一条链路大概是Scrapy 把评论抓下来写到 MongoDB异步任务从 MongoDB 读原始文本做清洗和情感分析统计结果落到 MySQLFlask 读 MySQL 提供 JSON 接口前端 ECharts 拉接口画大屏。Redis 在中间负责去重、任务调度和缓存。这样做的好处是每一层都能独立替换。比如情感分析模块一开始用轻量模型后期想换成深度学习模型只需要替换分析层不牵扯采集和展示。存储层也是同理MongoDB 存原始数据MySQL 存统计结果哪天数据量大到单机撑不住把 Mongo 换成 HBase 或把 HDFS 接进来对上层分析逻辑的影响能降到最低。2.2 关键选型对照表模块候选方案最终选型原因采集框架Scrapy / requests多线程 / PlaywrightScrapy自带去重、中间件、并发控制生态成熟任务队列Redis List / RabbitMQ / KafkaRedis List团队没人力维护 KafkaRedis 初期完全够用原始数据存储MySQL / MongoDB / HBaseMongoDB原始文本字段不固定JSON 结构扩展方便统计结果存储MySQL / PostgreSQLMySQL团队熟悉SQL 查报表方便情感分析SnowNLP / 微调BERT / 商用APISnowNLP规则修正初期数据量不大成本低后期可替换展示端FlaskECharts / DjangoECharts / 商用大屏平台FlaskECharts轻量、和 Python 分析代码同语言改起来快很多人会问为什么不上 Hadoop 和 Spark我做过一个估算。假设系统日增 5 万条评论每条原始字段平均 2KB保留一年总数据量大约 36GB单机 MySQL 和 MongoDB 完全扛得住。只有当日增量到百万级、需要长期保存几亿条原文或者要做分钟级实时分析时再考虑 Spark、Kafka 这批组件。数据量是被算出来的不是靠感觉拍出来的。2.3 基础环境版本项目用的 Python 3.9Scrapy 2.8MongoDB 4.4MySQL 8.0Redis 6.0Flask 2.2SnowNLP 0.12.3。这些不是最新版本都是线上验证过的稳定组合。做数据类项目稳定性比追新版本重要特别是 SnowNLP 这种依赖训练语料的库版本变了可能直接导致已训练的模型文件不兼容。3. 数据采集层实战从公开页面到干净语料的四道关3.1 第一关采集策略与访问频率控制采集的原则是“只抓公开数据遵守平台规则”。反爬不是完全靠伪装和绕验证码更多是靠合理的频率控制。一个最简单的请求封装如下import time import requests class CommentCollector: def __init__(self, api_url, interval1.0): self.api_url api_url self.session requests.Session() self.session.headers.update({ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120 Safari/537.36 }) self.interval interval def fetch(self, params): resp self.session.get(self.api_url, paramsparams, timeout10) resp.raise_for_status() time.sleep(self.interval) return resp.json() # 示例抓取某个公开评论接口实际路径以目标平台开放规则为准 collector CommentCollector(https://example.com/api/comments, interval0.8) data collector.fetch({page: 1, size: 50})如果换成 Scrapy则重点调这几个配置# settings.py DOWNLOAD_DELAY 1.0 CONCURRENT_REQUESTS_PER_DOMAIN 8 COOKIES_ENABLED False RETRY_ENABLED True RETRY_TIMES 3 DOWNLOAD_TIMEOUT 15很多新手一上来就把并发调到 32、64结果请求响应反而慢甚至触发限流。我的习惯是先从 DOWNLOAD_DELAY2 开始观察监控指标再逐步压到 0.5。舆情采集是长期任务跑得久比跑得快更重要。3.2 第二关清洗、去重与表情符号处理公开评论里最多的是 HTML 标签、URL、用户名、无意义的空格换行。清洗要保留的是“人说的核心话”。一个随手能用的清洗函数长这样import re import hashlib def clean_text(raw: str) - str: raw re.sub(r[^], , raw) # 去HTML标签 raw re.sub(rhttps?://\S, , raw) # 去URL raw re.sub(r[\w\u4e00-\u9fa5], , raw) # 去用户 raw re.sub(r\s, , raw) return raw.strip() def get_dedup_key(text: str) - str: 返回归一化文本的MD5指纹用于去重 return hashlib.md5(text.encode(utf-8)).hexdigest() # Redis去重 def try_dedup(redis_conn, text: str) - str | None: fp get_dedup_key(text) ok redis_conn.set(fcomment:fp:{fp}, 1, nxTrue, ex7 * 24 * 3600) return text if ok else None这里有个细节经常被忽略表情符号不能一律删掉。、、这类 emoji 直接承载了用户情绪删掉等于丢掉重要特征。正确做法是单独把 emoji 抽取出来作为情感辅助字段。清洗后的文本拿去算情感emoji 标签拿去修正置信度两路特征都比只保留纯文本要好。3.3 第三关增量更新与失败重试增量采集的关键是记住“上次跑到哪里”。最普通的方案是把游标存到 Redis比如记录最后一页的翻页游标或者最后一条评论的时间戳定时任务启动时先读取然后从这个位置继续。这里我用 APScheduler 做调度每 10 分钟跑一次增量任务失败的任务进入重试队列。网络请求不可能永远成功所以重试策略必须带指数退避。我习惯用 tenacity 库from tenacity import retry, stop_after_attempt, wait_exponential retry(stopstop_after_attempt(3), waitwait_exponential(multiplier0.5, min1, max10)) def request_with_retry(url, params): resp requests.get(url, paramsparams, timeout10) resp.raise_for_status() return resp.json()有个容易被忽视的点不要把原始 HTML 直接存数据库。清洗后的纯文本、抽取出的图片链接、发布账号、发布时间、所属渠道这些字段才有长期价值。原始 HTML 只会占用大量磁盘空间后期查询还慢。4. 情感分析与主题聚合模型选型、调参和偏差修正4.1 SnowNLP 的情感得分能不能直接用SnowNLP 是很多 Python 入门者接触情感分析时用的第一个库接口简单一个sentiments属性就能输出 0 到 1 的得分。但它的训练语料集中在电商评论领域直接拿去做旅游、餐饮、美妆评论分析偏差会很明显。比如“住在山里非常安静孩子玩得很开心”这种句式模型打得还行但“人巨多排队俩小时进去十分钟就出来了”这种典型差评模型很容易给成中性。正确的做法是采集一批目标领域语料重新训练。手动标注 1500 条正面、1500 条负面然后from snownlp import sentiment sentiment.train(data/travel_neg.txt, data/travel_pos.txt) sentiment.save(travel_model.marshal)使用的时候把模型路径传进去from snownlp import SnowNLP s SnowNLP(排队两小时风景也就那样, pathtravel_model.marshal) print(s.sentiments)这里提醒一句不同版本的 SnowNLP 对path参数的支持可能有差异。我在项目里是在进程启动时全局加载一次避免每条评论都重新读模型文件浪费 I/O。训练语料不是越多越好但要覆盖目标业务的典型表达。比如做景区舆情就得多收集“缆车排队”、“门票贵”、“停车难”、“民宿踩雷”这类句子否则模型永远学不到领域里的负面表达。4.2 规则层修正处理否定词、程度副词和领域惯用语光靠模型不够。我们实际测试中发现带有否定词的句子经常被预测错最具代表性的就是“这个景点一点都不冷清”。“冷清”在旅游评论里是负面词模型看到它就容易打低分但实际上加上“不”字整句话变成正面。规则层做的事情很简单在模型分数基础上根据否定词、程度副词、领域惯用语做修正。negations {不, 没, 不太, 并不, 一点也不} boosters {非常, 太, 超级, 极其, 真的} attenuators {有点, 稍微, 略显} def rule_adjust(text: str, base_score: float) - float: # 领域正话直接用白名单拉高分数 if any(w in text for w in [不冷清, 不坑, 没踩雷, 值得再来]): return min(1.0, base_score * 1.3 0.2) # 出现否定词且模型分偏低反转或拉高 for w in negations: if w in text and base_score 0.45: return max(0.0, 1 - base_score) # 程度副词增强/减弱 if any(w in text for w in boosters): return min(1.0, base_score * 1.15) if any(w in text for w in attenuators): return max(0.0, base_score * 0.9) return base_score这个规则肯定不完美但它能把误判率降一个量级。重点是规则要小步迭代每星期抽样几百条预测结果把典型错例加进规则或语料里慢慢补。比起一开始就上深度学习模型这种“轻量模型规则兜底”的组合在小团队场景下更容易维护。4.3 主题聚合先用 TF-IDF 顶住别急着上 LDA主题模型 LDA 在小语料上极不稳定换一次随机种子结果可能完全变样。我们在项目一期直接放弃了 LDA改成“TF-IDF 提取关键词 人工规则做负面归因”。负面归因就是把差评按维度分类比如景区场景可以分成交通、住宿、票务、卫生、服务、体验。这样老板看到的不只是“今天有 200 条负面”而是“今天负面集中在停车难和排队时间长”。用 jieba 做分词后再用 TF-IDF 提取关键词import jieba from sklearn.feature_extraction.text import TfidfVectorizer def jieba_tokenizer(text): return [w for w in jieba.cut(text) if w.strip() and len(w) 1] corpus [停车场离景区大门太远, 门票涨价就算了还排长队, 工作人员态度很差] # 示例 tfidf TfidfVectorizer(tokenizerjieba_tokenizer, max_features2000) matrix tfidf.fit_transform(corpus) feature_names tfidf.get_feature_names_out() top sorted(zip(matrix.sum(axis0).A1, feature_names), reverseTrue)[:20] print([word for _, word in top])负面归因的分类器不用写得太复杂。先人工给 1000 条负面样本打上类别标签再用关键词规则覆盖 80% 的常见场景剩下 20% 留给人工去补规则。这样的可解释性反而比黑盒分类模型好运营同学也能自己维护规则库。5. 存储层设计MySQL、MongoDB、Redis 各管哪一段5.1 原始数据与统计结果的分工原始评论全部进 MongoDB因为来源平台不同、字段差异大。有的带图片链接有的带地理位置有的有转发数如果一开始就把 schema 定死在 MySQL后期加字段就是一场灾难。MongoDB 文档模型天然适合这种半结构化数据。MySQL 只存结构化统计结果和查询频繁的字段。比如每条评论的最终情感分、情感标签、发布时间、来源渠道、关键词、所属省份。这样报表查询走 MySQL全文检索和复杂字段的备份走 MongoDB各司其职。建表语句参考CREATE TABLE comment_sentiment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, source VARCHAR(32) NOT NULL, comment_id VARCHAR(64) NOT NULL, url_hash CHAR(32) NOT NULL, sentiment_score DECIMAL(3, 2) NOT NULL, sentiment_label VARCHAR(16) NOT NULL, keywords VARCHAR(512), province VARCHAR(32) DEFAULT NULL, publish_time DATETIME NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_url_hash (url_hash), KEY idx_source_time (source, publish_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里有两个关键点。第一个是url_hash必须加唯一索引这是数据库层的最后一道去重保障防止同一个评论在爬虫重试后重复入库。第二个是utf8mb4字符集不用它的话 emoji 保存会直接报错或者变成问号。5.2 统计任务怎么设计不容易跑死最容易犯的错是在一条大 SQL 里对整张表做全量聚合。数据量一旦过了百万行那种SELECT COUNT(*) ... GROUP BY会把 MySQL 拖垮。我的做法是先把原始评论按天导出或者按小时聚合聚合结果存到daily_stats表报表只读这张小表。日报、周报、月报都从日统计表继续向上卷而不是每次从原始表重新算。如果后续数据量真的涨到需要分布式计算再把原始数据导出成 JSON 文件放到 HDFS用 Spark 做离线任务。一段示例是from pyspark.sql import SparkSession spark SparkSession.builder.master(yarn).appName(daily_comment_stat).getOrCreate() df spark.read.json(hdfs:///data/comments/*.json) df.createOrReplaceTempView(comments) spark.sql( SELECT source, sentiment_label, COUNT(*) AS cnt FROM comments WHERE publish_time 2025-01-01 GROUP BY source, sentiment_label ).show()但我会反复提醒自己迁移到 Spark 不是技术先进性问题而是成本和收益问题。十几个人维护一个 Spark 集群如果只是为了跑每天几百万行的 group by确实不划算。6. 可视化与预警把统计结果变成能直接指挥行动的看板6.1 Flask 聚合接口设计大屏不是直接把数据库表放出来而是把业务问题翻译成接口。我做了三个核心接口/api/overview返回总体声量、正负面数量/api/trend返回按天趋势/api/topics返回负面关键词和归因分类。一个趋势接口的示例app.get(/api/trend) def trend(): days int(request.args.get(days, 7)) sql SELECT DATE_FORMAT(publish_time, %%Y-%%m-%%d) AS d, SUM(sentiment_score 0.6) AS positive, SUM(sentiment_score 0.4) AS negative FROM comment_sentiment WHERE publish_time DATE_SUB(CURDATE(), INTERVAL %s DAY) GROUP BY d ORDER BY d rows query_db(sql, (days,)) return jsonify({code: 0, data: rows})这里有个小坑在 Python 的 MySQL 参数化查询里如果驱动不同SQL 中的%可能需要写成%%否则会被当成参数占位符。我因为这个报错过半小时排查到最后就是一行百分号的问题。前端直接使用 ECharts 的 line 图fetch(/api/trend?days7) .then(r r.json()) .then(res { const dates res.data.map(x x.d); const pos res.data.map(x x.positive); const neg res.data.map(x x.negative); chart.setOption({ xAxis: { data: dates }, series: [ { name: 正面, type: line, data: pos }, { name: 负面, type: line, data: neg } ] }); });不要把前端搞得太复杂。项目里有人提议用 Vue Element UI 重写大屏被我否了。一个只给内部看的数据大屏单页面 HTML 引入 ECharts 就够了。少一个工程化的前端项目就少一堆构建链路的维护成本。6.2 预警规则负向飙升不是看绝对值而是看异常预警是最容易做出“狼来了”效果的模块。如果简单设置“负面数量超过 100 条就报警”平时日负面向来只有二三十条的业务会被阈值拍死而如果业务旺季日正面就有一千条100 条负面反而可能是正常现象。所以我用的是三西格玛异常检测取最近 7 天同一时段的数据计算均值和标准差当当前值超过均值 3 * 标准差时触发预警。这个规则不需要机器学习模型效果却比固定阈值靠谱得多。import statistics def is_anomaly(current: float, history: list[float]) - bool: if len(history) 7: return False mean statistics.mean(history) std statistics.pstdev(history) return current mean 3 * std触发预警后的推送可以走企业微信机器人或钉钉机器人一个requests.post就够import requests def send_alert(text: str): webhook https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyYOUR_KEY data {msgtype: text, text: {content: text}} requests.post(webhook, jsondata, timeout5)预警一定要加冷却时间。我在 Redis 里存一个alert:cooldown:{rule_name}设置一小时过期防止同一个异常触发一轮又一轮的报警轰炸。没有冷却的预警系统上线第二天就会被运维关掉。7. 上线前后踩过的四个大坑现象、排查链路与修复7.1 时区错乱导致“凌晨三点爆热搜”上线第二天看趋势图发现凌晨零点到一点出现了一波巨大的声量高峰。第一反应是有人刷量后来查了原始数据才知道平台接口返回的时间字段带Z后缀也就是 UTC 时间。存库时没有统一转换直接把 UTC 当成北京时间存了进去真实发生在早上八点的评论全被挪到了凌晨。排查链路是先看趋势图发现异常时段再抓几条原始数据比对publish_time最后确认是时区问题。修复很简单统一在数据入库前转成带时区的datetime展示层再转北京时间from datetime import datetime, timezone, timedelta cst timezone(timedelta(hours8)) dt_utc datetime.fromisoformat(raw_time.replace(Z, 00:00)) dt_cst dt_utc.astimezone(cst)这个坑提醒我所有时间字段在代码里都要有一个明确的“模型”要么全存 UTC要么全存北京时间绝不允许混着用。7.2 情感模型误判“这一点都不冷清”随机抽样检查中我拿 100 条人工标注结果和模型预测结果做对比发现准确率只有 67%。仔细看错例集中在一类句式句子里有明显的负面词但前面有否定词比如“不冷清”、“不坑”、“没踩雷”。模型抓到“冷清”、“坑”、“踩雷”这些词后直接给负分。根因确认后我在规则层加了两样东西。第一是领域正面惯用语白名单第二是整个句子的否定词检测。改完后同一批样本准确率提升到 83%。要说明的是这 83% 是在样本不大、规则人工维护的前提下得出的不是模型本身变强了。但做业务系统规则兜底往往比换复杂模型见效更快。7.3 爬虫被限流后整条链路堵死系统上线第三周MongoDB 写入量突然掉到几乎为零但 Redis 队列的长度在疯狂上涨。查服务日志发现采集任务里一个慢请求占住了所有并发槽位后面排队等着的链接全部超时超时又触发无限重试把队列越堆越满。修复方法三管齐下设置DOWNLOAD_TIMEOUT让慢请求快速失败调低CONCURRENT_REQUESTS_PER_DOMAIN防止把目标站点打崩给重试次数加上限并记录失败原因。最重要的教训是采集系统必须把队列当作缓冲调度端永远要有限流机制否则一个平台的网络抖动会影响整条数据链路。7.4 服务器上没有中文字体词云全是“豆腐块”开发机上词云显示正常部署到 Linux 服务器后所有汉字变成了方框。排查了一圈不是代码问题是服务器字体库里根本没有中文字体wordcloud 库找不到能渲染汉字的字体文件。修复方式apt-get install -y fonts-wqy-zenhei然后在代码里显式指定字体路径from wordcloud import WordCloud wc WordCloud( width1200, height600, font_path/usr/share/fonts/truetype/wqy/wqy-zenhei.ttc, background_colorwhite )这类问题特别坑因为它不会报错只会默默输出一堆方框。后来我在部署检查清单里加了一条所有涉及图片生成的服务必须先确认目标机器的字体环境。8. 系统跑稳之后我才想明白的事这套舆情系统真正稳定上线之后我最大的体会是最花时间的不是写采集代码不是调情感模型而是数据标注和规则迭代。每周固定抽样本、看错例、补规则、重新评估准确率这个循环才是整个系统的护城河。换一个会写 Python 的人两三周也能把系统搭出来但只有经历了数据循环的人才知道哪些词在哪个渠道里有特殊含义。另外一个经验是别把“舆情分析”做成一个孤立的定期报表。真正有价值的是把情感分析结果和业务行为打通比如景区发现某一时段负面集中立刻推给现场运营去处理。一个能触发行动、能闭环反馈的系统才值得持续投入资源维护。后续如果要升级我会考虑接本地化部署的文本大模型做摘要和归因但前提一定是把上一阶段的准确率指标和人工审核链路先固化下来否则模型升级只会带来更多不可控的误判。