数据网格是一种去中心化数据架构，具有四个特定特征。首先，它要求指定领域内的独立团队拥有他们的分析数据。其次，在数据网格中，数据被视为产品，以帮助数据使用者发现、信任并将其用于任何目的。第三，它依赖于自动化基础设施的配置。第四，它使用治理机制来确保所有独立的数据产品都是安全的，并遵循全球规则。
虽然构成数据网格的概念并不新颖，但Nextdata的首席执行官兼创始人Zhamak Dehghani值得赞赏，因为她创造了"数据网格"这个术语并结合了这些概念。尽管其他人对数据网格的定义有不同看法，但本书将其定义基于Dehghani的工作，特别是她的四个数据网格原则，本章将对此进行讨论。非常重要的一点是要理解数据网格是一个概念，而不是一种技术。这完全是关于公司内部的组织和文化转变。用于构建数据网格的技术可能遵循现代数据仓库、数据编织或数据湖架构，甚至不同的领域可以采用不同的架构。
在本章和下一章中，我们将深入探讨数据网格架构的微妙世界，提供了一个在分散化原则基础上导航复杂数据网格景观的路线图。在本章中，我将解剖分散式数据架构，澄清围绕数据网格的热点问题，并阐明其四个基本原则。我们将深入探讨纯数据网格的本质，并穿越数据领域的复杂性，然后发现支持基础设施的逻辑架构和各种拓扑结构，并对数据网格和数据编织进行对比。最后，我将讨论数据网格的适用案例。
在第14章中，重点关注实施数据网格可能面临的挑战，揭示常见误解，以协助组织在决定是否采用数据网格时进行明智的决策。接下来，我将讨论进行组织评估，以确定采用数据网格是否与您的组织需求保持一致。然后，我将深入探讨实施成功数据网格的建议，确保过渡顺利，并获得最大的收益。然后，我将展望数据网格在不断发展的数据景观中的预期轨迹，并讨论何时使用四种架构：现代数据仓库、数据编织、数据湖架构和数据网格。
加入我，解开数据网格架构的复杂性，为您提供对其分散式框架的深入而简洁的洞察。
去中心化架构
迄今为止，我在本书中谈到的数据架构------现代数据仓库、数据布局和数据湖屋------都是集中式架构，所有分析数据都由IT团队创建和拥有。数据网格与其他数据架构的一个重大区别在于，它是分散式的。这意味着数据以及用于管理数据的所有内容都由组织内的各个团队或"领域"拥有和管理，并按业务领域进行分组，而不是由中央机构或IT单个团队管理。这些领域团队负责收集、处理和管理自己的数据，并且有权自主决定数据的使用和共享方式。数据保留在领域内；最终用户可以在数据所在的地方访问和查询数据，而无需将其复制到中央位置。这增加了责任感，并确保数据由最了解它的人员管理和维护。
这解决了集中式架构的主要问题，即组织和技术的扩展。随着公司的发展和需要快速集中更多数据，IT往往会超负荷，成为一个瓶颈。
当我谈到本书中所有其他数据架构都是集中式时，我指的是这些架构的各个方面。不仅中央IT团队拥有和控制数据，该团队还负责：
- 整合来自不同来源的数据
- 将数据存储在自己拥有的集中位置
- 构建数据模型并将其存储在中央存储库中
- 管理和遵守治理和合规性，包括定义和执行数据质量、安全性和隐私标准
- 创建和维护数据管道和转换逻辑
- 通过分析、验证、清洁和其他流程强制执行数据质量
- 优化性能
- 管理所有计算技术
- 管理分析和报告工具
- 存储和管理元数据
- 灾难恢复和备份
此外，在集中式架构中，硬件和处理能力是为纵向扩展而设计的。
数据网格的炒作
数据网格自2019年首次提出以来吸引了很多关注。Gartner有一个著名的数据管理"炒作周期"，根据当前的采用水平和达到主流采用所需的年数来衡量技术的成熟度。在其2023年的数据管理炒作周期中，它将数据网格排在了炒作周期的顶部（接近"过度期望的顶峰"），在受益评级上则为"中等"。数据网格的市场渗透率为5%到20%，有趣的是，Gartner预测"数据网格将在平台之前变得过时。随着组织开始收集被动元数据，实践和支持技术将向数据编织发展。"
许多炒作数据网格的人会声称数据仓库项目的失败率非常高，不可持续，并且无法处理大数据，因为它们无法扩展。随着所有的炒作，你可能会认为构建数据网格是解决所有这些与数据仓库"问题"的答案。事实是，虽然数据仓库项目确实失败了，但很少是因为它们无法扩展到足以处理大数据，或者因为架构或技术不够强大。失败几乎总是因为人员和/或流程存在问题，或者组织选择了完全错误的技术。有时我觉得数据网格是在寻找问题的解决方案，而炒作数据网格的人把管理和集成数据的整个挑战过于简单化了。
我见过大数据解决方案多年来非常成功地运行，而没有数据网格，从20世纪80年代末（当时一兆字节被视为"大数据"）到今天的数据宝宝字节。技术没有停滞不前。集中式数据架构和云产品完全有能力处理任何数量的批处理和流处理数据。这些解决方案几十年来一直为大数据工作。我们为什么要假设它们在未来不起作用呢？
当然，这都是猜测。数据网格还很新，但显然并不是每个人都相信炒作。我属于怀疑论者的阵营。我从事数据库工作已有35年之久，数据仓库工作已有15年之久，见过许多被大肆炒作的技术来来去去。虽然我不认为数据网格会过时，但我不相信任何公司会构建"纯粹"的数据网格。少数公司会构建修改后的数据网格，其余公司将使用其他架构。
我很少见到公司将修改后的数据网格投入生产。许多公司声称已经这样做了，希望显得尖端，但大多数情况下实际上是数据编织或数据湖。但即使对"数据网格"的解释非常宽泛，构建该架构的公司也非常少。当我谈论数据架构时，我总是问听众："有多少人听说过数据网格？"通常至少有75%的人举手。然后我接着问："有多少人正在构建数据网格？"也许在一百人的人群中会有一两个人举手。然后我再问："有多少人正在生产中使用数据网格？"我还没有看到一个人举手。其他同事也报告了类似的经历。尽管这是个人经验，但似乎表明数据网格并没有达到炒作的期望。尽管如此，数据网格架构具有许多积极的方面，可以改善任何其他数据架构。本章和下一章将详细解释。
Dehghani的数据网格的四大原则
数据网格试图解决集中式数据架构的四个最大挑战：缺乏所有权、低数据质量、技术扩展和组织扩展。Dehghani提出的四项原则解决了这些挑战。让我们依次来看每一项。
原则1：领域所有权
第一项原则建议将责任分散和分配给与数据最接近的人，以支持持续变化和可扩展性（例如制造、销售、供应商）。
在集中式架构中，通常会出现对"谁拥有"分析数据的混乱（或者在一些会议上，会有激烈的争论）。 大多数源数据是由自制的运营系统、诸如Salesforce和Microsoft Dynamics之类的CRM工具，以及诸如SAP和Microsoft Dynamics之类的企业资源规划（ERP）工具生成的。这些特定领域的系统和应用由专门的运营人员运行，这些人通常几乎不与中央IT数据平台团队交流。通常，这些运营人员并不知道"他们"的数据被发送到数据平台。
当数据位于操作性数据库中时，它属于拥有该数据库的操作领域。当它被复制到集中式数据存储（通常是数据湖）时，IT通常拥有它，但一些人认为它仍应属于该领域。 至于中央IT数据平台团队，他们很少对操作系统或业务应用的运行方式有坚实的了解。他们对数据了解不多，对数据是如何生成的或实际含义是什么没有上下文。他们只看到表和字段名称或文件。因此，他们在生产高质量数据和可用分析方面存在困难。
数据网格的第一原则---领域所有权---解决了这个挑战。负责操作数据库的人员始终是分析数据的所有者，他们负责管理和维护数据。责任和所有权分散和分配给了与数据最接近的人员，以支持持续变化和可扩展性。这些人员根据业务领域进行分组，例如制造、销售或供应商；定义公司的领域可能是具有挑战性的。每个领域都拥有其操作和分析数据。
原则2：将数据视为产品
第二项原则建议将由领域提供的分析数据视为产品，并将数据的使用者视为客户。每个领域都有领域团队、API代码、数据和元数据以及基础架构。
在集中式架构中，IT团队拥有分析数据，因此负责数据质量---但他们通常对数据了解不多，并且可能在转换数据时犯错。另一方面，领域团队深入了解数据及其在业务领域内的上下文。这种了解使他们能够识别和解决中央IT团队可能忽视的数据质量问题，因为中央IT团队在理解业务需求方面缺乏上下文。
数据网格的第二原则是，与其将分析数据视为输入、资产或过程的副产品，数据所有者将数据视为完全独立的产品，他们负责这些产品。他们将数据的使用者（数据用户、数据分析师、数据科学家）视为客户。这意味着领域团队将产品思维应用于其数据，以确保数据易于发现并且可信、可访问、安全和可理解。
将数据视为产品的第一步是明确了解组织中的数据产品是什么。数据产品是可独立部署的自包含数据单元，提供业务价值。它包含源自操作或交易应用程序的分析数据。它由单一产品团队设计、构建和管理。
第三原则：自助式数据基础设施作为平台
第三项原则建议通过自动化基础设施提供（例如存储、计算、数据管道和访问控制），简化数据产品的创建和管理。 正如本章开头所提到的，在集中式架构中，中央IT团队可能成为一个瓶颈，使得有效扩展变得困难。这个团队建立和监视着所有的架构，包括存储、计算、数据管道和数据访问策略。通常，他们没有足够的人手及时提供数据。
在数据网格中，因为每个领域团队拥有其领域数据并将其数据视为产品，所以它需要自己的工程团队和基础设施来构建、部署、监控和提供对其数据产品的访问。这扩展了领域团队的责任，从构建运营应用程序扩展到包括构建分析和创建共享数据解决方案。简而言之，数据网格的前两个原则增加了领域工程团队的额外工作量。而这一原则就是为了减少这种工作量。
领域团队可能对管理、组建、监督和支付开发和管理其数据产品感到沮丧。为了避免挫折和阻力，你需要为他们提供一条"捷径"，以克服一些额外的工作。你也不希望每个领域都从头开始构建自己的基础设施；在每个领域中"重新发明轮子"通过复制努力将会显著延迟数据网格投入生产，增加成本，并增加领域间的大规模不一致性和不兼容性的风险。
为了防止这些问题，应该由专门的中央平台团队构建一个数据网格平台。并非数据网格中的所有内容都是去中心化的。该平台必须实现领域工程团队需要的所有工具和接口，以简化构建、测试、部署、安全、维护和共享数据产品的生命周期，无论是与消费者还是与其他数据领域。领域团队不应该担心底层基础设施资源的提供。你可以通过公开一组标准化的平台API或脚本，供数据产品开发者使用来陈述其基础设施需求。然后你可以让平台处理存储、计算、数据管道和访问控制的创建和管理。这将导致一种标准化的方式来创建数据产品、保障数据产品、找到数据产品、连接数据产品以及读取数据。在数据网格中，领域工程团队由通用技术人员组成，而不是专家，因此通过数据网格平台减少复杂性可以使他们有更多的空间来创新其数据。
这一原则的目标是节省成本、减少复杂性、减轻领域团队的负担、减少技术专业化的需求，以及自动化治理政策。
第四原则：联邦计算治理
第四项原则规定，领域之间和中央数据团队之间存在协作的数据治理，以定义、实施和监控全局规则（例如互操作性、数据质量、数据安全、法规和数据建模）。
在集中式架构中，数据治理比在数据网格中容易得多，因为采用集中式架构方法，只有一个中央数据团队拥有所有数据，并定义、实施和监控所有数据治理。然而，这种集中化的方法经常导致瓶颈，拖慢决策过程，限制各个领域对变化条件和特定情况的迅速响应能力。它也可能导致局部专业知识和上下文理解的缺乏，因为中央团队必须管理各种各样的数据，而没有深入了解每个领域的细微差别。
在数据网格中，中央数据团队定义并监督所有数据治理标准和政策，包括数据质量、数据安全、法规和数据建模等内容。中央数据团队由领域代表和主题专家（对合规、法律、安全等方面）组成。然而，实施和监控数据治理留给了领域，因为他们拥有数据并最了解数据。 将责任分配到多个领域团队可能导致不一致性和冲突做法的潜在问题，从而导致运营效率低下和复杂性增加。领域可能为数据质量实施不同的标准（例如使用美国州的全名与两个字母的邮政缩写）。他们可能使用不同的安全系统或数据建模技术。但并非所有的治理规则都可以全局设置；一些是特定上下文的，真正应该由领域设置。例如，中央数据团队可以指定用户必须经过身份验证，而领域团队则定义每个用户可以访问的数据产品。
这种不一致性可能导致糟糕的数据、人们看到他们不应该看到的数据，以及其他问题。集中式系统通常在尝试实施一揽子政策时遇到这些细微差别，这可能导致不一致性，并未满足不同部门或部门的特定需求和要求。
这就是为什么联邦数据治理的概念对于保持组织的一致性和安全性至关重要，它结合了集中化监督和领域特定的自治。希望能在领域独立性和中央数据团队监督之间取得平衡。在可能的情况下，自动实施和监控政策以及为更容易识别的标记数据，都有助于解决这些问题。
"纯" 数据网格
现在您了解了这四个原则，请看图13-1。它展示了一个使用这四个原则的高层数据网格架构。前两个原则是分散的，每个领域都使用自己的IT团队和基础设施创建分析数据。但是另外两个原则需要中央团队，一个用于实施数据基础设施平台，另一个用于实施所有领域共享的治理。
那么，什么是真正的数据网格？这就是困惑的起源。关于何时可以称为数据网格解决方案没有普遍的规则。
如果一家公司构建了一个完全遵循所有四个原则的数据网格，我们都会确信称该解决方案为"纯"数据网格。但是如果解决方案只使用了三个原则呢？我们还能称之为数据网格吗？如果只使用了两个原则呢？
如果解决方案使用了所有四个原则，但方式并未完全满足原则的所有要求呢？例如，您可以遵循原则#2，但是让各个领域共享相同的基础设施，通过将一个物理数据湖逻辑地分隔为只能由各自领域访问的领域特定文件夹，或者通过将多个领域分配给少数几个计算集群。另一个例子是，使用原则#3，中央IT可以提供帮助构建领域存储和管理的脚本，但将领域的其余基础设施建设交给领域自己来完成。再考虑一个：对于原则#4，中央IT可以制定数据安全和规范标准，但让领域自行监测合规性，并允许其自行进行数据质量和建模。
有些公司构建了一个只部分实施了两个或三个原则的解决方案，并称之为数据网格。其他人为每个领域创建了单独的数据湖，并说他们已经构建了一个数据网格。然而，仅仅通过业务部门对数据进行分组或将数据组织成领域并不是数据网格。即使假设他们已经正确设计了他们的领域（下一节的主题），该方法也只适用于原则#1，而不适用于其他任何原则。
一些供应商会告诉您，如果使用他们的产品，您将拥有一个数据网格，即使数据网格与组织和文化转变有关，而不是技术有关。我甚至听说过有人说，要创建数据网格，您只需要使用虚拟化软件连接所有数据湖和数据仓库！这并不考虑任何四个原则。
正如您所看到的，每个原则内部可能存在许多"例外情况"，用于纯数据网格。对于一个解决方案来说，要被认为不是数据网格，需要多少例外情况（将其视为最小可行网格）？如果四个原则没有被普遍接受，我们甚至无法尝试回答这个问题。我们是否应该完全遵循Dehghani的定义，还是根据行业其他人的反馈进行调整？我们是否需要一个行业委员会来提出数据网格的修订定义？我们如何避免仅基于自身利益的反馈？
我恐怕没有所有答案。我希望本书通过提供一些关于常见数据架构概念和先前数据网格的架构的清晰度，开启一场健康的讨论。
Data Domains
设计面向领域的架构的过程被称为领域驱动设计（DDD），这是非常困难且耗时的。DDD起源于软件设计，但在处理数据时变得更具挑战性。第一步是定义领域在公司背景下的含义。
根据德加尼的第一原则，分析数据应该由最接近数据的业务领域拥有，这些领域可能是数据的来源或主要使用者。她定义了三种类型的面向领域的分析数据：
- 源对齐的领域数据：源对齐的领域数据是与数据来源紧密对应的分析数据，数据从源应用的操作性数据库复制到领域，并经过转换成为协作分析数据。这些数据不是为特定的使用者而定制或建模的。源对齐的领域可以有一个或多个来源：数据通常来自于该领域的操作系统，但也可能来自其他领域的操作性或分析性数据。例如，一个在线销售图书的公司可以根据客户的购买过程将其数据划分为领域：产品搜索、浏览、结账和付款。创建领域的挑战在于所有权；例如，如果一个业务当前被划分为应用程序领域（仅基于支持特定应用程序的领域），但需要划分为业务领域（基于业务能力），那么一个业务领域可能拥有多个应用程序。
- 聚合的领域数据：聚合的领域数据是从其他领域组合和/或聚合数据的分析数据，通常用于帮助查询性能。例如，您可以将制造领域和销售领域的数据组合起来，以更轻松、更快地创建损益报告，或者创建一个对使用者更容易使用的数据模型。
- 消费者对齐的领域数据：消费者对齐的领域数据是根据一个或多个特定部门或用例的需求进行转换的分析数据。消费者对齐的领域几乎总是从源对齐的领域接收数据。例如，制造领域的领域数据可以以两种不同的方式进行建模和描述：一种是针对了解制造业的人员（源对齐），另一种是针对制造业外的人员（消费者对齐）。另一个例子是将源对齐的数据转换为消费者对齐的数据，以便更容易训练机器学习模型。
关于数据领域和领域驱动设计的更多细节，我强烈推荐阅读彼得海因·斯特伦霍特的《规模数据管理》，第二版（O'Reilly，2023年）。
Data Mesh的逻辑架构
图13-2展示了一个具有少数领域的公司可能的数据网格逻辑架构。每个领域都可能拥有一个或多个产品。
在图13-2中，制造、销售和供应商都是源对齐的领域。每个领域都有自己的操作性和分析性数据。例如，销售领域可以使用Salesforce跟踪有关其客户的所有信息（操作性数据）。销售随后可以将其数据放入数据湖架构（见第12章），并将其与包含操作性数据的其他数据源以及供应商领域的分析数据相结合。这将创建销售分析数据，然后可以将其放入数据湖架构。销售还创建API来与其他领域和消费者共享该分析数据及其关联的元数据。
请注意供应商的消费者对齐领域。这是因为供应商源对齐领域的分析数据对供应商领域之外的人来说过于复杂而创建的。在供应商消费者对齐领域中，数据模型被简化，并且供应商行话更容易理解。
还有一个利润和损失（P&L）聚合领域，它使用来自制造源对齐领域和销售源对齐领域的数据构建。在很大程度上，这是出于性能原因。如果那些领域拥有地理位置非常远的单独数据湖，执行从多个领域组合数据的查询或报告可能会太慢。
最后，还有一个客户360领域。这个领域获取来自各种来源的客户数据（如人口统计数据、行为数据、交易数据和客户反馈数据），对其进行清理和主数据管理（见第6章），然后将其组合起来以获得客户的完整图景。所有需要客户数据的领域都从这个客户360领域中提取数据。这比让每个领域自己提取、清理和主数据管理客户数据要好得多。
正如您所见，拥有许多领域可能会导致一团复杂的混乱。想象一下，如果有数十个甚至上百个领域，图13-2中的图表可能会是什么样子。这就是为什么领域设计如此重要的原因。我在本章的前面进行了介绍，但我鼓励您查阅其他深入探讨此主题的资源。在开始构建数据网格之前，您需要花费大量时间来设计领域和产品，以确保在数月内不必返回重新设计。
不同的拓扑结构
Mesh Type 1
在这种架构中，所有的领域都使用相同的技术。例如，它们可能都使用同一家云服务提供商，并且受限于该提供商的产品，因此每个领域都将使用相同的产品进行存储、数据管道、安全性、关系型数据仓库、报告、元数据目录、主数据管理、数据虚拟化、API、机器学习工具等。在某些产品中可能会有一些选择，但这些选择会很少。每个领域都将拥有自己的基础架构，因此一切都将是分散式的------除了存储。每个领域都拥有自己的数据湖，而不是每个领域都拥有自己的数据湖，而是有一个企业级数据湖，每个领域在湖中都有自己的容器或文件夹，只有它才能访问。
因此，逻辑上，每个领域都有自己的数据湖，但物理上，所有领域的数据都在一个数据湖中。许多客户使用Mesh Type 1，因为当存在多个物理数据湖时，将数据合并在一起会出现性能问题，这些数据湖可能相距很远。此外，拥有一个物理数据湖极大地简化了数据的安全性和监控，以及进行灾难恢复备份的过程。
Mesh Type 2
在这种架构中，各个领域使用与Mesh Type 1相同的技术。每个领域都拥有自己的数据湖，而不是一个企业级数据湖存储所有领域的数据。所有数据湖都使用相同的技术。这使得基础设施真正实现了分散化，但代价是：当需要从多个领域组合数据时，链接所有数据湖并获得可接受的性能存在技术挑战。因此，我看到更多的公司使用Mesh Type 1。
Mesh Type 3
在这种架构中，每个领域都可以选择任意技术和任何云服务提供商，并拥有自己的数据湖（也可以使用任何技术）。例如，DomainA和DomainD使用Azure，DomainB使用AWS，DomainC使用GCP，而DomainA选择Azure Synapse作为关系型数据仓库，DomainD选择在虚拟机中使用SQL Server作为其数据仓库。挑战包括处理每个领域的不同安全类型，在多种产品中找到和支持专家，为不同云中的多种产品创建治理标准（原则 #4），创建可以容纳所有这种多样性的自动化基础设施（原则 #3），以及尝试从不同云中的多个产品中合并数据。这符合之前讨论的纯数据网格的范畴。由于存在许多挑战，我认为Mesh Type 3 永远不会被采用。
在图13-3的左侧，架构具有最高的集中化程度，随着向右移动，架构变得更加分散。
数据网格与数据编织
数据编织和数据网格在当今的数据景观中都是重要的概念，但它们扮演着不同的角色，不应混淆。从本质上讲，数据编织是一种架构框架，旨在在数据网格内的一个或多个领域内使用。然而，数据网格是一个全面的概念，涵盖了技术、策略和方法。事实上，它的定义是如此全面，以至于我甚至不愿将其标记为一种架构。
在另一方面，数据编织的技术和架构基础可以被量身定制，以支持数据网格内部各种复杂性和组件。它们之间的关系不是竞争或可互换的，而是协同作用的。单个数据网格可能会整合多个数据编织，每个数据编织都根据其所在领域的独特需求进行定制。
在这种情况下，您可以将数据网格中的每个领域视为其自身的生态系统。在这个生态系统内，该领域可以构建、完善和运营自己的数据编织，确保它符合特定的要求和目标。换句话说，虽然数据网格提供了一种分散和面向领域的数据方法的蓝图，但数据编织提供了支持这些领域的架构和技术基础设施。将它们结合使用可以实现更加集成和高效的数据基础设施。这也适用于将数据网格与现代数据仓库或数据湖架构结合使用。
用户案例
希望到目前为止，您已经对德赫加尼描述的数据网格有了很好的理解，我将其称为"纯"数据网格。虽然纯数据网格在理论上听起来很好，但它非常假设，并且技术支持有限。因此，实际的数据网格解决方案将包含很多例外情况，以适应德赫加尼的愿景。对于大多数构建的解决方案，对于纯数据网格存在如此多的例外情况，以至于这些"数据网格"实现甚至不应该被称为数据网格。
要问的主要问题是：您是想要实现仅仅数据联合------将来自多个不同来源的数据集成在一起，而无需将数据在IT拥有和管理的单个存储库中进行物理整合，还是您真的想要构建一个数据网格？您可以在不构建数据网格的情况下实现数据联合；基本数据联合可以被认为是满足数据网格原则#1而不是其他三个原则。如果您选择这条路线，您的解决方案是否仍然应该被称为数据网格？我认为您可以称呼它为任何您喜欢的名称，但是更准确的称呼可能是企业数据湖架构或数据编织架构，特别是当每个领域都拥有自己的工作空间时；您所构建的最准确的描述是一个带有多个工作空间的企业数据湖架构或数据编织架构（每个领域一个工作空间）。请记住，如果每个领域拥有其操作数据衍生的分析数据，则可以满足数据网格的原则#1，即使是IT创建分析数据。然而，除非每个领域都创建自己的分析数据并创建界面共享该数据，否则无法满足原则#2。
还要记住，要满足原则#1，您的组织必须经历重新组织公司按业务领域进行的过程。我怀疑，如果您没有满足原则#2（数据作为产品），那么创建领域的工作是否值得；如果是IT而不是领域进行数据清理，那么您将错过拥有数据网格的重要一点。
举个例子，假设您的公司收购了许多其他公司。您让每个收购对象拥有其数据，并使用虚拟化软件进行访问。在这种情况下，您已经实现了数据联合，但您肯定没有一个数据网格；您没有按数据领域对组织进行拆分（除非您根据业务功能定义领域，并决定收购的业务是自己的领域，但这并不合理，因为您将会有多个HR领域，具有重复的HR产品）。即便如此，再次强调，根据收购进行领域组织仅满足原则#1。我会认为必须满足原则#2才能称之为数据网格架构，因为它实现了数据网格的两个最大优点：组织和技术的扩展。
最后一点：在努力在数据网格内实现中央集权和分权之间取得平衡的过程中，理解责任分配的分布至关重要。图13-4是一个标度，显示了每个责任领域在一个虚构用例中可能的位置。 
在图13-4的左侧是中央化的IT，而右侧是分权的业务领域。在最左边的一个点表示中央化的IT执行所有特定项目，而在最右边的一个点表示每个分权的业务领域执行所有特定项目。中间的点显示了每个责任领域在这个范围内的位置。
如果您大部分的点都在最左边，那么您的解决方案中存在着如此多的中央集权，以至于称其为数据网格可能不太合适。将其更好地归类为企业数据编织或数据湖架构可能会更为适当。
总结
本章全面介绍了数据网格概念及其基本原理。首先进行了集中化和分权化的比较分析，强调了从单体架构向分权化数据景观的转变，其中数据被视为由跨职能团队拥有的宝贵产品。接着解释了Zhamak Dehghani提出的数据网格的四个原则：面向领域的分权化数据所有权、数据作为产品、自助式数据基础设施作为平台以及联邦计算治理。这些概念突显了将数据视为由特定领域团队拥有、维护和利用的整体实体的重要性。其核心思想是将每个数据单元视为具有自己生命周期的独立产品，由最了解其价值和用途的团队管理。
在详细阐述了基础原理之后，本章深入探讨了纯数据网格，强调了其纯粹的形式。然后探讨了数据领域的概念，突出了它们在构建分权化环境中的作用。讨论了数据网格逻辑架构以及支持数据网格的各种拓扑结构，展示了它们对数据流和交互的影响。通过对比数据网格和数据编织，澄清了它们的不同特点和应用。最后讨论了数据网格的使用案例。
尽管数据网格方法可能是我们处理数据的一个重要变革，但并不是没有障碍和困难，这将在下一章中深入探讨。我还将解答关于数据网格的一些常见误解，并帮助您确定是否采用数据网格对您的组织是正确的选择。