1. 实时数据产品概述
大家好，我是老赵。做数据产品这些年，我见过太多团队一上来就追「实时」，结果搞成了「实时灾难」。今天咱们先把这个概念掰扯清楚。
1.1 什么是实时数据产品
实时数据产品，说白了就是数据从产生到被消费，延迟控制在秒级甚至毫秒级的产品。你打开外卖App看到骑手离你还有800米，那就是实时数据在背后跑着。
我个人习惯把实时数据产品分成三类：
- 实时监控类：比如服务器CPU飙到90%立刻告警
- 实时决策类：比如你刚刷完信用卡，风控系统0.1秒内判断是否盗刷
- 实时交互类：比如直播弹幕、协同编辑，延迟超过1秒用户就骂娘
核心指标：实时不是「零延迟」，而是「可接受的延迟」。金融交易要求毫秒级，推荐系统几百毫秒也能忍，报表系统延迟几秒问题不大。
1.2 实时与批处理的区别
很多新手问我：「实时不就是批处理跑快点吗？」嗯，还真不是。我拿做饭打个比方：
- 批处理像周末包饺子——先和面、再剁馅、然后一起包，最后冻起来慢慢吃。数据也是先攒着，到点统一算。
- 实时处理像点外卖——你下单，厨房立刻做，做完马上送。数据来一条处理一条，不攒着。
下面这张表把关键区别列清楚了：
| 维度 | 批处理 | 实时处理 |
|---|---|---|
| 延迟 | 分钟~天级 | 毫秒~秒级 |
| 数据范围 | 全量历史数据 | 当前窗口数据 |
| 触发方式 | 定时调度 | 事件驱动 |
| 计算模型 | MapReduce / Spark | Flink / Kafka Streams |
| 典型场景 | 月报、离线训练 | 风控、推荐、监控 |
| 容错成本 | 低（重跑即可） | 高（状态一致性难保） |
避坑指南：我曾经接手过一个项目，团队用Spark Streaming做实时风控，结果延迟一直在5秒以上。后来发现他们用的还是微批次模式，批次间隔设了3秒。换成Flink纯流处理后，延迟降到200毫秒。选对引擎很重要。
1.3 实时数据产品的典型应用场景
你想想看，哪些场景对「快」有硬需求？我挑三个最常见的聊聊。
1.3.1 风控场景
这是实时数据产品最刚需的领域。用户每点一下鼠标、每刷一次卡，背后可能都在跑几十条规则。
我记得在支付公司那会儿，双十一峰值每秒要处理8万笔交易。风控系统必须在100毫秒内给出「放行/拦截/人工审核」的判断。怎么做？
- 实时特征计算：比如过去5分钟该用户交易次数、金额总和
- 规则引擎：if-else 跑得飞快，适合已知模式
- 模型推理：用训练好的机器学习模型打分，适合未知模式
注意：实时风控最怕「雪崩」。如果系统处理不过来，宁可放过一笔可疑交易，也不能把整个支付链路堵死。这叫「降级保活」，我吃过亏才明白。
1.3.2 推荐场景
推荐系统分两种：离线推荐和实时推荐。离线推荐算好结果存起来，用户来了直接取。实时推荐呢？用户刚点了一个商品，系统立刻根据这个行为调整推荐列表。
举个例子：你在短视频App上刷到一个美食视频，停留了10秒。实时推荐系统会立刻把更多美食视频推到你面前。如果等批处理跑完再推，你早划走了。
实时推荐的技术栈通常是：
- 实时行为采集：点击、停留、滑动等事件
- 实时特征更新：用户兴趣向量实时增量更新
- 实时召回：从百万级候选集中快速捞出几百个
- 实时排序：用轻量模型对候选集打分
1.3.3 监控场景
这个最直观。服务器挂了、接口慢了、流量突增了，都得立刻知道。我见过最夸张的监控系统，每秒处理200万条日志，告警延迟控制在3秒以内。
监控场景的核心能力：
- 多维聚合：按机器、机房、服务、接口等维度实时计算
- 异常检测：用滑动窗口算均值、方差，超出阈值就告警
- 根因分析：告警后自动关联上下游，定位问题源头
个人经验：做监控别一上来就搞复杂模型。先用简单的「3-sigma」或「同比环比」规则，能覆盖80%的异常。剩下的20%再用机器学习慢慢补。
1.4 实时数据产品的核心架构
下面这张图是我自己总结的实时数据产品通用架构，你照着搭基本不会跑偏。
这个架构图我用了好几年，每次给团队讲都从这张图开始。你注意看，每一层都有明确的职责，层与层之间通过消息队列解耦。这样做的好处是：哪一层出了问题，不会把整个链路拖死。
1.5 什么时候该上实时？
最后聊个实在问题。不是所有场景都需要实时，盲目上实时只会增加复杂度。我一般用三个问题来判断：
- 业务决策对延迟敏感吗？ 延迟10秒和延迟1分钟，结果有本质区别吗？
- 数据量级值得吗？ 每天几百条数据，批处理1秒就跑完，没必要上实时。
- 团队有实时能力吗？ 实时系统的运维成本是批处理的3-5倍，你扛得住吗？
我的建议：先从最核心的场景切入，比如风控或监控。跑通了再逐步扩展到推荐、报表等领域。别一上来就想搞「全实时」，那通常是灾难的开始。