本章内容
- 向你的组织介绍数据网格
- 在选择数据架构前考虑决策驱动因素
- 将数据网格与其他流行数据架构进行对比
- 将你组织的架构转型为数据网格
在第 1 章中，我们解释了数据网格的含义以及为何你的公司应考虑实施它。本章我们将回答另外两个关键问题：
- 我是否应该在业务中实施数据网格（即，哪些因素驱动采用数据网格）？
- 实施数据网格需要多少投入（即，收益是否大于实施成本）？
在本书语境里提出第一个问题也许会让你惊讶。数据网格已成为业内最热门的流行语之一。但很多公司在未充分考虑其是否适配自身组织（或未想清全部要求与影响）的情况下就匆忙上马。我们过去已见过多次类似的“跟风”——如微服务或敏捷。大量案例以失败告终，人们把锅甩给模式与实践，而非自身的落地问题。事实是：没有银弹。每一种模式/实践都有其适用范围与权衡。把数据网格当作你工具箱里的又一把工具即可。
本章后半部分聚焦如何实施数据网格。我们会展示达成这一目标的可能步骤，以及后续各章的技能与知识如何拼合到一起。但正如前面所说，最重要的是先弄清你是否需要数据网格。我们从这里开始。
2.1 分析数据网格的驱动因素
要判断数据网格是否适合你，需要分析架构选型背后的决策驱动因素。我们将其分为三类：
- 业务驱动
- 组织驱动
- 领域数据驱动
先从最关键的方面——业务原因——开始。
2.1.1 业务驱动
建议从业务侧展开分析。如果找不到一个合适的业务理由开启数据网格之旅，就此打住——你已经有答案了：你不需要数据网格。
业务战略
查看公司层面的业务战略；若是大公司，也可看事业部层面。寻找如下问题的答案：
- 我们是否将公司定位为“数据驱动”，或计划转向更加数据驱动的战略？
- 我们是否有需要依赖数据才能达成的 OKR（目标与关键结果）或其他目标管理方法？
注：OKR 是一种用于公司（及个人）设定目标的方法，常被用来落地业务战略。
若以上回答为“是”，可继续深挖，寻找需要数据支撑的具体业务用例（下一步会覆盖）。若回答为“否”，你的工作将更具挑战性。很多“需要数据”的业务用例藏在业务单元战略或具体业务流程里，找到它们需要一番笨功夫。
业务用例与其复杂数据需求
要为数据网格构建一个可行的业务用例，先回答：
- 是否存在正在进行或即将启动、且具有复杂数据需求的具体业务流程？
- 是否需要启动一个具备复杂数据需求的产品/项目来达成 OKR？
这里的“复杂数据需求”，指在来自多个数据源之上的多维分析（临时查询、AI/ML、报表）。如果答案是肯定的，你就可能拥有一个有力的业务用例。
关键要点：只有在存在相应的复杂数据需求且有明确业务用例时，数据网格才有价值。
示例 1：扫雪业务
第 1 章的案例中：
- Candace 把太多业务流程揉成了一条数据流，从而丢失了数据上下文。
- Adam 与 Eve 无法用他们的知识与经验来补充原始数据。
- Bob 与实际干系人脱节地运作。
将 Candace 的扫雪业务“网格化”的业务用例，可以是改进雪铲采购的需求预测。
示例 2：某知名快消品巨头
一家真实的 FMCG 公司发现其品牌间的研发彼此割裂。各研发团队自行产出数据并存储在烟囱中，描述语言也存在不精确与矛盾。尽管执行着相似/相同的测试，各组却使用不同的标准操作规程（SOP），结果描述也各不相同。
当中央数据团队无法构建统一的企业级数据模型时，建立数据仓库的初始尝试被叫停——缺少共同语言（且需求互相矛盾）使之无从下手。
引入数据网格后，帮助在几个方面改进：
- 去除了中央数据团队与所有领域“逐一对接”的瓶颈。中央团队转而聚焦构建数据交换平台并提供必要的元数据管理工具。
- 各领域团队不再需要为他域改造自身数据结构，而是投入精力完善源数据的文档化。
去中心化后，领域团队可借助其他数据集的完整元数据来复用同行历史数据。还出现了溢出效应：当团队开始互用并讨论彼此的数据时，数据的自然对齐与共同语言的形成会逐步发生。
可见，业务用例可以从公司战略层面的整体清理，到单一业务流程的改进。路径与规模会不同，但关键因素（业务改进）都需要被识别与量化。
2.1.2 组织驱动
组织驱动描述这样的情形：组织本身成为瓶颈。实施数据网格应通过撼动组织结构与文化来缓解这些问题。
社会—技术复杂性（Socio-technical Complexity）
一个社会—技术复杂的组织拥有大量产生与消费数据的系统，这些系统由不同团队/单元/个人开发，隶属不同管理链路。
也可能只有少数但极其庞大的团队，内部沟通困难（例如分布式办公且远程协作文化薄弱）。我们认为，社会—技术复杂性叠加复杂数据需求是引入数据网格的主要原因。
关键要点：数据网格适用于社会—技术复杂且数据需求复杂的组织。
数据成熟度
用于衡量数据成熟度，我们认为 Gartner 的“分析上升模型”（Descriptive/Diagnostic/Predictive/Prescriptive 四阶段）很有用：
- 描述型：记录发生了什么
- 诊断型：解释为何发生
- 预测型：预测将要发生
- 处方型：指导应当如何行动
引入数据网格的公司至少应能在该尺度上“打分”（即具备数据采集、存储系统与文化，能可靠访问历史数据）。若不具备，应先逐步学习如何使用已有数据，而不是贸然大改。通常成熟度越高，越可能从数据网格中获得更大收益。
关键要点：数据网格适用于具备一定数据成熟度的公司。
软件工程成熟度（CI/CD、DevOps）
数据网格是一种社会—技术层面的变革。尽管我们强调社会学的一面，技术层面的能力也必须匹配。评估研发团队能否高效推动所需改动，可从以下维度观察（非穷尽）：
- 测试自动化水平
- DevOps 文化
- 持续集成/持续交付（CI/CD）
- 安全左移（在开发流程中嵌入安全）
- 以产品为中心而非以项目为中心
若这些概念并非你团队的“日常”，要他们打造高质量的数据产品将会很难。在开始数据网格转型之前，或许应优先提升工程成熟度。
关键要点：数据网格适用于软件工程成熟度较高的公司。
图 2-1：主要的组织层面数据网格驱动因素（示意）
请记住：这些驱动因素都不构成实施数据网格的必要或充分条件。下面讨论同样重要的“领域数据驱动”。
2.1.3 领域数据驱动
领域数据驱动聚焦于领域层面产出的数据（不清楚“领域”可回看第 1 章，或第 4 章的方法论）。可先近似理解为某一业务职能的责任范围。以下因素指示：数据网格适合用于对外暴露该领域产出的数据。
领域与数据模型的复杂度
复杂业务场景的数据建模与维护本就不易，既要懂数据建模也要懂业务。强中心化架构（尤其在大公司）中，中央数据团队往往服务过多领域，难以保证所需专长；工作饱和也让其无暇投入到资源密集的数据对齐与紧耦合模型演进（第 1 章已指出）。即便假设跨职能推进模型开发，若中央团队并不直接参与领域运营，那么对模型的持续更新与修改在认知负荷上也会把团队压垮。
关键要点：数据网格适用于领域复杂的公司。解决之道是去中心化数据所有权——这正是数据网格的支柱之一。
数据多样性
当公司同时处理多种格式与来源的数据（结构化/半结构化/非结构化；事件/文件/图/关系型/NoSQL 等），常会被“数据对齐”困住。每引入一种新格式/来源，就增加了一份耦合与变更概率。源头或中间模型的每次变化，都可能引发级联故障。
另一个常见难题是可发现与可访问性：让元数据仓保持最新很难；当数据来自不同监管辖区（如欧盟 vs 玻利维亚）且保护等级不同，针对数百个资产维持细粒度访问控制也很难。
关键要点：数据网格适用于数据源多样的公司。
当公司在一致性、对齐以及繁多数据源上举步维艰时，数据网格通过数据产品化、松耦合以及领域化所有权提供了一条可行路径。
数据量
高数据量会在成本与时延上形成瓶颈。中心化架构尤甚，因为所有数据都需汇入中心湖进行转换与查询。
若你的业务要求将数据生成到消费/分析的时间最小化（可扩展、近实时），那么通过去中心化所有权与数据产品化来处理大体量数据，往往更高效。
图 2-2：领域数据相关的数据网格驱动因素（示意）
同样请记住：这些驱动因素（即便与上一节的组织驱动组合在一起）也不构成实施数据网格的必要或充分条件。为了更全面，你还应考虑一些次要驱动因素，我们将在下一节介绍。
2.1.4 次要的组织驱动因素（Minor organizational drivers）
这些因素并非你开展数据网格之旅的关键前提（但在评估一旦启动所需成本时值得纳入考量）。我们认为数据网格是架构演进的下一阶段。如果你的组织已具备较成熟的治理、工程与领域驱动设计实践，并拥有具备数据素养的工程师，那么实现业务用例目标会相对容易，转型过程也更顺畅。
如果这些方面尚不成熟，但第 2.1.2 与 2.1.3 节所述的主要驱动仍在推动你走向数据网格，那么你需要将文化变革管理的额外投入计入成本。下面这些因素会影响你对转型成本与投入的评估，并可作为一个扎实的起点。
数据治理成熟度
数据网格的支柱之一是联邦式数据治理（第 6 章详述）。不论你当前采用哪种数据治理模型，治理成熟度越高，转型越容易。
评估数据治理成熟度，我们建议采用 Gartner Data Governance Maturity Model（不要与第 2.1.2 节提到的分析上升模型混淆；见 mng.bz/XZl6）。该模型将治理成熟度分为六级：
- Unaware（无感知） ——未定义数据的所有权、安全或相关系统
- Aware（已感知） ——面向项目的策略，开始梳理与记录数据相关风险，孤岛信息尝试汇总
- Reactive（被动响应） ——信息共享目标形式化，本地集成与点对点接口
- Proactive（主动） ——建立数据治理团队，遵循数据相关政策，本地维护的数据模型与中央架构指引对齐
- Managed（已管理） ——治理机构跨职能地处理信息问题，形成企业级信息需求方法
- Efficient（高效） ——数据治理自动化，信息流畅通无阻
如果公司处于早期成熟阶段（如 Unaware 或 Aware），实施联邦式数据治理将消耗大量时间与精力。
关键要点：数据治理成熟度越高，数据网格越易落地。
具备数据素养的软件工程师
即便软件开发团队整体成熟，在许多公司里，“软件世界”与“数据世界”仍相互割裂，二者（不）沟通常在数据运营中制造瓶颈。若工程师已具备数据素养，让现有系统演化为数据产品会更快更容易。否则，在规划数据网格转型时，需要考虑能力差距的补齐成本。
即便你已招聘到优秀的数据工程师，仍需打造一支强大的平台团队，为软件与数据联合团队提供友好的使用环境；同时还需要赋能团队对其他团队进行辅导。
若你的软件团队缺乏与数据打交道的经验，同时也缺少资深数据工程师，可能需要招聘具备数据素养的工程师，把这部分成本计入预算。
关键要点：当软件开发与数据专家紧密协作时，数据网格更易实施。
遵循领域驱动设计（DDD）的方法
领域导向是数据网格的核心。即便团队未显式采用 DDD，也可以评估他们日常工作与其原则的贴合度。要评估将团队重心转向“领域”的成本，可就以下三点发问：
- 他们与领域核心的贴近度如何？工作是否紧扣领域逻辑？
- 其软件与数据设计是否基于领域模型？
- 是否与领域专家协作？
我们在讨论其他驱动时部分覆盖了这些问题，但合并来看，有助于判断在你的组织中落地“领域所有权”原则的难易度。
关键要点：越是遵循 DDD 的公司，实施数据网格越容易。
以上任何单一驱动因素，或其组合，都不能直接给出“上/不上数据网格”的明确答案。要判断数据网格是否适合你的组织（乃至是否是解决你业务用例的正确方案），还需与备选方案进行对比。
2.1.5 数据网格适合我吗？
请自问一个关键问题：你当前的社会—技术架构，能否充分支撑当下及规划中的业务运营？ 这也是为何本章开头鼓励你先从业务用例入手。如果下述一条或多条符合你的现状，数据网格可能有所助益：
- 数据消费者难以发现或访问所需数据，拖慢了运营。
- 数据消费者与软件/数据工程团队对齐所需时间过长。
- 中央数据团队背负冗长的待办清单（例如维护数据模型与目录、决定访问权限、处理来回的数据传输成本）。
如果这些问题仅轻微存在且影响有限，数据网格的投入可能不划算。相反，若你观察到上述问题的任意组合；并且你的组织具有强烈的业务动因（需要从数据中创造价值、社会—技术架构复杂、数据需求复杂，或为规划增长提供可扩展性），那么数据网格很可能适合你。要做出最终决策，不仅要理解预期成效，还要看清这段旅程意味着什么。
2.2 数据网格的替代与互补方案
本节所述方案既可作为互补，也可作为替代，取决于你将其视为技术还是社会—技术架构。因此，我们不仅从技术视角介绍这些常见模式/架构（这通常是业界做法），也从社会—技术视角加以审视。
希望这段讨论能帮助你判断：是否有其中任一种方案已足以满足你的组织需求。你也可以将它们作为数据网格的技术组成来选用。
注：数据仓库、数据湖、湖仓、数据织体（fabric）都可以是互补方案。它们并非必然与数据网格对立；关键在于跳出其“默认的社会—技术架构”，并将其与数据网格的社会—技术架构对齐。实现路径是——去中心化所有权。
需注意，每种架构在实践中都有诸多“风味”。不同组织里都会经历微调、改造与演进。为便于对比，我们只讨论最常见、最“标准”的落地方式，不穷尽所有变体。
2.2.1 企业数据仓库（Enterprise data warehouse）
企业数据仓库是一种将数据存放在中央数据存储库中的方法，由中央数据团队拥有与管理。数据通常通过 ETL（extract, transform, load） 或 ELT（extract, load, transform） 从系统记录（system-of-record, SoR）数据库直接引入到数据仓库。随后，数据被规范化为标准（canonical）模型并存放在仓库中。下游要么直接从数据仓库消费数据，要么通过更简单、通常聚焦某个业务职能的数据集市（data mart）来消费（见图 2-3）。
图 2-3 在这种企业数据仓库的社会—技术架构中，方框代表不同团队的职责范围，“ETL or ELT”和“ETL”矩形代表数据转换组件，箭头表示调用方向——从调用方指向被调用方。
在图 2-3 的示例中，团队 A、B、C 负责产出数据，但不拥有从其源系统抽取数据的管道——这些管道归中央数据团队所有。通常也假定中央团队同时拥有 BI 与报表。图中将 BI/报表与数据分析描绘为由不同团队所有，但在很多组织里，它们也可能由同一个中央数据团队负责。
在以下情形下，应优先考虑实施企业数据仓库而非数据网格：
- 大多数数据源是结构化的。
- 当前的数据用例明确稳定，不太可能大量扩展或演化。
- 主要通过 BI、报表与数据分析 来从数据中提取价值。
- 依赖的源系统数量少且变化不频繁。
- 数据源由少量团队所有。
- 中央数据团队对数仓技术具备经验与专长。
正如开头所述，企业数据仓库是一种社会—技术路径，而“数据仓库”本身是一种底层技术。技术层面它并非数据网格的对立面；在数据网格中也可以将数据仓库作为技术方案之一。但在这种情况下，数据仓库不应试图汇聚全公司的所有数据，而应由各业务域按需决定是否采用。
在以下情形下，可在数据网格之外叠加使用数据仓库：
- 至少有一个业务域的来源以结构化数据为主。
- 该域主要通过 BI/报表/分析 产出价值。
- 你的数据工程师对数仓技术较为精通。
2.2.2 数据湖（Data lake）
我们在第 1 章已提到数据湖，这里进一步展开。数据湖与数据仓库的共同点是都依赖中央数据存储库；但关键差异在于数据湖以原始（raw）格式存放数据。数据工程师会将其转换为更结构化、清洗过的形式，并连同血缘与版本信息一同移动到不同的分区/区域（zones） 。
数据湖通常包含多个区域（例如：处理区（process zone）用于存放已处理但尚未对生产或终端用户开放的数据；访问区（access zone）用于存放已整理好、可供消费者访问的数据，见图 2-4）。常见表述是：数据湖为读时模式（schema-on-read） ，而数据仓库为写时模式（schema-on-write） 。即在数据湖中，入湖数据无需立即符合既定的模式与模型；而是在被访问到不同区域之前，再按需套用/强制相应模式。
图 2-4 数据湖的社会—技术架构
数据湖常被描述为不仅仅是一个存储模式；它通常还包含诸多配套能力（摄取机制、安全、元数据与目录、处理引擎、访问机制等）。
其典型的社会—技术架构与企业数据仓库几乎相同：如图 2-4 所示，所有与数据相关的组件由中央数据团队拥有。在以下情形下，可优先考虑数据湖：
- 你需要处理大数据（体量、速度与多样性）。
- 你拥有结构化、半结构化与非结构化多种数据源。
- 难以预见全部数据用例。
- 数据源由少量团队所有。
- 消费模式尚未成形。
2.2.3 数据湖仓（Data lakehouse）
数据湖仓是数据仓库与数据湖的结合（见图 2-5），建立在数据湖之上，并增加了以下特性：
- ACID 事务支持（原子性、一致性、隔离性、持久性）
- 模式强制与治理
- 在同一数据源之上的 BI 支持
图 2-5 数据湖仓的社会—技术架构
如图 2-5 所示，其社会—技术架构与数据仓库/数据湖相同。在以下情形下，可考虑实施数据湖仓：
- 部分用例明确且依赖结构化数据。
- 主要通过 BI、报表、数据分析 提取价值。
- 同时拥有结构化、半结构化与非结构化数据源。
- 多数数据用例难以预见。
- 面对大数据场景。
- 数据源由少量团队所有。
- 消费模式尚未完全稳定。
关于数据湖、数据仓库与数据湖仓“相似性”的影响
这三者在标准落地中都高度依赖中央数据团队。当公司拥有众多数据源且使用模式复杂时，这往往是它们的根本短板。
但从纯技术视角看，这三种架构都可以为数据网格提供良好的计算环境——网格中的各元素可直接复用现有基础设施来构建。数据网格并不要求你更换已投入巨资的技术栈；它关注的是组织层面的去中心化，以避免过度中心化带来的低效拖累平台潜力。
上述三种方案的共同点是：中央数据团队。而下一种方案则处在集中化光谱的另一端。
2.2.4 数据编织（Data fabric）
数据织体是一种以技术为中心的数据管理方案：通过低代码/无代码平台将数据源与消费者连接起来，并在其上施加治理，旨在于异构、多平台环境中简化数据集成与交付。
数据织体通常结合 AI/ML、知识图谱 以及元数据，尽量自动化集成与交付流程。由于“数据织体”概念相对模糊，很难给出精确定义。Gartner 的定义（见 mng.bz/yvjq 与 mng.bz/M5Gn）给出了一个理想的数据织体应包含的组件（见图 2-6）。
图 2-6 数据编织的组成
按定义，数据织体并不内含固定的社会—技术架构，因此难将其视为数据网格的替代。更恰当的看法是：它可以作为实现数据平台的一种途径。市面上的数据织体产品包括 Cinchy（www.cinchy.com）与 Talend Data Fabric（www.talend.com/products/da…
- 拥有结构化、半结构化与非结构化多种数据源。
- 面对大数据场景。
- 数据源数量多、归属团队多。
- 数据消费方式多样，需要统一编排与治理。
2.2.5 数据网格与“其它架构”的对比
我们在图 2-7 中汇总了主流数据架构与数据网格的对比。这张维恩图沿用了 2.2.1、2.2.2 与 2.2.3 节中描述的几类“气泡”。
图 2-7 数据架构对比
如你所见，就社会—技术与数据需求两个维度而言，数据网格适用于复杂组织。如果你的数据多样性高，数据网格同样契合。若一个组织在这三个维度上都“打勾”，可以考虑将数据网格与数据织体（data fabric）结合使用。请记住：按经典方式落地的数据湖 / 湖仓 / 数仓并不适合社会—技术高度复杂的组织，但与数据网格结合后，它们反而能蓬勃发展。
图 2-7 的核心结论可概括为下述关键点：
关键点 数据网格适用于社会—技术复杂且数据需求复杂的组织。
如果你判断组织中的社会—技术与数据复杂度足以支撑一次数据网格实践，下一节将展示实施数据网格需要做什么。
2.3 评估数据网格的实施工作量
如果你已经按 2.1 节做完“驱动因素分析”，应该能判断实施数据网格是否能带来价值。现在就需要考虑：要满足哪些前提与要求，以及这些付出是否值得。为回答这个问题，我们会带你过一遍我们建议的步骤，以及在组织层面上为实施数据网格所需的结构性安排。
我们不打算在此详述技术选型与对应成本——可能性太多，不便一一列举。不过我们相信，读完本书，尤其是第 7、8 章后，你将能够基于自身情境做出合理估算。现在先来看一份实施流程的概览。
2.3.1 数据网格的开发周期
根据我们的经验，数据网格的实施最佳方式，类似于基于 CI/CD 的软件开发：小步快跑、迭代推进，以获得快速胜利、迅速反馈与修正，并灵活应对变化。图 2-8 展示了开发流程的高层视图。
图 2-8 数据网格开发要素
在“跳进去”之前，应该先为变革打地基。图 2-9 聚焦于准备阶段的要素。
图 2-9 数据网格开发要素——项目准备细节
我们先前强调过业务用例（business case）的重要性——它将作为所有决策的参照。准备工作的第二件事，是确保你具备必要的赋能性组织结构。你应重点考虑以下三类关键要素：
- 赋能团队（Enabling team）
- 治理团队（Governance team）
- 平台团队（Platform team）
后两者是否必需，取决于你的具体环境。详见第 6 章与第 7 章。不过以我们的经验，赋能团队的质量对数据网格成败至关重要。你可以把赋能团队组织为变更管理小组、实践共同体（CoP） ，或治理团队。我们会在 2.3.3 节进一步阐述它们的职责。
在初步结构就位后，就可以启动开发迭代。图 2-10 展示了开发周期的要素。
图 2-10 数据网格开发要素——开发周期细节
迭代应始于一个可由数据赋能的业务目标，并为其设定清晰的成功度量。
另一方面，对赋能性结构的调整应放在周期末尾，此时各种错配或不足已较为清晰。
支撑业务用例所需的数据产品开发，是数据网格迭代的核心。图 2-11 展示了数据产品开发周期的细节。
图 2-11 数据网格开发要素——数据产品开发周期细节
首先要充分理解消费者需求（来自业务用例），再把这些需求转化为数据产品的功能/非功能需求。接着为数据产品设计边界、明确所有权并对齐治理策略。到这一步才进入软件开发本身。开发周期的一个内建环节是对数据产品进行成效监测：这既帮助数据产品负责人持续改进，也便于开发者识别需要调整赋能结构的地方。
当业务用例得到解决、数据产品就位、并（如有必要）完成了对赋能结构的调整后，就进入下一轮。图 2-12 汇总展示了数据网格开发的所有要素。如果这一流程看起来有些“庞杂”，请参见第 3 章，我们给出了一种一个月内交付的 MVP 实施示例。
图 2-12 数据网格开发要素的详细视图
2.3.2 在“扫雪”案例中的开发周期
在第一章里，我们描述了 Candace 如何把数据网格引入她的组织：
- 她识别出业务用例：利润偏低，而且数据使用复杂且低效。
- 她做了项目准备工作。
- 她“任命”自己为赋能者，并把《Data Mesh in Action》从头到尾读了一遍。
- 她把业务划分为若干域，并把数据、信息以及部分决策的所有权下放到主要运营域。她没有再去收集原始数据并在中央进行转换/分析，而是把问题直接抛给域的所有者。大家共同商定：Adam 与 Eve各自用自己的数据，为各自街区建立定价决策模型。
值得注意的是，在第一轮开发迭代尚未真正开始前，她就已经获益了！到了下一年，团队经历了第一轮迭代：
- 业务目标细化为：改进采购预测。
- 明确了数据产品：Adam 与 Eve 的铁锹使用量估算。
- 交付了数据产品：供 Adam 与 Eve 使用的在线表格。
- 她复盘了结果，并规划了下一轮。
可见，第一轮数据网格迭代并不需要漫长或艰难，也不必一次性覆盖所有数据网格属性，同样能够带来业务价值。我们会在第 4 章进一步展开——以 Messflix 为例，展示如何在一个月内落地一个数据网格 MVP。在此之前，先对迭代中的要素再多了解一点。
2.3.3 赋能团队（Enabling the team）
无论你计划实施的数据网格范围大小如何，都必须确保有人对推进进度负责并承担责任。由于数据网格横跨“数据世界”和“软件世界”，找到合适的人来牵头并不容易，但此人应当同时具备这两方面的经验。
鉴于驱动数据网格实施的因素通常出现在社会—技术高度复杂的环境中，仅靠一个人几乎不可能胜任。此外，赋能团队必须是跨学科的：成员可以来自实践共同体（Communities of Practice）、行会（guilds）或章节（chapters）。
确保数据治理
你的组织可能已经有治理结构，也可能没有。若现有治理足以支撑首轮迭代，你可以先不动，把问题留到反馈收集阶段再识别摩擦点与改进项。下一轮目标也许就是优化治理。但建议至少确保你设计的数据产品的相关数据由其所有者负责。
促进数据产品开发
赋能团队需要支持各域开发其数据产品。成员应当撮合与促进领域专家、数据工程师和软件开发者之间的协作。其职责见图 2-13。
图 2-13 赋能团队在数据产品开发中的角色
促进平台开发
赋能团队还必须能支持平台团队（若已设立）。这意味着赋能团队需要在概念层面对齐数据产品团队的需求与平台能力：
— 帮助数据产品团队用平台能力的语言表达诉求；
— 帮助数据平台团队向数据产品开发者清晰传达平台特性、期望与限制（见图 2-14）。
图 2-14 赋能团队与数据平台团队协同支持数据产品团队的角色
平台团队应以 X-as-a-Service（一切皆服务）的方式提供能力，可能是 PaaS/SaaS/IaaS。当平台团队开发新功能时，最好与一个使用团队结对做试驾。
促进治理
依据你组织的治理模型与成熟度，“促进治理”可能是赋能工作的最具挑战部分。数据治理团队需要足够的权威与影响力来履职；而建议他们改变惯性做法往往并不轻松。
成功的关键在于澄清数据网格治理的角色与职责边界。无论是偏向极度集中还是极度分散的一方，都需要先理解联邦式治理的优势，才能接受其作为方案。
第 6 章列出了联邦治理的主要优点。赋能团队在接触潜在治理团队成员前，最好烂熟于心。与治理团队协作，要求至少部分赋能团队成员既具备技术素养（软件开发与数据工程），也具备软技能（见图 2-15）。否则，治理会议可能会跑偏成争论，而不是围绕政策与实践的讨论。
图 2-15 治理团队的团队拓扑
如你所见，赋能团队在整个变革过程中都会非常忙碌。下面来看该团队所支持的开发周期。
2.3.4 开发周期详解（Development cycle in detail）
数据网格的开发周期以用数据达成业务目标为中心：先定义目标与所需数据，然后开展开发；若有必要，再调整数据治理环境或改造中央平台。
在数据网格早期，这些工作可能还不会同时发生在多个域中；但当网格覆盖多个域时，每个域都会有各自的开发周期，同时还需要与中央团队（数据治理与平台）的工作对齐。
选择一个可由数据赋能的业务目标
2.1 节的“驱动因素”有助于你识别想通过数据网格解决的痛点。但仅给出名称不够，描述业务目标时需要明确其定义目的：
- 先解释为何值得达成：它能给业务带来什么增量价值？可以采用 OKR 或 SMART（具体、可衡量、可达成、相关、具时限）等框架表述。
- 其次，要把目标放在实现所需工作的上下文中。我们不仅要权衡收益与投入，还要让参与团队能把自身任务与目标关联起来。目标应成为判断是否接单与优先级的最终依据。
- 最后，应为业务目标配套职责分配矩阵，例如 RACI（负责 / 主管 / 咨询 / 通知）、PARIS（参与者 / 主管 / 需评审 / 需输入 / 需签署）等，以确保目标对业务持续相关且不跑偏。
定义所需的数据产品
前文提到，目标需要与实现它的工作相挂钩。此处深入到一个关键工作面：明确实现目标所需的数据，并将其转化为数据产品，以便数据消费者高效使用并产出业务价值。
建议从识别数据用例入手，可快速回答以下问题：
- 为实现目标，关键的**参与者（actors）**是谁？（若目标描述清晰，此题不难。）
- 这些参与者如何使用数据？
- 他们使用的数据是什么？
- 他们从哪里获取这些数据？
- 这些数据的真实源头在哪里？
输出应是一份数据源清单及其访问系统。第 4 章的方法可用于判断哪些源可归属同一域，并作为合并候选以减少需要开发的数据产品数量。
同时关注参与者使用的数据访问系统：它们可能被合并或重塑为面向消费者的数据产品。若源数据产品能够直接以可用形态提供数据，则某些下游系统可被完全省略。
开发数据产品
无论你如何划定边界，第 5 章会指导你把数据源落地为数据产品。其开发与常规 IT 产品并无本质不同，只是从头到尾需要软件工程师、领域专家与数据工程师共同参与。同时，数据产品负责人拥有平台、源与数据的所有权；他们与团队应对开发框架有最终决定权，以匹配需求与团队风格。
收集关于平台的反馈并分析共性需求
这一步对长期成功至关重要（仅次于业务用例选择）。即使数据产品在设计或实现上出错，只要反馈循环做得好，都能纠正。
请务必同时关注两类对象的痛点，且同等重视：
- 数据消费者（产出业务价值的角色）
- 开发者
理解数据消费者的需要固然重要，但开发者遇到的问题也不容忽视。数据网格的目标是打造可扩展且高效的去中心化环境；尽早识别并清除他们的阻碍因素至关重要。第一轮第一个数据产品中解决的问题，未来就不会滚雪球，这正是可扩展性的核心。
若不确定如何收集反馈，可组合采用：
- 邮件 / 聊天：提交方便，但归纳整理成本高；
- 会议：便于追问澄清，但组织难度与打断感较强，且信息易遗失；
- 反馈表：结构化采集定性/定量意见，代价是可能丢失“非常态细节”；
- 专业反馈平台：采集与聚合更系统，但需要付费与培训成本。
拿到反馈后，识别重复出现的问题，以及可用同一方案化解的簇。
制定共通政策并改进治理
务必将识别的问题系统性解决：有时靠最佳实践与推广即可；有时需要培训/辅导；还有些问题过于严峻，不能靠自觉，需要通过政策并由治理结构守护其落地。
以我们的经验，这属于重锤。为每个小问题都制订政策，可能导致瘫痪，或至少降速，甚至被静默忽视。是否上升为中心化约束，应由治理团队把关：既要判断问题等不等得上“上政策” ，也要审查方案是否与内外部合规一致。
建设平台
是否要建设/改造平台取决于业务用例与数据环境的特性。若产出业务价值需要调整现有平台或建设新平台，这是启动的合适时机。第 7 章详述平台建设，第 8 章对实施选项做了对比。
贯穿整个开发周期，**平台应被当作“产品”**来运营，至少要支持两件事：
- 连接数据产品与数据消费者（任意所需拓扑）；
- 自动化地实施治理政策。
在首轮数据产品开发与反馈前，几乎不可能准确定义平台工作的范围。有了来自数据消费者与产品团队的反馈，平台团队才能为下一轮制定恰当计划。
——本章到此，你已了解数据网格的业务语境与启动一项变革所需的前期地基。下一章我们将展示如何在一个月内用一个MVP验证数据网格的业务价值假设。
总结
-
数据网格不是业务目标本身。先看你公司的战略是什么；如果战略强调“从数据中创造价值”，数据网格可能有用。
-
先识别具有复杂数据需求的业务用例；再评估数据网格是否有助于解决那些长期存在的难题，据此推进。记住：数据网格并不适用于所有情境。
-
不同业务需求可能有更合适的替代架构。数据网格更适合社会—技术复杂度高、数据需求复杂、数据类型多样的环境。
-
识别全部转型驱动因素：
- 组织层面——如社会—技术复杂度、数据与软件开发的成熟度；
- 领域数据层面——如领域及其数据的复杂度、数据多样性与数据量。
-
为数据网格打好基础：明确业务案例，建立治理团队与赋能团队；同时确保数据产品、数据治理与中央平台的建设得到充分支持与推进。
-
以循环迭代的方式建设数据网格：围绕将新数据产品纳入网格、收集并分析反馈来推进；仅在必要时修改平台与治理。
