指标口径变更后，历史数据到底要不要回刷？回刷后老报表怎么办？

先给结论：大部分口径变更不需要全量回刷，但必须做"口径版本标注 + 并行过渡期"，否则业务方永远在问"为什么上个月跌了20%"。 下面按你问的 4 点逐一给可操作方案。

1. 回不回刷：决策 checklist（我们团队在用的版本）

| 判据 | 回刷 | 不回刷（标注即可） | |---|---|---| | 指标是否进入过对外承诺（OKR / 合同 / 监管报送） | ✅ 必须回刷 | | | 口径变更是否改变量纲或分子分母结构（如从 UV 改成 PV） | ✅ 必须回刷 | | | 变更只是阈值微调（如停留 ≥3s → ≥5s）且影响 <10% | | ✅ 标注 + 并行 2 周 | | 回刷成本 > 3 人天 且无合规要求 | | ✅ 标注 + 异步补算 | | 数据已超出保留窗口（>12 月冷存储） | 只回刷最近 6 月 | 更早的标注"不可回溯" |

量化判据：如果新旧口径在 30 天窗口内的偏差 <5%（用 1 天抽样对比即可算），直接走"标注"路线；>5% 才值得回刷。

2. 回刷的工程降本手段

你提到 Flink 重放 + ClickHouse 分区搬热，3-4 天。实际可以拆成三层：

(a) 只回刷"被引用的"指标，不刷全部 30 个

-- 找出近 3 个月被 BI 看板 / 周报引用过的指标
SELECT metric_name, COUNT(*) AS ref_count
FROM bi_dashboard_query_log
WHERE query_time >= now() - INTERVAL 90 DAY
GROUP BY metric_name
HAVING ref_count > 0;

通常 30 个指标里真正被引用的只有 8-12 个，回刷量直接砍 60%。

(b) 用 ClickHouse 的 ALTER TABLE ... POPULATE 做增量物化，而不是重跑 Flink 全链路 如果口径变更只改了 WHERE / CASE WHEN 逻辑，而上游原始事件表（Kafka → ClickHouse raw 表）还在，可以直接在 ClickHouse 里对 raw 表做 INSERT SELECT：

-- 假设 raw 表是 events_raw，新口径是"点击或停留>=5s"
INSERT INTO metrics_daily_new
SELECT toDate(event_time) AS dt,
       uid,
       count() AS active_days
FROM events_raw
WHERE event_type IN ('click', 'page_view')
  AND (event_type = 'click' OR duration_ms >= 5000)
  AND toDate(event_time) BETWEEN '2026-04-01' AND '2026-09-30'
GROUP BY dt, uid;

这比 Flink 重放快一个数量级，因为省了 Kafka 消费 + 状态恢复的开销。

(c) 新旧口径并行存 14 天 新建 metrics_daily_v2 表，看板同时出 v1 和 v2 两条线，业务方自己看差异。14 天后 v1 降级为"历史参考"，30 天后归档。

3. 口径版本标注（最关键、成本最低、效果最好）

在看板 SQL 层加一个 metric_version 字段：

-- 看板查询时拼接
SELECT *,
  CASE
    WHEN dt < '2026-09-15' THEN 'v1_open_app'
    ELSE 'v2_effective_interaction'
  END AS metric_version
FROM metrics_daily;

前端在断崖点画一条竖线 + tooltip 写"2026-09-15 口径变更：打开App → 有效交互(点击/停留≥5s)"。

具体做法：在指标元数据表里加 effective_from 和 effective_to 字段，看板组件读这个字段自动渲染断点标注。我们用了这个方案后，"为什么上个月跌了"的工单直接归零。

4. 已导出的老报表

不要作废重发（会引发更大的混乱，因为对方可能已经基于老数字做了决策）。正确做法：

• 在老报表文档顶部追加一行："⚠️ 本报告中'活跃用户'指标基于 v1 口径（打开App即算），2026-09-15 起已切换为 v2 口径（有效交互），数值不可直接对比。"
• 如果老报表是 PPT / 邮件，在下一版周报里用一页"口径变更说明"统一交代，附上新旧口径定义和 14 天并行期的对比截图。

踩坑提醒：我们去年回刷过一次，最大的坑不是技术成本，而是回刷期间新旧数据同时存在导致看板出现"两条线"，业务方以为是 bug。解决办法是回刷期间看板只展示 v1，回刷完成 + 验证一致后才切 v2，中间用内部看板做校验，不对业务暴露。