2. 金融数据治理基础

在金融行业，数据治理不是“锦上添花”的IT项目，而是监管合规、风险计量与经营决策的底座。做dbt数据测试与文档治理，必须先理解治理的四个基本盘：数据质量、数据血缘、元数据管理、合规要求。它们决定了我们在dbt中该测什么、该记什么、该留什么证据。

一、核心原理：治理四要素与dbt的对应关系

数据质量关注数据是否“可用、可信、可解释”，在金融场景中通常体现为完整性、准确性、一致性、及时性、唯一性和有效性六类维度。数据血缘描述数据从源系统到报表、模型、指标之间的流转路径与加工依赖，是影响分析和问题定位的基础。元数据管理是对技术元数据、业务元数据与操作元数据的统一登记与维护，让“字段是什么、谁负责、怎么算”有据可查。合规要求则来自监管制度与内部审计，强调可追溯、可审计、可举证。

dbt的治理价值在于：把上述要求从“文档里的制度”变成“代码里的约束”。通过schema测试、数据测试、模型契约、 exposures、meta配置与自动生成文档，dbt让质量规则、血缘关系、元数据说明和合规证据在同一套工程体系中持续运行。

二、方法流程：从治理要求到dbt落地

把治理要求落到dbt，建议按以下流程推进：

1. 识别关键数据资产：优先覆盖监管报表、风险指标、客户主数据、交易流水等高风险高价值对象。
2. 定义质量规则：将业务规则翻译为dbt测试，如not_null、unique、accepted_values、relationships及自定义singular测试。
3. 建立血缘与依赖：通过ref、source、exposure声明模型依赖与下游消费关系，让血缘自动生成。
4. 补齐元数据：在schema.yml中维护模型描述、字段说明、owner、tags、meta等，形成可检索的数据字典。
5. 固化合规证据：将测试结果、文档版本、变更记录纳入CI/CD与审计留痕。

下面是一个金融场景中常见的dbt测试与元数据配置示例：

models:
  - name: fct_transaction
    description: "交易事实表，覆盖全行零售与对公交易"
    meta:
      owner: "risk-data-team"
      compliance_level: "high"
      regulation: "银保监数据治理指引"
    columns:
      - name: transaction_id
        description: "交易唯一标识"
        tests:
          - not_null
          - unique
      - name: customer_id
        description: "客户编号"
        tests:
          - not_null
          - relationships:
              to: ref('dim_customer')
              field: customer_id
      - name: amount
        description: "交易金额，单位：元"
        tests:
          - not_null
          - dbt_utils.accepted_range:
              min_value: 0

三、案例/场景：监管报送数据质量排查

某银行在季度监管报送前发现“贷款五级分类”报表与核心系统不一致。排查时，团队先看dbt血缘图，定位到中间模型int_loan_classification同时被三个下游模型引用；再查看该模型的测试结果，发现accepted_values测试未覆盖新增分类码“关注类-重组”。进一步检查元数据，发现该字段的业务定义未更新，导致加工逻辑遗漏。

修复动作包括：补充accepted_values测试、更新字段描述与owner、在exposure中标记监管报送依赖、将本次变更写入审计日志。整个过程从“靠人问”变成“靠血缘和测试定位”，排查时间从两天缩短到两小时。

四、误区/复盘：常见治理陷阱