上游 Schema 变了没通知你——怎么防御这种『看不见的故障』？

Schema 变更没通知下游是数仓里最让人抓狂的事故类型——表面上任务一切正常，数据悄悄错了，业务方发现时已经错了几天。面试官问这道题想考两件事：（1）你有没有被这种事故咬过；（2）你能不能设计出防御机制。能把『契约 + 校验 + 告警 + 组织约束』一整套讲出来，这题就到了资深水平。

业务场景：某短剧出海公司的广告回传字段含义变更事故

我在某短剧出海公司真实遇到过这个经典事故。上游广告系统的回传字段 `ad_revenue` 原来是美元，某次版本升级后变成了『当地币种金额』，同时加了 `currency` 字段标识。上游同事觉得『加了新字段就是向前兼容』，没通知下游。

我们的 DWD 照旧把 `ad_revenue` 当美元算，结果海外广告 ROI 看板当天虚高 3 倍——印尼盾的广告收入直接当美元计算。业务方炸了一周才发现，投放组已经按错误数据调整了预算。

-- 事故前后的 schema 对比
-- 上游原始 schema（v1）：
CREATE TABLE ads_report_v1 (
  campaign_id BIGINT,
  ad_revenue  DECIMAL(10,2),  -- 美元
  ...
);
 
-- 上游变更后 schema（v2，悄悄上线）：
CREATE TABLE ads_report_v2 (
  campaign_id BIGINT,
  ad_revenue  DECIMAL(10,2),  -- 含义变了！成了当地币种金额
  currency    STRING,          -- 新加字段
  ...
);
 
-- 我们的 DWD SQL（没察觉）：
INSERT INTO dwd_ad_report
SELECT campaign_id, ad_revenue AS revenue_usd  -- 还当美元用
FROM ods_ads_report;
 
-- 结果：印尼的 campaign 看起来收入暴涨 15000 倍
-- （因为 1 美元 = 约 15000 印尼盾）

段落一：第一层——契约（数据合同）

第一层防御是在上下游之间建立明确的数据契约。契约里明确：字段名、类型、单位（！）、业务含义、允许的值范围、变更流程。

# 数据契约模板（放在 git 仓库，上下游共同维护）
table: ads_report
owner: ads_team  # 上游负责人
consumers:
  - dwh_team     # 我们
  - bi_team
  - risk_team
 
fields:
  - name: campaign_id
    type: bigint
    nullable: false
    description: 广告活动ID
 
  - name: ad_revenue
    type: decimal(10,2)
    nullable: false
    unit: USD            # 单位明确（这次事故的关键！）
    description: 广告收入（美元）
 
change_policy:
  - 新增字段：提前 3 天通知所有 consumers
  - 删除字段：提前 14 天通知 + consumers 签字
  - 含义变更：禁止（改名建新字段）

关键一点：契约必须由上下游共同 review，不是上游单方面决定。契约变更走 Pull Request 流程，所有 consumers 必须 approve。

段落二：第二层——DQC 自动校验

契约是人读的，DQC 是机器校验的。每天任务跑完自动校验 schema 是否符合契约。

-- DQC 校验模板（每日定时跑）
 
-- 校验 1：字段存在性
SELECT
  CASE WHEN COUNT(*) = 0 THEN 'FAIL: missing column ad_revenue'
       ELSE 'PASS' END AS result
FROM information_schema.columns
WHERE table_name = 'ads_report' AND column_name = 'ad_revenue';
 
-- 校验 2：字段类型
SELECT column_name, data_type
FROM information_schema.columns
WHERE table_name = 'ads_report'
  AND data_type != 'decimal';  -- 期望类型
 
-- 校验 3：数值范围（防止单位偷偷变了）
SELECT 'FAIL: revenue out of range' AS result
FROM ads_report
WHERE dt = '${bizdate}'
  AND ad_revenue > 1000000;  -- 单个 campaign 日收入不会过百万美元
                              -- 如果触发，可能是单位变了
 
-- 校验 4：环比异常
SELECT SUM(ad_revenue) AS today,
  (SELECT SUM(ad_revenue) FROM ads_report WHERE dt = DATE_SUB('${bizdate}', 1)) AS yesterday
FROM ads_report WHERE dt = '${bizdate}';
-- 差异超过 20% 告警