第13章：Data Mesh 与数据产品

元数据卡

前置知识：第11章（数据治理基础）
预计时间：40 分钟
核心难度：进阶
阅读模式：轻松漫游
完成标志：能描述 Data Mesh 的四个原则，并设计一个数据产品

你的进度

你追踪了数据的血缘，发现一个更大的问题：预言厅里的数据来自十几个不同的领域——前线战报、后勤补给、人员档案、装备维修、魔法研究……它们各有各的语义、格式、更新频率。

你不可能一个人维护所有领域的数据。每个领域的人最懂自己的数据。你需要一种新的组织方式——让数据的所有权和治理回到它产生的地方。

你的任务

你的组织有 10 个团队，每个团队产生和消费数据。过去的方式是：一个中央数据团队负责所有数据管道。但中央团队成了瓶颈——他们不了解每个业务领域的数据含义，排期越来越长，数据质量反而下降。Data Mesh 是另一种模式：把数据作为产品，让业务团队自己负责自己的数据。

Data Mesh 为什么要出现

传统数据架构（集中式数据仓库 → 单一数据团队）在组织达到一定规模后出现三个典型症状：

认知负载集中。中央团队需要理解所有业务领域的数据——但他们不可能做到。结果：数据定义模糊，消费方对数据不信任。
单点瓶颈。所有数据变更请求排一条队。小到一个字段改名都要等两周。
耦合。数十个消费方依赖同一张表。改一个字段值波及其他所有下游。

Data Mesh 不是新工具——它是一套组织模式，由四个原则构成。

原则一：领域数据所有权

每个业务团队拥有自己的数据——就像他们拥有自己的代码一样。领域团队最了解数据的业务含义，他们负责数据的质量、文档、访问控制。

架构上的体现：

传统模式：
 源系统A → [中央ETL] → 数据仓库/单一大表 → 消费方A/B/C

Data Mesh 模式：
 领域A → 数据产品A ──→ 消费方A
 领域B → 数据产品B ──→ 消费方B
 领域C → 数据产品C ──→ 消费方C

每个领域暴露的"数据产品"不是原始数据——它是经过清洗、有文档、有 SLA 的可靠数据输出。

原则二：数据即产品

数据产品不只是"一张表"。一个数据产品包含：

python

# 数据产品规范示例
data_product = {
 "name": "mission_completion_rate",
 "domain": "operations",
 "owner": "team-operations",
 "output_format": "parquet",
 "schema_version": "v2.1",
 "description": "每日任务完成率，按类型和区域分",
 "SLA": {
 "availability": "08:00 daily",
 "max_lag_hours": 4,
 "min_completeness": 0.95,
 },
 "documentation_url": "https://wiki.internal/mission-completion-rate",
 "lineage": ["missions_raw", "team_assignments"],
 "consumer_teams": ["analytics", "performance-dashboard"],
}

关键转变：数据产品像软件产品一样有版本、有文档、有 owner、有错误报告渠道。消费方不用追着问"这个字段是什么意思"——因为它有文档。

原则三：自助式数据基础设施

领域团队需要能够自己发布数据产品。这意味着一个共享的数据基础设施层：

统一的存储方案（如对象存储 + 数据湖）
标准的数据发布接口
自动化的质量检查和血缘记录
访问控制与计费

领域团队不需要自己搭 Kafka 集群——他们使用共享的基础设施，但控制自己领域内的数据产品内容。

原则四：联邦治理

每个领域自治，不意味着没有全局规则。联邦治理是指：全局规则（命名规范、安全策略、合规要求）由治理团队制定；具体执行（数据格式、质量规则、文档标准）由各领域团队在当地决定。

全局治理（横切关注点）：
 - 用户身份认证与权限模型
 - 数据分类与合规标记
 - 全局数据目录

领域自治（垂直决策）：
 - 如何清洗数据
 - 使用什么转换频率
 - 如何文档化字段含义

实施路径

Data Mesh 不是一夜之间能落地的。典型实施路径：

阶段1 — 集中式（起点）：
 - 中央数据团队管理所有管道
 
阶段2 — 数据产品化（6-12个月）：
 - 识别第一个"适合作为产品"的数据集
 - 把它包装成数据产品：加文档、加 SLA、建监控
 
阶段3 — 领域扩展（12-24个月）：
 - 一个团队开始自己维护数据产品
 - 中央团队转为"平台团队"，提供基础设施和支持
 
阶段4 — 网格运作（24+个月）：
 - 多数领域有自己的数据产品
 - 联邦治理常态化
 - 跨域数据产品的消费通过统一的目录发现

数据产品的反模式

 数据产品 = 原始表
 领域表直接暴露给全公司。缺失清洗、文档、SLA。

 过度拆分的"微"数据产品
 一个字段算一个数据产品。消费方需要组合 20 个数据产品才能得到一个完整视图。

 领域自治 = 领域隔离
 每个领域用不同的命名规范、不同的编码方式、不同的时间格式。消费方痛苦不堪。

常见陷阱

把 Data Mesh 当作技术架构来买。没有一个"Data Mesh 工具"能替代组织的模式转变。
领域团队没有数据工程能力就强推。自助式平台需要足够简单，或者平台团队提供足够的培训和支持。
数据产品的"产品"部分被忽视。一个没有文档、没有 owner、没有 SLA 的表不是数据产品。

通关挑战

热身：识别你的团队/组织中哪些数据可以封装成"数据产品"。
挑战：为其中一个数据集设计完整的数据产品规范——包括 schema、SLA、owner、文档和血缘。
排障：组织尝试 Data Mesh，但第一个季度数据质量反而下降了。可能的原因有哪些？

验收标准

能说出 Data Mesh 的四个原则并解释每个原则解决的问题
能设计一个数据产品的规范
理解 Data Mesh 和集中式数据架构的优劣势
知道 Data Mesh 实施的关键风险和反模式

旅人笔记

Data Mesh 把数据视为产品，把责任还给业务团队。它是数据和组织的演化自然下一步——但不是每个组织都要走这一步。

下一站预告

不论数据怎么划分、谁拥有它，一个恒定的约束始终存在——安全与合规。最后一章，隐私合规与数据安全。