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