背景
做指标体系这 3 年，我最常听到的一句话是："这个指标能不能做成实时的？"
说这话的人通常是业务负责人或老板，语气里带着一个隐含假设——实时是默认态，T+1 是"偷懒"。我理解他们：竞品看板都是实时的、数据延迟导致错过了一次运营干预窗口、"等第二天早上看到 GMV 跌了 30% 再调策略"确实很痛。
但作为指标体系的设计者，我每次听到"做实时"时脑子里闪过的不是 Flink 窗口大小，而是三组数字：
- 架构复杂度从"1 条 SQL + 调度"变成"Kafka + Flink + ClickHouse + 对账 + 口径版本管理"，维护人力 ×3；
- 初始准确率下降 5%–15%（因为实时链路为了速度牺牲了完整性，迟到数据、乱序、去重窗口都是精度税）；
- 口径漂移风险翻倍（两条链路各维护一套逻辑，口径变更时改一处漏一处是常态）。
常见分歧 / 几种做法
阵营 A：业务方 "竞品是实时的，用户也是实时的，你的数据凭什么不是？""实时是标配，T+1 是技术债。" → 潜台词：实时性没有成本，只有"做不做"的问题。
阵营 B：数据 / 平台团队 "实时链路的维护成本是离线的 5–10 倍，而且口径一致性更难保证。你们到底多快？5 分钟够不够？1 分钟呢？" → 潜台词：实时性是一种昂贵的定制化服务，应该按需付费。
阵营 C：折中派 "核心 3–5 个指标做实时，其余 T+1。实时链路只保证'量级对'，精确数以 T+1 为准。" → 这是大多数团队实际在跑的方案，但争议在于：怎么定义"核心"？谁来决定？这个标准会不会随老板换人而变化？
阵营 D（我见过的少数派）： "大部分指标根本不需要实时。'7 日留存'定义上就是 T+7 才能确定的，'转化率'需要漏斗完整才能算，'客单价'需要订单关闭才能确认。真正需要实时的指标，可能只有大盘 GMV、异常告警、实时风控这一类。" → 潜台词：我们被"实时"这个词绑架了，把"比 T+1 快"的需求包装成了"实时"。
我的倾向与理由
我倾向把"实时性"从技术属性降级为业务属性——也就是说：
-
实时性是一种"付费选项"，不是"免费默认值"。 业务方要求实时，应该像要求"高可用 99.99%"一样，明确说出：我愿意接受什么代价（架构复杂度、初始精度下降、口径漂移风险、维护人力），以及我能用这个实时性避免什么具体损失。如果答不出具体场景和金额，大概率不需要实时。
-
先问"你上次因为数据延迟损失了什么"，再决定要不要做实时。 从问题现象倒推根因：如果业务方说不出一个具体的"因为数据晚看到了 X 小时，导致 Y 损失 Z 万"的案例，那"实时"大概率是一个模糊的焦虑，而不是一个明确的需求。
-
给"实时性"分级，而不是二选一。 我见过最有效的做法是把指标按"延迟容忍度"分三档：
- 秒级（告警 / 风控）：数据延迟 > 30s 就影响决策 → 实时链路；
- 分钟级（运营干预）：延迟 5–15 min 可以接受 → 准实时（Flink 窗口 + 增量刷新）；
- 小时级 / T+1（策略 / 复盘）：看趋势、做归因 → 离线链路。
每档有不同的 SLA、精度承诺和维护成本，业务方选档而不是选"实时/非实时"这个布尔值。
-
实时指标的"精度降级"必须显式标注。 实时链路因为乱序、迟到、窗口截断等原因，天然比 T+1 离线链路"粗"。如果业务方在实时看板上看到一个数，和第二天 T+1 报表上的数差了 8%，这不是 bug，是架构选型的代价——但这个代价必须在看板上写清楚，而不是等业务方发现数字对不上才解释。
想听大家在什么场景下怎么选
- 你们团队有没有一个明确的"实时性分级"标准？是业务方自己选，还是数据团队定？
- 有没有遇到过"业务方要求实时，但实际 T+1 就够了"的案例？怎么说服的？
- 实时和离线两条链路的数字对不上时，你们怎么沟通的？是"以 T+1 为准"一锤定音，还是每次都解释？
- 有没有人算过"实时化"的 ROI？（架构 + 人力成本 vs 避免的损失）
- 指标定义本身需要"数据完整"才能算的（比如留存、转化率、客单价），你们在实时看板上怎么处理"数据还没齐"的状态？
抛出来想听听大家的真实做法，尤其是那些"业务方拍桌子说必须实时"最后怎么收场的故事。