每隔几个月，就会有客户向我们倾诉他们在数据方面的痛点——数据无法被发现、彼此无法互通、被孤立在各个系统之中，以及这一切如何成为瓶颈；或者向我们描绘他们对全公司范围数据访问的愿景。他们希望实现按团队进行的治理，以及安全的 AI 工作负载——这些工作负载能够调用每个部门的资产，同时又不违反隐私或合规要求。他们会阐述自己设想的架构、遇到的问题，以及正在斡旋应对的种种政治因素。然后我们会说：“你所描述的，用两个词就能概括：Data Mesh（数据网格）。你听说过吗？”
十有八九，答案都是没有。这是我们为客户实现得最多的模式，然而最需要它的那些人却很少听说过这个术语。本指南正是为他们而写，也是为所有那些怀疑自己组织的数据问题在于“归属权缺口”而非“技术缺口”的人而写。
AWS SageMaker Unified Studio 上的数据网格在架构上很简单。AWS 已经把控制平面产品化了。成败的关键在于：你的组织能否在不制造官僚主义的前提下采纳联邦式的归属权模式。本指南涵盖数据网格的含义、SageMaker Unified Studio 如何实现它、决定下游一切的三项架构决策，以及决定你的网格能否在与现实的碰撞中存活下来的组织模式。
数据网格到底意味着什么（以及为什么你的 CDO 很可能没听说过它）
数据网格不是一项技术。它不是某个特定的 AWS 服务。它不是你数据湖的替代品，更绝对不是让你一夜之间重组组织架构图的理由。它是一种关于数据归属权的组织架构：四条原则，通过技术加以落地实施。
这四条原则，由 Zhamak Dehghani 定义，并符合 AWS Well-Architected 数据分析透镜（Data Analytics Lens），具体如下：
- 面向领域的归属权。 数据归属于生产它的团队，而不是那个试图管理所有人资产的集中式“数据”团队。
- 数据即产品。 每个领域都发布可被发现、经过质量管控且带有明确 SLA 的数据集。可以把它想象成一份内部 API 契约，只不过是针对数据的。
- 自助式数据平台。 一套让领域团队能够自主运作的基础设施，无需提交工单，也无需等待某个中心化的瓶颈。
- 联邦式计算化治理。 标准集中，执行去中心化。规则自上而下制定；而实现则由各团队负责。
温斯顿·丘吉尔曾说：“我们塑造我们的建筑，此后，建筑便塑造我们。”这同样适用于公司组织团队的方式。如果你的公司按技术专业来划分人员（一个“数据”团队处理公司所有数据，而不论其归属），那么你的架构就会反映出这种集中化。随着公司发展，这种局面会迅速失控。数据网格则把这一点颠倒了过来。
最能引起技术受众共鸣的类比，是领域驱动开发。你能理解按业务领域来划分代码：一个 Payments（支付）模块，而不是“所有 Python 脚本”或“所有与 Stripe 相关的文件”。数据网格把同样的原则应用到了数据资产上。亚马逊著名的“两个披萨团队”也遵循着同样的理念：小型、自主、跨职能、以结果为导向的团队，端到端地拥有自己的领域。
正如应用架构从单体演进到了微服务一样，数据团队也正在把他们的平台模块化为联邦式、去中心化的解决方案。AWS Well-Architected 框架数据分析透镜（Data Analytics Lens） 明确地做出了这一类比。
为什么经验丰富的 CDO 会忽略这一点？因为这个概念要求在一个不同的抽象层次上思考。它无关乎新工具，而关乎谁拥有什么、以及为什么。这种认知上的转变是困难的，即便对于那些从事数据工作数十年的人也是如此。对于那些在“管理—执行”这条谱系上更靠近动手实施一端的数据管理者来说，这尤其艰难。
SageMaker Unified Studio 如何实现数据网格
AWS SageMaker Unified Studio 自 2025 年 3 月起正式全面可用，是 AWS 对数据网格原则的具体实现。它构建于 SageMaker Catalog（Amazon DataZone 的演进版本）、Lake Formation、Glue Data Catalog 和 Athena 之上。这些组件共同构成了联邦式数据架构的控制平面。
层级结构：领域、领域单元、项目
完整的结构可以清晰地映射到组织的现实之中：
AWS 账户 → 领域 → 领域单元 → 项目 → 成员
一个领域代表一条主要的业务线。大多数公司只需要一个。例外情况是大型的、多元化经营的企业，例如西门子——在那里，为能源、消费电子和交通运输分别设立独立的领域才有意义。当我们构建为西门子能源打造的事件驱动数据管道时，其跨账户架构自然而然地映射到了他们的事业部结构上——而这正是数据网格所形式化的一种模式。作为一条经验法则，对于那些涉足众多彼此关联松散的业务的公司而言，领域对应的就是它们的主要业务线。
推荐的设计是设立一个单一的治理领域，它不包含任何数据或领域单元，仅充当整个网格的控制平面。规则和最佳实践就是在这里被强制执行的。其他数据丰富的领域则被接入进来参与其中。数据生产方拥有数据所有者和工程师。数据消费方则拥有数据工程师、报表构建者和数据科学家。如有可能，请把用于治理的 AWS 账户与其他账户分开。否则，就让它们并排存在于同一个 AWS 账户之中。
领域单元 是一个领域内部的组织性细分单位，例如部门、团队和能力域。大部分结构都存在于此。
经验法则是：一个治理领域，一个根业务领域并带有众多领域单元，每个领域单元下再有众多项目。然后，这套结构会在开发、UAT 和生产账户中重复出现。
项目作为工作的基本单位
一个项目团队并不是一个永久性的团队。它是来自不同实体团队的人员为了某个特定业务目标而聚集在一起的、跨职能的交集。成员要么是 Contributors（贡献者），要么是 Owners（所有者），他们随项目的需要而来去。
“你是想让我为每个部门都雇一名数据工程师吗？”这种反对声正是在这里消弭的。数据工程师临时加入某个特定项目，配置好必要的机制，然后离开，等到拥有该项目的团队需要帮助时再回来。还是今天这些人。只是处在不同的抽象层次上。
项目包含实现其业务目标所需的资源：用于数据源的 Data Lakehouse、用于处理和迁移的 ETL 工具（脚本、notebook、Airflow 编排），以及用于数据科学工作的 MLflow tracking server。每个项目都会选择用来配置这些资源的蓝图（blueprint），我们强烈建议把所有蓝图都设置为 ONDEMAND（按需），而不是 ONCREATE（创建即启用）（更多细节请参见下文的成本章节）。
企业级领域使用 Tooling 蓝图；而个人 IAM 领域则使用较新的（但功能较弱的）ToolingLite 蓝图。这两者之间的差异，以及何时该用哪一个，是本系列另一篇文章的主题。
目录：生产方/消费方模式
数据网格是通过生产方/消费方模式焕发生机的，该模式直接映射到Well-Architected 参考架构，具体如下：
- 生产方项目 会把数据资产发布到 SageMaker Catalog，并附带完整的元数据、术语表条目、质量信息和血缘（lineage）。
- 消费方项目 则订阅这些资产，并在 Unified Studio 内部通过 Athena 对其进行查询。
- Lake Formation 负责强制实施分区级别的访问控制，充当生产方与消费方之间的治理层。
按照 Well-Architected 的指导，每一层（生产方、治理、消费方）都驻留在各自独立的 AWS 账户中。这一最佳实践并非总能实现。许多公司，即便是大公司，其工作负载也是共用同一个 AWS 账户，而非彼此隔离。最常见的约定是每个环境（dev/uat/prd）一个 AWS 账户。
主数据（Master Data）生产方项目：我们的建议
我们建议围绕关键数据源建立专门的项目，并在名称后附上“Master Data”：“CRM Master Data”“Website Analytics Master Data”。这些项目由一个数据源供给，而该数据源会被多个消费方通过若干项目加以使用。
有一个值得澄清的细微之处：任何项目既可以是数据生产方，也可以是数据消费方。大多数项目都会两者兼具。然而，主数据项目是不可或缺的、原子性的叶子节点。通常，它们并不消费数据。它们只是把一个数据源暴露给网格目录。Well-Architected 框架建议尽早把这些生产方设置好，但现实要更为微妙。我们遇到过一些例外情况：某位客户的保单管理系统及其前身被暴露为两个独立的数据集，另外还有一个聚合视图，将旧的模式改造适配到了新模式之中。消费方可以查询保单仓库，就仿佛它从未迁移过一样。其内部的底层机制和历史上的业务决策都被隐藏起来，从而简化了对接。
只有数据所有者（CRM 对应销售部门，其分析数据对应营销团队）才是永久成员。数据工程师只是被临时邀请进来配置蓝图和连接，随后便被移出，直到再次被需要为止。这些主数据项目所暴露的，是带有友好名称、术语表、元数据、描述、血缘和质量信息的、经过清洗的数据集。它们是所有下游分析、BI 和 AI 工作的核心模块。
决定一切的三项决策
在编写基础设施代码之前，有三项决策将决定你实现的复杂程度、治理的粒度以及每月的账单。
决策 | 选项 A | 选项 B | 我们的建议 | 理由 |
|---|---|---|---|---|
AWS 账户策略 | 每个环境（dev/UAT/prod）一个账户，容纳所有领域和项目 | 每个领域一个账户（若为多领域），或每个项目一个账户（若为单领域） | 每个领域/项目一套（各自都有 dev/uat/prd） | 契合 SDLC，遵循每个“工作负载 + 环境”组合对应一个 AWS 账户的最佳实践。 |
身份模型 | 通过 AWS Identity Center 实现 SSO | IAM | SSO | 用户级别的粒度、可追溯性、精细化的 Lake Formation 治理，是 AWS 所推荐的做法。 |
网络配置 | 不使用 VPC（默认） | 仅限 VPC | 从开放式起步，除非政策另有强制要求 | 仅限 VPC 会大幅增加复杂性；先证明价值，之后再收紧。 |
1. AWS 账户策略
理想状态是每个“工作负载 × 环境”对应一个 AWS 账户。对于单领域网格，这通常意味着每个环境（dev/UAT/prd）一个账户，并在每个账户中复制出完整的领域结构。对于多领域企业，每个领域（甚至每个大型项目）都拥有自己的一套账户。原则是：隔离影响范围（爆炸半径），并契合你的 SDLC。
每个账户都有自己的根领域。像开发应用程序一样开发网格：在 dev 中构建，晋级到 UAT，再部署到生产环境。
不要把 AWS（在 Unified Studio 内部）的“环境”概念与 dev/UAT/prod 环境相混淆。它们是不同的东西。每个 SDLC 环境都会复制出一套完整的领域结构。
2. 身份模型：SSO 对比 IAM
强烈推荐通过 AWS Identity Center 实现 SSO。 它为治理、可追溯性和精细化的数据访问控制提供了用户级别的粒度。在 IAM 力有不逮之处，SSO 却能派上用场。SageMaker Unified Studio 的 AWS 控制台会不断提示你去配置 SSO，直到你完成配置为止。
另一种选择——结合联邦组的 IAM——则会丧失粒度。最小的访问控制单位变成了“组”，这对于有实际意义的数据治理而言太过粗糙。如果你的公司强制要求使用联邦组而不使用 Identity Center，你就将牺牲可追溯性和用户级别的可审计性。
现实的政治情况是这样的：SSO 往往是最难争取到客户支持的事项之一。他们的手脚被那些位于指挥链更上层的人束缚住了。如果允许使用 IAM 用户，那么 IAM 领域是可行的，但这一点往往并无保证。
我们经常看到一种混淆：客户把 IAM/SSO（基础设施访问，即谁能登录 AWS 控制台）与 Lake Formation（数据治理，即谁能看到表中的哪些行和哪些列）混为一谈。这是两个相互独立的访问控制平面。大多数技术人员都很了解 IAM，却从未接触过 Lake Formation 中诸如行级访问、列级访问、基于角色的访问控制（RBAC）或基于标签的访问控制（TBAC）之类的概念。每一次实施，都是从一场在白板前厘清这一区别的讨论开始的。
3. 网络配置：仅限 VPC 对比开放式
仅限 VPC 的领域更为安全，但会大大增加实现的复杂性。你可以预见到需要配置 VPC 服务端点（service endpoints）、修改安全组（security groups），并与 IT 部门协调进行网络变更。在那些使用带有 Transit Gateway 的中心辐射式（hub-and-spoke）架构、且辐射端 VPC 没有互联网流量的组织中，复杂性还会进一步扩大。
如果（出于政策或法规原因）必须采用仅限 VPC 的模式，那就从一开始就采用它。不要留到以后再说。把仅限 VPC 的模式改造嵌入到一个已有的网格中，要比从第一天起就将其内建进去困难得多。
对于并未强制要求仅限 VPC 的首次部署，可以从默认的开放式配置起步，先证明网格的价值，然后再收紧。但前提是，这对你的组织而言确实是一个可行的选项。
抵御未来安全审查的一个实用做法，是从第一天起就加入 CDK NAG。这带来的额外开销是实实在在的，但当有人问起（是“当”而不是“如果”）“这套东西是否已经过验证，是否符合AWS 最佳实践？”时，它能让你抢占先机。
运营模式：实施成败的关键所在
在数据网格的实施中，技术大约只占 30%。剩下的 70% 是组织变革管理：角色、归属权，以及关于“谁来控制数据”的种种政治博弈。
为什么领域团队会抗拒承担归属权
最常见的反对声是：“你是想让我为每个部门都雇一名数据工程师吗？”管理者一听到“联邦式归属权”，脑海中立刻浮现出为每个团队增加人头编制的请求。
换个角度来看：项目团队可以是流动的，而非永久的。数据团队（也就是当前的“数据部门”）是一群固定的人。而项目则是来自不同团队的若干子集的临时交集，为了某个业务目标而聚集起来。数据工程师本就已经存在。我们并不是要雇用新人。我们只是针对每个项目，把同样这批人以不同的方式重新分组。如果某个团队始终让一位技术成员忙个不停，那么作为管理者，你就发现了一项关键的局部需求，此时雇用一名专职的全职员工（FTE）或许是个好主意。
康威定律确保了你当前的组织结构会催生出你当前的架构。数据网格把这一点颠倒了过来：按业务结果来分组，而不是按技术专业来分组。
治理的悖论
中央治理负责定义标准：命名约定、质量阈值、保留策略和分类规则。领域团队则负责为各自的数据产品实现并维护相应的契约。
最难的部分不是技术。而是让那些对数据访问抱有偏执担忧的利益相关者，就“共享”的含义达成一致；让他们意识到，这并非“要么全有、要么全无”。安全悖论再次浮现：一个组织的治理越不成熟，它为新系统设定的门槛就越高。
数据契约与问责制
每个数据产品都需要一份明确定义的契约：模式（schema）、质量规则、新鲜度 SLA，以及一位指名道姓的所有者。Well-Architected 透镜 明确规定，数据产品必须是自主的、可被发现的、安全的和可复用的。
数据管家（data steward）这一角色（依据 AWS 的参考架构）确保了联邦式的决策制定和元数据的可审计性。若没有契约和管家职责，网格就会退化成一团分布式的乱麻，比它所取代的那个集中式数据湖还要糟糕。
争取认同与支持
实施既是工程问题，也同样是政治问题。从一个主数据生产方项目开始。证明受控访问是行之有效的：销售团队能看到他们的 CRM 数据，营销团队能查询网站分析数据，而借助精细的、按项目进行的控制，双方都无法访问对方的表。
“近藤麻理惠（Marie Kondo）”式的论点：在你能够在公司规模上运行 AI 工作负载之前，你需要对治理良好的数据拥有精细的、依上下文而定的访问权限。数据网格并不是与你的 AI 路线图并列的一种奢侈品。它是让 AI 成为可能的先决条件。
它的成本几何（以及什么会让人措手不及）
网格基础设施本身是廉价的。那些出乎意料的成本，来自你在尚未弄清蓝图会配置哪些资源的情况下就贸然激活它们。
蓝图的成本陷阱
搭建 SageMaker Unified Studio 本身没有按领域计的费用。Lake Formation、Glue Catalog 和项目管理在小规模下基本上是免费的。账单来自蓝图所配置的计算资源。（当前费率请参见SageMaker 定价。）
最昂贵的意外： MLFlow tracking server。它由一个面向 ML 的蓝图激活，即便选用最小的计算选项、即便无人使用，每月的费用也高达数千美元（中位数量级）。我们见过一些客户在激活数周之后才发现这一点，纳闷这笔账单究竟从何而来。（注意：AWS 宣布推出了一个无服务器的 MLflow 选项，于 2025 年末推出且不额外收费，但由较旧的蓝图配置出来的那种托管式 tracking server 仍然会产生这笔费用。）
Code space（代码空间）（即你用来编写脚本的远程 JupyterLab 和 VS Code 计算环境）价格实惠，但并非免费。一个 t3.medium 实例每使用 10 小时约花费 0.60 美元，而自动关闭前的最短空闲超时为 1 小时。
GP3 存储 大约为每 15 GB 每月 2 美元。可以忽略不计。
规律如下： 基础设施（领域、项目、目录）= 基本免费。计算（端点、tracking server、code space）= 账单增长之所在。治理（Lake Formation、权限）= 免费。存储 = 廉价。
我们的建议： 如果你事先并不清楚自己的项目会需要哪些功能，你可以创建一个“All Capabilities”（全部能力）项目配置文件，把所有蓝图都添加进去，并将它们全部设置为 ONDEMAND（按需），而不是 ONCREATE（创建即启用）。如果你不知道某个蓝图会配置出什么，就不要激活它。我们本系列即将推出的文章会逐一解释每个蓝图及其所创建的内容。
我们如何在成本方面提供帮助
作为一家 AWS Partner（合作伙伴），我们帮助客户获取超出常规计算优化所能提供的成本优惠——这些节省是直接与 AWS 打交道时无法获得的。所有客户都能免费获得 DoIt PartnerOps，一个跨云的 FinOps 与合规平台。它能让你清楚地看到究竟是哪些由蓝图配置出来的资源在推高支出。我们见过有客户仅仅依靠成本优化工具，就节省下了相当于我们咨询费的金额。
务实之路：从小处着手，证明价值
不要试图把整片海洋煮沸（贪大求全）。挑选一个关键数据源、一个领域单元、一个消费方，在要求其他任何人做出改变之前，先证明这套模式是行得通的。
第 1 步： 找出你被索取得最多的那个数据集——也就是目前每个项目都要通过 Slack 私信、共享盘或手动导出才能拿到的那个。或者，挑一个痛点：“我们在现有的这套 SAS 平台上花费过多，需要迁移到现代化的架构上。”
第 2 步： 创建一个主数据生产方项目，指定数据所有者，并通过 SageMaker Unified Studio（而非直接在 Lake Formation 控制台中）配置 Lake Formation 访问权限。
第 3 步： 连同元数据、术语表条目和质量规则一起，发布到 SageMaker Catalog。
第 4 步： 接入一个消费方项目。证明他们无需向任何人开口，就能发现并查询数据。接入 AWS QuickSight，让业务利益相关者能够与 BI 仪表板进行对话式交互。反响通常是立竿见影的。
第 5 步： 为这次胜利庆祝一番。然后再做下一个数据集。如果做得好，每一次成功的接入都至少会造就一位内部布道者——一个亲眼见证它奏效、并向同事们奔走相告的人。这些布道者至关重要。顾问并不享有同等的信任。同侪之间的口碑推荐，在传播数据网格理念方面，要比任何自上而下的行政命令都有效得多。
这恰恰正是 Well-Architected 透镜所推荐的做法：快速的交付周期，并根据吸取的教训进行迭代。另一种做法（要求所有人同时改变的“一步到位”式网格铺开）则会在治理委员会的会议上无疾而终。
对于那些希望用基础设施即代码来自动化这一流程的团队：我们维护着一个面向 SageMaker Unified Studio 的、有明确设计主张的开源 L2 构件库（construct library），它使用 projen 进行管理。它能在单次 CDK 部署中一并配置好领域、领域单元、项目和蓝图。等它稳定之后，我们会将其发布到 NPM 和 PyPI，所以请关注我们的 GitHub 以获取更新。
给选择 IaC 路线的团队几点实用提示：随着你的网格不断增长，你会撞上CloudFormation 每个堆栈 500 个资源的上限。我们的做法是：为数据网格资源单设一个 CDK stage，每个领域一个堆栈，项目则使用嵌套堆栈。这样就为扩展留出了空间，而无需重构整个部署。
从第一天起就把你的 CDK 测试自动化。代码会经历显著的演进，而你会希望把等待失败部署所耗费的时间降到最低。那些被浪费掉的分分秒秒是会累积起来的。
AWS 也提供了一些有用的起点：面向 SageMaker Unified Studio 的 CI/CD CLI 以及一个官方实用工具仓库，其中包含针对常见模式的 CloudFormation 模板。
结论
SageMaker Unified Studio 上的数据网格在架构上很简单。AWS 已经把控制平面产品化了：领域、项目、目录，以及 Lake Formation 权限。这项技术是行之有效的。你的实施成败，取决于你的组织能否在采纳联邦式归属权的同时，不至于制造出比它所消除的还要多的官僚主义。
那条作为前提的洞见并未改变：若没有对受治理数据的、精细的、依上下文而定的访问权限，就无法在公司规模上运行安全的 AI 工作负载。“AI 需求金字塔”在此同样适用：干净的、受治理的、可访问的数据，是承载其余一切的基石。数据网格并不是与你的 AI 路线图并列的一个副项目。它才是让企业级 AI 成为可能的东西。
如果这正描述出了你所面临的挑战——怀揣着全公司范围数据访问的愿景，却没有一条从当下通向彼岸的清晰路径——那正是我们能够帮上忙的地方。作为一家 AWS Partner（合作伙伴），我们带来的是各项认证、成本优惠以及实践者的经验。
