1、实时数据产品概述：定义、价值与典型应用场景
大家好，我是你们这门课的老朋友。今天咱们聊聊实时数据产品。说实话，我入行那会儿，大家还在玩命搞离线数仓，T+1 报表能准时出就算阿弥陀佛了。后来业务部门开始抱怨：“昨天的数据，今天看，黄花菜都凉了。” 嗯，实时数据产品就这么被逼出来了。
1.1 到底什么是实时数据产品？
先别急着背定义。我个人的理解很简单：数据从产生到被消费，延迟在秒级甚至毫秒级，并且能直接驱动业务决策或自动化动作的产品，就是实时数据产品。
你想想看，它跟离线产品最大的区别在哪？
| 维度 | 离线数据产品 | 实时数据产品 |
|---|---|---|
| 延迟 | 分钟级 ~ 天级 | 毫秒级 ~ 秒级 |
| 处理方式 | 批量调度（T+1） | 流式处理（事件驱动） |
| 数据范围 | 全量历史数据 | 近期窗口数据 + 状态 |
| 典型输出 | 报表、BI 看板 | 告警、推荐、风控决策 |
| 存储选型 | Hive、ClickHouse | Kafka、Redis、Druid |
说白了，离线产品回答的是“昨天发生了什么”，实时产品回答的是“现在正在发生什么，接下来该怎么办”。
核心定义：实时数据产品 = 实时采集 + 流式计算 + 低延迟存储 + 即时反馈。缺一个环节，都不能叫真正的实时。
1.2 为什么企业砸钱也要做实时？
价值这东西，光靠嘴说没用。我经历过一个项目，客户是做电商的，大促期间风控系统延迟 30 秒，结果被羊毛党撸走了 200 多万。老板当场拍桌子：“给我上实时！”
实时数据产品的核心价值，我归纳为三点：
- 缩短决策周期：从“事后复盘”变成“事中干预”。比如实时监控发现服务器负载飙升，立刻自动扩容，而不是等用户投诉了才去查日志。
- 提升用户体验：你刷抖音，下一帧视频已经预加载好了；你点外卖，推荐算法根据你当前的位置和时段秒推店铺。这些都是实时在背后撑着。
- 降低风险损失：金融交易中的反欺诈、工业 IoT 中的异常检测，每快一秒，可能就少损失几十万。
我的经验：别为了实时而实时。如果业务场景允许 5 分钟延迟，就别硬上毫秒级架构。实时是有成本的——计算资源、存储开销、运维复杂度，都会翻倍。
1.3 典型应用场景拆解
光讲理论太虚。咱们直接看三个最典型的场景，也是后面几章会反复提到的。
1.3.1 实时风控
这个我太熟了。以前在支付公司，每天要处理几百万笔交易。风控规则跑在离线批处理上，等结果出来，钱早就被转走了。
实时风控的典型流程是这样的：
- 用户发起交易 → 产生事件流（Kafka）
- 流式计算引擎（Flink）实时匹配规则（如：同一设备 1 分钟内登录 5 个不同账号）
- 命中规则 → 毫秒级返回决策（通过/拒绝/人工审核）
- 决策结果写入 Redis，同时回写 Kafka 做审计日志
这里有个坑，我曾经踩过：规则引擎的性能瓶颈。一开始把所有规则都写在 Flink 的 ProcessFunction 里，结果规则一多，状态后端压力巨大，延迟从 10ms 飙到 2s。后来改成规则引擎独立部署，Flink 只做特征计算，才把延迟压回来。
避坑指南：实时风控的延迟要求通常是 100ms 以内。如果超过 500ms，用户体验会明显下降，而且容易被黑产利用时间差。我曾经见过一个项目，因为 Redis 集群网络抖动，导致风控决策超时，默认放行，结果被刷了 50 万。所以，超时降级策略一定要谨慎设计。
1.3.2 实时推荐
推荐系统大家都不陌生。但离线推荐和实时推荐，完全是两码事。
离线推荐：每天凌晨跑一次协同过滤，生成用户推荐列表，存到 Redis。用户白天访问时，直接读缓存。缺点很明显——用户刚点了一个商品，推荐列表还是昨天的，完全不相关。
实时推荐要解决的问题是：捕捉用户当下的意图。
- 用户搜索了“iPhone 15” → 实时更新推荐候选池，把手机配件、壳膜类商品提权
- 用户把商品加入购物车 → 实时计算关联推荐（买了这个的人也买了...）
- 用户浏览了 3 次但没下单 → 实时触发优惠券推送
我参与过一个资讯类 App 的实时推荐项目。架构上用了 Flink 做实时特征计算，把用户的点击、停留时长、滑动速度等行为实时加工成特征向量，然后推给在线推理服务。效果很明显，点击率提升了 15%。但代价也不小——Flink 的状态后端每天要存几十 GB 的 session 数据，调优了好几次才稳定下来。
1.3.3 实时监控与告警
这个场景最直观。不管是服务器监控、业务指标监控，还是 IoT 设备监控，核心逻辑都一样：数据流进来，规则判异常，通知发出去。
我见过一个比较典型的架构：
- 采集层：Telegraf / Filebeat 采集机器指标和日志
- 消息队列：Kafka 做流量削峰
- 流处理：Flink 做窗口聚合（5 秒平均 CPU > 80% 则告警）
- 存储：时序数据库（InfluxDB / Prometheus）存指标
- 告警：AlertManager + 企业/钉钉机器人
这里有个容易被忽略的点：告警风暴。我曾经遇到过一次，一台交换机挂了，导致 200 台机器同时失联，告警消息瞬间刷爆了运维群。后来我们加了告警聚合和降噪策略——同一故障源的告警，合并成一条，并且设置 5 分钟静默期。嗯，世界清净了。
1.4 实时数据产品的核心架构逻辑
说了这么多场景，咱们来抽象一下。不管什么业务，实时数据产品的架构都可以归纳成下面这张图：
这张图我建议你保存下来。后面每一章，其实都是在拆解其中某一层的细节。比如第 3 章讲 Kafka 怎么保证不丢数据，第 5 章讲 Flink 的状态管理，第 8 章讲 Redis 在实时场景下的特殊用法。