数据网格 Data Mesh
概述
Data Mesh 是近年热门的数据治理思想：不是把所有数据集中到中央平台，而是按领域分权自治，每个领域拥有并交付自己的数据产品。本文讲透四大原则、数据产品设计与联邦治理。
一、为什么要 Data Mesh
1.1 集中式平台的问题
痛点：
中央团队成为瓶颈（需求排队）
领域不懂自己的数据
数据质量责任不清
平台无限膨胀
表现：
取数慢、口径乱、责任模糊| 问题 | 表现 |
|---|---|
| 集中瓶颈 | 需求排队等待 |
| 责任不清 | 数据坏了没人管 |
| 领域失权 | 领域不能自治 |
| 扩张失控 | 平台复杂度爆炸 |
1.2 Data Mesh 的核心思想
核心思想：
把数据当产品
按领域分权
领域自治 + 联邦治理
一句话：
谁产生数据，谁负责把它做成好用的产品二、四大原则
2.1 领域所有权（Domain Ownership）
原则：
数据归业务领域所有
领域负责数据的质量与交付
示例：
订单数据 → 交易领域负责
用户数据 → 用户领域负责
领域内定义、加工、维护价值：
责任清晰
领域最懂自己的数据
领域自治（不再排队等中央团队）2.2 数据即产品（Data as a Product）
数据产品要求：
可发现（有人知道）
可理解（有文档/字典）
可信（质量保证）
可访问（自助获取）
可运维（SLA 明确）
关键：
产品有 owner
用户是"客户"
有质量承诺2.3 自助服务平台（Self-Service Platform）
平台提供：
数据接入/加工工具
数据产品发布
发现与订阅
血缘与质量监控
权限与审计
目标：
领域自给自足
不依赖中央团队2.4 联邦计算治理（Federated Computational Governance）
治理模式：
全局统一标准（规范/协议）
领域自治执行
治理自动化（计算化）
统一：
命名/模型规范
安全/合规标准
质量基线三、数据产品设计
3.1 数据产品要素
| 要素 | 说明 |
|---|---|
| 数据域 | 所属领域 |
| 数据契约 | 结构/Schema/接口 |
| 质量基线 | 质量指标承诺 |
| 文档 | 口径/说明 |
| 访问方式 | 表/API/流 |
| SLA | 时效/可用性 |
数据契约（Contract）：
定义数据的样子
变更通知
兼容性保障
（类似 API 契约）3.2 数据产品形态
| 形态 | 说明 | 场景 |
|---|---|---|
| 数据表 | 湖仓表 | 离线分析 |
| 数据流 | 消息流 | 实时消费 |
| API | 服务接口 | 应用集成 |
| 指标 | 指标产品 | 报表 |
一个领域输出多种产品：
订单明细表（离线）
订单事件流（实时）
订单指标 API（业务）3.3 质量与责任
领域对产品的责任：
质量监控（行数/时效/校验）
问题响应
变更管理
使用反馈
配套：
质量看板
责任团队
产品评级四、平台与基础设施
4.1 自助平台能力
平台能力清单：
数据接入（CDC/文件）
开发（SQL/任务编排）
发布（注册数据产品）
发现（目录/检索）
消费（自助取数/API）
治理（血缘/质量/权限）平台定位：
不替领域做数据
而是让领域高效做数据
提供能力 + 规范约束4.2 统一基础设施
基础层：
存储（对象存储/湖仓）
计算（Spark/Flink）
消息（Kafka）
目录（数据产品注册）
权限（统一认证授权）
监控（统一观测）
领域在此之上自治五、联邦治理
5.1 全局统一什么
| 统一项 | 内容 |
|---|---|
| 标准 | 命名/模型/编码 |
| 安全 | 分级/合规 |
| 平台 | 统一的工具链 |
| 协议 | 数据契约格式 |
| 度量 | 质量/价值度量 |
5.2 治理自动化
计算化治理：
治理规则写成"代码/配置"
平台自动执行：
Schema 检查
质量校验
权限检查
血缘采集
价值：
不靠人盯
规模化治理5.3 治理与自治的平衡
平衡点：
自治：领域管自己的数据
统一：全局标准由联邦治理定
原则：
协议统一，实现自治
平台统一，内容自治
标准统一，执行自治六、Data Mesh 落地
6.1 落地路径
步骤：
1. 组织准备（领域认领数据）
2. 平台建设（自助能力）
3. 制定统一标准
4. 试点（选 1-2 个领域）
5. 推广与度量
6. 持续治理6.2 挑战与对策
| 挑战 | 对策 |
|---|---|
| 领域能力不足 | 平台 + 培训 |
| 标准难统一 | 联邦治理牵头 |
| 责任转移难 | 试点 + 激励 |
| 平台建设重 | 渐进式建设 |
6.3 与传统治理对比
传统：中央团队统管所有数据
→ 瓶颈、责任不清
Data Mesh：领域自治 + 联邦标准
→ 责任清晰、扩展性好
适用：
大规模多领域组织
数据分散难以集中
领域能力强七、Data Mesh vs 数据中台
| 维度 | 数据中台 | Data Mesh |
|---|---|---|
| 模式 | 中央集中 | 领域分散 |
| 责任 | 中台团队 | 领域团队 |
| 平台 | 中台统一建设 | 自助平台 |
| 治理 | 集中治理 | 联邦治理 |
关系：
不是非此即彼
中台提供平台能力
Mesh 提供治理思想
实际常融合使用八、常见问题
8.1 什么时候不适合 Data Mesh
不适合：
组织小/领域弱
数据高度集中
治理能力不足
强合规要求（集中审计）
先评估组织能力再决定8.2 领域团队能力不足怎么办
对策：
平台降低门槛（低代码/模板）
数据治理团队提供教练
先试点小领域
逐步授权8.3 如何度量成功
度量：
数据产品数量/质量
取数时效（自助成功率）
需求响应（不再排队）
数据质量事故率
领域自治程度九、小结
Data Mesh 是一套组织 + 技术变革：四大原则（领域所有权、数据即产品、自助平台、联邦治理）解决集中式平台的瓶颈。落地核心是"平台赋能 + 领域自治 + 标准统一"三者平衡。它不是银弹，但对多领域、大规模、需要快速取数的组织是值得探索的方向。