自动驾驶治理：用血缘自动化数据治理（Google Cloud）

今天尝试Gemini Enterprise

工作场所AI的前门

立即尝试

每个数据团队都知道那个时刻。有人打开一个表，看到一列名为cust_seg_flg，然后不得不去四处询问它的含义、是否安全使用，以及是否已经有人在三个团队之外的其他仪表板中回答过这个问题。将这个乘以数千个表和视图，你就会得到治理债务的真实成本：不是合规失败，而是对每个试图用你的数据做诚实工作的人每天征收的税。

如今大多数治理工具都是被动的。你扫描问题，得到报告，有人开票，三周后一列有了描述。而治理代理项目（构建于Google Cloud Knowledge Catalog、BigQuery和列级血缘之上）采取了不同的起点：如果上游的表已经被文档化、标记和信任，为什么每个下游视图都必须从头开始、手动地、每次都去赢得这种信任？

这篇文章正是关于这一转变：从你恐惧的审计，变成在后台自行保持当前的治理。

问题简而言之

数据资产通过管道增长。原始表被连接、过滤，并重塑为视图，而这些视图又供更多视图使用。在链条的某处，原始上下文（列的含义、是否属于PII、所持的质量标准）往往会丢失。它就是不传播。

结果是熟悉的模式：少数金表因为有人投入了时间而得到了良好的治理，而它们下游构建的所有内容逐渐变得文档不全、标记不全、可信度降低，即使底层数据实际上并没有变差。表的治理质量最终取决于多久之前有人关心过它，而不是数据今天如何被实际使用。

随着数据在公司中流动，它被组合、过滤，并重塑以供不同团队使用。但在旅程的某个地方，重要的上下文——比如一条信息的含义、是否包含私人细节，或者是否准确——被遗留在后。元数据根本没有随数据在生态系统中数据资产的演进过程中传播。

结果是熟悉的模式：公司会有几个完美文档化的"核心"数据集，因为有人投入了时间，但建立在它们之上的所有东西都成了谜。数据本身并没有变质，但没有原始上下文，人们开始不信任它。最终，数据只有在有人最近手动更新其元数据时才被视为可靠，而不是因为它实际包含的内容。

代理实际做什么

核心思想简单直接：使用列级血缘来找出列的来源，并传播上游已有的治理元数据，而不是要求人类重新推导。

具体来说，它处理四件事：

描述。 如果transactions.customer_id上游有清晰的描述，而下游视图通过两到三次连接的跳跃拉取该列，代理就会追踪该血缘并在下游提出相同的描述。当列不是直接传递（它是SUM()、CASE WHEN、COALESCE）时，代理会读取生成它的实际SQL，并编写反映转换的描述，而不是复制不再适用的上游描述。

业务词汇术语。 技术列名很少与人们实际使用的业务语言匹配。代理使用语义相似性将列映射到受控词汇表，还可以读取非结构化文档（PDF政策、产品规格、Markdown设计文档）以找到明确定义，而不是仅凭列名猜测。

策略标签。 这是对风险最重要的一项。如果上游列被标记为PII，代理就会追踪数据流向何处，并在下游推荐相同的标签，同时附上当前谁有读访问权限以及适用哪些脱敏规则的摘要。它还检查转换是"直接拉取"（敏感值原样传递）还是经过聚合或匿名化处理，这样就不会盲目地将PII标签印在不再承载风险的列上。

信任和数据质量评分。 代理不是将每个视图视为未知，而是基于其上游来源的数据质量与概况分析结果推导信任评分，并在检测到转换实际提高了数据质量（去重、空值处理等）时给予加分。

每一个操作在应用之前都会通过置信度阈值。系统明确不会在没有坚实依据的情况下推断PII状态或词汇映射。如果证据薄弱，传播不会自动发生。这是一个刻意的设计选择：代理旨在快速弥合明显空白，而不是做出应由人来做的判断决定。

为什么"主动"是正确的词，而非夸大其词

主动治理并不意味着预测未来。它意味着治理工作随着数据的移动而发生，而不是等待定期审查或合规事件触发。在实践中，这体现在三个方面：

• 新视图自动继承上下文，而不是在未文档化状态下开始并等待有人注意到。
• 敏感数据在其流动时被标记，而不是在被十二个不知道需要脱敏策略的人查询之后才发现。
• 数据管家将时间花在判断决策上，比如模糊映射或新的词汇术语，而不是逐列标记的重复工作，而血缘图本可以告诉你这些。

这些都不会取代数据管家。它只是改变了数据管家的一天：减少在UI中键入描述的时间，增加在决定什么应算作业务术语或边缘情况是否需要策略例外的时间。

当血缘耗尽，带上你自己的上下文

血缘关系很强大，但并不完整。很多表没有干净的上游来源可以继承：新摄入的数据集、一次性导入、早于你现有血缘追踪的表。对于这些情况，代理不会只是耸耸肩。它让你将你自己的文档（PDF 策略、产品规格、Markdown 设计文档，甚至是电子表格或数据字典的截图）指向它，并以此作为依据。

有三种方式可以提供上下文，选择哪种取决于你传递的内容大小。对于短文档，你可以直接将全文注入提示。对于长篇内容，比如五十页的数据分类策略，代理会将其分块、嵌入，并仅检索与描述的具体列相关的段落，这样你就不必为每个字段重新阅读整个文档而付费。如果你的组织已经在 Vertex AI Search 中建立了适当的文档存储库，代理可以直接查询该存储库，而不是每次都重新处理文件。

值得指出的是，这种依据是多么保守。这不是“阅读文档然后猜测”。给模型的指令是明确的：如果文档中没有明确定义列，它必须说明并停止，而不是用听起来合理的猜测来填补空白。这条规则对策略标签和术语表术语尤其严格。只有当文档以明文语言说明时，列才会被标记为 PII，比如明确的“PII: Y”标志或指定的敏感度部分。不能从列名推断，也不能说“这听起来可能是敏感的”。

这种区别比听起来更重要。一个在不确定时推断 PII 状态的工具最终会掩盖不需要掩盖的列，或者更糟的是，放过真正需要掩盖的列。让“我不知道”成为有效答案，才能使自动化足够可信，无需人工重新检查每个输出。

两个信号，而非一个：血缘加智能

血缘是主要信号，但并非代理听取的唯一信号，且值得精确说明原因。数据血缘 API只知道作业明确记录的内容。如果一个表是通过良好监测的管道构建的，那么这是一条清晰、高置信度的线索。但许多实际情况存在空白：早于良好血缘捕获的表、在跟踪作业之外运行的转换、技术上存在但从未记录为依赖的关系。

对于这些空白，代理有第二次通过。它可以触发知识目录数据文档扫描（Gemini 在表或数据集上运行的 AI 驱动分析），即使没有干净的 SQL 线索，也能推断关系和列含义。这些推断的关系被提取并本地缓存，然后加载到处理血缘的同一遍历引擎中，因此两个信号一起检查，而不是存在于必须手动协调的独立系统中。

顺序很重要。标准血缘先运行，因为它基于实际记录的作业。智能传递其次，仅填补血缘未找到的内容，并且其提供的任何内容都明确标记为来自该来源，而不是静默混合。如果您稍后审计传播的描述或标签，您可以判断它来自硬血缘链接还是推断链接。此路径有专门的端到端流程（触发扫描、等待、提取结果、应用），因此它不是附加到主工作流的手动辅助任务。

实际效果：不完整或新接入的管道在第一天就能获得有用的传播，而不是等待血缘覆盖赶上。

日常外观

该项目附带基于 Gradio 的仪表板和 CLI，这比听起来更重要。在演示前审核少量表的管理员会需要仪表板：运行扫描，查看哪些表有元数据间隙，预览建议的描述或标签，并单击批准。希望将其作为夜间作业或 CI/CD 管道一部分的平台团队将使用 CLI，以与其他管道步骤相同的方式编写 steward_cli scan、apply 和 policy-propagate 命令。

这种双界面反映了实际的操作选择：仅从 UI 工作的治理工具永远不会自动化，而仅从 CLI 工作的治理工具永远不会被最接近数据的人采用。

需要人工参与的地方

值得直言不讳：这不是“设置后不管”的系统，也不应被这样对待。血缘置信度评分仍然可能出错，尤其是在重命名列或异常连接情况下。语义不匹配检查能捕捉明显错误（日期列不应继承 ID 列的描述），但它们是启发式方法，而不是保证。每次传播都设计为在应用前预览，该预览步骤不是形式，它是实际的安全机制。

诚实的宣传语不是“无需努力的治理”，而是“将努力集中在正确的5%决策上，而不是重复的95%”的治理。

客户评价

作为VodafoneThree UK数据枢纽的管理者，我们面临的最大挑战之一是，我们的数据资产中有很大一部分仍然没有文档记录或标签不一致。这给数据发现带来了障碍，拖慢了交付团队的速度，并限制了我们从基于数据构建的AI解决方案中释放价值的能力。数据管理员代理改变了这一切。通过结合编目、血缘和自动元数据传播，它使我们能够将治理工作集中在对价值提升最大的地方，同时自动将可信上下文传递到下游。我们无需手动审查数千张表，而是能够专注于治理源数据集，并让血缘将这种知识扩展到整个平台。我们估计，这种方法可以将编目工作量减少多达75%，同时显著提高英国数据枢纽的数据可发现性、可信度和AI就绪度。” - Radina-Paola Ivanova，VodafoneThree UK数据枢纽生成式AI工程师

要点

治理债务与技术债务一样会悄然累积：直到下游某人在最糟糕的时刻撞上它。这类方法的价值不在于让治理不再是问题，而在于将工作移到上游，字面意义上让上下文和控制随数据同行，而不是每次有人构建新视图时都从头重建。

对于拥有多年未入档BigQuery数据资产的团队来说，这不是可有可无。这是治理成为你每年赶工两次的事情与治理跟上数据实际移动速度之间的区别。

发布在

• 数据分析