一、实时指标概述

大家好，我是这门课的主讲人。做了十几年数据工程，我见过太多团队在「实时」这两个字上栽跟头。今天咱们就从最基础的问题聊起——到底什么是实时指标？

1.1 什么是实时指标

实时指标，说白了就是「数据产生后，几乎立刻就能看到计算结果」。不是等明天、不是等下一个小时，而是秒级甚至毫秒级出结果。

举个例子。你在电商App上点了个「加入购物车」，后台立刻更新了「今日加购人数」这个数字。你点完刷新页面，数字就变了。这就是实时指标。

我个人习惯把实时指标分成两类：

• 实时：数据产生到结果展示，延迟在1秒以内。比如监控系统的CPU使用率。
• 近实时：延迟在几秒到几分钟。比如电商大促的实时GMV，通常有5-10秒延迟。

1.2 实时指标 vs 离线指标

很多新手搞不清实时和离线到底差在哪。我直接画个对比表，你一看就明白。

对比维度	实时指标	离线指标
计算时机	数据到达即计算	定时批量计算（如每天凌晨）
延迟要求	秒级~分钟级	小时级~天级
数据量	单条或小批量	全量或大批量
存储选型	Redis、Kafka、Druid	HDFS、Hive、Spark
典型场景	实时大屏、风控、监控	日报、月报、数据仓库
准确性	允许一定误差	要求精确

嗯，这里要注意一个关键点：实时指标通常允许「近似准确」。为什么？因为实时计算要快，就不能等所有数据到齐。我在做双十一大屏时，就遇到过数据延迟导致实时GMV比实际少了0.3%，但业务方完全能接受——他们要的是趋势，不是精确到分。

1.3 实时计算的应用场景

你想想看，哪些地方非用实时不可？我挑几个典型场景说说。

场景一：实时监控与告警

服务器CPU飙到95%了，你能等明天看报表吗？肯定不行。实时监控就是干这个的——数据一到，立刻判断是否触发阈值，该报警就报警。

场景二：实时大屏

双十一的销售额大屏、物流配送的实时地图、工厂的生产线看板……这些都需要秒级刷新。我记得第一次做双十一大屏时，每秒要处理几十万笔订单，压力确实大。

场景三：实时风控

用户刚输完密码，系统就要判断这笔交易是不是盗刷。等离线算完，钱早没了。实时风控要求延迟在100毫秒以内，这是最硬核的实时场景之一。

场景四：实时推荐

你刷短视频，刚点了个「喜欢」，下一秒推荐流就变了。这就是实时推荐在起作用——根据你的即时行为调整推荐策略。

场景五：实时数据同步

比如从MySQL实时同步到数据仓库，或者从业务库同步到搜索引擎。这类场景对延迟要求没那么高，但数据不能丢。

1.4 实时指标的核心架构

说了这么多，咱们看看实时指标系统长什么样。下面这张图是我自己总结的通用架构，你照着搭基本不会错。

这个架构图你记住几个关键点：

• 消息队列是核心：没有Kafka，实时系统基本玩不转。它负责解耦和缓冲。
• 计算引擎选型：Flink是目前的主流，Spark Streaming适合和离线共用一套代码。
• 存储要分层：Redis扛实时查询，OLAP引擎扛历史分析，各司其职。