为什么读取时模式停止工作
Schema-on-read 是 2015 年的正确折衷方案。它让数据团队的摄取速度比上游生产者标准化的速度更快，降低了探索性分析的成本，并成为数据湖时代的基础。到了 2020 年，缺点就显而易见了。到 2026 年，它们将主导每个成熟数据组织的事件日志：生产者和消费者之间无声的模式漂移、仅在第三周的模型评估中才会出现的微妙的字段级语义变化，以及令人不安的事实，即公司中最昂贵的仪表板通常运行在没有人通过合同同意保持稳定的数据上。
正在进行的转变是对合同的回归——但应用在正确的层面。数据契约使得生产者-消费者关系在操作系统和数据平台之间的接口上变得明确。它们不是数据库模式，不是 OpenAPI 规范，也不是 dbt 测试。它们是一个协议，规定：这些字段、这些类型和这些语义、这些更新节奏和这些空保证、这个版本控制策略将一直存在，直到我们明确协商更改为止。
接下来的框架详细介绍了有用的数据合同实际指定的内容、合同在架构中的位置、它们如何与 ML 功能管道和 LLM 数据源交互、为什么生产者激励是组织的难点、始终如一的 90 天采用模式，以及区分工作合同计划和文档练习的运营治理。
数据合同实际规定了什么
有用的数据契约有六个要素。发货量较少的团队发现每次发生事件都要重新就合同提起诉讼；随着表面积的增加，运送更多的团队发现自己无法维持合同。
- 架构。字段名称、类型、可为空性、枚举和约束。大多数团队开始和结束的赌注层。必要但其本身在物质上是不够的。
- 语义学。每个字段在业务术语中的实际含义、上游计算方式以及明确排除的内容。 “收入”字段在操作上没有任何意义，除非合同指定其是总额、净额、合同签署、计费、收取还是确认。模糊的语义会产生最昂贵的事件。
- SLA。更新频率、延迟、新鲜度保证。 “每日”不够具体； “在 UTC 时间 07:00 之前在仓库中可用，与源系统最多有 4 小时的延迟”是合约所需的精确度水平。
- 质量阈值。可接受的空率、基数界限、分布检查、引用完整性期望、值范围约束。字段可能是模式正确的，但仍然存在质量问题，从而默默地破坏下游模型的性能。
- 版本控制和弃用政策。如何宣布重大变更、过渡期间旧模式与新模式共存多长时间、谁签署变更、回滚过程是什么。
- 业主。指定的生产者所有者、指定的消费者负责人和记录的支持路线。没有指定人类所有者的合同会在六个月内解散，因为没有人负责在正常的团队轮换周期中维护它们。
将合约放在架构中的什么位置
常见的架构错误是将数据契约视为文档。未执行的合同是一个维基页面，有人最终会停止维护。执行点比合同格式更重要。
2026 年可行的实用模式：以轻量级、机器可读的形式保存合约（针对架构注册表的 YAML 或 JSON，使用开放规范，例如来自 Linux 基金会 Bitol 项目的数据合约规范或开放数据合约标准），并在两个边界上强制执行。
- 摄入时。不符合合同的数据会因明显错误而被拒绝，而不是被默默地强制为最接近的匹配形状。生产者立即看到失败；下游消费者不会接触到会悄悄降低其模型性能的垃圾数据。
- 出版时。在任何合同变更发布之前，都会根据持续集成中的测试数据检查生产商的合同。重大变更是在代码审查时发现的，而不是在消费者的下一个批处理作业中发现的。
为什么“大声而快速地失败”是正确的默认设置
在摄取和发布时通过合同执行构建的管道很快就会失败，而这正是合同应该做的。另一种选择——对不合格数据进行无声强制——会产生持续数周的事件，其中模型一直在错误的分布上进行训练，直到生产性能下降到超过阈值为止，没有人注意到。
团队必须内化的文化转变是，大声而快速的失败是好的。最初的几次合同执行被拒绝让人感觉管道突然变得脆弱了。在实践中，管道总是脆弱的——合同只是在有人可以廉价修复它的时候让脆弱性变得可见，而不是让它默默地传播到周期中最昂贵的部分。
ML 特征管道合约
对于大多数企业数据组织来说，价值最高的合同是涵盖生产机器学习模型所使用的功能的合同。默默地丢失字段、更改空编码或分布漂移的特征管道是生产模型回归的最常见原因，也是最难诊断的回归类别之一，因为模型不断评分，标题指标移动缓慢，并且在面向客户的影响累积之前没有人得到传呼。
机器学习功能的合同规定比分析更严格。分布测试必须是合同的一部分，而不是可选的事后想法——如果分布转变为 50/50，则在 {A, B, C} 中应为 80% 值且在其他地方为 20% 值的字段应使合同失败。训练-服务偏差（以一种方式计算训练，以另一种方式计算生产服务的特征）是年度操作错误材料，只有当合同在训练和服务都消耗的一个权威位置指定确切的计算逻辑时才能捕获。
对于 LLM 时代的 ML 管道，契约面扩展到嵌入源数据、检索语料库以及提供代理工具调用的结构化元数据字段。 “截至昨天，该语料库是否仍被索引？”问题是一个合同问题，而不仅仅是一个运营问题，将其视为合同可以在过时数据事件成为生产质量问题之前捕获它们。
LLM数据源和检索管道的合同
2026 年更新的数据合同用例类别是 LLM 数据源。检索增强生成管道使用具有自己的生产者-消费者动态的语料库数据：谁维护文档语料库、刷新频率、新鲜度保证是什么、每个文档附带哪些权限和 ACL、适用于分块和嵌入输出的版本控制。
LLM 数据源的合同通常指定：语料库刷新节奏以及源系统更新和索引可用性之间的滞后、随检索移动的许可模型（因此用户永远无法检索他们不应该看到的内容）、嵌入模型版本和模型更改时的重新嵌入策略，以及分块策略及其版本控制。如果在这些维度上没有明确的契约，检索管道会积累无声的质量问题，这些问题在已部署的人工智能产品中表现为用户信任问题。
生产者激励是最难的部分
数据合约的架构方面很简单。组织方面是大多数实施失败的地方。合同将成本归于生产者——同意模式、处理弃用窗口、维护质量检查、协调重大变更——并将利益归于消费者。如果没有明确的反激励措施，生产者就会抵制这种纪律，因为他们的日常指标无法体现稳定合同的价值。
在企业环境中始终有效的组织模式：
- 将合同视为数据产品 SLA 的一部分，而不是作为对下游团队的恩惠。合同就是产品；缺少它是生产者团队拥有的服务级别违规。
- 将合同的质量得分分配在生产者团队仪表板中的可见位置。可见性会产生反压力，从而使合同纪律持久。
- 每月进行一次跨团队合同审查，其中重大变更需要在合并之前制定正式的弃用计划。审查是一个30分钟的会议；它所预防的事件始终更大。
- 将制片人团队的待命轮换与违反合同事件联系起来。当消费者团队的仪表板因生产者更改字段而损坏时，生产者团队将被寻呼，而不是消费者团队。
- 将合同合规性作为生产者和消费者团队的季度 OKR。共同责任创造了一致的激励措施，这是任何单一团队指标都无法复制的。
一条不会让海洋沸腾的收养之路
大多数企业数据组织不具备同时在每个数据集上签订合同的政治或工程能力。务实的 90 天采用模式始终如一地实现：
- 第 1-15 天：选择三个数据集。不是一个（太小而无法改变文化），也不是所有的东西（太大而无法落地）。标准：高商业价值、多个下游消费者以及合同可能捕获的已知事件历史。
- 第 16-45 天：与生产者和房间里排名前两位的消费者签订合同。不是在文件审查周期中，而是在 90 分钟的工作会议中，分歧立即浮出水面，并由双方所有者解决。根据开放规范以机器可读的形式记录合同。
- 第 46-75 天：在摄取和发布时强制执行。使合同检查成为管道部署的一部分；漂移构建失败；因不符合项而导致摄取失败。文化学习就在这里发生。
- 第 76-90 天：发布一个仪表板，显示每个数据集的合同合规性、前后的事件计数以及消费者对新状态的满意度。让领导层和相邻团队都能看到案例。
- 第 91 天以上：一旦前三个数据集干净运行了一个季度，就扩展到下一层。文化变革在规模化之前需要证据；过早扩张会导致学科在回归之前就被拉伸。
数据合约程序中的常见故障模式
生成数据合同程序的重复模式在纸面上看起来很全面，但在生产中却失败了：
- 合同作为文件，而不是执行。最常见的故障。合约存在于 wiki 页面中，生产者偶尔会更新；消费者会忽略它，因为违规行为不会产生任何运营后果。
- 仅模式合约。团队指定字段名称和类型，但跳过语义、SLA、质量阈值和所有权。仅模式合约捕获了明显的故障并错过了昂贵的故障。
- 无弃用政策。重大变更在没有记录的过渡路径的情况下发布，消费者团队会陷入混乱。弃用纪律使得合同关系在不可避免的变化中可持续。
- 没有指定的所有者。当团队重组时，指定“数据团队”或“制作人团队”而不是特定人员的合同就会解散。具有记录的继任者的指定所有者能够在团队变更中幸存下来。
- 没有元数据治理的合同蔓延。每个团队在自己的位置以自己的格式编写合同，没有共享目录。该学科没有规模化；消费者找不到他们所依赖的合同。
- 不与数据注释管道交互。对于注释提供模型训练的人工智能程序，注释输出本身应该遵守合同。跳过这一步会将注释程序和模型训练结合在一起，当任何一方发生变化时，都会产生静默回归。
2026 年剩余时间的情况会怎样
到 2026 年的发展方向是跨工具和平台共享合约词汇的出现。数据合约规范和开放数据合约标准在过去一年中发生了有意义的融合；大多数现代数据目录平台现在都使用这些规范的某些变体作为一流元数据。这种融合很重要，因为它将“数据契约”从每个组织的自定义制品转变为数据产品定义的可移植部分，就像 OpenAPI 将 API 规范从文档问题转变为生态系统一样。
监管层面也在加速推进。欧盟人工智能法案第 10 条对高风险人工智能系统数据治理的要求、NIST AI RMF 对数据质量和可追溯性的要求以及 ISO/IEC 5259 数据质量测量都推动了正式的生产者-消费者合同作为审计证据层。到 2026 年，拥有已投入运营的数据合同的组织将比尚未投入运营的组织以少得多的改造工作来满足这些要求。
首先达到成熟合同纪律的组织将拥有更安静的待命轮换、实质上更可预测的机器学习管道、“业务逻辑发生变化”和“数据平台迎头赶上”之间的周期时间大大缩短，以及监管机构无需数月改造即可检查的审计就绪证据管道。默认情况下保持读取模式的组织将继续支付他们十年来一直支付的成本，只是现在与停止读取模式的同行进行比较。
常见问题
数据平台负责人在确定数据合同计划范围时提出的常见问题：
- 合约如何与我们已有的读取模式数据湖交互？合约位于生产者和湖之间的边界，而不是湖内部。现有数据湖内容继续按原样运行；根据合同摄入的新数据得到执行；迁移是渐进式的，而不是大规模的。
- 我应该使用 YAML、JSON 还是自定义格式编写合约？ YAML 中的开放规范（数据合同规范、开放数据合同标准）是操作默认值。自定义格式会产生供应商锁定并阻止合同在目录和工具之间移植。
- 如何在不破坏消费者的情况下处理合约演变？版本控制加上弃用。新版本与旧版本一起发布；消费者明确迁移；旧版本在弃用窗口后将停用。该规则与 API 的语义版本控制相同。
- 谁支付合同维护费用？生产者团队拥有该合同，作为数据产品 SLA 的一部分。成本在生产者一方；通过减少事故量，双方都受益。
- 它如何与我们的数据网格交互？数据合约和数据网格是互补的，而不是竞争的。网格分散了数据产品的所有权；合约使得数据产品之间的生产者-消费者关系变得明确。没有合约的网格始终比单一的中心化平台更糟糕；与合同的结合可以带来实质上的更好。
