摘要
1) 一句话摘要
本文通过网站分析案例，阐述了组织如何利用标准化的数据契约作为核心控制层，从中心化的数据单体架构平稳过渡到去中心化、领域驱动的数据网格，并为未来的 AI 应用奠定安全基础。
2) 关键要点
- 单体架构的局限性：传统企业数据仓库因中心化团队、组件紧密耦合、变更周期缓慢以及领域上下文脱节，最终演变成了扩展困难的瓶颈。
- 数据网格的核心支柱：数据网格是网络模式的转变，而非纯技术转变，建立在领域所有权、数据即产品、自助式数据平台和联邦治理四大支柱之上。
- 数据契约的定位：数据契约是维系数据网格的“粘合剂”，它将静态文档转化为可执行的控制层，明确了数据生产者与消费者之间的协议。
- 数据产品的分层设计：在网格架构中，数据产品分为“基础数据产品”（由特定领域拥有，专为复用设计，采用高弹性模型）和“消费者数据产品”（基于基础产品构建，专为特定用例设计，允许逻辑重复）。
- 采用开放标准 (ODCS)：推荐使用 Bitol 的开放数据契约标准（YAML 模板），以人类和机器可读的格式定义模式、质量期望和 SLA，为跨领域协作提供通用语言。
- 工具互操作性：标准化的契约无需定制集成，即可被 dbt、SQLMesh、Great Expectations 等第三方 ETL 和数据质量工具解析，实现自动化的测试、验证和监控。
- 赋能 AI 与 LLM：结合模型上下文协议 (MCP) 服务器，数据契约提供的标准化元数据为大语言模型和自主智能体提供了必要的访问策略和安全运行护栏。
3) 风险与不足
- 推进阻力：基础数据产品由谁拥有以及由谁承担成本，是现实中经常阻碍数据网格推进的核心问题。
- 架构极端化风险：组织容易陷入两种极端——要么过度设计（损害自主性并增加成本），要么放任自流（形成互不沟通的孤立数据产品网络）。
- 供应商锁定风险：如果依赖特定供应商的契约格式而非开放标准，未来切换工具的成本将极其高昂。
- 去中心化的混乱：如果没有清晰、可执行的数据契约，数据网格的自主性将演变成信息孤岛，导致影子 IT 成倍增加，不一致性的扩散速度将超过业务价值的产生速度。
正文
对于许多组织来说，从传统数据仓库向数据网格（Data Mesh）的转变感觉不像是演进，而更像是一场身份危机。
某天一切还在正常运转（也许“正常运转”有些夸张，但大家都熟悉现有的架构）。第二天，新任首席数据官（CDO）就带来了激动人心的消息：“我们要转向数据网格。”突然之间，多年来精心设计的流水线、模型和规范都受到了质疑。
本文将抛开理论和流行语，通过一个具体的例子——网站分析，探讨从集中的数据“单体架构”向契约驱动的数据网格的实际过渡。
标准化的数据契约（Data Contract）是实现这一过渡的关键。通过遵循开放、结构化的契约规范，模式定义、业务语义和质量规则得以用一致的格式表达，ETL 和数据质量工具可以直接解析。因为契约遵循标准，这些外部平台可以无需定制集成，就能以编程方式生成测试、强制验证、编排转换并监控数据健康状况。
契约从静态文档转变为可执行的控制层，无缝集成了治理、转换和可观测性。数据契约真正成为了维系数据网格完整性的粘合剂。
为什么传统数据仓库会变成单体架构
提到“单体架构”，人们常想到糟糕的架构。但大多数单体数据平台并非一开始如此，而是逐渐演变而成的。
传统的企业数据仓库通常具有以下特征：
- 一个中心化团队负责数据接入、建模、质量和发布。
- 一个中心化架构，共享流水线和模式。
- 组件紧密耦合，一个模型的更改可能波及各处。
- 变更周期缓慢，因为需求总是超出处理能力。
- 领域上下文有限，建模人员往往远离业务。
- 扩展困难，随着更多数据源和用例的出现而加剧。
这不是能力不足，而是中心化和多年意外后果的自然产物。最终，数据仓库成为了瓶颈。
数据网格到底改变了什么（以及没有改变什么）
数据网格常被误解为“不再需要数据仓库”或“各行其是”。实际上，它是一种网络模式的转变，而不一定是技术的转变。
数据网格建立在四大支柱之上：
- 领域所有权 (Domain ownership)
- 数据即产品 (Data as a Product)
- 自助式数据平台 (Self-serve data platform)
- 联邦治理 (Federated governance)
核心区别在于，不再是由一个团队拥有一个庞大的系统，而是拥有许多小型、互联的数据产品。这些产品由各个领域拥有，并通过清晰的契约连接在一起。而数据契约正是这个故事中默默无闻的英雄。
数据契约：缺失的稳定器
数据契约借鉴了软件工程中熟悉的概念：将 API 契约应用于数据。
它们在 2021 年至 2023 年间在数据网格社区中普及，主要贡献者包括 Andrew Jones、Chad Sanderson 以及 Bitol 项目引入的开放数据契约标准（Open Data Contract Standard）。
数据契约明确定义了数据生产者和数据消费者之间的协议。
案例分析：网站分析
让我们通过一个具体场景来落地。假设有一家在线玩具店 PlayNest，业务部门希望分析网站上的用户行为。
这里涉及两个主要部门：
- 客户体验部：负责用户在网站上的旅程，以及客户浏览产品时的感受。
- 营销部：负责开展活动将用户引流至网站，并激发他们购买产品的兴趣。
这两个部门之间存在自然的重叠，领域之间的边界往往是模糊的。
在操作层面上，网站数据通常包括：访客、会话、事件、设备、浏览器和产品。
然而，从营销角度来看，他们不需要原始事件，他们需要：
- 营销线索
- 漏斗转化表现
- 活动有效性
- 废弃购物车数据
- 用户点击了哪些类型的产品（以便进行重定向营销等）
从客户体验角度来看，他们想知道：
- 挫败感评分
- 转化指标（例如有多少用户创建了心愿单，这标志着他们从随机用户转化为了感兴趣的用户）
中心化（网格化前）的方法
在中心化的湖仓一体架构中，通常使用奖牌架构（Medallion framework）来构建：
- 铜层 (Bronze)：来自 Google Analytics 等工具的原始、不可变数据。
- 银层 (Silver)：经过清洗、标准化、与源无关的模型。
- 金层 (Gold)：经过整理、与业务对齐的数据集（事实表、维度表、数据集市）。
在铜层，原始数据存储在对象存储中，中心团队负责接入数据、确保遵循 API 规范并监控流水线。在银层，中心团队开始清洗和转换数据，可能使用 Data Vault 等建模方法进行标准化。在金层，中心化 IT 团队根据记录的最终用户需求，实现不同领域分析所需的维度和事实。
现在，让我们将这个例子从中心化运营模式转变为去中心化、由领域主导的方法。
数据网格中的网站分析
在数据网格中，数据产品由领域拥有，具有特定类型，数据通过输入端口进入，通过输出端口流出。每个端口都由数据契约进行治理。
组织在选择数据网格时，经常需要在以下两种方法中抉择：
- 使用可复用的构建块来组织架构，将逻辑整合在一起。
- 让所有数据产品的消费者自行决定如何实现，承担逻辑重复的风险。
显然第一种是更好的实践。但在现实中，马上会面临两个基本问题：谁来拥有基础数据产品？谁来为此买单？
这些问题往往会阻碍数据网格的推进。因为你可能会过度设计（拥有大量可复用组件，但损害了自主性并增加了成本），或者创建出一个互不沟通的孤立数据产品网络。我们需要避免这两种极端。
在我们的例子中，假设我们不让每个团队独立接入 Google Analytics，而是创建一个或多个共享的基础产品（例如“网站用户行为”和“产品”）。这些产品由特定领域（如客户体验部）拥有，他们负责在标准输出端口暴露数据，并受数据契约治理。其核心理念是，这些产品应该像外部数据集通过标准化 API 模式复用一样，在组织内部可复用。下游领域（如营销部）则在此基础上构建消费者数据产品。
基础数据产品与消费者数据产品
网站用户行为基础数据产品 (Foundational Data Product)
- 专为复用而设计。
- 稳定且治理良好。
- 通常使用 Data Vault、第三范式 (3NF) 或类似的高弹性模型构建。
- 为变更而优化，而不是为仪表板优化。
建模技术由领域决定，但核心动机是可复用性。输出端口也为复用而设计，可以组合成易于使用的格式，或者直接暴露原始表供技术消费者使用，甚至可以发布单独的输出供大语言模型（LLM）或自主智能体使用。
营销线索转化指标消费者数据产品 (Consumer Data Product)
- 专为特定用例设计。
- 由消费领域的需求塑造。
- 通常是维度模型或高度聚合的。
- 允许（也预期）在需要时重复逻辑。
消费者数据产品将基础数据产品作为输入端口，并准备好满足特定的消费需求。由于主要用于分析和仪表板构建，选择维度模型是最合理的。
深入理解数据契约
数据契约是维系数据网格完整性的粘合剂。它不仅应规定技术期望，还应包括法律、质量要求以及消费者关心的任何内容。
Bitol 的开放数据契约标准 (ODCS) 旨在解决市场上特定供应商契约存在的差距，提供了一个共享的、开放的标准，以人类可读、机器可读且与工具无关的方式描述数据契约。
为什么如此关注共享标准？
- 跨领域的通用语言：如果每个团队定义契约的方式不同，联邦治理就不可能实现。标准为生产者、消费者和平台团队创建了通用词汇表。
- 工具互操作性：开放标准允许数据质量工具、编排框架、元数据平台和 CI/CD 流水线消费相同的契约定义，而不需要各自的配置格式。
- 作为活文档的契约：契约不应是静态文档。有了标准，它们可以被版本化、自动验证、在流水线中测试并随时间进行比较。这使契约从“文档”变成了可执行的协议。
- 避免供应商锁定：许多供应商支持数据契约，但如果没有开放标准，切换工具的成本将非常高昂。
ODCS 是一个 YAML 模板，包含以下关键组件：基础信息（目的、所有权等）、模式（字段、类型等）、数据质量期望、服务等级协议 (SLA)、支持与沟通渠道、团队与角色、访问与基础设施，以及自定义领域规则。并非每个契约都需要所有部分，但结构很重要，因为它使期望变得明确且可重复。
数据契约实现互操作性与 AI 赋能
在我们的例子中，输入端口和输出端口都有数据契约。由于契约遵循标准化的机器可读格式，现在可以与第三方 ETL 和数据质量工具（如 dbt、SQLMesh、Great Expectations 等）集成，以编程方式生成测试、强制验证、编排转换并监控数据健康状况。
LLM、MCP 服务器与数据契约
通过使用包括数据契约在内的标准化元数据，组织可以安全地利用 LLM 和其他智能体 AI 应用程序与其核心数据进行交互。
假设业务人员想查看访问量最高的产品。LLM 可以利用元数据确定哪些数据产品是相关的，同时发现用户没有数据访问权限。它可以决定如何以及向谁申请访问权限。一旦获得授权，LLM 就能解析元数据并创建符合用户请求的查询。
确保自主智能体和 LLM 具有严格的运行护栏，将使企业能够扩展其 AI 用例。多个供应商正在推出 MCP (Model Context Protocol) 服务器，为向自主智能体暴露数据提供结构化方法。强制通过元数据标准和协议（如数据契约）进行接口交互，将允许更安全、更可扩展地推广这些用例。
MCP 服务器提供了运行的工具集和护栏，而包括数据契约在内的元数据则提供了任何智能体运行所必须遵守的策略和可执行规则。
目前，业务部门对 AI 用例的需求如海啸般涌来，但大多数尚未产生价值。现在正是投资建立正确护栏的绝佳时机。当价值爆发的临界点到来时，我们需要先准备好这些构建块。
结语
可以这么说：没有契约的数据网格只是去中心化的混乱。如果没有清晰、可执行的协议，自主性就会变成信息孤岛，影子 IT 会成倍增加，不一致性扩散的速度将超过价值产生的速度。到那时，你构建的不是网格，而是分布式的无序状态，还不如退回到中心化架构。
契约用问责制取代了假设。从小处着手，智能连接，清晰治理——不要把网格搞得一团糟。