3. 需求分析与产品定义：从模糊想法到可执行方案
实时数据产品最怕什么？最怕做出来没人用。我见过太多团队，一上来就搭架构、选引擎，结果业务方说“我要的不是这个”。所以，需求分析这步，省不了。
这一章，我们聊聊怎么把业务方的“我要实时看数据”这种模糊需求，变成可落地的产品定义。说白了，就是搞清楚三个问题：做什么、先做哪个、做成什么样算好。
3.1 识别实时业务场景：哪些场景真的需要“实时”？
不是所有场景都需要实时。我遇到过业务方说“我要实时报表”，结果一问，每天看一次就够了。实时是有成本的——计算资源、存储成本、运维复杂度，都比离线高一个量级。
那怎么判断？我一般看三个特征：
- 决策时效性：数据晚到一分钟，决策就失效。比如风控拦截、交易监控。
- 用户预期：用户天然认为数据应该是“现在”的。比如物流轨迹、订单状态。
- 系统联动：数据需要触发下游动作。比如库存不足自动补货、异常指标自动告警。
满足任意两条，基本就是实时场景。一条都不满足？那离线报表就够了，别折腾。
3.2 需求优先级评估：资源有限，先做哪个？
需求永远做不完。实时产品更是这样——每个业务方都觉得自己那摊事最急。怎么排优先级？我常用一个四象限模型：
具体怎么用？我一般三步走：
- 估价值：这个需求上线后，能帮业务省多少时间？降多少风险？提多少效率？
- 估成本：开发要多久？数据源好不好接？实时链路稳不稳定？
- 排顺序：右上角（高价值低复杂度）先做，左上角（高价值高复杂度）拆成多个版本做。
3.3 实时数据产品PRD撰写要点
实时产品的PRD，和普通数据产品的PRD，写法不太一样。普通PRD可以写“每天凌晨2点更新”，实时PRD不行——你得说清楚“延迟不超过5秒”。
我写实时PRD，一般包含这几个部分：
| 模块 | 内容 | 示例 |
|---|---|---|
| 业务背景 | 谁在用？解决什么问题？ | 运营团队监控大促活动实时效果 |
| 数据范围 | 数据源、字段、更新频率 | 订单表（实时binlog）、用户行为埋点（Kafka） |
| 性能指标 | 延迟、吞吐、准确性要求 | P99延迟≤3秒，峰值吞吐5000 QPS |
| 交互逻辑 | 数据怎么展示？刷新机制？ | WebSocket推送，前端自动更新 |
| 异常处理 | 数据延迟怎么办？断流怎么恢复？ | 超过10秒无数据，显示“数据加载中” |
| 验收标准 | 怎么才算上线？ | 连续24小时无数据丢失，延迟达标 |
这里有个坑——异常处理很多人不写。我曾经有个项目，上线第一天数据源挂了，前端直接显示空白。业务方打电话来骂：“你们这实时系统，还不如我手动刷新Excel！”从那以后，我每个PRD都会写清楚：数据延迟了怎么提示？数据断了怎么恢复？
3.4 关键指标定义：延迟、吞吐、准确性
实时产品好不好，不能靠感觉。得用数据说话。三个核心指标：
3.4.1 延迟（Latency）
延迟就是数据从产生到可被消费的时间。注意，不是“处理时间”，是“端到端时间”。
我一般分三个维度定义：
- P50延迟：一半数据在这个时间内到达。反映正常情况。
- P99延迟：99%的数据在这个时间内到达。反映极端情况。
- 最大延迟：最慢的那条数据花了多久。反映系统瓶颈。
举个例子：一个实时大屏，P50延迟1秒，P99延迟5秒，最大延迟30秒。说明大部分数据很快，但偶尔有数据卡住。这时候就要排查那1%的慢数据是什么原因。
3.4.2 吞吐（Throughput）
吞吐就是单位时间内能处理多少数据。常见单位：条/秒、MB/秒。
这里有个常见误区——很多人只看峰值吞吐。我建议看两个值：
| 指标 | 定义 | 为什么重要 |
|---|---|---|
| 峰值吞吐 | 系统能承受的最大负载 | 决定要不要扩容 |
| 持续吞吐 | 系统稳定运行时的平均负载 | 决定日常资源配比 |
我记得有个项目，压测时峰值吞吐能到10万条/秒，但持续跑半小时就OOM了。后来发现是内存没释放。所以，别只看峰值，要看持续能力。
3.4.3 准确性（Accuracy）
实时系统的准确性，和离线不一样。离线可以保证“数据完全一致”，实时不行——因为数据在流动，状态在变化。
我一般用两个维度衡量：
- 数据完整性：有没有丢数据？丢了多少？
- 数据一致性：实时数据和最终离线数据，偏差有多大？
举个例子：实时统计“今日订单数”，可能因为延迟，5秒前的订单还没算进来。这时候实时值是995，离线最终值是1000。偏差0.5%，可以接受。但如果偏差超过5%，就要查原因了。
3.5 需求文档中的指标定义示例
说了这么多，给个实际PRD里的指标定义片段，你们感受一下：
## 3. 性能指标
### 3.1 延迟要求
- P50 延迟 ≤ 2秒（端到端）
- P99 延迟 ≤ 5秒
- 最大延迟 ≤ 10秒（超过10秒视为异常）
### 3.2 吞吐要求
- 日常吞吐：2000 条/秒
- 峰值吞吐：8000 条/秒（持续不超过5分钟）
- 数据源：Kafka Topic "order_events"，分区数 8
### 3.3 准确性要求
- 数据完整性：丢包率 ≤ 0.01%
- 数据一致性：与离线T+1数据偏差 ≤ 2%
- 校验方式：每小时自动比对实时聚合值与离线快照值
### 3.4 异常处理
- 延迟 > 10秒：前端显示“数据更新中”，自动降级为离线数据
- 数据源断流 > 30秒：触发告警，自动切换备用Topic
- 数据丢失 > 0.1%：触发数据回溯任务，从Kafka重放
你看，这样写出来，开发知道要做什么，测试知道要测什么，业务方也知道能期待什么。不会出现“我以为实时就是秒级，结果你们搞了个分钟级”这种扯皮。