1. 数据网格概述
大家好，我是这次课程的主讲。先聊点实在的——数据网格到底是什么？
说白了，它是一套组织数据的方式。不是某个工具，也不是某个平台。而是一套思维模式。我最早接触这个概念是在 2019 年，当时团队正被数据湖的混乱搞得焦头烂额。嗯，那时候我就意识到，光靠技术解决不了问题。
从单体数据仓库到数据网格的演进
先看看我们是怎么走到今天的。
最早的数据架构，就是单体数据仓库。所有数据往里灌，所有报表从里出。听起来很美好，对吧？
我在 2015 年参与过一个零售项目，就是这种架构。业务方提需求，ETL 团队排期，数据团队加班。一个简单的销售报表，从提需求到上线，平均两周。为什么？因为所有逻辑都耦合在一个庞然大物里。
后来有了数据湖，解决了存储灵活性的问题。但新的问题又来了——数据沼泽。没人知道哪些数据是可信的，哪些是垃圾。
再后来是数据中台。这个概念本身没问题，但落地时往往变成了一个「超级数据团队」在维护一个「超级数据平台」。你想想看，这跟单体仓库有什么区别？只是换了个名字。
直到 2019 年，Zhamak Dehghani 提出了数据网格（Data Mesh）。核心思想很简单：把数据当作产品，让业务团队自己负责。
核心演进路径：
- 单体数据仓库 → 集中式存储，ETL 团队维护
- 数据湖 → 灵活存储，但缺乏治理
- 数据中台 → 集中治理，但团队瓶颈明显
- 数据网格 → 分布式治理，业务团队自治
我个人的经验是，很多团队跳过了数据湖，直接从仓库跳到网格。结果呢？水土不服。因为网格需要组织文化的配合，不是换个技术栈就能搞定的。
数据网格的四大原则
数据网格不是拍脑袋想出来的。它有四个核心原则，缺一不可。
| 原则 | 核心思想 | 我见过的坑 |
|---|---|---|
| 领域数据所有权 | 每个业务团队拥有并管理自己的数据 | 团队不愿意接，觉得「这不是我的活」 |
| 数据即产品 | 数据要像产品一样设计、文档化、维护 | 只产出数据，没有文档，没有 SLA |
| 自助式数据平台 | 提供基础设施，让团队能独立发布数据 | 平台太复杂，团队用不起来 |
| 联邦式治理 | 全局标准 + 局部自治 | 标准定得太死，或者完全没有标准 |
1. 领域数据所有权
这个原则的意思是：谁产生数据，谁负责。
举个例子。订单团队产生的订单数据，就由订单团队负责清洗、建模、发布。而不是扔给数据团队去处理。
我曾经在一个金融项目里遇到过这种情况：交易团队把原始日志直接丢到 Kafka，然后说「你们数据团队自己看着办」。结果数据团队花了三个月才搞清楚那些字段是什么意思。这就是典型的所有权缺失。
我的建议：刚开始推行时，不要一刀切。先选 1-2 个成熟度高的团队试点，做出样板再推广。
2. 数据即产品
这个原则最容易被人忽略。很多人觉得「我把数据给你了，你还想怎样？」
但你想一下，一个合格的产品应该有什么？
- 有说明书（数据字典）
- 有客服（负责人联系方式）
- 有质量保证（SLA、数据质量监控）
- 有版本管理（变更记录）
数据产品也一样。我见过最好的实践是：每个数据产品都有一个README.md，里面写清楚数据来源、更新频率、字段说明、常见问题。嗯，就是这么简单。
3. 自助式数据平台
光有原则不够，得有工具支撑。
自助式平台要提供什么？
- 数据存储和计算资源
- 数据发布和订阅的接口
- 数据质量监控工具
- 数据目录和发现服务
我见过最失败的案例是：平台团队花了一年时间搭建了一个「完美」的平台，结果业务团队根本不会用。为什么？因为太复杂了。平台团队用的是 Kubernetes + 自定义 CRD，业务团队连 YAML 都写不利索。
避坑指南：我曾经犯过这个错——过度设计平台。后来学乖了：先给最简单的方案，比如一个 S3 桶 + 一个数据目录表。等团队用起来了，再逐步加功能。
4. 联邦式治理
这个原则解决的是「既要又要」的问题。
既要全局统一标准（数据格式、命名规范、安全策略），又要局部灵活（每个团队可以自己决定用什么工具、什么节奏发布）。
怎么平衡？我个人的做法是：
- 全局必须统一的：数据安全等级、个人隐私字段标记、数据格式标准
- 局部可以自定的：数据模型设计、ETL 工具选择、发布频率
数据网格与传统数据架构的对比
光说概念不够，我们直接对比一下。
| 维度 | 传统数据架构 | 数据网格 |
|---|---|---|
| 数据所有权 | 中央数据团队 | 业务领域团队 |
| 数据交付 | ETL 流水线，批量处理 | 数据产品，API / 事件驱动 |
| 治理方式 | 集中式，自上而下 | 联邦式，全局标准 + 局部自治 |
| 技术栈 | 单体仓库 / 数据湖 | 分布式平台 + 自助工具 |
| 团队结构 | 数据团队是服务方 | 数据团队是平台方 |
| 变更速度 | 周 / 月级别 | 天 / 小时级别 |
| 扩展性 | 受限于中央团队带宽 | 随业务团队线性扩展 |
你看这个表格，最核心的区别其实是团队结构。传统架构里，数据团队是「接活」的。业务方提需求，数据团队排期、开发、交付。这个模式在数据量小的时候没问题，但一旦业务复杂起来，数据团队就成了瓶颈。
数据网格把数据团队的角色从「服务方」变成了「平台方」。数据团队不再直接生产数据产品，而是提供工具、标准、基础设施，让业务团队自己生产数据产品。
我刚开始转型时，团队里有人质疑：「那数据团队不就没事干了吗？」
其实恰恰相反。数据团队的工作从「做数据」变成了「做平台」。需要的能力不一样了——以前要懂 ETL，现在要懂平台工程、懂自动化、懂治理策略。
本章知识体系总览
下面这张图，是我自己梳理的数据网格知识体系。你可以把它当作本章的「地图」。
这张图把本章的核心内容串起来了。从左到右是演进路径，中间是四大原则，下面是传统架构和数据网格的对比。你可以把它当作一个「速查表」。
好了，第一章的内容就到这里。记住一句话：数据网格不是技术革命，而是组织革命。技术只是工具，真正改变的是人和流程。