漫话以治理优先的思维方式设计数据体系

引言——重新思考治理

当我听到“治理”这个词时，我会立即想象人们说“不！”，阻止访问，要求批准，甚至可能有点.严厉。对我来说，治理更像是一种障碍，而不是一种推动因素。

说实话，我觉得这很无聊。我尽量避免任何看起来像安全或合规的东西。我跳过了安全相关的认证，因为深入研究访问策略和审计日志感觉很枯燥。

我还记得职业生涯早期，我需要访问一个项目的数据集。这花了好几天时间，我辗转于不同的团队。等我终于拿到访问权限时，项目方向已经发生了改变。

那一刻，我心里就形成了一个信念：治理妨碍了一切！许多人通过变通方法来应对这种摩擦：本地副本、非官方管道、未记录的快捷方式。

我“有时”也会这么做，尤其是在研究型实验中，治理并非迫切需要关注的问题。但在孤立实验中行之有效的方法，在旨在扩展、协作或服务真实用户的系统中却行不通。

我花了不少时间，经历了不少“意外事件”，才意识到治理并非“以后再处理”的事情。它不是阻碍，不是开销，而是设计！本文是从另一个角度对这一认识进行结构化的思考。

治理不再是我回避的事情。它是我认真、系统地思考的事情 ， 从第一天开始！

为了给这种思维转变带来 架构性 ， 我们可以看看 DAMA 模型 。 我不会解释整个模型；它非常广泛，涵盖的内容远超我在这里所能触及的范围。相反，我会将自己的学习成果映射到其中选定的部分，并非作为抽象的理论，而是一种将实践见解锚定在结构化且被广泛认可的事物上的方法。可以说，我会在相关的时候参考 DAMA 模型，但这不是重点，而是一个有用的参考，以形成我对治理的思考。

➀ 治理不仅仅是访问控制

长期以来，治理一直处于我的认知边缘。作为一名数据科学家，我通常将其视为访问控制的同义词，即谁可以读取什么，谁可以在何处写入。考虑到我的工作性质，这很合理。

如果您是数据科学家或分析师，您可能有自己的看法，治理是您在请求访问时偶尔遇到的背景事物。

但这只是整个情况的一部分。

当我担任 架构 师的角色时，我与治理的关系发生了变化。

突然间，这不仅仅是关于“有人可以访问这个表吗？”的问题，而是关于信任、可追溯性和长期可维护性的问题。

我必须思考系统如何 构建 、团队如何协作以及今天做出的决定明天如何被理解。就在那时，我意识到治理包括访问控制，但并不由它来定义。

DAMA 框架帮助我实现了这一目标。通过它的术语，我发现我过去所说的“治理”实际上只涵盖了数据安全领域的一小部分。

但是 DAMA 的数据治理领域向我介绍了我以前没有太注意的概念，例如：管理和决策权。

乍一听，这些术语似乎有些抽象。但仔细观察后，我发现它们恰恰描述了我所遇到的差距。

🏷 ️数据管理的本质在于：谁来管理这些数据？实际上，数据管理就是确保所有数据都记录在案、定义保持一致、质量问题得到及时解决而不是被忽视的人。当有人问“这一列是什么意思？”时，数据管理人才是真正了解数据含义的人，或者知道该问谁！

是的，也许你会问：“管理权和所有权之间有什么区别？”我也有同样的问题。

简而言之：所有权关乎责任，管理权关乎 任务 。

即使您不亲自处理数据，您也可能拥有数据，做出关键决策并对结果负责。相反，您可以管理数据，维护其质量和可用性，而不是在出现问题时承担最终责任。例如，数据管理员（例如，BI 开发人员或业务分析师）说：“这个数字似乎不对，我认为它包含的收益有误。” 数据所有者（例如，财务合伙人）说：“谢谢，我们现在就修复这个问题，确保不再发生。”

决策权处理的是一个经常被忽视的问题：谁来对这些数据做出决策？谁来决定重命名字段、更改数据类型或重新定义指标？在许多团队中，变更是临时发生的，由需要的人推动。良好的治理会为这些决策引入清晰的流程，确保变更经过深思熟虑，其后果也易于理解。

作为一名架构师，通过更广阔的视角看待治理让我意识到，治理不是事后修补的，而是需要 尽早进行设计！

② DAMA治理架构一瞥

说到这儿，你可能会想：DAMA 模型到底是什么？它包含哪些内容？我还有什么没注意到的？

我也有类似的疑虑。尤其是因为人们经常会列出一些熟悉的概念，比如数据质量、访问控制、元数据，然后随意地加上“等等”，仿佛其他一切都只是事后才想到的模糊概念。

这或许是一句无关紧要的玩笑话，但在技术对话中，“等等”通常表示我们已经理解到极限了。说实话，我在上面的比喻图中也提到了这一点（冰山一角，我提到了“……等等”）。

具体来说，DAMA 框架列出了 11 个不同的数据管理领域。它不是一份清单或分步指南，更像是一张地图。地图很有用，尤其是对 架构 师来说。

轮子的中心是数据治理。你可能会注意到，它不仅仅是众多框架中的一个，而是将所有内容整合在一起的协调层。

围绕它的领域包括数据架构、元数据管理、数据安全、数据质量以及“更多”领域，但这些领域定义明确，具有实际意义。

不过，情况并非如此：如果你是一名数据架构师，那么这些领域中只有一个，也就是数据架构，字面上的标题里有“架构”这个词。但在实践中，你几乎会被所有领域吸引。

您将做出依赖于元数据良好管理的设计决策。

您将继承没有明确管理的系统，并被要求“使其具有可扩展性”。

您将构建假设数据是可信且受管理的管道。

您需要对质量进行建模，跨孤岛集成，并在执行过程中“确保安全”。

所以， 架构 师并非拥有整个 DAMA 体系。但如果你不了解它的组成部分，最终可能会不小心围绕它们进行设计，甚至更糟的是，你会忽略它们，直到它们在生产中出现故障。

③ 利用元数据和血统构建信任

一旦我开始将治理视为设计而不是限制，我就无法停止注意到系统中信任破裂的所有细微、安静的方式。

它并不总是戏剧性的。它不是数据泄露或系统故障。它比这更微妙：有人在使用数据集之前犹豫不决，因为他们不确定它是否是最新的。仪表板被废弃，因为没人记得某个数字是如何计算的。初级分析师从头开始重新创建报告，因为他们找不到或无法信任现有的报告。

这些情况很少出现在事件日志中，但它们却是治理缺失的真正代价。它们拖慢了团队的进度，造成了冗余，并削弱了信心。

那时我才意识到：治理不仅仅关乎谁有权访问，还关乎人们能否信任他们访问后看到的内容。

这种信任并非来自仪表板或文档。它来自元数据和 血缘 ！

元数据：系统自己的内存

元数据不仅仅是一个描述或一个标签。它是系统的记忆！

它使数据集能够自我解释。它使人们能够无需猜测地应对复杂情况。它能够提高可发现性，减少误解，并使团队摆脱对部落知识的依赖。

在现代数据系统中，元数据并非事后才填充的内容，而是设计时就已考虑到的。元数据为原本杂乱无章的表格和文件提供了结构。

我之所以这么说，是因为我曾经经历过类似的情况。我是一名数据科学家，打开一个没有描述、没有所有者、甚至不知道一半列含义的表。我和很多人一样，会猜测，或者忽略那些我不理解的列。有时我很幸运，有时则不然。

元数据涵盖数据集所有权、字段定义、分类、对象间关系、使用模式以及访问上下文等内容。捕捉所有这些信息不仅仅是文档，更是设计。

因为好的元数据不会放在 wiki 的一边；它会影响您的系统如何被理解、使用和扩展。

从命名约定到所有权模型，从分类到谱系，这些选择都会影响架构。它们不仅仅是描述性的，更是结构性的。

设计时考虑治理意味着您不仅仅会问“这应该放在哪里？”

你还会问，“六个月后，当我不在身边时，人们如何找到它、理解它，更重要的是信任它？”

Lineage：建立信心的足迹

如果元数据是记忆，那么 血缘 就是故事！

血缘 可以告诉你数据集是如何形成的，哪些源系统输入了它，应用了哪些转换，以及哪些仪表板或模型依赖于它。它能将不可见的逻辑转化为可见的流程！

当出现问题或看起来不对劲时，沿袭通常是唯一可以放心调试的方法。

我在实践中见过这种情况。仪表板上的数字看起来很可疑，而且没有血缘关系，你只能打开标签页、追踪管道并进行猜测。

但是有了血统？你顺着线索走。你看到了引入空值的那个连接。你注意到了上游悄悄弃用的字段。你调试的是“系统”，而不仅仅是“症状”。

但血统不仅仅适用于紧急情况。即使一切正常，它也能建立信心。它帮助分析师提出更好的问题。它帮助新团队成员更快地上手。它帮助利益相关者信任他们看到的数字。

这就是为什么所有设计都应该考虑到血统意识。

④ 注重质量的设计

数据质量是一个很难反驳的流行词。每个人都在谈论它，每个人都说自己关心它。但当它涉及到实际系统时，人们的做法往往是被动的：事后测量，报告问题，然后指望下游有人能修复这些问题。

它被视为技术问题：测试、验证、检查。但如果你仔细观察，就会发现质量是治理的实际行动。它关乎设定期望，并将这些期望融入系统结构，而非错误日志。

DAMA 模型使这种区别更加清晰。数据质量是一个独立的领域，但它与数据集成并存。因为真正的质量问题不仅仅是无效值，还包括不匹配的连接、未记录的假设、静默截断以及一个团队做出的对另一个团队影响的决策。

航空史上有一个故事让我印象深刻。二战期间，英国制造了一架非凡的飞机：德· 哈维兰蚊式轰炸机 。与当时的大多数飞机不同，这架飞机主要由木材制成，以便节省金属用于其他战争用途。它轻巧、快速、高效，被认为是工程学上的一项成就。

但后来事情开始变得糟糕。飞机开始在空中解体。起初，故障被归咎于敌方袭击。但经过调查，原因远没有那么引人注目，反而更加明显：其中一家工厂用于粘合木质部件的胶水混合不当！

它并没有立即出现故障迹象。但随着时间的推移，在压力和湿度的作用下，它最终崩溃了。飞机通过了检查，执行了任务。但飞机内部却已经开始解体。

这个故事总是提醒我，一个系统可以在表面上“运作”，但其内部却在悄悄地退化。

在数据系统中，这就是缺失的质量控制。管道运行，仪表板加载。但这些数字建立在无声的假设之上：缺少字段、默认值、未知的连接。就像蚊子一样，系统会一直保持，直到它失效！

这就是为什么质量必须在设计中融入，而不是在检查中融入。设计始于期望。

模式强制执行是最明显的例子之一。它常常被视为限制性的，阻碍了灵活性。但实际上，它意味着清晰度。它就像系统在说：“这就是我期望的。”

当强制执行某种类型、声明必需字段、拒绝未知列时，这不仅仅是一个技术特性，而是一个治理视角。你声明有效数据是什么样的，系统会维护这个定义。

但期望并不止于结构。它们延伸到集成：键是否对齐？关系是否合理？维度是否对齐？这个数据集能否安全地与那个数据集连接，还是会引入“静默”重复？这些问题完全属于数据集成领域，而且往往是质量问题最严重的隐患。

值得庆幸的是，现代架构为我们提供了无需依赖人工记忆就能确保质量的方法。我们可以将约束直接编码到模型中。我们可以创建仅允许经过验证的数据通过的层。我们可以定义 合约 ，即数据生产者和消费者之间的明确协议，例如：“这是我们承诺交付的内容，如果我们未能交付，您将通过合约得知。”

这些不仅仅是实践，更是设计原则。如果正确实施，它们将改变治理的本质：从被动应对转变为主动预防。

⑤ 安全、分类和策略作为设计工具

2018 年，全世界目睹了一项悄无声息的 决策演变成 一场全球丑闻 。一款看似无害的性格测试应用竟然收集了个人信息，不仅来自其用户，还来自数千万好友，这都归功于Facebook的系统设计方式！

没有黑客攻击，也没有防火墙被攻破。问题不在于未经授权的访问，而在于系统从一开始就没有将这些数据标记为敏感数据！没有明确的分类，也没有对哪些数据可以收集、共享和重新利用进行任何划分。

架构允许这样做。因此数据流动，远远超出了用户的理解或预期。

后果是巨大的。调查、国会听证会、数十亿美元的罚款，以及历史性的信任丧失。这一切都是因为没有一个机制来规定“这些数据不应该被泄露”。

长期以来，我都把安全视为边界防护。防火墙、访问控制，如果情况严重，或许还会用到加密。我没有意识到，在系统内部，治理方式已经受到我们如何标记、控制和定义数据行为的影响。

对我来说，“分类”这个词一直属于机器学习！我把分类器看作是算法。但进入 架构 行业后，我发现了一种不同的分类器，它能够悄无声息地决定一列或一个数据集的整个生命周期。它不是通过预测，而是通过意图。

一旦表达了这种意图，设计就变得至关重要。标记为可识别个人身份的列不仅在视觉上被隐藏，还会触发系统层面的屏蔽。访问规则不仅仅是用户角色，更是目的、责任和暴露风险在架构上的体现。

对于用户来说，这些可能看起来像是令人沮丧的政策、缺失的值、被阻止的报告、被屏蔽的字段，但实际上系统正在执行其设计的功能！

这改变了我的观点。安全和分类并非附加控制，而是根植于架构之中。在旧系统中，策略是文档。如今，它们是设计决策。系统的行为反映了这些决策。标记上游的字段会在整个流程中携带该标记。

DAMA 模型所称的数据安全和数据治理并非孤立的领域。它们紧密交织。一方提供规则，另一方则将规则构建到系统中。

如果在设计时嵌入分类和策略，您无需手动强制执行信任。系统会为您执行信任。而且，它会安静、精确且一致地执行。

因此，我们不再问谁能看到某些数据，而是开始问一个不同的问题：这些数据代表什么？它应该如何表现？以及，将它从一个地方移动到另一个地方会产生什么影响？

从控制访问到编码含义的这种转变才是治理优先架构的真正面貌。

⑥ 机器学习治理

如果你翻阅DAMA的 车轮图 寻找“机器学习治理”，你不会找到明确的答案。DAMA并非为机器学习系统设计。然而，你在模型构建、跟踪、解释和调试上花费的时间越多，你就越能 发现DAMA模型仍然适用。

只是我们还没有更新我们的思维模式来赶上。

传统的数据治理侧重于数据集、转换、沿袭和访问。但机器学习系统并不止于数据。它们会生成行为，而这些行为是由输入、训练过程、超参数以及可能已不复存在的历史数据快照所塑造的。

机器学习领域的治理带来了一些新挑战，这些挑战既熟悉又陌生，只是更加混乱。曾经的表格现在变成了模型制品。曾经的字段现在变成了特征。曾经的转换步骤现在变成了训练流程。

但核心治理问题依然存在。我们能信任它吗？我们能追踪它吗？谁应该为此负责？究竟发生了什么变化？

版本控制、可解释性、可重复性和可审计性不再只是学术上的机器学习难题！它们是真正的治理问题，并且正在引起现实世界的关注。

各国政府正开始行动。《 欧盟人工智能法案》 以及全球围绕人工智能伦理和透明度的努力，正在规范化良好治理的模式。这些不仅仅是法律辩论，更是系统解释能力的转变。

现代平台也在迎头赶上。许多平台现在将模型视为数据生态系统中的“一等公民”。您可以将预测追溯到模型版本，模型版本追溯到训练运行，训练运行追溯到数据快照和代码。

这是模型的血统！是的，它看起来很像我们已经对数据集所做的！

作为一名架构师，你或许需要开始将模型视为不断发展、受管控的对象，而非输出。你不仅要监控它们的性能，还要审查它们的构建过程、依赖关系以及审批者。

这就是为什么诸如受管控的特征存储、感知沿袭的 ML 注册表以及部署审批工作流等模式不仅仅是 MLOps 技巧。它们是治理实践，即使它们尚未进入 DAMA 框架。

也许他们应该这么做。

因为模型成为生产系统的一部分后，就承担了重要的责任：决策、风险和后果。这意味着它 们应该遵循我们应用于其他一切事物的相同设计准则。它不是事后诸葛亮，也不是例外。它只是治理的延伸！

治理优先设计清单

在结束这篇文章之前，我想没有比分享一份清单更好的方法了。

这是一种表达“是的，治理在这个架构中是完整的”的方式。它们是设计时的反思。如果你能仔细检查这份清单，并真诚地回答“是”，那么你很可能不仅仅是在构建一个有效的系统，而是在构建一个持久的系统。对我来说，这才是治理优先设计的真正样子。

这还不是一个全面或标准化的清单，但这是一个开始。而且不知何故，它已经带来了巨大的改变。

访问和保护

☐系统是否根据目的和敏感度（而不仅仅是用户角色）实施访问控制？

☐访问决策是否被记录并可审计，包括覆盖的理由？

元数据和可发现性

☐作为管道的一部分，数据集、模型和仪表板是否包含丰富的描述、所有权和标签？

☐新团队成员是否可以在不询问任何人的情况下理解数据集是什么、它来自哪里以及如何使用它？

☐在 wiki 中，元数据是否被视为第一类对象，而不是事后才想到的东西？

分类与策略意识

☐分类是否嵌入在设计中，例如机密、内部或 PII 等标签；并在整个数据流中受到尊重？

☐这些分类是否会动态触发治理行为，例如屏蔽、访问限制或保留限制？

☐政策是否已编纂、可追溯并且直接与分类级别相关？

传承与变革意识

☐每个仪表板或模型都可以追溯到产生它的数据和逻辑吗？

☐系统是否显示了在转换过程中发生了哪些变化、何时发生了变化以及为什么发生了变化？

☐当源数据集发生变化时，是否能立即清楚下游会受到什么影响？

质量与期望

☐数据预期和验证规则是否在设计时声明和执行，而不是后来作为测试添加？

☐模式演变是否通过有意的审查而不是默默的漂移来处理？

☐数据缺失、重复或过时等质量问题是否明显地被提出并发送给正确的所有者？

AI 和 ML 治理

☐模型预测是否可以追溯到所使用的模型版本、训练数据和代码？

☐模型批准、部署和审查是否受结构化工作流程的管理，而不仅仅是代码笔记本？

☐可解释性、偏见和性能监控从一开始就是模型生命周期的一部分吗？

架构连贯性

☐治理原则是否反映在架构图中，而不是仅仅埋藏在文档或幻灯片中？

☐命名约定、领域边界和职责是否反映所有权和目的的明确性？

☐如果六个月后你不在了，其他人还能满怀信心地信任、使用和扩展这个系统吗？

本文来自微信公众号“数据驱动智能”（ID：Data_0101），作者：晓晓，36氪经授权发布。