别再迷信离线数仓了，用流处理把实时指标平台（实时 OLAP）真正“跑起来”

别再迷信离线数仓了，用流处理把实时指标平台（实时 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% 指标，不是炫技。

八、我自己的几点真实感受

干了这么多年大数据，我越来越觉得：

1. 实时不是技术问题，是产品问题
   指标定义不清，技术再牛也白搭。

2. 流处理不是万能，但它很诚实
   算力、延迟、状态，成本都摆在那。

3. 一个能用 3 年的实时指标平台，一定很“克制”
   克制指标数量
   克制维度自由度
   克制“全都要”的欲望

九、最后一句话送给你

如果你正在做实时指标平台，我想送你一句我常对自己说的话：

别急着做一个“什么都能查”的系统，先做一个“永远不骗人”的指标。

流处理 + 实时 OLAP，不是为了炫，而是为了让数据早点说真话。