1. 实时指标概述
各位同学好，我是老张。做实时计算这些年，踩过不少坑，也积累了一些实战经验。今天咱们聊聊实时指标——这个听起来很基础、但实际做起来门道不少的话题。
先说说我自己的经历。几年前我刚接手一个实时大屏项目，业务方说要「实时看到用户行为」。我当时想，这不就是跑个流任务嘛，简单。结果上线第一天，数据对不上，延迟忽高忽低，业务方直接找到我办公室……嗯，从那以后我才真正开始认真琢磨：到底什么是实时指标？它跟离线指标差在哪？
什么是实时指标
实时指标，说白了就是数据产生后，在极短时间内就能被计算和展示出来的度量值。这个「极短时间」没有标准，但通常指秒级到分钟级。
举个例子：你在电商App上点击了一个商品，3秒后大屏上就更新了「今日点击量」。这就是实时指标。
我个人习惯把实时指标分成两类：
- 纯实时指标：数据一到就计算，不依赖历史数据。比如当前在线人数。
- 准实时指标：需要结合历史数据做聚合，但窗口控制在分钟级。比如过去5分钟的成交额。
核心要点：实时指标的关键不是「快」，而是「可容忍的延迟」+「数据一致性」。很多新手只追求速度，忽略了准确性，结果就是「快但错」。
实时指标与离线指标的区别
这个问题我面试时经常问。很多人能说出「实时快、离线慢」，但深层的差异往往说不清楚。
你想想看，离线指标跑的是T+1的数据，今天算昨天的。实时指标呢？数据来了就得算，算完就得用。这背后是两种完全不同的技术栈和思维方式。
我整理了一张对比表，把核心差异列出来：
| 对比维度 | 实时指标 | 离线指标 |
|---|---|---|
| 计算延迟 | 秒级~分钟级 | 小时级~天级 |
| 数据范围 | 当前窗口数据 | 全量历史数据 |
| 计算引擎 | Flink、Spark Streaming | Hive、Spark SQL |
| 存储选型 | Redis、HBase、Druid | HDFS、Hive表 |
| 容错机制 | 状态恢复、Exactly-Once | 重跑任务 |
| 数据精度 | 可能存在近似值 | 精确计算 |
| 开发复杂度 | 高（要考虑乱序、延迟、背压） | 相对低 |
我的经验：离线指标做错了，大不了明天重跑。实时指标做错了，影响的是正在看大屏的业务方。所以实时开发对「数据正确性」的要求其实更高，只是很多人没意识到。
实时指标的应用场景
说到应用场景，我这些年接触过的项目基本覆盖了大部分常见场景。咱们挑几个典型的说说：
1. 实时大屏
这是最直观的场景。双11大屏、运营监控大屏、系统健康大屏……数据一跳一跳地往上翻，看着就带劲。但要注意，大屏上的数字如果错了，那可是当着老板的面出丑。我曾经就遇到过——大屏显示成交额100亿，实际只有80亿，原因是重复计算了退款订单。
2. 实时风控
金融场景里，每一笔交易都需要毫秒级判断。用户刚刷完卡，系统就得决定：这笔交易正常还是异常？这时候离线指标根本来不及。实时指标配合规则引擎，才能做到「边交易边判断」。
3. 实时推荐
你在刷短视频，系统根据你刚刚的点击行为，实时调整推荐内容。这背后就是实时指标在支撑——「用户最近1分钟的行为序列」就是一个典型的实时指标。
4. 实时监控告警
服务器CPU飙高了、接口响应变慢了、订单量突然暴跌了……这些都需要实时指标来触发告警。离线指标等发现问题时，用户早就跑光了。
5. 实时数据同步
这个场景比较特殊，但很常见。业务库的数据需要实时同步到数仓或搜索引擎，这时候实时指标用来衡量「同步延迟」——比如从MySQL到ES的延迟是3秒还是30秒。
下面这张图是我自己总结的实时指标应用全景，帮你快速建立整体认知：
避坑提醒：我曾经在一个项目中，业务方要求「所有指标都要实时」。结果做了三个月，发现80%的指标其实T+1完全够用。实时是有成本的——计算资源、存储成本、开发维护成本都比离线高。所以，不是所有指标都需要实时化，先问清楚业务场景再动手。
实时指标的核心挑战
说了这么多好处，也得聊聊难点。实时指标开发，说白了就是跟「不确定性」打交道：
- 数据乱序：数据到达的顺序和产生顺序不一致，怎么处理？
- 数据延迟：某些数据迟到了，是等还是算？
- 状态管理：实时任务的状态怎么保存？挂了怎么恢复？
- 背压问题：数据量突然暴增，系统扛不住怎么办？
- 数据一致性：实时结果和离线结果对不上，怎么排查？
这些问题，后面的章节咱们会一个一个拆解。今天这一讲，主要是帮你建立对实时指标的整体认知。
记住一句话：实时指标不是离线指标的加速版，而是一套全新的技术体系。思维方式、技术选型、运维手段都不一样。准备好了吗？后面还有29章等着咱们。