Data Mesh 数据产品详解：核心架构、接口与数据产品工厂

Data Mesh 真的只是又一轮营销炒作吗？如果不是，它赖以成立的基础又是什么？本文源自 Eric Broda 的一次分享，围绕数据产品展开。

数据产品作为企业数据网格的基石，作用至关重要。那么，什么是数据产品？它们如何运作？我们又该怎么识别并快速构建这些关键组件？下面从核心概念、工作机制到高效构建方法，逐一拆解。

1. 什么是数据产品

数据产品以及由它们构成的数据网格，显著提升了数据的可访问性、可用性、共享性与治理效率。要实现这个目标，从业者必须让数据产品的构建、部署、安全和管理都足够简单高效。

Data Mesh 的提出者 Zhamak Dehghani 把数据产品视为数据网格中的“架构量子”。它们是“可以独立部署和管理的最小架构单元”，具备可发现性、可理解性、可信赖性、可寻址性、互操作性、可组合性、安全性以及本地可访问性，而且自身具备很高价值。

一个补充定义是：数据产品 = 数据领域 + 产品思维。这种结合使数据产品既能提供高质量的数据服务，又能借助灵活的产品设计与开发流程，快速响应业务变化。

实际应用中，数据产品通常以 API 形式对外提供服务，因此很容易集成到各类应用和服务中。同时，数据产品还会提供丰富的元数据和文档，帮助用户理解和使用数据，并支持多种数据格式与协议，满足不同场景需求。

什么是“产品思维”？《哈佛商业评论》最近一篇文章给出了几点有趣的观察：第一，产品整合了组织的生产能力，以实现“交付并获取价值”；第二，存在一个或多个“购买并使用该产品的终端客户”；第三，产品有明确的所有者和团队，他们负责制定长期计划，推动产品持续改进，关注结果而非产出。

换句话说，产品思维意味着确保产品既能满足特定业务需求，又能真正发挥价值。它强调长期规划与持续迭代，让产品适应市场变化和客户需求。同时，产品思维还要求明确授权的所有者，他们既要代表企业利益，也要关注客户利益，在商业目标与客户价值之间取得平衡。

定义“数据域”并不容易，在大型企业里这个词往往相当模糊。对首席数据官（CDO）和首席信息官（CIO）来说，治理、监管和隐私是造成数据域划分过粗的主要原因。比如，当前的“客户”数据未必能代表所有客户，有时甚至只是某个特例。数据架构师可能把客户看成某种参与方的子集，包括现有客户和潜在客户；而开发人员则可能只把客户当作连接客户、账户与交易的唯一标识符。

这种分歧反映了不同角色对数据的不同视角和需求。要解决这个问题，企业需要采取更统一、更协调的方式定义和管理数据域，包括建立清晰的数据治理框架，确保数据质量和一致性，制定有效的数据隐私政策保护客户敏感信息，并加强跨部门沟通协作。这样才能真正用好数据资产，提升业务决策的效率和准确性。

简单说，数据域可以定义为一组可识别的、真实且相关的数据，它们被一致地管理，并具备一定的质量和准确性度量。

因此，一个实用的数据产品通常包括：

• 清晰的边界，以建立一组可识别的相关数据；
• 被授权的所有者，提供组织资源和决策，让数据有价值、值得信赖，并给出产品演进的长期视角；
• 作为生产者和消费者生态系统的一部分，保证数据的互操作性、一致性和质量；
• 平台能力，让数据可发现、可寻址、可访问、可互操作；
• 公开的元数据，支持发现和自助服务，同时让数据易于理解；
• 联邦治理，在企业策略与数据安全之间实现本地自治与全局管理的融合。

2. 数据产品的架构

数据产品的架构特性包括可互操作性、有界性、自感知、可发现性、安全性、历史与时序，以及可共享性。这些特性确保数据产品能够满足数据访问与摄取需求，拥有明确定义的边界和所有者，自动捕获变更和自身信息，通过内置“注册表”发布元数据和政策，保证数据在构建期间与运行时的安全，并借助不可变日志管理数据状态或异常的变更。此外，数据产品还允许其管理的数据被摄取或使用，支持准实时通信或在数据产品域内、数据产品之间传递。

数据产品的架构具备以下组件特性：

• 可互操作：接口涵盖查询以及 API、管道、文件和事件等，用于解决数据访问与摄取需求；另有接口（通常实现为 API）用于观察、运营、保护和管理数据产品。每个接口都有契约（例如 API 使用 OpenAPI 规范）来规范交互。
• 有界：数据产品可以存储任何类型的数据，但必须有明确定义的边界和所有者。虽然分析数据是主要用例，但运营数据和行为数据同样可以纳入管理。
• 自感知：自动捕获变更和自身信息。所有数据产品变更都可作为“事件”在数据产品内分发，或发送给其他数据产品和相关方。
• 可发现：每个数据产品都内置“注册表”，发布元数据、所有权信息、政策及其他支持行为。对开发人员、数据科学家和数据分析师来说，注册表就是“一站式”入口，用来查找、使用、共享和治理数据产品管理的数据；它也支持请求访问数据，或由所有者创建新的数据产品。
• 安全：数据产品确保所有数据在构建期间和运行时都安全，目标是让所有数据产品运行在“零信任”容器或环境中。
• 历史与时序：数据状态或异常的变更被记录在不可变日志中，以支持联邦治理、安全问题诊断和数据沿袭。
• 可共享：数据产品允许其管理的数据被摄取或使用。信息和事件（例如数据更改或 API 调用）可以借助管道流水线实现准实时通信，或在数据产品域内、数据产品之间传递。

3. 数据产品互操作接口

考虑互操作性接口时，最先关注的是两类：将数据摄入数据产品的接口（流水线、API 等），以及用于消费数据产品的查询。

但在大型企业中，互操作接口还要面对几个约束，某些情况下甚至是强制性需求：

• 正式契约：每条数据摄取或消费路径（管道、查询、API 或事件）都应由正式且已发布的契约定义。某些情况下，契约会与具体工具绑定，例如 API 可用 OpenAPI 规范，事件可用 JSON Schema 等正式规范。
• 正式版本控制：契约应进行版本控制，从而支持向后兼容。在小环境中，只有少数参与者共享数据，这一点也许不重要；但在数据广泛共享的大型企业里，确保上游系统变更数据格式时下游系统不被破坏，就至关重要。
• 正式安全规范：每种工具可能提供不同的安全方法，更糟的是，有些工具可能没有健壮完整的安全模型。但这不能成为忽略保护生产者和消费者接口的理由，反而让安全这件事变得更有挑战。

生产者与消费者的接口固然重要，但也不该忽视发现、可观测性和可管理性接口的关键作用。事实上，这些接口大多以 API 形式实现，完全可以利用 OpenAPI 规范提供的能力。

OpenAPI 和 AsyncAPI 规范提供了文档完善、经过实战检验的正式同步/异步契约，适合作为企业内部标准。OpenAPI 允许灵活地对 API 进行版本管理，以便从容应对契约变更；它还提供了健壮、易理解且文档化的方式定义安全模式，这些模式被定义为直接映射到角色的“作用域”。经过一些前期工作，这些作用域可以通过 OAUTH2（一种常见的安全方法）落地，并接入企业身份记录系统。

4. 数据产品价值链

数据产品的价值与其在企业中的使用程度成正比。在早期阶段，Data Mesh 中的数据产品应当具备可发现、可寻址、可互操作、自描述、可信赖和安全等特征。按照 Data Mesh 创始人 Zhamak Dehghani 的说法，这些是数据产品的基本特征，也是它持续创造价值的构件。

有了这些基础属性，企业就可以开始使用数据产品了。如果设计得当，数据产品能让数据易于查找、使用、共享和治理。而数据被更轻松、更频繁地使用和共享后，又会带来新的敏捷性和速度。凭借这种能力，企业可以获得以下商业价值：

• 更快、更好的洞察力，这是打造出色客户体验或快速响应市场变化的关键；
• 缩短上市时间，尤其是对严重依赖数据的最终消费产品；
• 降低交付成本，因为速度和敏捷性压缩了交付周期。

但怎样才能快速、一致且安全地交付数据产品？这正是“数据产品工厂”发挥作用的地方。

数据产品工厂通过建立可重复的步骤来制造数据产品：

• 提供模板简化数据产品构建。这些模板会生成具备内置可发现性（/discover 端点）和可观察性（如 /observe、/usage、/logs、/alerts）的微服务API。
• 通过扩展上述模板，让每个 API 或微服务都能基于 OAUTH2 获得安全保护；再经过更多前期工作，这些模板还能为数据产品 API 或微服务及其数据生成“零信任”运行环境。
• 易于部署：通过扩展模板，把 API 或微服务（必要时连同数据）打包进“容器”（例如 Docker）或 Kubernetes Pod，让 Data Products 更容易部署到内部或云环境，也更容易纳入 DevSecOps 管道。
• 易于管理：将生成的 API 或微服务（例如 /logs 和 /alerts 端点）与企业管理和监控工具对接。

5. 数据产品识别

如何确认数据产品的身份？有不少方法可以帮助我们在企业中找到数据产品。

康威定律应用到数据产品中，意味着所有权会转移到与组织单元（如业务线）紧密结合的团队，这些团队深入了解数据，并对数据交付结果直接负责。CDO 数据域和业务架构则提供了识别数据产品候选者的“提示”，但往往需要进一步细分为更细粒度的域。行业或商业模型基于数十年经验，识别出特定行业中的核心实体，例如金融服务业中的 BIAN 和 Teradata（FSLDM）。

• 康威定律：将康威定律应用于数据产品，意味着所有权转移到与组织单元（业务线等）紧密结合的团队，团队对数据有深入了解，并对交付结果负直接责任，因而拥有数据的决策权和资金权。
• CDO 数据域：数据域映射（企业或组织级）标识出对企业有重要价值的业务实体，这些实体提供了识别数据产品候选者的“提示”。不过有些场景下，企业域需要再细分为更细粒度的域，才能映射到 Data Products。
• 业务架构：业务架构（企业或组织级）标识重要业务能力。这些能力通常较容易转换为数据域，与 CDO 域类似，也能提供识别数据产品候选者的提示。同样，企业域可能要拆分成更细粒度的域。
• 行业或商业模型：基于数十年经验构建的商业模型，能识别特定行业中的核心实体。金融服务业中，BIAN 和 Teradata（FSLDM，Financial Services Logical Data Model）就是已建立的几个商业模型。

粒度问题不容忽视。所谓“企业客户端”这类企业数据域，粒度太粗，很难定义清晰的数据边界和所有者。更细粒度的数据边界反而更容易映射到“所有者”，进而映射到数据产品，例如“某银行的商业贷款客户”。

6. 数据网格：一个数据产品的生态系统

并不存在孤立的数据产品。所有数据产品都是某个生态系统的一部分，并在其中运行，这个生态系统就是 Data Mesh。

进一步看，我们可以把一些明确而具体的职责交给企业的 Data Mesh。Data Mesh 首先是一个概念，它不仅是营销口号或执行指令，更是企业数据旅程中的关键划分。它的主要目的是描述并传达如何把数据产品绑定到生态系统的组织结构与逻辑架构抽象中。

作为数据产品的可发现性代理，Data Mesh 扮演着“企业数据产品注册中心”所有者的角色，让数据产品易于查找、使用、共享和治理。这样一来，Data Mesh 保障了数据产品的可见性与可用性，促进企业内部的数据流通和利用。

此外，Data Mesh 还是数据产品协议的管理者。它建立了一套协议，让数据可以在数据产品内部、数据产品之间以及与更广泛的组织之间共享。这套协议不仅规范了数据交互方式，还提升了数据交换的效率和安全性。

因此，Data Mesh 成为企业公共通信、流水线或事件流主干中的关键消费者与利益相关者。它通过统一接口和标准，让不同数据源和应用能够顺畅集成与交互，大幅提升企业数据处理能力和业务响应速度。

可以说，Data Mesh 作为一种创新的数据管理架构，为企业提供了全新的数据资产管理视角。它不仅简化了数据发现和使用过程，还强化了数据治理与安全。随着越来越多企业认识到 Data Mesh 的价值，这一架构有望在未来得到更广泛的应用。

7. 一句话小结

数据产品是数据网格旅程的基础。本文梳理了数据产品如何让数据易于查找、使用、共享和治理，以及“数据产品工厂”如何让数据产品易于构建、部署、安全和管理。