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

Sat, 08 Aug 2026 00:00:00 +0000

很多银行的数据治理项目，最后都沦为「补元数据、填责任表、交汇报 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;

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

元数据 on 追风笔记