本章内容
- 定义数据网格（data mesh）
- 介绍数据网格范式的关键概念
- 了解为何数据网格是一次“社会—技术（socio-technical）”范式转变
- 看到数据网格的优势
- 识别落地数据网格可能面临的挑战
数据网格是一种去中心化范式。它将数据的所有权、数据到信息的转换以及数据服务进行去中心化，通过此举消除数据价值流中的瓶颈，从而提升数据价值的提取。
数据网格范式正在重塑数据领域。大小公司都在互联网上展示其类似数据网格的实践之旅。对任何希望从数据中获取更大价值的公司而言，它正在成为一件“必试”的新事物。本书将数据网格描述为一种社会—技术架构，并强调其中的“社会层面”：焦点在人、流程与组织，而不仅是技术。数据网格可以用当下大多数数据系统所使用的同类技术来实现，但并不必须如此。
然而，关于数据网格的讨论仍在持续，最佳实践与标准也在渐进形成。我们因而需要一本深入的著作，既覆盖促成数据网格有效运转的关键原则，又给出可适配于不同公司的案例与变体。本书旨在做到这一点：帮助你开启自己的数据网格之旅。
我们会提供概念性工具（不限于关键的数据网格原则）以及来自一线的洞见与示例。本书并非纯理论的全面研究，而是提供让你着手落地所需的实用指导。
作为开篇，我们将先看数据网格的核心思想，以及其相伴随的收益与挑战。我们也会给出一个以结果与可操作性为中心的数据网格定义。
1.1 数据网格入门（Data mesh 101）
本书中的数据网格范式，核心在于去中心化责任。例如：负责公司“客户注册”组件的开发团队，同时也产出一个用于分析“已注册客户”的数据集。该团队通过对数据进行转换（如转为 CSV），并以消费者期望的方式对外提供（如放在一个集中式文件共享系统），来确保该数据集易于消费。
但这个看似简单的定义蕴含大量影响。因为在大多数公司里，数据常被当作副产品来处理：它通常先被当作副产品丢入存储，然后被集中式数据团队拉入中心化技术栈，再被分散的参与方取用——可能是市场部分析师、用于营销活动的推荐系统，或某个前端展示。图 1.1 展示了一种常见的数据架构（既包括组织层面也包括技术层面），并尽力标注了它的若干问题点。
图 1.1 分散式的数据产生与中心化的转换会给用户带来问题，比如数据归属不清、质量责任不明等。
这里可以看到两层“中心化”：
- 技术中心化：以集中存储与常见的数据工程/数据科学工具链为代表
- 组织中心化：集中式数据团队
由于开发团队将数据视为副产品，所有权便被隐含地指派给数据团队。但此类中心团队通常难以及时掌握多个业务领域的知识。负责“客户注册”的开发人员只需理解该组件的领域语言、更新节奏与相关业务；而中心数据团队则需要对多个领域都具备同等理解。这种认知过载使中心团队很难达到一线团队的理解深度。结果往往是：数据团队无法判断数据是否正确、其实际含义为何、某些具体指标代表什么。
数据网格所倡导的范式转变，是将数据的责任去中心化——把数据当作真正的产品。图 1.1 的情形可以通过如下方式转变成数据网格：例如，让开发团队通过一个标准化的数据端口（data port）直接向分析师提供数据产品。这个产品可以非常简单：一份放在合适云存储位置的纯 CSV 文件，分析师可以轻松访问。图 1.2 展示了这种转变。
图 1.2 去中心化的数据转换通过提供易访问、描述完善的数据，让数据消费者更满意。
一个平台团队可以为开发团队提供“技术即服务”，使其能快速部署此类数据产品（包含数据端口）。数据生产者专注于构建数据产品，并与数据消费者一起建立连接，逐步编织成一个网络。我们称这个网络为网格（mesh） ，其中各个节点就是数据产品与消费者。
即便在这个小例子里，我们也能看到一次显著的运营范式转变：既包括所有权责任（从中心数据团队转移到开发团队）的变化，也包括让新架构有效运行所带来的技术挑战。
在运营范式中引入改变，会在业务的许多方面引发“连锁反应”。为了避免这些涟漪演化成混乱，我们需要指导性原则。本章稍后会做简要介绍，并在第 4～7 章详细展开。在此之前，你需要理解我们对数据网格的定义以及它的非技术侧面。Zhamak Dehghani 在 2019 年对数据网格理念做了出色的梳理（“How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh”，mng.bz/nNaK）。她给出了关键元素，并为上述范式转变引入了结构化方法。
自 Dehghani 提出数据网格以来，涌现了许多受其启发、源自业务或理论的案例。大量内容并不完全契合最初的框架描述，许多企业也并不确定：什么才算真正符合数据网格的定义。
在我们的工作与本书中，我们倾向于务实可落地（这也是书名“Data Mesh in Action”的由来）。因此，我们给出的数据网格定义力求广义且实用，强调去中心化的努力以最大化数据价值。
定义 数据网格是一种去中心化范式。它将数据所有权、数据到信息的转换与数据服务去中心化，旨在通过消除数据价值流中的瓶颈来提升数据价值提取。数据网格由四项原则（见 1.4 节与第 4～7 章）进行引导，以实现规模化的高效数据运营：领域所有权、领域数据即产品、联邦计算治理以及自助式数据平台。数据网格的实施在范围与各原则的贯彻程度上可能有所不同。
实施数据网格的目标，是从公司的数据资产中提取更多价值。这也是我们保持定义轻量且包容的原因——允许不同组织在不同层面实践各项原则。下面这个非技术的数据网格用例，或许能更好地说明我们的意图。
1.2 为什么需要数据网格？
我们认为，数据世界需要以“数据网格”的形式走向去中心化，主要有三点原因：
- 随着数据源与数据消费者的激增，夹在中间的中央团队会形成组织瓶颈。
- 在多种产数/用数技术并存的情况下，夹在中间的单体式集中存储会形成技术瓶颈，并在中间这一步丢失大量信息。
- 数据质量与数据所有权通常只被隐式地分配，导致混乱以及对二者缺乏掌控。
过去 30 年里，大多数数据架构都致力于整合多个数据源：中央数据团队把各类源系统的数据合并起来，向用户提供“统一”的数据集，期望由此驱动业务价值。然而十余年来，“大数据后遗症”困扰着各种规模的公司：方案难以扩展、数据不完整、可访问性差……很可能你的公司也在为如何从数据中提取价值而苦战？
一些方法显然并不奏效。做了成打的报表与看板，产出与创建/维护的成本相比收效甚微；一堆数据科学项目停留在原型阶段；即便上线的数据密集型应用，也常常遭遇各种与数据相关的问题，投入精力远超一般软件组件上线所需。
可扩展性问题的一个原因，是数据源与数据消费者的爆炸式增长。当一个中央团队负责数据从采集、转换与标准化到服务所有潜在用户的全程，瓶颈就不可避免。即便把团队沿“数据管道”切开也难见成效：采集侧工程师改了点什么，就必须通知负责转换的一组，否则上游可能失败，或更糟——悄悄把数据错处理了。工程师之间的高强度协作会把各个数据相关系统紧耦合在一起。
另一问题来自单体化的数据平台（如数仓与数据湖）。它们往往缺乏足够的多样性，无法真实承载源域数据的语义与结构；强行扁平化数据结构会让关键的领域知识在集中平台中流失，削弱了从数据中产出洞见的能力。
我们在一个项目中就见过类似问题：一家汽车零部件制造商购买了各种零件故障数据。供应方拥有来源溯源信息（该零件安装于哪款车型），但买方的数据模型无法存储这类信息。结果是只能分别分析零部件，研发部门难以看到“大图景”。
还有两点彼此交织、进一步加剧了上述问题：不清晰的数据所有权与数据质量责任。当数据在各“专责团队”之间流转时，会与其业务语义逐步脱节。集中式数据处理系统/应用的开发者不可能、也不会完全理解数据内容；而离开语义谈“质量”，也无从谈起。
软件工程的其他领域早已识别过类似问题，并催生了领域驱动设计（DDD）与微服务等成功实践。把关注点放在数据所有权与共享工具上的类似思路，应用到数据工程领域，便发展出了数据网格。
1.2.1 替代方案
与数据网格“按领域去中心化”相对，主要有两类替代模式。我们在第 6 章会更细讲，这里先概览一下。
方案一：人和技术都集中。这是任何初创公司的默认形态；就像对软件组件而言，“单体”也是合理的默认。起步阶段，去中心化的成本往往大于收益；同处一个数据团队、只用一套技术，协作与落地都更容易。
关键点：在组织与技术层面，中心化是合理的默认选项。去中心化是有成本的，中心化能在早期对冲这些成本。但这同时假定：集中与分散两种形态下能提取的价值大体相当。
**方案二：按技术拆分而非按业务域拆分。**常见形态是：一个核心数据工程团队负责采集与底层存储平台，多个其他团队（分析、数据科学、分析师等）在下游从原始数据“各显其能”。你也可以先把数据系统中心化，然后在其上叠这种“技术分工”以提升流量。
这两种做法本身都没问题，作为默认选择合理。但它们都难以与价值创造对齐——而价值创造与业务域紧密相关。二者都难以应对单个业务域的突发变化。类似微服务可以单独扩一项服务以快速提取对应价值，数据网格也可以仅在一个域内快速放大价值提取；其他做法则往往需要“全体扩容”，才能在一个域里多拿点价值。
因此，这两种替代方案终会撞墙：再接入一个数据源或再做一个数据科学项目时，你会明显感到复杂度与成本的“断崖式上升”。到了那一步，就应考虑切换到数据网格。
1.2.2 数据网格中的数据仓库与数据湖
关于数据网格有个误解：有人把它当成集中式数据湖或集中式数据仓库的互斥替代。这忽略了数据网格的本质——它同时关乎技术与组织。数据网格反对的是：只有一个中央数据单位在中央存储里打理一切数据。
这并不排除“中央存储 + 去中心化团队”的组合。实际上，在不需要对数据生产者端完全灵活的公司，这很常见；把数据湖/数据仓也放在 BI 或数据科学团队内部同样常见。此时，数据湖/仓只是数据网格中的一个节点。见图 1.3。
图 1.3 数据网格仍可使用数据湖：例如，数据科学团队在构建数据产品时，把数据湖作为网格中的节点来用。
数据网格大量使用数据湖与数仓的多种形态；它总体上不偏好特定技术。相关的二元对立我们在 1.6 节会进一步讨论。此处先聚焦数据网格的收益。
1.2.3 数据网格的收益
我们从两种视角审视数据网格落地的潜力：业务决策者与技术从业者。
业务视角
从业务角度看，数据本身并无价值；甚至意味着成本。听上去像“异端”？要理解并向业务同伴解释这点，需要理解人们理解现实的不同层级。
一个常用的近似是 DIKW 金字塔（数据-信息-知识-智慧），源自 1934 年 T.S. Eliot 的戏剧《The Rock》。它把 Data、Information、Knowledge、Wisdom 视作层级结构，后一层由前一层推演而来。（参考 Anthony Figueroa《Data Demystified: DIKW Model》，mng.bz/v60M）
在这个语境中，“数据”只是一堆值（存它还要花钱！）。要从数据中提取价值，必须为其补足语境，以支持明智决策。数据网格提升了这座金字塔的稳健性。
首先，仅有原始数据对决策者没什么用。理论上他们可以把数据下到本地自行分析——没错！但这隐含两个前提：
1）数据可访问；2）数据应尽可能完整，分析才有价值。
对第一点：我们反复强调，数据网格高度关注数据的可访问性——不仅可访问，还要可发现、可互操作、可复用。这嵌入在四项原则之一： “把数据当产品” ，确保数据“随取随用”。
对第二点：数据完整性也是数据网格的强项。不同于多数数仓/数湖架构里由 IT 脱离业务来定义数据产品与模型，在数据网格里，数据产品由业务域团队与平台协作设计，确保对域外发布的数据足以支撑有意义的结论。
数据网格也有助于金字塔更高层的价值创造。负责把数据转化为信息、知识与“洞见”的团队（企业常这么称呼）可以即时访问多个可互操作的数据源。
理论上，在一个数据湖上也能做到“即时访问”。但现实中，一个团队同时负责技术、权限与数据传输审批，几乎不可能做到；更别说数据散在两个甚至四个数据湖时的跨湖协同。简言之，面向读取优化的数据产品使得快速原型新的分析方法成为可能，也为快速孵化新业务能力打开通道。
技术视角
技术上的最大收益是：随着组织增长，仍能维持开发速度，从而持续产出业务价值。数据网格通过去中心化生产与治理来弥补传统数仓/数湖的短板。后者会形成一个统一瓶颈——中央团队必须为全公司统一与准备一切数据；随着组织诉求多样化，这个团队在技术与知识上都会成为规模瓶颈：维护时间越来越多，新项目越来越拖。
数据网格的另一好处是从数据诞生之初就明确所有权。这使数据管理结构变“扁平”，只保留一层薄薄的联邦式治理，其职责主要是协调各自治域间的标准。
开发加速还来自对实施团队的赋能。因为数据产品的生产与维护由他们负责，变更不再受制于中央集成团队的长队列；因此无论演进还是修复都更快，尤其是故障修复/降本增效。拥有数据产品的团队无需频繁上下文切换，反应自然更敏捷。
此外，数据网格提升了环境稳定性。数据产品对外提供契约化版本的数据访问，基于它们构建的管道更加稳健、低维护。
1.3 用例：清雪生意
Candace 经营着一家清雪公司。她是一位骄傲的女企业家，最初每年冬天都是自己上阵铲雪。几年之后，她扩大了业务规模，把精力放在物流、结算和全业务的定价上，并雇了三名员工：Adam 负责 Pine Road 的住户；Eve 负责 Oak Street 的住户；Bob 负责采购新铲子——因为铲子似乎总是很容易坏。
Adam 和 Eve 在各自街区既负责清雪，也负责拓展新客户。毕竟每年冬天他们在那一带铲雪，和居民接触的时间很多！但 Candace 并不满意。图 1.4 展示了 Candace 业务的初始状态。
图 1.4 在 Candace 的清雪业务中，Adam 与 Eve 负责具体工作，而 Bob 则囤积库存，冻结了资金。
前一年，Candace 让 Adam 和 Eve 记录工作时长和清理的房屋数量。她把这些数据放进一个漂亮的 Microsoft Excel 表里，以便计算并制定价格。图 1.5 显示了这条数据流。
图 1.5 从 Adam 与 Eve 流向 Candace 的集中式数据流，用于决策
可以这样说：Candace 把从 Adam 与 Eve 收到的数据在她的 Excel 里转化为信息，再进一步转化为决策，从而产生业务价值。除此之外，她还让 Adam 与 Eve 估算一下他们需要的铲子数量。图 1.6 展示了流向 Bob 的数据流。
图 1.6 从 Adam 与 Eve，经由 Candace，再到 Bob 的集中式数据流
也就是说，Adam 与 Eve 向 Candace 提供原始数据；Candace 汇总成信息，再交给 Bob 做出决策并创造业务价值。注意这里再次出现了一条管道：一系列步骤把数据转化为价值。定价这条管道有两步（Adam 与 Eve 在工时单里收集数据，Candace 汇总并基于此做决策）；而 Bob 的铲子采购有三步（Adam 与 Eve 产出铲子需求的预测，Candace 汇总，Bob 基于此做采购决策）。
但是，如前所述，Candace 对现状并不满意。利润不太理想。铲子采购总是拿捏不准：有时库存堆积如山，有时 Adam 与 Eve 又因为缺铲子而耽误工作。
今年，读了《Data Mesh in Action》之后，Candace 决定做个实验。她按照书第 3 章的描述为数据网格打基础，并运用第 4 章的方法划定领域边界，把数据所有权交给她的核心清雪领域负责人——也就是 Adam 与 Eve。具体包括：
- Candace 不再收集工时，而是让 Adam 与 Eve 按他们认为合适的方式自行记录工时。
- Adam 与 Eve 各自为所在街区定价。
随后有趣的事情发生了：Eve 把 Oak Street 的价格上调，而 Adam 把 Pine Road 的价格下调。事实证明他们对各自街区的了解确实超过 Candace。Oak Street 的房子都有很长的车道，所以 Eve 需要收更高的费用；而 Pine Road 有个本地小孩在做更便宜的清雪，Adam 为了保持竞争力就需要降价。图 1.7 展示了现在的去中心化数据流。
图 1.7 在 Adam 与 Eve 各自领域内的去中心化数据流
从现在的数据流看，数据→信息→决策（定价模型）这个链条完全留在 Adam 与 Eve 各自的领域里。随着利润增长，Candace 决定更进一步。在实验的第二年，Candace 着手解决采购问题。为此，她让 Adam 与 Eve 直接把可能需要的铲子数量告知 Bob。
为避免反复邮件沟通造成的混乱，Adam 与 Eve 建了一个共享表格。他们定期更新，一旦天气预报或实际情况改变，估算也能及时反映。图 1.8 展示了为 Bob 提供数据的这条去中心化数据流。
图 1.8 由 Adam 与 Eve 的领域去中心化供数，服务 Bob 的决策
在这条数据流中，Adam 与 Eve 现在把数据与信息都保留在自己的领域里。他们尽量向 Bob 提供足够完备的信息（而不仅是原始数据），以便他做出采购决策。Bob 看起来高兴多了。Candace 问他原因，Bob 说：Eve 发现他还需要知道铲子损坏的频率——因为车道更长，Eve 的铲子坏得更频繁。
缩短数据流还带来了一个意想不到的业务收益。过去，Adam 与 Eve 有时会给出偏保守的估算，以免铲子不够；有时又担心 Candace 对“坏了太多铲子”的反应，抱着侥幸心理给出偏乐观的估计。Candace 往往在这些数字上再加一层“安全边际”交给 Bob；但有时她又担心成本过高，会把估计压低。Bob 知道拿到的数字并不可靠，常常凭直觉调整订单（还会对 Candace 说，比如市场上买不到那么多铲子）。为了让公司不至于停工，他不得不建立缓冲库存，结果冻结了资金、增加了仓储成本。现在能直接看到 Adam 与 Eve 的预测，Bob 就能刚好采购到位；年末几乎不留库存，也没有出现铲子断供。
对 Candace 而言，这意味着第二年因成本下降而获得了不错的利润，而且三位员工也都很满意。你应该注意到，真正的根源在于这条“管道” （数据从 Adam 与 Eve 流向 Candace，再到 Bob）。Candace 所做的，不过是把这条管道拆成一两段——这就是去中心化在发挥作用。
事实也就这么简单：在某些场景下，把管道拆开，结果会更好，因为去中心化的各部分（这里是 Adam 与 Eve）更能把数据转化为价值（而整条长管道却做不到）。
大概明年，Candace 会想引入一些治理措施。比如规定更新频率；或者给电子表格做安全防护，以免 Pine Street 的小孩来捣乱。也许她会雇人做一个网站，让客户可以在线预约——那就需要把 Adam 与 Eve 的工时做成数据产品，并通过平台的某个能力把它们和新系统对接。当你已经实现经营性利润时，未来是不是充满可能？
接下来，我们会展示数据网格的四项原则。它们是落地实施的基石。但正如前文所言，我们对数据网格的定义是包容且以业务价值为导向的。因此，你需要自行确定这些原则的优先级与遵循的力度，以实现你的业务目标。就像 Candace 一样，把这些原则当作成功实施数据网格的航标。
1.4 数据网格原则
Dehghani 将当下的数据网格（data mesh）概念总结为四条原则。本书其余部分将聚焦于这些原则的落地细节。下面先对这四块基石做一段概览。
1.4.1 面向领域的去中心化数据所有权与架构
第一条原则是：数据及其相关组件应由最贴近数据的人所有、维护并发展——也就是数据所属领域中的人。这要求把领域与限界上下文（bounded context）的思想引入数据世界，同时在所有权与架构层面推行去中心化。
其核心思路与前述示例一致：领域内的工程师负责提供数据接口，使其他使用者（数据科学家、自助式 BI 用户、数据工程师或系统研发人员）能使用该领域的数据。数据产品工程师应成为单一领域的专家，从而最大限度降低沟通成本与数据误解。
数据必须有清晰的所有者，且不应停留在组织的集中层面。我们应把责任交到最了解数据的人手中：
- 若是源对齐的数据集（贴近业务系统输出），则通常由领域团队负责；
- 若是由多个数据集合成的新数据集，也可能由数据工程、分析工程或数据科学团队负责；
- 如果数据集强烈面向消费侧，则也可能由相应的业务单元负责。
领域（domain） 是对业务的切分方式；组织结构常与业务领域相映射。以 Messflix 为例，可见“分发内容、生产内容、市场与品牌”等领域（见图 1.9）。
图 1.9 Messflix 业务领域简图
领域所有权原则要求：拥有某一领域的团队，同时拥有在该领域内产生的数据。例如，支撑“内容生产”的软件团队，也应对“内容生产数据”负责。那么“对数据负责”意味着什么？
对数据负责意味着：托管并向组织其他部分（其他领域）提供数据集。该团队既是数据的所有者，也应对其管道、软件、清洗、去重与丰富等工作负责。
如同敏捷原则，所有权必须配套自治权才有意义。因此团队应能自主发布与部署其运营／分析数据系统。
如 Messflix 的例子所示，任何企业都由多个领域构成，每个领域往往还可进一步拆分为子领域。遵循该原则，最终会形成一个由领域数据节点互联的“网”。网内的节点可以也应当相互连接：数据可在必要时跨域移动、复制、变形。通常数据会从源数据域（接近业务系统的输出）流向更消费对齐的数据域；后者会将原始数据聚合与转换为更易消费的形态与格式。
在这样的多域／子域互联的网状结构中，只有贴近数据的人才足够了解数据，进而正确处理它。仍以先前示例为喻：“content（内容）”在三个领域里的含义是否相同？理应不同：
- 在“生产内容”领域，既有草稿与创意，也有已进入生产流程的内容；
- 在“分发内容”领域，人们说到“内容”时通常指已成品、可分发的内容。
想象“分发内容”领域的一位开发要去“生产内容”领域拉一份内容清单：他很可能只拉到“已生产的内容”，而这可能偏离需求——需求也许是包含创意、在制、已取消在内的全部内容项，并附上它们的状态。域外人员甚至未必意识到这些都是关键数据点。这正说明：域内人员才是能真正把握并处理本域数据的人。
源数据域通常对外提供反映业务事实的数据与信息，既服务运营（如 REST API），也服务分析。它们应对外暴露领域事件与随时间聚合的历史快照；对后者而言，应确保底层存储对大数据分析友好（如数据湖）。在前例中，“生产内容”领域对外暴露“已生产内容列表”时，即成为一个源数据域。
消费数据域则紧贴消费场景。比如“管理报表与预测”域，或 Messflix 中“内容推荐”域（可作为“分发内容”的子域）。当市场团队将“已生产内容列表”与营销素材（推文等）进行丰富时，这份新列表就滑入了消费数据域。
跨域的数据可以复制，但因服务目的不同，其建模也会不同。于是领域边界往往也会成为数据模型边界。为给团队足够自治，我们不追求全组织唯一的规范模型，而是允许团队按需建模。除源域与消费域外，组织内还可能存在被广泛使用的核心数据域，通常代表关键实体或对象。
当把数据责任分散到组织各处，可获得巨大的可扩展性与可维护性：
- 新增数据集 = 向网中新增一个自治节点；
- 团队只需拥有并维护自己真正理解的数据。
1.4.2 数据即产品（Data as a Product）
第二条原则是：把数据当作产品。这要求把产品思维引入数据管理。
谈到数据，人们往往先想到文件或数据库表，脑海里是带列名的表格。若仅从技术细节出发，容易忽略关键问题：**从组织视角，什么让数据有价值？**反过来：是什么阻碍数据被转化为有价值的决策？
即便数据准备得再好，缺少恰当的说明与上下文，也可能无人发现、无法使用。如果时效性与完整性未知，数据也可能失去意义。因此应将数据视为“产品”——它是一个更大的整体，承载着最终用户体验。
我们的经验是，由数据团队对外提供的数据，应具备典型的“产品特性”：
- 可用质量：借助领域专家保障质量。
- 预判用户需求：理解企业环境，以现有数据管道易于消费的格式呈现，确保可得与易用。
- 可用性与安全性：确保在用户需要时可获得。
- 聚焦用户目标：专注本域不等于闭门造车；应主动寻求协同与共用工具，增进对彼此需求的理解。
- 可发现（Findable） ：数据产品应可被轻易发现，而不是“数据库里的一张无名表”。
- 可互操作（Interoperable） ：不同数据产品可组合，从而增值。
何时可称“数据是产品”？
日常生活中，“产品”通常指有意识产出的结果。以牛仔裤为例：它应有既定的形制、唯一的名称（同厂商不同型号需能区分），满足耐用与安全等标准，并有明确的负责人对质量与使用后果负责。对数据也应做同样的思考。
把数据当产品，意味着：有人为之进行过有意识的设计、创建与发布，对其负责，尤其对其质量负责。在数据网格中，这通常是数据产品负责人（owner）与数据产品开发者的职责。类似商店货架上的产品，数据产品也应有唯一名称与既定特性，例如：
- 质量等级
- 可用等级
- 安全规则
- 更新频率
- 具体内容范围
以产品视角思考，不只是把数据“摆出来”那么简单，还要尽量提升终端用户可用性。在此，数据产品负责人至关重要——他／她对数据的最终用户体验负责。
回到 Messflix 的“生产内容”领域，可设想一些示例性数据产品：
- 成本报表（Cost statement）
- 剧本（Scripts）
- 演员阵容（Cast）
- 影片热度（Movie popularity）
- 影片趋势（Movie trends）
“数据即产品”把我们直接带到产品思维路径：从“客户要解决的问题”出发，驱动数据产品设计；作为数据产品负责人，你需要依据预设的成功标准交付能真正解决问题的产品。
同时，“数据即产品”也暗含一定的标准化，以便其顺利融入更大的数据网格生态。要称之为数据产品，应具备：
- 自描述且可发现：产品应带有自身描述，并能在网格生态中注册，从而被发现。
- 可寻址（Addressable） ：具备唯一地址（如 URI），可被引用，并能建立产品间关联。
- 可互操作（Interoperable） ：遵循既定标准（共享形式、格式、词汇、术语／标识、安全与可信等），满足并声明SLA，并提供受控访问，以保障知识产权与法规（如 GDPR）合规。
作为自治组件的数据产品
在满足上述条件的同时，数据产品本身应是一个可由负责团队独立演进的自治组件。从技术实现看，它近似数据世界里的一个微服务：除对外提供数据外，还内嵌与转换、清洗、对齐相关的代码；并通过接口与数据网格环境与平台自动集成，例如提供：
- 输入逻辑与输出端口：从源摄取、向消费者暴露数据的形式与协议。
- 运行度量：用户数、吞吐量、拉取数据量等。
- 数据质量报告：缺失数据量、格式不兼容、异常值统计等。
- 元数据：模式规范与说明、领域描述、业务所有权等。
- 配置端点：运行期配置能力（如设置安全规则）。
以上仅是构成“数据产品”这个技术组件的若干示例要素。
1.4.3 联邦式可计算治理（Federated Computational Governance）
第三条原则，是在数据网格的所有参与方之间联邦化并自动化数据治理。其目标是在大体独立的数据产品生态之上，提供一套统一的框架与互操作能力，让各自治的数据产品不仅各自可用，而且在网格中协同工作。
联邦式可计算治理包含两个不可分割的要素：治理主体与规则执行机制。全局性的规则与规范应由一个治理机构共同制定，该机构由数据产品负责人、自助式数据基础设施平台团队、安全专家以及 CDO/CIO/CTO 的代表组成。该机构同时也是讨论议题的场所，例如：是开发新的数据产品还是给现有数据产品补充新数据集、如何引入新的外部数据源、以及中央平台的优先级等。
数据治理之所以关键，其中一个重要原因是：数据安全是各行业、各规模企业的 CDO/CIO 的核心关切。此外，多数大型企业还必须满足政府或行业法规对数据安全与治理的要求，例如 GDPR、HIPAA、PCI DSS 与 SOX 等。
数据治理的联邦化
乍看之下，在原本就很广的治理范围上再叠加数据网格，似乎会增加复杂度：责任被下放到数据产品层面，而每个数据产品都需要一套流程，来安全、高效地处理其基础设施、代码、数据与元数据。同时，治理流程还要在公司级统一性（通常依赖标准化实现）与团队自治带来的灵活与创新之间取得平衡。
务必认识到：没有银弹可以一次性解决“中央治理 vs. 本地自治”的平衡问题！做法始终取决于你组织的具体情况：
— 你们的数据产品负责人需要什么、成熟度如何？
— 组织对数据相关风险的偏好如何？
— 中央数据治理团队的专业能力处于何种水平？
— 你们处理的数据敏感度如何？
在厘清这些问题前，无法明确中央与本地团队的责任边界。
另一方面，还需要一组策略来确保数据产品之间的互操作，以及消费者可以便捷地将多个产品拼接组合。最后，这些流程应保证不同数据产品之间的兼容性，而无需强推一个全域的“总线数据模型” ——后者在实践中往往形成数据运营瓶颈。
数据网格用联邦化治理来回应这些需求：在中央与本地两个层级上建立对等运作的治理结构。中央层（可称为数据治理委员会；本书第 3 章也称其为“数据治理团队”）只制定一套最小全局规则集，以确保数据产品的可安全发现与可互操作。
各数据产品团队（由数据产品负责人带领）在此边界内，保持高度自治，自行决定技术与流程问题（在企业技术栈范围内）。至于中央与本地的职责划分、治理委员会的组织形态与具体规则，并不存在放之四海而皆准的答案——每家企业都会形成自己的全局规则，给领域团队留出不同程度的自主空间。第 4 章将讨论不同自治级别对团队敏捷性与系统复杂度的影响。
数据治理的“可计算”要素
“联邦式可计算治理”一词由 Dehghani 在其事实上的数据网格宣言中提出（参见博文 Data Mesh Principles and Logistical Architecture，mng.bz/44rV）。由于“可计算治理”在其他地方并无统一定义，本文将其理解为：借助中央平台（自助式基础设施作为平台，1.4.4 小节与第 7、8 章详述）对治理要素进行自动化，并以平台为介质连接不同数据产品。
可被自动化并内嵌进数据平台的数据治理要素包括但不限于：
- 元数据（Metadata）
- 目录、参考数据与主数据（Catalog / Reference / Master Data）
- 数据血缘与来源溯源（Lineage & Provenance）
- 校验与验证（Validation & Verification）
- 存储与运维（Storage & Operations）
- 安全与隐私（Security & Privacy）
同样，没有银弹来决定哪些要素应该自动化。团队需要识别哪些治理任务正在成为你们数据网格推进的瓶颈，并将其自动化。自动化的收益在两方面显著：
- 为数据产品负责人提供低摩擦的连接方式，让产品快速接入平台；
- 让使用者能够高效利用已暴露的数据。关于如何自动化这些要素，下一小节讨论“自助式数据基础设施作为平台”的细节时会进一步展开。
1.4.4 自助式数据基础设施作为平台（Self-Serve Data Infrastructure as a Platform）
第四条原则，是将数据网格中被重复实现的共性工作抽取出来，沉淀为平台能力。这要求把平台化思维应用到数据场景：凡是在公司内部被大量重复的工作，都应被一次建设、服务多方。
就像任何人都可以在主流公有云上租用资源并按需定制，无需重复自建与维护整套“私有云”，这一思路也可以在公司内部落地。构建与维护数据产品资源消耗大、技能跨度广（从算力环境管理到安全合规）。如果把这份投入按数据产品数量线性放大，整个数据网格方案将难以为继。中央平台的作用，是在适度集中可复用、可泛化的动作，同时提供抽象专门技能的一揽子工具，降低数据产品开发者与消费者的进入与使用门槛。
你可以从首批数据产品负责人的需求出发，迭代式地扩展平台以适配组织需要。平台既可部署在本地数据中心，也可运行在公有云，或采用混合模式；其能力形态可包括 IaaS / PaaS / SaaS 或它们的组合。一个数据网格平台可以支持如下方面：
- 可治理性（Governability） ：与数据治理相关的所有计算与流程都应被纳入平台，并在连接到平台的每个数据产品上自动执行。
- 安全性（Security） ：平台应确保在授权访问下，数据产品为用户提供足够的操作自由，同时防止未授权访问。应向产品创建者与使用者提供一套开箱即用的流程、工具与制度。
- 灵活性、适应性与弹性（Flexibility / Adaptability / Elasticity） ：平台需要支持多类型业务域数据，这意味着要支持多样的存储方案、ETL 与查询、部署形态、处理引擎与管道编排，并具备可扩展性以应对业务增长。
- 韧性与高可用（Resilience） ：数据驱动业务要求高可用的数据服务；因此平台在各组件设计层面应内建冗余与容灾机制。
- 流程自动化（Process Automation） ：从数据产品注册时注入元数据，到访问控制与质量监控，平台内的数据流转应尽可能全自动化——在可行场景下可引入 ML/AI 提升处理、质量与监测效率。
至此，四条数据网格关键原则已做了概要回顾。接下来，让我们回到 Candace 的故事，看看她在这些原则上的“成绩单”如何。
1.5 回到铲雪的故事
在 Candace 的生意里，你大致可以识别出若干“专家型领域”。铲雪工具（铁锹）采购显然是一个领域，而两条街（Pine Road 与 Oak Street）看起来也分别构成各自的领域。它们在若干关键要素上确实不同，要想高效开展工作，需要本地知识。看看这门生意是如何随时间演进的：
- 第一年：团队虽然在各自领域内对运营负责、也会产出领域数据，但并不拥有这些数据。没有提到任何数据治理，也缺少能帮助他们处理数据的平台。数据只是他们工作的副产物。
- 第二年：Candace 做出关键改变——把各自领域内的数据所有权下放给 Adam 与 Eve；她总体上也扩大了他们的职责。这在很多公司里，往往是将数据所有权下放之前会发生的事。不过，这时依然没有数据治理或平台，数据也还没有被当作产品来对待。
- 第三年：Candace 基本上要求 Adam 和 Eve 不仅为自己使用数据，也要把数据当作能服务他人（此处即 Bob）的数据产品来建设。Bob 终于拿到了合格的数据产品，也因此能够优化成本。
小结：Candace 主要抓的是去中心化的数据所有权与数据产品思维两条原则。由于她的业务规模很小，除了和员工沟通如何在决策中使用数据之外，并不需要太多治理；她也不必建设庞大的平台（甚至不需要任何“中央平台”，或许邮件就够了），因为眼下还没有大量需要相互连接的数据产品。
要点：价值的核心在于去中心化，而不是一定要一次性落实四条原则。我们认为，数据网格的本质，就是把数据所有权下放到某种自治单元里——这个单元可以是一名个人、一个部门，或其他形式，视情形而定。四条关键原则是指导方针，帮助我们把这件事做好。
我们相信：无论企业大小，只要你感到去中心化的“拉力”在增强，数据网格之旅都可以开启。第 2 章会更深入展开。
要点：数据网格适用于各类规模的公司，但这不意味着它在任何阶段都是正确工具。在某些阶段，它也可能并不适合（同样与规模无关）。第 2 章会讨论如何做出选择。
那么，为什么 Candace 会感到这种去中心化的“拉力”？为什么你也可能在某个时刻感到同样的“拉力”？
1.6 社会—技术架构
数据网格不是一套单纯用技术来解决数据问题的方案。数据网格依靠一种社会—技术（socio-technical）架构/系统设计来解决问题。我们认为，这正是数据网格作为一种范式的最大优势；实践中，你应把社会—技术架构视为数据网格落地的基石，并且要有意识地运用它，才能取得成功。
在此之前，你需要理解它意味着什么、起源何处，以及它背后的基本法则。因此，我们先看 Conway 定律，以理解为何单靠改变技术“自身”并不可行；随后看 Team Topologies（《团队拓扑》） 框架——本质上，它谈的就是社会—技术架构；最后，我们讨论支撑该框架的一条核心思想：认知负荷。
1.6.1 Conway 定律
Conway 定律的表述如下：
任何设计系统（广义）的组织，都会产出一种结构，映射为该组织的沟通结构。
计算机程序员 Melvin Conway 在 1968 年的论文（mng.bz/Qv9j）中提出了这一观察——也就是 Fortran（第一个被广泛使用的高级语言）发布后的第十年。我们很快就能在实践中看到这股强大的“引力”：我们的体系结构迟早会被“拉扯”成与组织沟通结构相似的样子。作为架构师，我们必须清楚其隐含后果。
这有点像武道中的合气道（Aikidō） 。“合气（Aiki）”指的是顺势而为、借力打力的原则：不要以硬对硬，而是利用对方的力道来控制局面。同理，我们也应当顺应并利用 Conway 定律，而不是与之对抗。
示例：中央数据仓库
Conway 定律很好地解释了为什么人们嘴里说“中央数据仓库”，潜台词往往是“由中央数据团队运营的中央数据仓库”。因为在现实里，只要你看到中央数据仓库，背后通常就会有一个中央数据团队。
Conway 定律告诉我们的，是要同时照顾组织侧与技术侧。只改技术而不动组织，往往达不到预期效果：组织最终会把自己“塞进”那套新技术的缝隙里，迫使技术重新长成组织的模样。
1.6.2 团队拓扑（Team Topologies）
在社会—技术架构的方法中，顾名思义，我们尝试同时共同设计“社会层面”（组织、团队、协作）与“技术层面”的架构元素。这样做可以在一开始就把各种约束与关切考虑进去。
本节介绍当下在数据网格社区中被广泛用于做好社会—技术架构的核心方法——Team Topologies（团队拓扑） 。其官网将其描述为：“一种清晰、易于遵循的现代软件交付方法，强调为流动（flow）优化团队交互”（teamtopologies.com）。Team Topologies 由 Matthew Skelton 与 Manuel Pais 提出，因其简单直接、便于落地而在社区中获得越来越多的关注。
Team Topologies 的目的，是帮助你避免落入 Conway 定律的陷阱。该框架旨在为“最优流动”来优化公司内部团队的组织方式，它高度依赖“认知负荷”这一理念，以便沿着端到端的价值流合理地切分工作；同时将团队类型简化为少数几类，并将团队之间的交互模式限定为有助于最小化认知负荷的几种。由于 Team Topologies 关注的是公司的整体流动性，它同样能够帮助我们优化企业内部“数据到价值”的流动。
1.6.3 认知负荷（Cognitive load）
“认知负荷”源自认知负荷理论，指个体所使用的心理资源/工作记忆的多少。最初该理论用于教育领域，影响了我们编写指引/教材的方式，使读者更易于吸收；后来被应用到更广的场景，包括 IT 领域。
作为社会—技术架构师，我们应当塑造团队，使其总体认知负荷受限，并且把主要的心智资源留给真正创造价值的活动。这就像公路交通：如果把每一平方米道路都塞满卡车、汽车和自行车，你不可能让车流最大化；只有车辆之间保留足够的间距，才能接近限速高效通行。团队亦然。
如何让数据网格团队高效？
首先，规划一套与团队能力相匹配、尽可能简单的技术栈。其次，拥抱平台化思维，避免让团队一次次从零折腾监控、日志等通用能力。二者兼顾，团队就能把精力完全聚焦在本业务领域；为进一步聚焦并避免过载，还应将大的领域拆解为更小、更聚焦的领域型数据产品。
数据网格的所有原则都深受社会—技术思维影响：
- 面向领域的去中心化数据所有权与架构：通过把责任分散到各领域及其数据，降低团队负荷。
- 数据即产品：让数据可发现、可访问、可互操作、可复用，并以预期且已知的格式与端口对外提供，减少团队间为取数而进行的协作成本与心智负担。
- 自助式数据基础设施平台：提供自助能力，压缩通用性工作占用的认知负荷。
- 联邦式计算治理：以统一的标准与模式来简化跨团队协作；同时通过收敛公司内部的技术栈，便于人员在团队之间流动。
可见，每条原则的核心都是社会—技术式的思考。正因这是一场社会—技术层面的范式转变，我们需要清晰认识其可能带来的收益。同时，尽管数据网格可以解决许多问题，它也伴随一些重大挑战——接下来我们将逐一展开。
1.7 数据网格的挑战
数据网格既不是银弹，也不是即插即用的方案。要想成功落地，必须跨越一系列障碍。本节从技术、数据管理与组织三个方面展开。
1.7.1 技术层面的挑战
最关键的技术挑战，是要同时为面向领域的团队与中心平台团队提供合适的工具链。仅仅提供数据可发现性和域间链接还不够，这样做很容易让整个生态演变为各自为政的数据孤岛。
另一项挑战，是确保本地开发的工具能够在不同领域之间复用。团队的灵活性与自治不能以公司层面的低效与协同下降为代价。为了高效地开发与运维各自的数据解决方案，领域数据团队需要对数据存储与计算服务拥有安全可靠的访问。例如，将云环境的运维集中化，通常比把这份工作分散到每个团队更高效；集中式的云存储与计算控制也有助于建立合理的成本管控。我们屡见不鲜的情况是：多个相互独立的团队各自都在“理性”花钱，但合起来的总成本远超公司可以接受的水平。
随着出现大量分布式、半独立的数据产品，想要建立一致的监控、告警与日志体系也会变得更难。因此，平台团队与领域团队必须密切协作，持续掌握并控制数据质量、安全与运维效率。
1.7.2 数据管理方面的挑战
与前述技术挑战类似，首要的数据管理挑战，是确保数据易于定位且具备完善文档。数据目录的重要性怎么强调都不为过。虽然这并非数据网格独有的问题，但在去中心化的范式下，忽视它的后果会更严重。不可能再指望一个中央数据团队临时去识别所有可用的数据资产（即便在数据湖里靠临时查询内容，本身也不是一种合适的交互方式）。
另一个挑战，是控制跨域的数据重复。当越来越多的业务域需要复用并再加工相同的数据时，冗余会不可避免地出现。这不仅推高存储与管理成本，还会带来血缘与版本问题——数据消费者可能在使用过时、不完整或已被修改的数据，进而得出误导性的结论。
第三个挑战并非数据网格所特有，但在开启数据网格之旅时必须铭记：那就是跨域分析。由于分析师与数据科学家无法直接使用一套全企业统一的数据模型，他们可能需要额外的平台来汇聚与整合多个数据产品。对分布式数据源开展工作，还可能导致**“意大利面式”数据管道**，削弱效率与复用性。跨域访问同样对数据保护与访问控制提出挑战：多对多的关系意味着需要同时访问多个数据产品。
1.7.3 组织层面的挑战
在数据网格语境下，组织挑战大致可分为三类：实施范围、数据实践与文化。
首先，是范式迁移的范围。数据网格需要来自多个业务领域的相关方——IT、业务部门与高层管理——进行协同推进。
其次，是多方对数据处理的成熟度。无论是中心职能、数据创建者、管理者还是使用者，都需要学习并达到一定的数据素养与熟练度。
第三，在大多数企业中，从“数据是副产品”转向“数据是产品”，是一场重大的文化变革。这不仅涉及数据工程与 IT 部门，也会影响到产品、管理、市场、销售以及几乎所有与数据打交道的部门。
要实现决策去中心化、设立数据产品负责人岗位、打造多职能跨域团队并重塑职责边界，往往意味着需要对现有组织架构进行较大幅度的调整，而且这会带来时间、脑力与资金方面的成本。
联邦式治理也要求打造全新的流程——从决策机制到沟通方式。相关职责与原则必须被清晰识别并进行联邦化分配。
随着本章结束，你应当已经将数据网格理解为一种技术与组织并重的范式（以及其底层原则）。在第 2 章中，我们将展示如何在一个月内在你的组织里搭建数据网格的雏形。
小结
- 数据网格的基石是去中心化——把数据的所有权与责任下放到更接近数据源的地方。其目标是让数据始终与业务主题保持同步，消除长链路与中央团队带来的瓶颈。
- 数据网格是一种社会—技术架构范式，基于四项原则：面向领域的数据所有权、数据即产品、联邦式计算治理与自助式数据基础设施平台。
- 面向领域的数据所有权：数据及其相关组件应由最了解它的人（领域内的人）来拥有、维护与演进。
- 数据即产品：面向外部有意识地设计产出，明确角色分工以保证可用性与质量，并保留足够自治去实现这一结果。
- 联邦式计算治理：其一，治理责任在中央机构（制定公司级政策与标准）与高度自治的领域团队（负责具体系统）之间分层分权；其二，在可行处应通过自动化来执行规则。
- 自助式数据基础设施平台：把数据网格中重复出现的共性工作抽取为平台能力，一次建设、多方复用。
- 数据网格不是精确规定的单一解法。四项原则在不同场景下的适用范围与执行力度会有很大差异，应结合业务实际灵活裁剪。
- 在评估与实施数据网格时，必须充分考虑技术、数据管理与组织层面的主要挑战。
