指标变更影响30张报表——指标的版本管理和下线机制怎么做？

「这个DAU口径要改一下，明天上线」——业务方说得轻巧，但下游可能有30张报表、20个数据应用、5个BI Dashboard在用。直接改就是事故。这道题考的是指标全生命周期管理能力——从创建、变更、版本、deprecation到最终下线，每一步怎么做才安全且高效。我在某出海硬件品牌做指标治理时，建立了一套"指标变更SOP"，把口径变更引发的事故从季度3-4起降到0。

业务场景：改DAU口径炸了30张报表

出海硬件品牌V0时期，CEO要求"DAU口径加上时长>30秒过滤"。我没想太多直接改了SQL，第二天炸出30+报表显示"DAU陡降12%"，业务方各种投诉，CDO开复盘会骂了我半小时。

根本原因是我没有：①双跑——新旧值同时存在让业务对照 ②通知——下游Owner不知道有变更 ③版本号——历史报表还以为用的是旧口径。从此痛定思痛建立了完整的版本管理体系。

方法一：版本号策略（SemVer风格）

我把指标版本号分为Major.Minor.Patch三级：

这套版本号写到指标字典里，每次变更都升级版本号。SQL里通过别名引用版本：`SELECT dau FROM ads_dau_v2`，老报表继续用`ads_dau_v1`，互不影响。

方法二：Major变更的双跑机制

Major变更必须双跑，新旧版本同时存在30天。SQL层面：

-- 旧版本（v1）：保留不变
CREATE TABLE ads_dau_v1 (
  dt DATE, dau BIGINT  -- 不加过滤的DAU
);
 
-- 新版本（v2）：新逻辑
CREATE TABLE ads_dau_v2 (
  dt DATE,
  dau BIGINT,                 -- 新口径（含过滤）
  dau_old BIGINT,             -- 同时输出旧口径（兼容期）
  dau_diff_rate DECIMAL(6,4)  -- diff率，监控用
);
 
-- 在BI层提供"指标版本切换"的UI能力
-- 业务方可以选择'当前用v1'或'切到v2'
-- 30天后v1自动deprecated，60天后冻结，90天后删除

双跑期间每周发"版本切换进度报告"——已切换的报表数、未切换的报表名单+Owner。这是Push式治理。

方法三：灰度+影响通知机制

Major变更前必须做影响分析（参考第13题血缘）+ 通知所有Owner：

def initiate_metric_change(metric_id, change_type, new_definition):
    # 1. 影响分析（基于血缘）
    affected = lineage.get_downstream(metric_id)
    affected_reports = [a for a in affected if a.type == 'BI_REPORT']
    affected_jobs = [a for a in affected if a.type == 'ETL_JOB']
    
    # 2. 收集Owner
    owners = set()
    for obj in affected_reports + affected_jobs:
        owners.add(obj.owner_email)
    
    # 3. 创建变更工单
    change_ticket = create_ticket({
        'metric_id': metric_id,
        'change_type': change_type,    # 'major' / 'minor' / 'patch'
        'old_def': metric.definition,
        'new_def': new_definition,
        'affected_count': len(affected),
        'owners': list(owners),
        'effective_date': today + 14,  # 至少提前14天
    })
    
    # 4. 发通知（邮件+飞书+IM）
    notify(owners, change_ticket)
    
    # 5. 等待回执（7天内必须有Acknowledge）
    return change_ticket