数据网格核心概念：面向领域的数据所有权、数据即产品、自助式数据基础设施、联邦治理

数据网格这概念，这几年在圈子里讨论得挺热。说实话，我第一次看到它时，第一反应是——这不就是把微服务那套思路搬到数据层了吗？后来深入做了几个项目，才发现事情没那么简单。

数据网格不是一套工具，也不是一个平台。它是一种组织架构模式。它要解决的核心问题，是传统数据平台在规模变大后，出现的“数据沼泽”现象。你想想看，当几百个数据管道、几千张表都堆在一个中央团队手里，谁还敢动？谁敢改？

今天我们就来拆解它的四个核心概念。这四个概念，缺一个，数据网格就转不起来。

1. 面向领域的数据所有权

这是数据网格的基石。说白了，就是“谁生产，谁负责”。

传统做法是：业务系统产生数据，ETL 抽到数仓，由一个中央数据团队统一管理。这个团队往往不了解业务细节，只能按通用方式建模。结果就是——数据质量差、口径对不上、业务部门不信任。

数据网格的做法完全不同：每个业务领域团队，对自己产生的数据拥有所有权和治理责任。

我在一个电商项目中遇到过这种情况：订单域和库存域各自维护自己的数据管道，但订单域需要库存数据来做“可售库存”判断。以前得走中央数仓，来回沟通要两周。后来我们按领域拆分，库存域直接发布数据产品，订单域订阅使用，效率提升非常明显。

2. 数据即产品

这个概念，很多人理解偏了。以为就是把数据打个包，挂个API，就叫产品了。

不是的。

“数据即产品”要求你用做产品的思维来做数据。什么意思？你要考虑你的“用户”——也就是数据消费者——他们需要什么？他们怎么用？他们遇到问题怎么反馈？

一个合格的数据产品，至少包含以下要素：

要素	说明	我的经验
Schema & 文档	字段定义、类型、业务含义、示例值	文档必须和Schema同源，否则很快过时
SLA	数据新鲜度、可用性、延迟承诺	我习惯用“P99延迟”而不是平均值
质量指标	完整性、准确性、一致性监控	每个数据产品必须暴露质量仪表盘
访问方式	API、事件流、批量导出、SQL查询	优先提供多种方式，别只给一种
反馈渠道	问题上报、版本变更通知、废弃计划	我曾经因为没通知消费者，直接改了Schema，导致下游管道全崩……

3. 自助式数据基础设施

这个点，是数据网格落地的技术保障。

你想想看，如果每个领域团队都要自己搭一套数据平台，那成本得多高？运维得多乱？所以我们需要一个共享的、自助式的数据基础设施。

这个基础设施要提供什么？

• 数据存储与计算引擎：比如 Lakehouse 架构下的对象存储 + Spark/Flink
• 数据目录与发现：让消费者能搜到、看懂、用上数据产品
• 数据管道编排：领域团队能自助创建、调度、监控管道
• Schema Registry：统一管理 Schema 版本，兼容演进
• 访问控制与审计：细粒度权限，谁用了什么数据，一清二楚

我个人习惯把基础设施分成两层：

1. 平台层：由中央平台团队维护，提供存储、计算、网络、安全等基础能力
2. 产品层：由领域团队使用基础设施，构建和发布自己的数据产品

这样做的好处是：平台团队不用懂业务，领域团队不用管基础设施。各司其职。

4. 联邦治理

这是数据网格里最容易被忽视，也最难落地的一个概念。

传统治理是“中央集权”——一个治理委员会，定标准、审变更、卡流程。数据网格不能这么搞，因为数据所有权已经分散到各个领域了。但你也不能完全放任不管，否则数据孤岛会卷土重来。

联邦治理的核心理念是：全局标准由各方共同制定，局部执行由领域自主负责。

具体怎么做？

• 全局标准：比如数据分类分级、命名规范、Schema 兼容性规则、隐私合规要求。这些由治理委员会（各领域代表 + 平台团队）共同制定。
• 局部执行：每个领域在自己的数据产品中，落实这些标准。平台提供自动化检查工具，比如 Schema 校验、质量门禁。
• 审计与反馈：定期审计各领域的数据产品是否符合标准。不符合的，不是直接禁止，而是标记风险，让消费者自己判断。

四个概念的关系

这四个概念不是孤立的。它们互相支撑，形成一个完整的体系。我画了一张图，帮你理清它们的关系：

从这张图你能看到：领域所有权是基础，决定了谁来做；数据即产品是输出，决定了做成什么样；自助式基础设施是工具，决定了怎么做；联邦治理是规则，决定了怎么管。

这四个概念，我建议你在实际落地时，不要试图一步到位。先选一个领域，把所有权和产品化跑通，再逐步引入基础设施和治理。迭代着来，比憋大招靠谱得多。