趋近智
数据治理扮演着数据基础设施的控制平面角色。传统上,它的界定侧重于合规要求和业务词汇表 (vocabulary),而工程界定则侧重于状态管理和严格限制。生产环境中的治理是一套可编程逻辑,它规定了数据的创建、存储、访问和删除方式。
我们将治理界定为一种技术规范,而非一系列会议,它在数据生命周期内强制执行不变性。就像数据库模式强制结构完整性一样,治理代码强制执行安全性和语义完整性。
为了有效地实施治理,我们必须摆脱模糊的指南,转向确定性函数。从软件工程角度来说,访问策略是一个函数,它接受一个主体(用户或服务)、一个对象(表、视图或存储桶)以及一个动作(读取、写入、删除)作为输入,并返回一个布尔值结果。
我们可以将基本的治理决策 以数学形式表达:
其中:
如果输出为 ,则允许访问;如果为 ,则拒绝访问。这种二元性质表明治理策略必须准确。在生产管线中,容不得任何解释空间。当我们把治理当作一个函数时,我们就可以对其进行单元测试、版本控制,并使用标准的 CI/CD 实践来部署它。
工程治理在两个不同层级上运行:基础设施平面和数据平面。为了实施可扩展的控制措施,需要理解这两者之间的分离。
基础设施治理涉及资源本身。这包括为 S3 存储桶配置 IAM 角色,或为数据仓库集群定义网络策略。这通常通过 Terraform 或 Pulumi 等基础设施即代码 (IaC) 工具来处理。
数据平面治理涉及这些资源的内部内容。这包括行级安全、PII(个人身份信息)的动态脱敏,以及确保特定列被正确标记 (token)。这通常由 dbt 或 Spark 等数据转换工具或特定的数据库授权来处理。
下图显示了一个高级策略如何转换为跨这些平面的技术强制执行。
通过部署管线,将静态策略文件转化为活跃的基础设施限制和数据库授权。
为了编写治理代码,我们将资产和动作归入一个特定的分类体系。这个分类体系将模糊的业务需求转化为工程规范。
从工程角度来说,与系统交互的每个实体都是一个主体。这包括人类用户、服务账户和上游应用。治理要求每个主体都拥有密码学可验证身份。无法识别的事物就无法治理。
分类是根据数据对象的内容为其分配元数据标签的过程。我们并非手动更新电子表格,而是在代码中定义分类规则。例如,名为 email 或匹配正则表达式模式 ^[\w\.-]+@[\w\.-]+\.\w+$ 的列会自动标记 (token)为 PII。
这使我们能够动态应用策略。我们并非为“表 A”编写规则,而是为“所有标记为 PII 的资产”编写规则。
溯源回答了来源的问题。在分布式系统中,仅知道数据集存在是不够的;我们必须知道产生它的转换图。血缘是数据流动的有向无环图 (DAG)。治理依赖血缘来执行影响分析,如果上游源更改了模式,血缘会告知我们哪些下游治理策略可能被违反。
传统数据管理的一个重大失败之处是在部署后才应用规则。这被称为“事后检查质量”。在现代工程方法中,我们通过将治理左移来“将质量内置”。
这表示策略在构建时进行评估。如果开发人员尝试合并一个添加了包含敏感数据但没有适当标记 (token)的列的拉取请求,构建就会失败。CI 系统充当第一道防线,确保主分支始终处于合规状态。
我们使用策略即代码框架来实施这一点。Open Policy Agent (OPA) 等工具允许我们编写逻辑来检查 Terraform 计划或 Kubernetes 清单。同样,我们也可以编写 Python 脚本来解析 dbt 模型,以确保它们遵循命名约定和访问控制。
最后,我们必须使用工程指标而非合规清单来衡量治理的有效性。
通过关注这些指标,我们将治理视为一个优化问题。目标是在最大化数据可用性的同时最小化攻击面,这通过精准、自动化的代码来达到平衡。
这部分内容有帮助吗?
© 2026 ApX Machine Learning用心打造