别再迷信离线数仓了，用流处理把实时指标平台（实时 OLAP）真正“跑起来”
说句掏心窝子的话，这几年我看过太多所谓的「实时指标平台」。
PPT 里写得天花乱坠：
- 秒级延迟
- 实时看板
- 实时 OLAP
- 业务决策“所见即所得”
结果一落地呢？
👉5 分钟延迟都算快的
👉 查一个指标，Flink 跑得比业务还慢
👉 一堆 Lambda / Kappa 架构，最后连自己都搞不清楚
所以今天我想聊的不是“什么是实时 OLAP”，而是一个更现实的问题：
实时指标平台，为什么必须用流处理？以及，怎么用才不翻车？
一、先说结论：实时 OLAP，本质不是“查得快”，而是“算得早”
很多人一上来就问：
Echo，实时 OLAP 用 ClickHouse 还是 Doris？
是不是加点内存、加点并发就行？
这个问题本身就已经偏了。
真正的实时 OLAP，有一个核心思想：
计算尽量前移，查询尽量变薄
你要是指望用户点一次看板，后台才开始GROUP BY + SUM + DISTINCT，
那不管你用啥引擎，最后都会变成：
“实时” → “忍一忍”
而流处理干的事情刚好相反：
- 数据一来就算
- 状态提前维护
- 查询阶段只做轻量聚合甚至直接读结果
这才是实时指标平台该走的路。
二、为什么“离线 + 定时”那套，在实时指标上基本必死
我见过最常见的三种“伪实时”方案：
1️⃣ 每 5 分钟跑一次 Spark
“业务也不是特别急，5 分钟能接受吧？”
一开始能接受，后来老板看了实时大屏：
- “为啥用户已经下单了，这里还没涨？”
- “为啥报警总是慢半拍？”
业务对实时的容忍度，是会被平台惯坏的。
2️⃣ Kafka + ClickHouse，全靠查
Kafka 当缓冲，ClickHouse 当实时仓库。
听起来很美，但问题是：
- 明细越堆越多
- 查询越写越复杂
- 高峰期一个大屏能把集群打跪
你会发现：
你其实是在用 OLAP 引擎，硬扛流计算的活儿。
3️⃣ Lambda 架构，算两遍
- 离线一套
- 实时一套
- 对账一套
最后的结局通常是：
实时不准，离线太慢，对账没人看
说白了，这不是技术问题，是认知问题。
三、流处理适合干什么？一句话讲清楚
我常跟团队说一句话：
流处理最擅长的，不是“算复杂”，而是“持续维护结果”
实时指标平台，本质就是：
- 连续数据流
- 有明确维度
- 有稳定指标口径
- 有时间窗口
这四点，天生就是流处理的主场。
四、一个最小可用的实时指标模型
我们先别上来就谈 OLAP、多维分析，先落到一个最小模型。
场景：实时订单指标
假设每条订单数据长这样：
{"order_id":"o123","user_id":"u88","city":"shanghai","amount":199.0,"event_time":1700000000}我们想要的实时指标是：
- 每分钟订单数
- 每分钟 GMV
- 按城市分组
五、用流处理，把“指标”当成一等公民
下面用Flink SQL 思路来写（逻辑比语法重要）。
1️⃣ 定义流表
CREATETABLEorders(order_id STRING,user_id STRING,city STRING,amountDOUBLE,event_timeTIMESTAMP(3),WATERMARKFORevent_timeASevent_time-INTERVAL'5'SECOND)WITH(...);注意这里有两个关键点：
- event_time：指标永远用事件时间
- watermark：实时 ≠ 不要乱序
2️⃣ 实时聚合指标
CREATETABLEorder_metrics(window_startTIMESTAMP,window_endTIMESTAMP,city STRING,order_cntBIGINT,gmvDOUBLE)WITH(...);INSERTINTOorder_metricsSELECTwindow_start,window_end,city,COUNT(*)ASorder_cnt,SUM(amount)ASgmvFROMTABLE(TUMBLE(TABLEorders,DESCRIPTOR(event_time),INTERVAL'1'MINUTE))GROUPBYwindow_start,window_end,city;这一刻，你就已经做了一件非常重要的事：
把“算指标”这件事，从查询时，提前到了数据进入系统的那一刻
六、实时 OLAP 的关键：状态 ≠ 缓存，而是资产
很多人一听 Flink State 就头大：
- 状态会不会爆？
- RocksDB 会不会慢？
- Checkpoint 会不会拖垮集群？
但我想换个角度说一句：
实时指标平台里，状态不是负担，是你最值钱的资产。
为什么？
- 它存的是已经算好的结果
- 它帮你抵御查询风暴
- 它让你从“算一次”变成“持续维护”
你要是不用状态，那你只能不停地重复计算。
七、实时 OLAP ≠ 全维度自由查询（别想太美）
这里我必须泼一盆冷水。
很多人幻想的实时 OLAP 是：
“任何维度，任何时间，随便拖拽，秒出结果”
说实话，这在实时场景下，99% 是不现实的。
正确的姿势是：
- 核心指标：流里算
- 高价值维度：提前建模
- 长尾分析：走离线或准实时
实时 OLAP，一定是有取舍的。
你要的是业务真正在乎的那 20% 指标，不是炫技。
八、我自己的几点真实感受
干了这么多年大数据，我越来越觉得：
实时不是技术问题，是产品问题
指标定义不清，技术再牛也白搭。流处理不是万能，但它很诚实
算力、延迟、状态，成本都摆在那。一个能用 3 年的实时指标平台，一定很“克制”
克制指标数量
克制维度自由度
克制“全都要”的欲望
九、最后一句话送给你
如果你正在做实时指标平台，我想送你一句我常对自己说的话：
别急着做一个“什么都能查”的系统，先做一个“永远不骗人”的指标。
流处理 + 实时 OLAP，不是为了炫，而是为了让数据早点说真话。
)
