PLFM_RADAR 这个项目名乍看有点抽象，拆开就清楚了：PLFM 基本就是 Platform 的缩写，RADAR 是雷达。合起来就是一个“平台雷达”系统——把多个数据源持续扫一圈，把散落的信号、动态、异常波动统一收进来，做成一个实时更新的态势感知面板，像雷达一样周期性扫描地平线。
这几年我做过的数据监控类项目不少，但这个项目比较特殊。它不是简单的爬虫入库，也不是传统 BI 报表，而是把“周期性扫描”和“信号判定”结合起来——扫描频率、信号阈值、多维度权重打分、雷达图可视化，每一环都需要仔细设计。如果你正在做平台数据监控、竞品动态跟踪或者舆情预警类的东西，这篇复盘应该能给你几条能直接抄作业的思路。
1. 项目定位与方案选型
1.1 为什么叫“雷达”而不是“监控”
监控这个词太被动了——通常是出了问题才知道，盯着日志和指标看。雷达不一样，雷达是主动扫描，周期性地向四周发射探测波，然后根据回波判断目标。
PLFM_RADAR 的核心思路就是这个：轮询式扫描 + 信号判定 + 可视化呈现。系统按固定的时间间隔去各个目标平台拉取数据，拉回来之后不是简单存起来，而是立刻做一次信号分析——有没有新目标出现、有没有指标异常、有没有趋势突变。如果有，就把这批信号标记出来，推送到面板前端。
换句话说，传统监控回答的是“系统挂没挂”，PLFM_RADAR 回答的是“平台上发生了什么值得注意的事”。这两个问题看着接近，但实现逻辑差别很大。
1.2 自研 vs 直接用开源监控工具
最开始有人提议直接用 Prometheus + Grafana 那一套，毕竟现成、稳定，画图也漂亮。但仔细评估之后放弃了，原因有三：
一是数据形态不匹配。Prometheus 是为服务器指标设计的，时序模型很固定。但 PLFM_RADAR 要做的不只是数值指标，还包括文本信号、分类标签、业务事件。强塞进 metric 模型里会很别扭。
二是信号判定逻辑太重。Prometheus 的告警规则适合做阈值判断，但我们的信号判定涉及多个维度加权打分，还要结合历史基线对比，用 PromQL 写起来极其痛苦，后期维护更是灾难。
三是可视化需求特殊。雷达图是这套系统的标志性界面，Grafana 虽然插件多，但要做一个动态更新的多维度雷达面板，还是自己写前端更可控。
所以最终方案是：Python 做数据处理和信号判定，Go 写 API 服务，前端用 ECharts 做雷达图可视化。数据存储用了 ClickHouse，后面细说为什么用它。
1.3 核心功能拆解
PLFM_RADAR 最终交付的核心功能有这么几块：
- 多源数据采集：支持同时接入多个平台数据源，每个源独立配置扫描周期和接口参数
- 信号信号解析：对采集到的原始数据做清洗、结构化、特征提取，转成统一格式
- 多维度信号判定：从活跃度、增长率、异常波动、文本情绪、交互质量等维度给每个目标打分
- 雷达图可视化：把打分结果映射到雷达图的多条轴上，一眼看出哪个方向有信号、哪个方向沉寂
- 信号事件追踪：对标记出来的异常信号自动创建事件记录，持续跟踪后续变化
- 告警通知：信号强度超过阈值时，通过 Webhook 推送到即时通讯工具（这里用企业微信机器人）
- 历史回溯：所有原始数据和信号记录都落库，支持按时间范围回放当时的雷达状态
这套组合下来，整个系统至少能覆盖从“数据接入”到“决策辅助”的完整链路。
2. 系统架构与数据链路设计
2.1 四层结构：从采集信号到决策辅助
PLFM_RADAR 的架构分四层，每一层各司其职。
第一层是数据接入层。这一层负责对接各平台的数据接口。每个平台写一个独立的采集器（Collector），实现相同的接口，但内部逻辑各自独立。这样新增平台只需要新写一个 Collector，不用动其他代码。采集器支持两种模式：主动轮询和 Webhook 被动接收。主动轮询就是定时去拉接口；Webhook 模式是平台有事件时主动推过来。我把两种都做了，轮询为主，Webhook 作为补充，因为很多平台的 Webhook 并不是实时可靠。
第二层是信号处理层，这是整套系统的大脑。原始数据进来之后先清洗，去掉明显无效的字段，然后做特征提取——把文本数据转成情绪评分、把计数数据转成变化率、把分类数据转成独热向量。接着进入信号判定器，这一层会结合历史基线判断当前这批数据有没有值得关注的信号点。
第三层是存储层。时序数据用了 ClickHouse，原因下面专门讲。业务元数据用 MySQL，Redis 用来做缓存和临时状态存储。
第四层是展示与交互层。后端 API 用 Go 写的，提供雷达图数据接口、信号事件接口、趋势查询接口。前端是 Vue + ECharts，雷达图是核心页面，旁边配信号事件流列表。
2.2 存储选型：为什么是 ClickHouse
这个决策是我在项目推进到一半的时候重新做的。一开始我用了 PostgreSQL 存所有数据，但跑了一周之后发现两个问题：
第一，数据量增长太快。多个平台、多个目标、每隔几分钟一轮扫描，一周就积累了上千万条信号记录。PostgreSQL 在这种规模下做聚合查询已经有点吃力了。
第二，雷达图后端需要按多种维度做聚合统计。比如“按小时统计某个平台所有目标的活跃度分布”“按天统计信号强度的均值与峰值”。这种多维聚合正是 ClickHouse 的强项。
于是把时序数据迁移到了 ClickHouse。表结构大致长这样：
CREATE TABLE signal_records ( platform LowCardinality(String), target_id String, ts DateTime64(3), dim_active Float32, dim_growth Float32, dim_anomaly Float32, dim_sentiment Float32, dim_interaction Float32, signal_score Float32, event_type LowCardinality(String), raw_data String ) ENGINE = MergeTree() PARTITION BY toYYYYMMDD(ts) ORDER BY (platform, target_id, ts);几个关键设计：
LowCardinality类型用在 platform 和 event_type 上，因为值种类很少，查询很快，存储也更省- 分区按天，每天一个分区，清理旧数据直接 drop partition，不用 DELETE
- 排序键是 (platform, target_id, ts)，这样按平台查目标的时间序列几乎就是顺序读，性能极好
这个表结构稳定运行到现在，千万级数据量下雷达图接口的响应时间基本都在 200ms 以内，很稳。
2.3 采集器的统一接口设计
每个数据源的采集器实现统一接口，这是我踩过坑之后总结出来的。最初第一个平台我写得很随意，第二个平台接入的时候发现没法复用，被迫重构，浪费了三天。
统一接口长这样：
class BaseCollector(ABC): @abstractmethod def fetch(self, last_since: datetime) -> list[RawRecord]: """拉取自上次扫描以来的新数据""" @abstractmethod def parse(self, raw: dict) -> NormalizedRecord: """把平台原始格式转成统一数据模型""" @abstractmethod def health_check(self) -> bool: """检查数据源连接是否正常""" @property @abstractmethod def platform_name(self) -> str: """平台标识, 全局唯一"""fetch的入参是last_since，这很关键。每个平台返回的数据只要增量，按时间过滤，避免重复拉全量parse是数据源适配的核心，把五花八门的平台字段映射到统一的 NormalizedRecord 结构health_check用来感知数据源本身是否挂了，挂了就跳过不阻塞主链路
只要新平台能实现这四个方法，就可以无缝接入雷达系统，主流程完全不用改。
3. 信号处理机制与实现细节
3.1 信号强度的五维评分模型
雷达图可视化的核心是维度评分。我用了五个维度，每个维度 0 到 100 分，五条轴构成雷达形状。这五个维度是反复试出来的组合：
- 活跃度（dim_active）：反映目标最近一段时间内的总体动作频率，比如发帖数、更新数、登录次数等。这是一个基础量，代表“目标有没有在动”。
- 增长率（dim_growth）：跟上一周期相比的增长幅度。这个维度专门捕捉“突然加速”，活跃度可能只是平均水平，但增长率一旦异动就有信号。
- 异常波动（dim_anomaly）：基于历史基线的偏离程度，用 Z-score 类方法计算。这个维度捕捉的是“不正常的状态”，区别于前两个维度的“正常变化”。
- 文本情绪（dim_sentiment）：对采集到的文本内容做情绪分析，从负面到正面映射到 0-100 分。这个维度对舆情类场景特别重要。
- 交互质量（dim_interaction）：统计转发、评论、点赞这类交互行为，并按互动深度加权。它跟活跃度的区别在于，活跃度只看“发了多少”，交互质量看的是“内容有多少人响应”。
每个维度的计算都独立实现，最后汇总时按权重加权平均。默认权重是：活跃度 0.2、增长率 0.2、异常波动 0.3、文本情绪 0.1、交互质量 0.2。异常波动权重最高，因为雷达的核心使命是捕捉异常，这一点从项目定位上就决定了。
3.2 异常检测：结合滑动窗口基线与 Z-score
异常波动的计算是整个系统技术含量最高的地方，也是最容易出 bug 的地方。
基本方案是维护一个滑动窗口的历史基线。每个目标保留最近 7 天的历史数据，按小时分桶（共 168 个桶），实时计算当前值与历史同期值的偏差。
def compute_anomaly(history, current): # history: 最近N天的历史值列表 # current: 当前周期的观测值 mean = np.mean(history) std = np.std(history) if std < 1e-6: # 历史方差接近0, 任何明显偏离都算异常 return 100.0 if abs(current - mean) > epsilon else 50.0 z_score = abs(current - mean) / std anomaly_score = min(z_score / 3.0 * 100, 100) return round(anomaly_score, 2)这里有个细节：Z-score 理论上是标准正态分布，超过 3 的概率约 0.3%，所以 3 个标准差打 100 分比较合理。但实际数据往往不是正态分布，偏态和长尾很常见，所以直接把 Z-score 线性映射到 100，并没有用 p-value 做非线性变换——工程上够用，而且解释起来更直观。
这个函数被调用之前还有一道预处理：历史数据先做一次离群值截断，把前 5% 的超高值剔除掉，不然一个极端历史值会把标准差拉大，导致当前异常被掩盖。
3.3 转录与汇聚：信号事件生成逻辑
单个异常点不构成信号，信号要“连续、显著、可追踪”才有意义。所以我单独做了一层事件生成逻辑。
事件生成的条件有三个，需要同时满足：
- 信号强度阈值：当前综合评分超过 70 分
- 持续时间：连续两轮扫描（超过一个扫描周期）都满足阈值，防止瞬时抖动误报
- 幅度条件：相对上一个基线周期的提升幅度不低于 30%
满足这三个条件之后，系统会自动创建一条 SignalEvent 记录，包含信号类型、涉及目标、初始强度和当前强度、事件时间线。事件一旦创建，后续每轮扫描都会更新它的“最新状态”，直到信号强度跌破 40 分并持续 3 轮，自动标记为“已平息”。
这套设计解决了一个很实际的问题：如果只对单点异常做告警，运营同事一天能收到几百条通知，最后大家都把通知免打扰了。事件聚合机制把几百条原始信号折叠成了几条真正值得看的结论。
3.4 雷达图后端数据的生成过程
雷达图的前端画起来不复杂，真正的复杂度在于后端要算出“此刻每个维度该显示什么”。
每轮扫描完成后，后端会为每个目标生成一条雷达数据记录，五个维度各一个 0-100 的值，外加综合评分。但这五个值不是同一时刻算出来的，因为五个维度依赖的数据源不同、时间窗口也可能不同。比如活跃度看的是最近 1 小时，增长率看的是环比上一扫描周期，异常波动看的是与历史基线的偏差。
所以我做了一个对齐操作：所有维度的值都对齐到“当前扫描轮次”这个时间坐标，即以当前时刻为基准，往前取对应的窗口期数据。这样雷达图上的每个点都代表“此刻这个目标的状态快照”，语义一致、可对比。
前端拿到的接口返回值格式大致是这样的：
{ "target_id": "tk_1024", "ts": "2024-03-18T14:30:00+08:00", "platform": "platform_beta", "dims": { "active": 76.5, "growth": 82.1, "anomaly": 93.4, "sentiment": 45.2, "interaction": 61.8 }, "signal_score": 78.3, "event_id": "evt_88991" }前端拿到这份数据，直接填进 ECharts 的雷达图配置项即可。单目标展示时画一个雷达；多目标对比时画叠加雷达，颜色区分目标，一眼就能看出谁在哪个维度上突出了。
4. 实操过程中的坑与排查记录
4.1 ClickHouse 对高基数表的查询延迟问题
跑了一阵子之后，雷达接口偶尔会从 200ms 抖到 1.5 秒以上。排查发现是target_id的基数太高，某个平台的目标数量有几十万个，按target_id过滤时索引选择率差，扫描数据块多。
处理方法：给高频查询的场景单独建了一张物化视图，按平台 + 小时粒度预先聚合好五维度的平均值和最大值。查询接口优先读物化视图，明细表只保留 7 天，用于下钻分析。
4.2 文本情绪分析在特定语料上翻车
文本情绪维度最初用的是开源的情感分析模型，中文语料下整体还行，但遇到网络热词、反讽语料就频频翻车。比如“太强了直接开摆”这句话，模型判成了中性偏负面，但实际语境是正面（“开摆”在这里是自我调侃）。
这个问题的解决思路比较务实：在小样本上人工标了一批领域特有词汇，做成一个覆盖层（override layer），先查词表，命中就覆盖模型结果；未命中才走模型。这样既控制成本，又能保证准确率在特定领域内达标。词表大概维护了 120 个词条，效果提升立竿见影。
4.3 扫描任务堆积导致延迟连锁放大
最开始用 Python 的 APScheduler 做定时扫描，平台多了之后就出现任务堆积——上一轮没跑完，下一轮又触发，导致采集延迟越来越大，数据新鲜度持续恶化。
改造方案是把调度逻辑改成“串行消费 + 超时熔断”：所有扫描任务投递到队列里，由一组 worker 消费；每个扫描任务设置三档超时时间（软超时报警、硬超时终止、熔断暂停该平台后续任务）。这个改动之后，哪怕个别平台接口变得很慢，也不会拖垮整体链路。
4.4 采集器被对端限流导致数据缺失
这个坑很经典。某个平台短时间请求太频繁，直接开始返回 429，而且后续一段时间内所有请求都被降级处理。结果就是当天该平台的数据大面积缺失，雷达图上直接凹进去一块。
对策有两层：第一层是退避重试，遇到 429 先停止该平台任务 60 秒，指数退避；第二层是数据补采，检测到缺失时段后，等流量平峰时启动补采任务，把缺的数据追回来。补采逻辑单独跑，不在正常链路里执行，不影响正在进行的扫描。
4.5 奇偶轮次波动导致的误报
某个目标平台的数据，晴雨表的波动本身有周期性。用“上一个完整周期”做环比时，如果恰好碰到周期边缘，增长率计算会异常高，触发误报。
后处理策略是：增长率维度采用“同周期环比”，比如与上周同一天的同一时段对比，而不是简单跟上一个 24 小时比较。同时增加了最小样本量约束——如果当前周期有效样本量不足 5 条，直接把增长率和平共处到中性位置，不参与雷达加权。
4.6 雷达图前端加载卡顿的真凶
雷达图页面加载慢，一开始怀疑是后端接口慢，查了半天性能瓶颈最后发现居然是 ECharts 实例没销毁。前端做了路由切换之后，旧的 chart 实例还挂在内存里，每个雷达图几百个点，累积起来内存就爆了。
解决办法是在组件beforeDestroy（或 Vue 3 的onBeforeUnmount）里调用chart.dispose()，同时在路由切换前清空所有实例的引用。改完之后页面切换流畅了很多，内存也稳定下来了。
5. 关于后续拓展和业务接入
整套系统从设计到落地，我个人有一些感受。
PLFM_RADAR 这种“雷达”思路很适合做成通用能力。我后续已经在规划把它抽象成一套 SDK，让不同业务方接入自己的数据源和目标集，哪怕不懂后端也能配置出属于自己的雷达面板。
有一个比较成功的应用是把雷达的评分结果接入到了业务侧的“重点目标识别”：每天凌晨跑一次全量目标扫描，按信号强度排序，把 top 10 的目标自动推送给运营同事作为当日重点关注清单。这个比人工刷后台高效太多，反馈非常好。
如果你想在自己团队里落地类似系统，我的建议是不要一开始就追求大而全——先选一个平台、一个目标集、三个维度，跑通一轮完整的“采集-分析-展示-告警”闭环，再逐步扩展。雷达图的魅力在于多维度交叉，但前提是每个维度都足够稳定，不然只会得到一个剧烈抖动的多边形，让你什么信号也看不清。
另外，信号阈值这种东西不要拍脑袋定，一定要让业务方参与进来。我最初定的 70 分阈值被运营挑战了好几次，最后是基于两周的线上数据和多次人工复核校准到 70 分的。后续每季度要重新复盘一次阈值，毕竟平台行为特征会随着时间缓慢漂移，一成不变的阈值迟早会失效。
最后分享一个小经验：这类系统的可视化，重要性绝对不能低估。雷达图不是锦上添花，它是信号判定结果的最终出口——一套算法再精准，如果展示得让人看不懂，那也起不到辅助决策的作用。我在设计雷达图时反复调整了轴向标签、配色对比度、数据刷新动画和异常高亮效果，这些细节直接决定了用户是每天打开看还是打开一次就再也不碰。如果你的项目也需要类似的可视化表达，多用真实数据去测试可读性，别在抽象图例上花太多时间。
