PLFM_RADAR，全称叫 Platform Radar，中文我一般叫它“平台监测雷达”。做这个项目之前，我一直在跟电商运营和内容运营打交道，最大的痛点就是“看不全、反应慢”：竞品什么时候偷偷改了价格，某个商品链接什么时候突然起量，抖音上哪个话题在凌晨开始发酵——这些信息往往要等到第二天才被同事截图甩到群里。等你知道的时候，流量红利已经过去了一半。所以我花了几个月时间，从零搭了一套能对多个内容平台、电商平台做“雷达式”扫描的监测系统，定时抓取指定关键词、指定店铺和指定商品的数据，算出热度指数和变化斜率，一旦出现异常波动就立刻推送告警到钉钉、企业微信或者邮件。
这套系统的目标用户很清晰：电商运营、内容运营、产品经理、市场调研人员，也包括像我这样喜欢自己做数据分析工具的独立开发者。它解决的不是“监控某一个平台”的单一问题，而是“如何在信息过载的环境里，第一时间锁定值得关注的变化”。这篇文章我会把 PLFM_RADAR 的整体设计、核心模块、落地实现和踩坑记录完整拆开来讲，希望能给准备做类似平台监控、舆情雷达、竞品跟踪工具的朋友一些可直接参考的干货。
1. 项目定位与整体设计思路
1.1 为什么叫“雷达”而不是“监控”
传统意义上的监控，更多是“盯着一个点看”——比如盯一个商品页面的价格，盯一个账号的粉丝数，数据变化了就在图表里显示出来。但雷达不一样，雷达的特点是“扫描一片区域，发现可疑目标”。PLFM_RADAR 的核心思路就源于这个差异：它不是先告诉你“去看某个链接”，而是先替你扫一圈，把待观察对象里变化最剧烈的目标挑出来，推到你面前。
所以在设计上，我把它分成三个动作：扫描、聚焦、告警。扫描阶段用低成本方式对候选目标做宽口径检测，聚焦阶段对异常目标做深度抓取，告警阶段再把结果以人类能理解的方式推送出去。这三个动作对应到系统结构上，就是采集层、分析层和通知层。这个思路比“对每个目标做高频全量抓取”要节省一半以上的资源，因为你永远只对“有变化信号”的对象加大采集力度。
1.2 关键需求拆解与方案取舍
我在动手前给自己列了必须要满足的四条需求，并用一个对比表格确认了技术选型方向：
| 需求 | 说明 | 技术选型 |
|---|---|---|
| 多平台统一接入 | 不同平台数据结构差异大，采集方式不同 | Scrapy + Playwright，统一输出标准事件格式 |
| 定时任务调度 | 按不同频率扫描，高峰加频 | Celery Beat + Redis Streams |
| 异常信号识别 | 需要自动发现波动，而非纯人工看报表 | EWMA + Z-Score 双重判断 |
| 通知触达 | 及时推送到内部协作工具 | 钉钉/企业微信 Webhook + 邮件兜底 |
选型的核心逻辑是“能用现成组件解决的，不自己造轮子”。比如定时调度直接用 Celery Beat，不引入 K8s CronJob，因为单机部署够用；消息队列用 Redis Streams 而不是 Kafka，因为我这场景吞吐量每小时也就几万条事件，Kafka 的运维成本在这个量级完全没必要。这个取舍原则我一直很坚持：很多工具说不上谁绝对更好，关键是匹配你的数据规模和团队维护能力。
1.3 雷达的“目标库”设计
雷达要扫描一片空域，首先得定义“空域”是什么。对 PLFM_RADAR 来说，目标库就是一张张关键词表、店铺 ID 表和商品 ID 表，存放在 PostgreSQL 里，支持按项目分组。
我特意给目标库设计了一个优先级字段：A 级目标（核心竞品、重点关键词）每 10 分钟扫一次，B 级目标每 30 分钟扫一次，C 级目标每小时扫一次。这个分级非常有用，因为平台的访问接口都有频率限制，分级扫描能有效降低被封禁的概率，同时保证最关键的数据永远是最新鲜的。目标库本身管理起来也简单，后期只需要在后台页面增删条目，调度器读取 Redis 里的目标清单即可，改完秒级生效，不需要重启服务。
2. 系统架构与核心链路
2.1 分层架构总览
PLFM_RADAR 从数据流方向分为四层：采集层、传输层、分析层、通知层。每层职责清晰，层与层之间通过标准数据格式解耦。
- 采集层：由 Scrapy-Spiders 和 Playwright 渲染节点组成。轻量级的列表页、价格字段走 Scrapy 直接解析；需要 JS 渲染的页面走 Playwright 无头浏览器，截图存档。
- 传输层：采集到的原始事件统一推入 Redis Streams，按平台名分成不同 Stream Key，比如
stream:tb、stream:dy。 - 分析层：独立的 Worker 进程消费 Stream，清洗、去重、计算热度指数和变化斜率，最后写进 PostgreSQL 和 MongoDB（原始快照）。
- 通知层：独立的告警判断模块，把异常事件格式化后推送到 Webhook 通道。
分层最大的好处是“某一路径坏了不影响全局”。比如 Playwright 渲染节点挂了，Scrapy 采集的电商价格数据流还在走；分析层逻辑升级，采集任务也不需要停。
2.2 事件标准格式定义
所有采集结果在上游就被统一成了相同结构的 JSON 事件，这是多平台接入的关键。我定义的事件字段包括：platform、target_type（keyword/shop/product）、target_id、metric（销售额/点赞数/评论数/价格等）、value、ts，外加可选的extra字典。
这个格式看起来简单，但它解决了一个大问题：分析层不用关心数据来自哪个平台，只需要按metric和target_id聚合计算。平台差异在采集层消化，分析层永远面对的是“干净的事件流”。如果你也想做类似项目，强烈建议先把这个标准格式想清楚，不然后面每接入一个新平台，分析代码就要跟着改一遍。
2.3 采集频率的“自适应”机制
雷达有意思的地方在于“有目标了才加大功率”。我的调度器用同样思路做了自适应频率处理：正常情况下按目标优先级固定频率采集，一旦某个目标的指标在某轮检测中触发“预关注阈值”（比如热度指数单轮涨幅超过 40%），调度器会主动把该目标的采集频率临时提高到最短 2 分钟一次，连扫 6 轮；如果之后恢复正常，再降回原频率。相当于雷达自动锁定了一个可疑目标进行跟踪。这个机制让我抓到了好几次新品起量的第一时间窗口——通常在关键词搜索榜上榜前几个小时就能看到信号。
3. 核心模块实现：热度模型与异常检测
3.1 热度指数怎么算才可信
热度指数是 PLFM_RADAR 的“信号放大器”。不同平台的量纲不同——抖音的点赞数和淘宝的销量没法直接比，所以必须做归一化和加权。我使用的热度公式是：
H = (0.4 * velocity_norm) + (0.35 * interaction_norm) + (0.25 * base_norm)其中velocity_norm是当前周期相对前一周期的新增量（归一化后），interaction_norm是互动量（点赞、评论、分享）的移动平均值归一化，base_norm是历史基数的归一化。这个公式的核心思想是：增量比总量更重要，互动比展示更重要。一个商品销量从 100 涨到 10000，和一个商品从 100000 涨到 101000，前者显然更值得关注，但绝对值模型会给出相反的结论。所以我把增量的权重抬到最高。
归一化我用的是 Min-Max + 对数压缩。先对原始值取log(1 + x)压掉长尾，再做 Min-Max 归一到 0~1 区间。这个细节很重要：如果不做对数压缩，头部大爆款会把所有腰部数据压成接近 0，雷达就失效了。
3.2 异常检测算法选择与原理
异常点检测我试过多种方案，最终稳定使用的是EWMA（指数加权移动平均） + Z-Score的组合。
EWMA 公式是E_t = α * x_t + (1 - α) * E_{t-1}，α 取 0.3，它对近期数据更敏感，能自然捕捉“趋势的变化”。然后我用当前值距离 EWMA 的偏差除以滚动标准差得到 Z-Score，当 Z-Score 绝对值大于设定阈值时触发告警。
z = (current_value - ewma_value) / rolling_std if abs(z) > threshold: trigger_alert()这里有一个明显的坑：如果直接拿原始销量做 EWMA，节假日和平台大促带来的自然波动会频繁误报。所以我对“环比增量”做 EWMA，而不是对原始值。简单说，检测的对象是“加速度”，不是“速度”。这个改动之后，告警准确率从最初的 60% 左右提升到了 88% 以上。
3.3 告警阈值调优经验
阈值调优没有捷径，只能靠标注样本反推。我把历史数据里人工确认为“重要事件”的时间点全部捞出来，计算它们的 Z-Score 分布，然后选了能覆盖 90% 重要事件的最低 Z 值作为初始阈值。
以我的数据规模来说，电商平台 Z 值设在 2.5，内容平台设在 3.0 比较合适。因为内容平台的自然波动比电商更大，阈值低了会天天被“正常热点”轰炸。另外我还加了一个“连续触发”规则：不要求单轮触发就告警，而是连续两轮都触发才推送。这一条规则把误报率又砍掉了三分之一。调优的过程本质是“在你的业务噪音和信号之间找分割线”，换一个平台就得换一套参数，不能偷懒。
4. 落地实现与关键代码解析
4.1 采集端的两种写法
采集端我同时保留了 Scrapy 和 Playwright 两条路径。以抖音商品列表页为例，Scrapy 负责接口直连；如果接口被风控挡了，就降级到 Playwright 模拟真人滚动页面。
一个典型的 Scrapy Spider 骨架大致长这样：
import json import scrapy from PLFM_RADAR.items import RadarEventItem class DouyinSpider(scrapy.Spider): name = "douyin_keyword" def start_requests(self): targets = self.get_targets(platform="dy", target_type="keyword") for t in targets: api_url = f"https://xxx/dy/search?kw={t['key']}" yield scrapy.Request(api_url, meta={"target": t}, callback=self.parse) def parse(self, response): data = json.loads(response.text) for item in data["items"]: event = RadarEventItem( platform="dy", target_type="product", target_id=item["product_id"], metric="sale_count", value=item["sale_count"], ts=self.get_now_ts(), extra={"title": item["title"]} ) yield eventPlaywright 端的核心则是一个渲染函数，用page.goto()打开目标页面后等待networkidle，再执行滚动脚本触发懒加载，最后把 DOM 里关键的 JSON 数据extract出来。注意必须在无头浏览器里设置真实的 UA 和 Viewport，不然很多平台直接返回验证码页。
4.2 消息缓冲与消费逻辑
采集端拿到的事件不会直接写数据库，而是推到 Redis Streams。这样做的好处是削峰填谷：平台方的接口响应速度不均匀，如果直接用同步方式写库，数据库压力会忽高忽低。Redis Streams 本身支持消费组和消息确认，我用一个独立消费者进程做批量落库。
import redis import json r = redis.Redis(host="localhost", port=6379, decode_responses=True) def publish_event(event: dict): r.xadd( f"stream:{event['platform']}", {"data": json.dumps(event)}, maxlen=10000, approximate=True )maxlen在这里很重要。如果不限制，消息积压会撑爆 Redis 内存；限制为 10000 条意味着哪怕消费者暂时挂了，重启后也只会丢最多最近一万条事件，对监测场景完全可接受。
4.3 分析 Worker 的状态机
分析层我实现了一个轻量状态机：每个目标对象有以下状态——normal、watching、alerting、cooldown。状态流转逻辑是：
normal状态下，Z-Score 超过阈值进入watching，不立即告警。- 下一轮仍超阈值，
watching转alerting，发送通知并记录事件。 - 发送完进入
cooldown，6 小时内同一目标不再重复告警，避免“告警疲劳”。 - 如果某轮 Z-Score 回落，直接从
watching回normal。
这个状态机用一张 Redis Hash 存储目标状态，比在数据库里维护状态要快很多，重启服务也不会丢现场。告警后加 cooldown 是非常必要的产品设计，没有冷却期的告警系统，最后一定会被用户手动屏蔽。
4.4 可视化看板
虽然强调自动告警，但一个供人工抽检的看板必不可少。我用 FastAPI 提供查询接口，前端用 Vue3 + ECharts 做了一张雷达图风格的仪表盘：横轴是时间，纵轴是热度指数，每个目标显示在对应位置，“锁定”的异常目标在图表上放大提高亮度。
页面上额外增加了“目标状态总览”表格，实时显示每个目标处于normal/watching/alerting的哪个状态，以及最近一次扫描时间和当前 Z-Score。这样哪怕人不在电脑前，回来看一眼图表也能快速掌握整体态势，不用翻告警日志。
5. 常见问题排查与避坑指南
5.1 采集端最容易翻车的三个问题
首先是动态页面的懒加载。很多平台页面只有滚动到底部才加载后续数据，如果直接用 requests 拉 HTML，永远只能拿到前 20 条。这个问题的对策是固定滚动策略：无头浏览器每 500ms 滚动一次，总共滚 5~8 次，等到页面高度不再变化才结束数据提取。
其次是接口签名问题。不少平台的列表接口带sign或token参数，直接拿到 URL 也调不通。我一开始也试过逆向 JS，但维护成本实在太高。后来改用 Playwright 拦截页面发出的网络请求，从请求包里直接读取真实接口的响应——这招叫“被动监听”，比主动模拟接口稳定得多，平台改签名逻辑也不会影响你。
第三个坑是触发反爬后的“假数据”。有些平台对疑似爬虫的账号会返回一个降级页面，页面看起来正常但没有真实数据，或者所有销量被统一改成 0。如果不做校验，这些脏数据会污染热度模型。我的解决办法是给每个采集任务加“业务校验规则”：比如销量大于 0 的比例低于 20% 时，判定本次采集异常，丢弃整批数据并标记目标为“采集受限”。
5.2 告警延迟和重复告警问题
告警延迟的一个隐蔽原因在 Redis Streams 消费端：如果消费者进程单条处理数据，碰上大促期间事件暴涨，消费速度跟不上，告警自然就慢半拍。后来改成xreadgroup批量读取，一次取 500 条，按目标 ID 分组后并行计算，延迟从平均 90 秒降到了 15 秒以内。
重复告警则基本都出在状态机实现不严谨上。早期我的状态判断直接用目标当前 Z-Score，忽略了同一个目标可能在同一轮被多个 Scanner 同时消费，导致重复推送。后来在状态机写入时加了 Redis 的SETNX锁，同一个目标同一时刻只有一个 Worker 能改状态，重复问题彻底解决。
5.3 常见问题速查表
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
| 某个平台一直无新数据 | 目标被平台风控，返回验证码 | 检查采集日志里的 HTTP 状态码，切换 Playwright 降级路径 |
| 告警频率过高 | 阈值偏低或检测对象用了原始值 | 改对环比增量做 EWMA，调高 Z 阈值 |
| 热度指数大多为 0 | 归一化没用对数压缩 | 对原始值先做 log(1+x) 再归一化 |
| Redis 内存暴涨 | Stream 没限制长度 | 加 maxlen 或设置过期策略 |
| 数据库写入慢 | 单条写入而非批量 | 消费端攒批 10 秒或 500 条再批量插入 |
| 告警间隔太长 | 冷却期设置过大 | 区分告警类型，A 级目标冷却期缩短到 2 小时 |
6. 后续可扩展的方向与我的个人体会
PLFM_RADAR 现在稳定跑在我的一台 4 核 8G 的小服务器上，Docker Compose 一键启停，依赖的服务只有 PostgreSQL、Redis、Nginx 和两个 Python Worker。整套系统从设计到落地最让我骄傲的不是某个算法多厉害，而是它确实改变了团队的日常协作方式——大家从“等别人发现变化”变成了“系统先告诉我们该看哪里”。
如果后续要扩展，我建议优先考虑这几个方向：
一是接入更多数据源类型，比如把搜索指数、广告投放数据、达人粉丝画像纳入雷达扫描范围，让“热度信号”从单一平台扩散到全网维度。
二是增加“事件归因”功能。目前雷达能发现异常，但还不能解释异常原因。我计划在告警事件里关联同时间窗口内的其他指标变化，比如某商品销量上涨的同时，是不是对应达人发布了种草视频，自动生成一条“可能的影响链”附在告警通知里。
三是把告警从“被动推送”升级为“主动报告”。每天固定时间生成一份《昨日平台异动日报》，按异常程度排序，像晨报一样推送到邮箱。实测这种形式比实时告警更受管理岗同事欢迎。
最后分享一个实际运维中的小技巧：把告警关键词做成简单的正则白名单，比如只关心“新品首发”“价格下调”“库存告急”这几类事件，能显著降低团队在正常运营波动上的注意力消耗。雷达的目的是帮人节省注意力，而不是抢占注意力，这个原则贯穿了 PLFM_RADAR 的所有设计。希望我的这套经验能给你一些启发，如果你也在做类似的平台监测工具，欢迎拿着文章里的思路去验证，特别是热度模型和状态机那两块，改动成本低，收益却很明显。
