指标加速层选型：现算、物化视图、实时流，一次把该选哪个讲清楚

本文站在「指标体系搭建」视角，对比三种指标加速方案的延迟、成本与口径一致性，给出可复现的选型决策。

一、现象与背景

接手一个 B 端数据产品后，第一周就撞上一堵墙：核心看板的三个查询——「近 7 日 GMV」「转化漏斗」「分渠道 ROI」——P99 延迟 8.4s，高峰 QPS 约 320，底层 OLAP 引擎（StarRocks 3.2，3 个 BE，每个 16C / 64G）的 CPU 常年压在 85% 以上，一到整点批量刷新就飙到 98%。产品给的硬指标是「3 秒内出数」。

问题不在业务逻辑，而在一个反直觉的事实：这三个查询每天只被调用约 4 万次，却每次都对着 420 亿行明细表做全量聚合 + 窗口计算。我们把一次性的重计算，摊到了每一次读上。

二、原理与根因

三种加速方案的本质，其实是同一件事的三种落点：把计算从「读时」挪走，用存储成本或数据新鲜度去换 CPU。

现算（OLAP 直算）：读时全算。最准、最实时，但每次读都付全价。适合查询少、维度组合不可枚举的场景。
物化视图 / 预聚合物化表：写后定时重算。把「读时全算」换成「写后批量算 + 读时直取」。代价是引入一个刷新窗口，窗口内读到的是上一版数据。
实时流聚合（Flink）：写时增量算。数据一进明细就立刻聚合成指标，新鲜度最好，但状态管理、Exactly-Once、反压、去重窗口都是新的复杂度。

一句话区分：现算用 CPU 换准确，物化用新鲜度换成本，实时流用复杂度换新鲜度。选错方向的代价，比参数调优大得多。

三、具体做法（可复现）

方案 A：现算 + 索引优化（基线）

-- StarRocks 3.2：靠分区 + 分桶让聚合下推，而不是靠堆并发
ALTER TABLE dwd_order
  PARTITION BY RANGE(create_date)
  DISTRIBUTED BY HASH(user_id) BUCKETS 64;
-- 查询时显式命中分区，避免全表扫
SELECT channel, SUM(pay_amt) AS gmv
FROM dwd_order
WHERE create_date >= date_sub(current_date(), 7)
GROUP BY channel;

基线 P99 仍 8.4s——说明加并发救不了聚合慢，这是数据分布问题。

方案 B：物化视图（推荐默认解）

CREATE MATERIALIZED VIEW mv_channel_gmv
  PARTITION BY create_date
  REFRESH ASYNC EVERY(INTERVAL 5 MINUTE)   -- 5 分钟增量刷新
AS
SELECT create_date, channel,
       COUNT(DISTINCT user_id)  AS uv,
       SUM(pay_amt)             AS gmv
FROM dwd_order
GROUP BY create_date, channel;

落地后：预聚合命中 96% 的查询，P99 从 8.4s 降到 210ms；单次增量刷新耗时 90s，CPU 峰值从 98% 回落到 41%。

方案 C：实时流（仅对"秒级新鲜"的少数指标）

Flink 增量聚合，关键配置：

// 状态 TTL 对齐窗口，防止状态无限膨胀
StateTtlConfig ttl = StateTtlConfig.newBuilder(Time.minutes(30)).build();
valueStateDesc.setStateTtl(ttl);
// 去重键必须和离线口径一致（见第四节坑 2）
keyedStream.keyBy(o -> o.userId)

作业规模：8 并发 × 4GB 堆，端到端延迟 P99 1.8s。

选型决策矩阵（可直接抄）：

| 维度 | 现算 | 物化视图 | 实时流 | |---|---|---|---| | 新鲜度 | 实时 | 分钟级（窗口内滞后） | 秒级 | | 成本 | 读时高 | 低 | 高（常驻作业） | | 口径一致性 | 最一致 | 窗口内可能漂移 | 需对齐去重键 | | 适用 | 低频/不可枚举维度 | 80% 的常规看板 | 少数强实时指标 |

经验值：默认走物化视图，只有当业务明确要"秒级"且指标 < 10 个时，才为那几个指标上实时流，其余仍走物化。

四、踩过的坑与反直觉之处

物化视图"部分刷新"会退化成全量重算。一开始分区键选成了 updated_at，因为大量行回刷，增量刷新每轮都扫全表，单次刷新从 90s 飙到 11min，直接把 5 分钟刷新窗口撑爆。改成按业务发生时间 create_date 分区后恢复正常。分区键要选"只追加、不修改"的字段。
刷新空窗 = 口径漂移。物化视图在 5 分钟窗口内读到的是上一版，而实时流读到的是最新值——同一张看板里，走物化的 GMV 和走实时流的实时 GMV 差了 0.7%。这不是 bug，是两套新鲜度对不齐。解法是给看板明确标注数据版本与刷新时间，而不是追求"看起来一样"。
去重键不一致比延迟更致命。预聚合表按 user_id 去重、实时流按 device_id 去重，同一个"UV"差了 12%，排查了两天才发现。离线与在线的去重键、时间字段（event_time vs updated_at）必须写进指标字典并强制一致。
反直觉：加并发不能解决聚合慢。我们曾把 BE 从 3 扩到 6，P99 只从 8.4s 降到 7.9s——瓶颈在数据分布和全表扫，不在算力。先改分区/分桶/rollup，再谈扩容。

五、结论与可复用清单

结论：指标加速不是"性能优化"，而是新鲜度 × 成本 × 口径一致性三选二的权衡。默认物化视图，强实时指标才上流，现算只留给低频长尾。

可复用清单（落地前逐项打勾）：

[ ] 先量化：列出每个指标的 QPS、P99、明细行数，别凭感觉选方案
[ ] 物化视图分区键选"只追加不修改"的业务发生时间字段
[ ] 刷新窗口写进指标字典，看板必须展示数据版本 / 刷新时间
[ ] 离线与在线的去重键 + 时间字段统一，写死在指标定义里
[ ] 扩容前先看数据分布与是否全表扫，而非直接加机器
[ ] 强实时指标控制在少数，其余一律走物化，避免"全都要秒级"

相关参考：站内@许望舒的《埋点事件模型选型：扁平宽表 vs 事件溯源》讲的是 event 该长什么样，本文讲的是 event 之上指标该"怎么算得快还不漂移"，两者正好上下游衔接。

赞 6 · 收藏 0 · 评论 0 · 浏览 0