数据治理：从资产目录到口径统一

从资产目录、元数据血缘到指标口径统一，讲清银行数据治理怎么从运动式填表，走向内建式、可验证的治理工程。

很多银行的数据治理项目，最后都沦为「补元数据、填责任表、交汇报 PPT」。运动一过，元数据过期、口径继续打架、下游照样不敢用这份数据。治理之所以失效，是因为它被当成了一份额外的「填表工作」，而不是数据生产流水线本身的属性。真正有效的治理，是让目录、血缘、口径和质量规则内建到系统里，而不是靠人肉维护。

治理为什么总做成运动

根本原因是把「治理」和「生产」割裂了。业务系统吐数据，治理团队在下游追着补标签、对口径。一旦人员变动或项目结项，治理成果立刻失真。

治理的目标不是「漂亮的报告」，而是让下游系统敢用这份数据。如果一份数据没人敢用来做决策，它就算被打了满分标签，也还是负债。

要扭转这个局面，得从三件最实在的事入手：盘清家底（资产目录）、追清来路（元数据血缘）、对齐说法（口径统一）。

资产目录：先盘清家底

资产目录回答的是「我们到底有哪些数据、归谁管、能不能用」。它不是 Excel 清单，而是带权属和分级的结构化注册表。

资产类型	例子	治理关注点
贴源表	核心系统流水	来源系统、更新频率
派生表	客户宽表	加工逻辑、依赖
指标	月活、不良率	口径定义、负责人
文件/接口	监管报送文件	敏感度、共享范围

目录必须和真实的元数据打通，否则就会出现「目录里说有、库里早就删了」的尴尬。一个可行的做法是：目录条目由采集任务自动生成，人工只补充业务语义，而不是反过来手工录入。

元数据与血缘：字段从哪来、到哪去

元数据解决「这个字段是什么」，血缘解决「它怎么变来的、又被谁用了」。两者合起来，才能做影响分析和溯源。

血缘怎么采

血缘最好自动采集，而不是靠文档口述。主流方式有两种：

静态解析：扫描 SQL、ETL 脚本、Spark/DAG 定义，提取表与字段级的输入输出关系。
运行时采集：在任务执行时记录实际读写的上下游，准确率最高但侵入性较强。

影响分析

有了血缘，一次核心系统字段口径变更，能立刻列出受影响的下游报表和指标。没有血缘，这类变更只能靠「老员工记忆」，风险极高。

血缘的价值不在炫技，而在于把「改一个字段要通知谁」从玄学变成可查询的图。它是治理能规模化的前提。

指标口径统一：最难的最后一公里

银行里「不良率」「活跃客户」「存款日均」这类指标，不同部门算出来常常不一样。根因不是谁算错，而是口径没有单一可信来源。

口径冲突的例子

「月活客户」可能被定义为：

渠道侧：当月登录 App 即算活跃；
零售侧：当月有动账交易才算活跃；
监管侧：按监管文件口径，且需去重。

三个数字放在一起对比，结论自然矛盾。更糟的是，没人说得清哪个是「官方版本」。

指标字典与单一来源

解决思路是建立指标字典：每个指标一条定义，包含口径 SQL、维度、过滤条件、负责人和生效时间。下游统一从字典取数，禁止各自重写逻辑。

-- 指标字典中「存款日均」的口径定义（单一来源）
SELECT cust_id,
       SUM(balance) / COUNT(DISTINCT cal_date) AS avg_daily_balance
FROM   dwd_account_daily
WHERE  cal_date BETWEEN :start AND :end
  AND  balance_type = 'SAVING'
GROUP  BY cust_id;

口径变更要走版本管理，旧口径保留可追溯，新口径标注生效日，避免历史报表被悄悄改义。

数据质量内建到流水线

质量不是事后抽查，而是 ETL/湖仓任务里的「门禁」。规则不过，数据不入库。

def quality_gate(df):
    checks = {
        "not_null": df["cust_id"].notna().all(),
        "unique":  df["cust_id"].is_unique,
        "balance_nonneg": (df["balance"] >= 0).all(),
    }
    failed = [k for k, ok in checks.items() if not ok]
    if failed:
        raise DataQualityError(f"质量门禁未过: {failed}")
    return df   # 通过才落库

规则要可配置、可观测，失败要告警而非静默跳过。
关键字段（证件号、金额）非空、唯一、非负，是底线规则。
质量趋势要可视化，恶化要能回溯到哪天哪个任务开始。

质量内建的核心，是把「信任」从事后审计提前到数据落库之前。一条坏数据一旦进了湖，下游十张报表一起错。

安全与合规：治理的硬约束

治理绕不开安全。银行对敏感字段的处理有硬要求：

静态加密：证件号、卡号、手机号落盘即加密，密钥与数据分离管理。
动态脱敏：查询侧按角色脱敏，开发人员查生产只能看到掩码。
分级分类：数据按敏感度分级，决定谁能看、能传到哪、能留多久。

这些不是治理的附加项，而是治理成立的边界条件。

落地节奏建议

治理切忌「全面铺开、一步到位」，那样必成运动。更稳的节奏是：

先选一个高价值域（如客户、账户），把目录、血缘、核心指标跑通。
把质量门禁接进现有流水线，不新建独立系统，降低阻力。
指标字典从冲突最严重的一批指标开始统一，尽快产出可见收益。
用自动化替代手工填表，让目录和血缘随任务自动更新。

小步快跑、用真实收益说话，比一份宏伟蓝图更能让治理活下来。

结论

数据治理不是运动，也不是额外的填表负担，而是把「可发现、可追溯、可信任」变成数据流水线的默认属性。从资产目录盘清家底，用元数据血缘追清来路，靠指标字典统一说法，再把质量门禁内建进去——四件事做实，数据才真正从负债变成资产。下一讲我们聊消息队列选型，那是让这些数据可靠流动的另一块基石。