数据网格（Data Mesh）：领域数据产品与去中心化治理

几乎所有公司都经历过同一个循环：建一个中心化数据湖，把所有业务数据汇聚进来，由数据团队统一加工。前两年很顺，随后就陷入泥潭——数据团队成为瓶颈、上游 schema 一变下游全炸、业务方抱怨"要个数据要等三周"。数据网格（Data Mesh）不是新技术栈，而是一次组织与架构范式的转移：把数据的所有权和交付责任还给最懂它的领域团队。本文讲清它的四大原则、数据产品怎么定义、以及现实中如何分阶段落地。

1. 中心化数据湖为什么会失败

1.1 架构失配

中心化数据平台的隐含假设是"所有数据都该集中处理"。当公司只有几条业务线时它成立，一旦扩展到几十个领域，三个问题同时爆发：

根本矛盾是：数据团队掌握管道，但领域知识在业务团队手里；两者分离，必然导致"最懂数据的人不产出数据，产出数据的人不懂数据管线"。于是数据平台越建越大，业务方却越来越不信任它产出的数字。

1.2 与单体架构的同构

这其实与软件架构的演进高度同构——从单体到微服务，是把"所有逻辑集中在一个团队"变成"按领域自治"。数据网格是数据侧的一次"微服务化"：

软件侧：单体应用  ──拆──▶ 微服务（按领域自治）
数据侧：数据湖    ──拆──▶ 数据网格（按领域自治的数据产品）

它借鉴了 限界上下文 的划分思想：数据边界应与业务边界对齐，而不是按技术切分。

2. 数据网格的四大原则

2.1 原则一：领域所有权（Domain Ownership）

谁产生数据，谁负责把它作为产品交付。订单域负责订单数据产品，支付域负责支付数据产品，而不是全部交给中心数据团队。

这要求每个领域团队承担起数据工程能力——通常通过"使能团队（Enabling Team）“来赋能，这与 平台工程 中"平台团队服务内部开发者"的模式一致。

2.2 原则二：数据即产品（Data as a Product）

数据不再是"副产品”，而是有明确用户、有 SLO、有文档、可发现的一等公民。一个数据产品至少要有：

• 可发现：能在目录里被搜到；
• 可寻址：有稳定、唯一的访问入口；
• 可信：有质量指标与新鲜度保证；
• 自描述：有 schema、语义、示例；
• 可互操作：遵循统一标准（格式、协议、编码）；
• 安全：有访问控制与合规标注。

2.3 原则三：自助数据平台（Self-serve Platform）

平台团队提供让领域团队能自主发布数据产品的工具链，而不是替他们做数据。平台的目标是"降低领域团队交付数据产品的门槛"。

2.4 原则四：联邦计算治理（Federated Computational Governance）

治理不再由中心团队制定并强制执行，而是由各领域代表共同制定标准，并把标准编码进平台自动执行。关键词是"联邦"（多中心协商）与"计算"（自动化而非人工审查）。

3. 数据产品：定义与契约

3.1 数据产品的组成

一个数据产品在结构上可以类比微服务——有"端口"和"实现"：

┌─────────────────────────────────────────┐
│            数据产品（Data Product）        │
│                                           │
│  输入端口 ←── 消费其他数据产品              │
│                                           │
│  ┌─────────────────────────────────┐     │
│  │  逻辑：转换、聚合、质量校验         │     │
│  │  存储：S3/Iceberg/ClickHouse      │     │
│  └─────────────────────────────────┘     │
│                                           │
│  输出端口 ──▶ 对外的表/流/API              │
│  可观测性：新鲜度、质量、血缘              │
│  治理：访问策略、分类分级、SLO             │
└─────────────────────────────────────────┘

3.2 数据契约（Data Contract）

数据契约是生产者与消费者之间的接口约定，是数据网格能运转的技术前提。它通常是一个可机器校验的文件：

# contracts/orders.v2.yaml
apiVersion: datacontract/v1
kind: DataContract
metadata:
  name: orders
  domain: order
  owner: order-team@example.com
  version: 2.1.0
  sla:
    freshness_minutes: 15
    availability: "99.9%"
schema:
  type: table
  columns:
    - name: order_id
      type: string
      required: true
      pii: false
    - name: customer_id
      type: string
      required: true
      pii: true
      classification: confidential
    - name: total_amount
      type: decimal(12,2)
      required: true
    - name: status
      type: enum
      values: [created, paid, shipped, closed]
  primary_key: [order_id]
quality:
  - rule: "row_count > 0"
  - rule: "unique(order_id)"
  - rule: "total_amount >= 0"

契约的价值在于变更可控：生产者想改 schema，先跑契约兼容性检查，破坏性变更必须走版本升级流程（orders.v2 → orders.v3），消费者有迁移窗口。

3.3 版本演进策略

兼容变更（自动通过）：新增可空字段、放宽枚举
不兼容变更（需评审）：删除字段、改类型、改语义、收窄枚举
        ↓
不兼容变更流程：
  1. 发布新主版本 v3（v2 继续服务 N 个月）
  2. 通知所有消费者（血缘图可查出）
  3. 双写过渡期 → 消费者迁移 → 下线 v2

4. 自助平台与联邦治理的落地

4.1 平台能力清单

自助数据平台需要提供的能力，按优先级排序：

4.2 策略即代码

联邦治理的核心是把标准写成代码，让平台自动执行而非人工审查：

# policy/data_product_policy.rego（OPA 风格）
package datamesh

# 所有 PII 字段必须标注 classification
deny[msg] {
  col := input.schema.columns[_]
  col.pii == true
  not col.classification
  msg := sprintf("PII 字段 %v 缺少 classification", [col.name])
}

# 对外数据产品必须有 owner 与 SLA
deny[msg] {
  not input.metadata.owner
  msg := "数据产品必须声明 owner"
}

平台在 CI 阶段跑策略，不通过就拒绝发布。这样"治理"不再是数据团队的警察，而是内建于平台的门禁。

4.3 与数据仓库/湖的关系

数据网格不否定数据仓库与数据湖——它们仍是存储与计算的底座。变的只是谁拥有、谁生产：

传统：数据团队从各业务库抽取 → 中心数仓加工 → 对外提供
网格：各领域团队自己生产数据产品 → 发布到统一底座 → 消费者直接订阅

底座仍可共享，但生产责任下沉。这也让"数据血缘"从可有可无变成必需——没有血缘，变更影响分析无从谈起。

换句话说，数据网格并没有抛弃数仓与数据湖，而是重新分配了"谁生产、谁负责"的边界：底座集中、生产分散、消费自助。

5. 分阶段落地路线

数据网格是组织变革，一步到位必失败。推荐四阶段：

阶段 1 的选点原则：选一个数据痛点最明显、团队最有动力的领域，而不是最容易的。样板要能证明"领域团队自己交付数据产品"确实可行。

6. 反模式与挑战

6.1 常见反模式

6.2 组织挑战

数据网格最难的不是技术，是职责与考核的转移：

• 领域团队要接受"数据交付"是本职，而非额外负担；
• 数据团队的定位从"生产者"转为"使能者 + 平台建设者"；
• 需要配套的激励：数据产品质量纳入团队 OKR。

没有组织配套的数据网格，注定退化成"每个领域各建一个小数据湖"——这比中心化数据湖更糟。数据网格与 多租户架构 面临的挑战类似：自治带来灵活性，也带来一致性与隔离的新成本。

7. 小结

一句话记住：数据网格不是"新的数据架构"，而是"数据责任的重新分配"。它把数据从"中心团队的产物"变成"领域团队的产品"，用契约保证接口稳定、用平台降低门槛、用联邦治理保证一致。技术只是载体，真正的变革发生在组织与职责的边界上。