以工程视角定义数据治理

数据治理扮演着数据基础设施的控制平面角色。传统上，它的界定侧重于合规要求和业务词汇表 (vocabulary)，而工程界定则侧重于状态管理和严格限制。生产环境中的治理是一套可编程逻辑，它规定了数据的创建、存储、访问和删除方式。

我们将治理界定为一种技术规范，而非一系列会议，它在数据生命周期内强制执行不变性。就像数据库模式强制结构完整性一样，治理代码强制执行安全性和语义完整性。

确定性治理函数

为了有效地实施治理，我们必须摆脱模糊的指南，转向确定性函数。从软件工程角度来说，访问策略是一个函数，它接受一个主体（用户或服务）、一个对象（表、视图或存储桶）以及一个动作（读取、写入、删除）作为输入，并返回一个布尔值结果。

我们可以将基本的治理决策 $D$ 以数学形式表达：

$$D(s, o, a) \rightarrow \{0, 1\}$$

其中：

• $s$ 是请求访问的主体。
• $o$ 是被访问的对象。
• $a$ 是被执行的动作。

如果输出为 $1$，则允许访问；如果为 $0$，则拒绝访问。这种二元性质表明治理策略必须准确。在生产管线中，容不得任何解释空间。当我们把治理当作一个函数时，我们就可以对其进行单元测试、版本控制，并使用标准的 CI/CD 实践来部署它。

基础设施平面治理与数据平面治理

工程治理在两个不同层级上运行：基础设施平面和数据平面。为了实施可扩展的控制措施，需要理解这两者之间的分离。

基础设施治理涉及资源本身。这包括为 S3 存储桶配置 IAM 角色，或为数据仓库集群定义网络策略。这通常通过 Terraform 或 Pulumi 等基础设施即代码 (IaC) 工具来处理。

数据平面治理涉及这些资源的内部内容。这包括行级安全、PII（个人身份信息）的动态脱敏，以及确保特定列被正确标记 (token)。这通常由 dbt 或 Spark 等数据转换工具或特定的数据库授权来处理。

下图显示了一个高级策略如何转换为跨这些平面的技术强制执行。

通过部署管线，将静态策略文件转化为活跃的基础设施限制和数据库授权。

工程治理的分类体系

为了编写治理代码，我们将资产和动作归入一个特定的分类体系。这个分类体系将模糊的业务需求转化为工程规范。

1. 身份与主体管理

从工程角度来说，与系统交互的每个实体都是一个主体。这包括人类用户、服务账户和上游应用。治理要求每个主体都拥有密码学可验证身份。无法识别的事物就无法治理。

2. 资产分类

分类是根据数据对象的内容为其分配元数据标签的过程。我们并非手动更新电子表格，而是在代码中定义分类规则。例如，名为 email 或匹配正则表达式模式 ^[\w\.-]+@[\w\.-]+\.\w+$ 的列会自动标记 (token)为 PII。

这使我们能够动态应用策略。我们并非为“表 A”编写规则，而是为“所有标记为 PII 的资产”编写规则。

3. 血缘与溯源

溯源回答了来源的问题。在分布式系统中，仅知道数据集存在是不够的；我们必须知道产生它的转换图。血缘是数据流动的有向无环图 (DAG)。治理依赖血缘来执行影响分析，如果上游源更改了模式，血缘会告知我们哪些下游治理策略可能被违反。

左移：CI 管线中的治理

传统数据管理的一个重大失败之处是在部署后才应用规则。这被称为“事后检查质量”。在现代工程方法中，我们通过将治理左移来“将质量内置”。

这表示策略在构建时进行评估。如果开发人员尝试合并一个添加了包含敏感数据但没有适当标记 (token)的列的拉取请求，构建就会失败。CI 系统充当第一道防线，确保主分支始终处于合规状态。

我们使用策略即代码框架来实施这一点。Open Policy Agent (OPA) 等工具允许我们编写逻辑来检查 Terraform 计划或 Kubernetes 清单。同样，我们也可以编写 Python 脚本来解析 dbt 模型，以确保它们遵循命名约定和访问控制。

治理的技术指标

最后，我们必须使用工程指标而非合规清单来衡量治理的有效性。

• 策略覆盖率： 被访问策略明确覆盖的数据资产百分比。
• 标记 (token)密度： 已分类列与总列数的比率。
• 最小权限差： 用户所拥有权限与实际使用权限之间的差异（通过分析查询日志确定）。

通过关注这些指标，我们将治理视为一个优化问题。目标是在最大化数据可用性的同时最小化攻击面，这通过精准、自动化的代码来达到平衡。