让元数据跟着数据走：用列级血缘把治理从补票变成自动传播

预计阅读时间：14 分钟

数据治理最常见的成本，并不是半年一次的合规审计，而是每天都有人盯着 cust_seg_flg 之类的字段发问：它是什么意思、能不能用、是否包含敏感信息、其他团队是否已经定义过？当数据资产扩展到数千张表和视图后，这些小问题会变成持续征收的“治理税”。

Governance Agent 提供了另一种思路：基于 Google Cloud Knowledge Catalog、BigQuery 和列级血缘，让已经建立的描述、业务术语、策略标签与质量信号沿着数据流向下游传播。治理不再等问题暴露后补票，而是在数据发生变化时同步更新上下文。

治理债务为什么会沿着视图链条放大

一张核心表可能维护得很好：字段描述完整、PII 标签准确、质量检查稳定，负责人也清晰。但它经过连接、过滤和聚合生成下游视图后，原有上下文通常不会自动同行。

例如：

CREATE OR REPLACE VIEW analytics.customer_revenue AS
SELECT
  c.customer_id,
  c.segment_code,
  SUM(o.order_amount) AS lifetime_revenue
FROM curated.customers AS c
JOIN curated.orders AS o
  ON c.customer_id = o.customer_id
GROUP BY 1, 2;

源表中的 customer_id 可能已经被标记为敏感标识符，segment_code 也可能关联了受控业务术语。然而，新视图往往只保留字段和值，不会自动携带这些说明。至于 lifetime_revenue，它又不是简单透传字段，直接复制 order_amount 的描述也会造成误导。

这正是列级血缘比表级依赖更有价值的地方。系统不只需要知道“视图依赖哪张表”，还要回答：

customer_id 是否未经修改地穿过了连接；
segment_code 是否被重命名或经过 CASE WHEN；
lifetime_revenue 来自哪个字段、使用了什么聚合；
敏感值是否仍然存在，还是已经匿名化或聚合到不再具备原风险。

如果不区分这些情况，自动传播就会从减少人工劳动，变成批量制造错误元数据。

四类上下文如何向下游传播

字段描述：透传可以继承，变换必须重写

对于直接投影或跨越多层视图的透传字段，代理可以沿血缘找到可信上游，并提出相同描述。遇到 SUM()、COALESCE()、CASE WHEN 等表达式时，则需要结合生成字段的 SQL 描述变换结果，而不是机械复制源字段说明。

一个稳妥的描述应同时保留业务含义和计算方式。例如：

客户历史累计收入，由订单金额求和得到；按客户及客户分群聚合。

这比把 order_amount 的“单笔订单金额”原样贴到 lifetime_revenue 上更准确。

业务术语：相似性只能提名，不能替代依据

技术字段名很少与业务语言完全一致。系统可以用语义相似度把字段映射到受控词汇表，也可以从产品规格、数据字典、Markdown 设计文档或政策 PDF 中寻找明确定义。

关键边界是：语义相似度适合生成候选项，不适合凭空确认事实。如果文档没有清楚定义某字段，系统应该返回“证据不足”，而不是补出一个听起来合理的术语。

策略标签：传播前必须理解变换

PII 等策略标签是风险最高的一类自动化。上游敏感值原样进入下游时，标签和相关控制理应一起传播；但经过聚合、脱敏或不可逆匿名化后，风险可能已经改变。

因此，策略传播至少要检查：

血缘是已记录作业产生的硬链接，还是扫描推断出的关系；
字段是直接透传、重命名，还是发生了表达式变换；
变换是否真正降低了可识别性；
当前读取权限和掩码规则是否与标签一致；
证据是否达到自动应用阈值。

尤其不能仅凭 email、phone、customer_name 这样的字段名推断 PII。误标会造成不必要的屏蔽，漏标则可能放行真实风险。

信任与质量：下游不应默认从零开始

下游视图的可信度可以参考上游 Data Quality 与 Profiling 结果。如果转换执行了去重、空值处理或约束过滤，也可以把这些质量改进纳入评分。

但“上游可信”不意味着“下游必然可信”。错误连接可能放大行数，过滤条件可能引入偏差，聚合粒度也可能与业务定义冲突。因此，信任分数适合解释为带来源的派生指标，而不是永久认证。

两条证据链：先查硬血缘，再用洞察补洞

Data Lineage API 记录的是作业明确留下的关系。在埋点完善的流水线中，这是优先级最高、可审计性最强的信号。但现实数据平台经常存在缺口：旧表早于血缘系统创建、转换任务运行在未接入的平台中，或者历史关系根本没有被记录。

Governance Agent 的处理顺序很重要：

先沿标准列级血缘查找来源；
没找到时，再触发 Knowledge Catalog Data Documentation 扫描；
提取并缓存扫描推断出的关系；
将两类关系放进同一个遍历流程；
在结果中明确标记证据来自硬血缘还是推断洞察。

这避免了一个危险做法：把已记录事实和模型推断静默混合。审核人员之后必须能够追溯某个标签为何出现，以及它依赖哪种证据。

当血缘本身不存在时，还可以使用企业自己的文档补充上下文。短文档可直接放入提示词；长政策文档适合切块、嵌入并按字段检索；已经接入 Vertex AI Search 的文档库则可以直接查询。无论采用哪种方式，都应把“没有明确依据就停止”写进策略，特别是 PII 和受控术语映射。

可以这样实践：先建立保守的自动应用闸门

下面是一个可在本地运行的最小示例，用来演示如何依据来源类型、置信度和变换类别，将建议分成“自动应用”“人工审核”和“拒绝”三类。它不是 Governance Agent 的原生 API，而是接入 CI/CD 时可以采用的控制层模型。

创建 governance-policy.yaml：

thresholds:
  hard_lineage: 0.95
  inferred_insight: 0.99

allowed_auto_apply:
  description:
    - passthrough
    - rename
  glossary_term:
    - passthrough
  policy_tag:
    - passthrough

always_review:
  - aggregate
  - anonymize
  - case_expression
  - coalesce
  - unknown

require_explicit_evidence_for:
  - policy_tag
  - glossary_term

再创建 evaluate.py：

from pathlib import Path
import yaml

policy = yaml.safe_load(Path("governance-policy.yaml").read_text())

proposals = [
    {
        "column": "customer_id",
        "kind": "policy_tag",
        "value": "PII",
        "source": "hard_lineage",
        "transformation": "passthrough",
        "confidence": 0.98,
        "explicit_evidence": True,
    },
    {
        "column": "lifetime_revenue",
        "kind": "description",
        "value": "Customer lifetime revenue derived from order amounts.",
        "source": "hard_lineage",
        "transformation": "aggregate",
        "confidence": 0.97,
        "explicit_evidence": True,
    },
    {
        "column": "contact_hint",
        "kind": "policy_tag",
        "value": "PII",
        "source": "inferred_insight",
        "transformation": "unknown",
        "confidence": 0.91,
        "explicit_evidence": False,
    },
]


def decide(item):
    if (
        item["kind"] in policy["require_explicit_evidence_for"]
        and not item["explicit_evidence"]
    ):
        return "REJECT: no explicit evidence"

    if item["transformation"] in policy["always_review"]:
        return "REVIEW: transformation changes semantics or risk"

    threshold = policy["thresholds"][item["source"]]
    if item["confidence"] < threshold:
        return f"REVIEW: confidence below {threshold}"

    allowed = policy["allowed_auto_apply"].get(item["kind"], [])
    if item["transformation"] not in allowed:
        return "REVIEW: auto-apply is not allowed for this combination"

    return "AUTO_APPLY"


for proposal in proposals:
    print(f"{proposal['column']}: {decide(proposal)}")

运行：

python -m venv .venv
source .venv/bin/activate
python -m pip install pyyaml
python evaluate.py

预期输出：

customer_id: AUTO_APPLY
lifetime_revenue: REVIEW: transformation changes semantics or risk
contact_hint: REJECT: no explicit evidence

这个例子体现了三个值得保留的原则：硬血缘阈值与推断关系阈值不同；聚合和匿名化等变换进入人工审核；没有明确证据时，不自动赋予 PII 或业务术语。

项目同时提供 Gradio 仪表盘和 CLI。数据管理员可以在界面中扫描、预览并批准少量建议，平台团队则可以把 CLI 接入夜间任务或交付流水线。根据项目提供的命令形态，自动化流程可以组织为：

set -euo pipefail

# 先扫描并生成建议，必须保留证据来源与置信度。
steward_cli scan

# 在这里插入组织自己的策略检查、审批或变更单步骤。
# 只有通过闸门的建议才允许应用。
steward_cli apply

# 敏感标签传播建议单独执行和审计。
steward_cli policy-propagate

实际运行前需要按项目说明完成 Google Cloud 项目、身份权限、BigQuery、Knowledge Catalog 与血缘数据配置。不要在无人审核的情况下直接把 scan 和 apply 串成全量生产写入。

上线时别追求“一键自治”

这类系统真正合理的目标，不是彻底移除数据管理员，而是把人工判断集中到少数高风险、低置信度问题上。列重命名、特殊连接和复杂 SQL 都可能让血缘判断出错；类型或语义检查能拦截一部分问题，却不能提供数学意义上的保证。

可以按以下顺序落地：

从只读预览开始：先收集误报率、证据覆盖率和管理员接受率。
只自动应用低风险描述：初期不要自动修改敏感标签与访问策略。
区分证据来源：硬血缘、推断洞察和文档检索必须分别标记。
记录完整审计轨迹：保存旧值、新值、来源字段、SQL 变换、置信度和批准人。
设置回滚机制：元数据错误也会传播，批量操作必须能够撤销。
治理上游黄金数据集：高质量源头越多，下游自动传播的收益越大。
定期抽样复核：即使超过阈值，也要监控漂移与新型转换。

案例中的数据团队估计，这种方式最多可减少约 75% 的编目工作量，但这个数字应理解为特定数据环境中的预估，而不是所有团队都能复制的承诺。实际收益取决于血缘覆盖率、上游元数据质量、转换复杂度和审批制度。

治理自动化最重要的能力并不是“什么都能判断”，而是知道什么时候不能判断。让可信上下文随数据一起移动，让不确定建议停在审核队列里，才能把治理从周期性补债变成一项持续运行、可追溯且可控的工程能力。