acf1sh.top1. 查询很快，数字仍然可能不可信
实时看板显示今天成交金额为一个确定数字。业务人员继续追问：退款扣了吗？跨天支付算在哪天？取消后重新支付怎么算？迟到事件到达后历史值会不会变化？
这些问题与查询速度无关。一个指标至少依赖四层内容：
原始事件
→ 可追溯明细
→ 业务聚合
→ 指标语义
→ Dashboard / NL2BI查询引擎负责计算，指标定义负责说明应该计算什么。
2. 先把“成交金额”写成业务规则
本文使用一个简化定义：
成交金额
= 已确认支付金额
- 已确认退款金额还要补充条件：
- 使用支付确认时间归属日期。
- 部分退款只扣除确认退款金额。
- 测试订单和风控关闭订单排除。
- 币种不同的数据先按规定汇率处理，或者分开统计。
- 时区固定，并在跨日查询中保持一致。
SQL 可以实现这些规则，却不应该成为规则唯一存在的地方。如果 Dashboard、日报和自然语言问数各写一份 SQL，口径会逐渐分叉。
3. 明细层保留计算依据
订单当前表便于查询现状，事件明细表负责追踪变化。可以再生成用于分析的支付和退款事实：
order_event_detail
payment_fact
refund_fact每条事实保存业务主键、事件标识、业务时间、处理时间和来源版本。发现指标异常时，可以回到原始事件，而不是只剩一个已经聚合的数字。
数据质量检查可以围绕不变量展开：
支付金额不能为负
退款累计不能超过可退款金额
同一 event_id 不能重复生效
订单版本不能倒退
必填业务键不能为空异常数据进入隔离区并保留原因。直接丢弃会让最终指标无法解释。
4. 聚合层减少重复计算
Dashboard 经常按店铺、地区、渠道和时间查看指标。如果每次从所有事件重新计算，查询成本和口径维护都会增加。
可以建立日粒度聚合：
sales_daily
biz_date
shop_id
channel_id
paid_amount
refunded_amount
net_amount
order_count
updated_at聚合表仍然是可重算的派生数据。它需要记录上游范围和最近更新时间，出现逻辑变更时能够按分区重新生成。
StarRocks 同步物化视图适合单表实时聚合和透明改写；异步物化视图支持更复杂的多表模型与独立刷新。两类视图的刷新语义不同，选择时要看查询、更新频率和允许的新鲜度。
5. 迟到事件会修改已经显示的历史
业务时间是订单真正发生的时间，处理时间是平台看到数据的时间。网络或上游故障会让昨天的退款今天才到达。
event_time 2026-07-24 23:58
processing_time 2026-07-25 00:06如果指标按业务时间统计，这条事件应该修正 7 月 24 日的结果。实时看板需要向使用者说明数据是否仍在更新，以及历史窗口何时视为稳定。
Flink 的 Window 与 Watermark 可以表达事件时间处理和允许迟到范围，但超出范围的数据仍需要补数或重算流程。一个固定 Watermark 参数不能适合所有业务，它取决于真实延迟分布和业务容忍度。
6. 数据新鲜度需要单独展示
页面显示“已更新”过于模糊。可以拆成：
| 指标 | 回答的问题 |
|---|---|
| source_max_event_time | 最新业务事件是什么时间 |
| kafka_lag | 消费位置落后多少 |
| last_checkpoint_at | Flink 最近何时完成恢复点 |
| last_load_at | StarRocks 最近何时提交数据 |
| mv_refresh_at | 物化视图最近何时刷新 |
| dashboard_query_at | 用户看到的查询何时执行 |
这些字段没有统一阈值。告警应由业务新鲜度目标推导，例如某看板允许分钟级延迟，日报则可以接受更长处理时间。
7. 权限不能只放在 Dashboard 菜单
隐藏一个看板入口，不能阻止用户通过 SQL、API 或自然语言工具访问底层数据。权限要沿着查询链路生效：
用户身份
→ 指标权限
→ 数据范围
→ 查询引擎身份
→ 审计记录店铺管理员只能查看所属店铺时，过滤条件需要在受信任的服务或数据访问层注入。不能让前端传入任意 shop_id。
已有的问数结果为什么会错讨论语义和权限；本文补上指标进入查询层之前的数据加工与刷新过程。
8. Java 控制面可以管理什么
Spring Boot 可以管理指标定义的元数据、数据源、任务状态、权限、刷新记录和质量告警。Flink 和 StarRocks 继续执行实际计算。
例如一个 MetricDefinition 可以保存名称、版本、责任人、时间字段、允许维度和状态。修改口径时创建新版本，并记录哪些 Dashboard 和问数入口开始使用它。
Java 服务不应该拼接任意 SQL 后直接执行。参数、允许维度、数据范围和查询资源需要受控，并留下审计记录。
实时 BI 的“实时”可以通过链路延迟描述，而“可信”来自口径、质量、血缘、权限和修正流程。物化视图能改善查询路径，却不能替平台决定正确的成交定义。把“订单怎样进入实时链路”和“指标落地前要确认哪些语义”放在一起看，就能把“实时”与“可信”这两件事接起来。