我要直言不讳------关于数据网格挑战的这一章是本书最长的章节之一。这并不是因为我认为数据网格是一个坏主意，或者我所讨论的其他架构更好；而是因为有很多关于数据网格的神话、关注点和挑战需要您了解。如果您决定构建一个数据网格，我希望您能做出明智的选择，不要受到过多的炒作影响。
在接下来的页面中，我将剖析围绕数据网格的误解，解决通常被忽视的真正关切，帮助您评估其在组织结构中的适应性，并提供成功实施的可操作建议。最后，我将展望数据网格发展的潜在未来，并讨论四种数据架构的最佳使用案例。
神话
神话：数据网格是快速解决所有数据挑战的银弹
事实上，情况恰恰相反。建立数据网格所需时间远远超过建立本书中提到的其他架构。Dehghani并未声称数据网格是一种银弹，但在媒体炒作中，她的观点往往被解读为这样。这就是为什么讨论使用数据网格的复杂性和挑战非常重要的原因。
神话：数据网格将取代您的数据湖和数据仓库
正如您在第13章中所了解的，数据网格中的每个领域仍然需要一个数据湖，可能还需要一个关系型数据仓库。改变的是，您不再拥有由中央IT团队拥有和管理的"中央"数据湖和RDW。每个领域都保留自己的数据。因此，使用数据网格，您实际上拥有更多的数据湖和数据仓库，领域必须共同使用这些数据湖和数据仓库。
神话：数据仓库项目都失败了，而数据网格将解决这个问题
我经常听到人们声称当前的大数据解决方案不可扩展，并提出数据网格作为解决方案。对此我不得不提出异议。虽然成千上万的组织已经实施了成功的大数据解决方案，但几乎没有数据网格投入生产（其中没有"纯"数据网格）。 在我从事数据仓库工作的15年中，我见过许多"单片"架构非常好地扩展了他们的技术和IT人员，甚至支持了PB级的数据。 当然，许多大数据项目失败了。然而，大多数失败的原因（通常与人和流程有关）也会导致数据网格失败。用于集中化数据的可用技术已经极大改善，并将继续改善。无服务器选项现在满足了大多数组织的大数据需求，允许解决方案随着节省成本而扩展。
神话：构建数据网格意味着完全去中心化
这可能是最常见的神话。事实上，即使是纯数据网格，中央IT团队仍然负责创建基础设施即服务（原则#3）来启动每个领域的基础设施。中央IT团队还负责创建和监视每个领域遵循的数据治理政策（原则#4）。让每个领域从零开始构建自己的基础设施是没有意义的。让每个领域制定自己的数据治理政策也是没有意义的------这会导致安全性的各种类型和标准和规定的解释与领域数量一样多。
神话：您可以使用数据虚拟化创建数据网格
我听到许多数据虚拟化倡导者说，如果您使用数据虚拟化连接所有数据湖和数据仓库，您将拥有一个数据网格！但是，这种方法完全忽略了数据网格的四个原则（请参见第13章）。
一个单一的企业数据布局（第11章）应用了数据虚拟化后能否成为数据网格是一个神话。你可以尝试这样做，但结果远非数据网格------这是数据联合，意味着集成来自多个不同来源的数据，而不是在单个中央存储库中物理整合或存储它。去中心化只是构成数据网格的一小部分------仅仅添加虚拟化将无法满足任何数据网格的四个原则！ 例如，假设一家公司有一个使用数据虚拟化的企业数据布局。每个领域都生成自己的分析数据，数据布局通过数据虚拟化软件连接到该数据。
这是一个数据网格吗？让我们应用四个原则来找出答案：
-
原则#1是关于领域所有权的。这些是否真正是数据领域，还是公司内的单独组织？
-
原则#2是关于将数据视为产品。每个领域是否有自己的团队构建分析解决方案，使用该领域自己的基础设施？这些团队是否遵循了约定数据契约，规定了他们如何使数据和元数据对所有人可用？这个组织是否使用数据虚拟化连接到其所有领域的数据，还是仅连接到一些领域？ 重要的是，如果每个领域没有自己的领域团队和基础设施，那么隔离的数据工程团队仍然会成为IT的瓶颈。同样，如果任何领域不使用数据虚拟化，它们的数据就需要被收集和集中化。帮助扩展基础设施和组织是数据网格的两个主要优点，如果领域不遵循原则#2，它们就无法实现这些优点。
-
对于原则#3，我们可以问：是否有一个独立的团队创建自助数据基础设施平台？
-
对于原则4：是否有一个独立的团队创建联邦计算治理？ 正如您所见，真正的数据网格解决方案与使用数据虚拟化的数据布局解决方案之间存在很大差异。
担忧
这一部分试图全面涵盖数据网格的挑战，将其按主题分类，并在可能的情况下提供解决方案以帮助克服这些问题。如果在阅读所有这些问题之后，你确定可以克服其中任何一个可能存在的问题，那太好了！数据网格也许适合你。当你在未来遇到这些问题时，你不会感到惊讶，因为你已经有所准备。我希望通过了解这些问题，你可以在开始之前解决它们，极大地增加成功的机会。
尽管这个列表专注于数据网格，但其中许多问题也适用于其他架构，因此最好都进行审查。即使你使用其他数据架构中的一种，我亲身经历过了解数据网格的情况可以引发热烈的讨论，有助于改进你使用的任何架构。
哲学和概念问题
Zhamak Dehghani的原始博客和关于数据网格的书籍树立了标准，但人们对她的著作有着不同的解读。一些人对"纯粹的"数据网格提出了"例外情况"，并提出了关于数据网格应该是什么的其他想法。所以，如果你想构建一个数据网格，你将使用什么定义呢？让所有参与构建数据网格的人达成共识可能需要几个月的时间。当许多产品的制造商对构建数据网格的许多不同想法时，这尤其具有挑战性。
为了使团队达成对数据网格的共同理解，考虑成立一个跨职能治理委员会，制定基础定义和标准。利用利益相关者研讨会和文档定义，确保每个人都在同一条船上。试点项目可以作为这些定义的实际测试，允许你根据需要进行调整。开放的沟通和定期审查将有助于在实施数据网格时保持这种一致性。
有一个真实的信息来源有助于确保组织基于可靠的数据做出决策，没有关于哪些数据是正确的的模糊或分歧。每个人都使用同一套信息使操作更加高效和有效。
在数据网格中，数据可以从一个域读取，由另一个域转换和存储。这种动态拓扑结构可能会导致维护单一真实来源变得非常困难。事实上，Dehghani称单一真实来源的想法是一个"神话"。我非常不同意；我个人见过许多公司在各种数据架构中实施了单一真实来源，并读过更多的例子。如果组织建立严格的数据治理并利用集中式数据目录（参见第6章），再加上跨领域的数据质量指标和强大的领域间协作，单一真实来源不仅是可行的，而且可以增强网格的灵活性和可伸缩性。
实施数据网格存在巨大的风险，特别是与数据仓库的成功相比。这需要激烈的组织变革和全新的架构。此外，数据网格假设每个源系统都能动态扩展以满足消费者需求。当某些数据资产在生态系统内成为"热点"，看到查询或使用量激增时，这可能变得特别具有挑战性。
在分散的环境中合并数据
你总是需要将来自多个域的数据组合进行查询或报告。有时，你可能需要将来自几十个域的数据合并在一起，这些数据可能分布在地理上相距很远的多个数据湖中。你需要仔细考虑如何克服性能问题，因为诸如数据虚拟化（见第6章）和聚合域的解决方案都有其自己的折衷办法。
有自主域的另一个折衷方案是，每个域往往只关注于自己的分析需求的数据产品。通常，所有者忘记考虑他们的数据可能如何与其他域的数据结合，也很少为如何将他们的数据模型与其他人的数据模型结合而付出努力。当有人需要从多个域中组合数据时，他们可能会遇到很多困难。
第4原则可以帮助你为所有域定义一套数据建模规则，但这需要有人了解所有域------这是数据网格试图摆脱的集中式架构的特征。在数据网格中，域的内部关注点可能没有人调查从组合数据中获得价值的方法。因此，确保存在这样一个人是很重要的。
如果你正在使用通用数据模型（CDM；见第8章），那么每个域都需要使用它。你将不得不协调确保每个域都有自己一套唯一ID的记录，这些记录与其他域的相同类型的数据相同（例如客户或产品）。否则，当你从多个域中合并数据时，你可能会遇到重复的ID。这可能会引入计数错误、聚合错误和查询和报告中的数据不一致性。为了在多个域中的CDM中避免重复的ID，你可以使用全局唯一标识符（GUID）或建立一个集中式ID管理系统来分配唯一的ID。或者，你可以应用命名空间，其中每个ID都以特定于域的代码作为前缀或后缀。
此外，随着域构建其产品和数据模型，其他域和消费者将根据这些数据模型消耗他们的数据，并根据这些数据模型组合多个域的数据。当域更改其数据模型或接口时，依赖关系可能会给使用核心数据模型或连接域数据模型的查询的其他域和消费者带来问题。当任何域更改其数据模型时，需要安排所有域进行协调。
最后，域团队对于什么是"干净"或"标准化"数据可能有不同的看法。如果域在是否使用缩写或完整州名定义州等问题上存在分歧，那么从多个域中合并数据可能会造成混乱。如果域没有时间构建代码来正确清理数据，那怎么办？为了解决跨域数据清洁度的不一致性，建立一个集中式治理框架，为清洁或标准化的数据设置标准定义。提供数据清理模板或共享库以节省时间并确保统一性。治理委员会或数据监管员可以帮助执行这些标准，使从多个域中合并数据变得更加容易，而不会出现问题。
去中心化的其他问题
聚合和消费者对齐的域（见第13章）并不是去中心化的。创建聚合域时，你正在从多个域中获取数据并将其集中化。对于聚合和消费者对齐的域，你必须决定谁拥有、构建和维护它们------这正是第1原则旨在防止的问题。构建这样的域还会导致数据重复。所有这些似乎与数据网格的精神相违背。
为了使聚合和消费者对齐的域与数据网格的原则相一致，考虑采用共享治理和指定的数据监管人员来管理这些域。利用数据虚拟化来最小化重复，并为抽象实现API层。通过强大的元数据和审计追踪来保持透明度。
安全性也是一个问题。在集中式架构中，一个团队负责保护所有数据。在数据网格中，这种责任被分配给了数十甚至数百个域，从而产生了更多的入侵可能。这极大地增加了安全侵犯的风险。
你需要指定某人来扫描个人身份信息（PII），并查看谁正在访问它，以及如果有人看到不应被允许看到的PII时，应该采取什么措施来解决问题。应该有人负责确保所有域都有足够的安全性。
在跨域选择和实施技术方面也很困难。虽然第3原则（基础设施即服务）旨在防止这种情况发生，但如果有几十个域的人员拥有不同水平的技能和经验，他们很可能会选择不同的技术、设置他们的基础设施方式以及配置他们的云产品设置。这可能会导致使用数据时出现重大问题。
你可以限制为每个域自动提供的技术，但这违反了第1原则，因为它限制了每个域为自己的用例选择技术的自由。支持许多不同的技术可能是具有挑战性的，创建跨所有域的通用接口也是如此。作为一个妥协，你可以创建一个大型的经过批准的技术目录------为域提供选择，但在确保更容易集成的框架内进行。
此外，虽然第4原则（联邦治理）制定了数据网格政策，但每个域都被要求实施这些政策。这可能导致实施不一致，潜在地导致性能下降和不同的成本配置文件。
复杂性
数据网格背后的思想很复杂。我坦率地承认，我不得不多次阅读Dehghani的博客才能完全理解这种架构。即使过了几年，我有时仍然意识到自己对其中的某部分理解不正确。我不是唯一一个；我几乎每个人都对数据网格感到困惑。这种复杂性，再加上缺乏对数据网格的标准定义，意味着大多数计划构建数据网格的团队将不得不投入大量时间来确保每个人都理解它（并且理解正确）。如果启动和升级需要很长时间，确保数据网格会为你带来足够的好处，使其值得时间和精力投入。
这种复杂性也延伸到组织复杂性，尽管数据网格的支持者声称相反。分布式团队涉及更多的人员，他们可能并不总是有效地进行沟通。
数据重复
Dehghani认为，在数据网格中复制源数据并不是一个问题，她写道，对于每个域，"我们很可能不需要数据湖，因为包含原始数据的分布式日志和存储可以作为不同可寻址的不可变数据集进行探索。"2 但你并不总是可以直接从这些不可变数据集中访问原始数据，因为通常存在安全性或即时检索的问题。（我仍然有很多客户使用不可能连接到的主机。）因此，要对原始数据进行任何操作，你仍然必须复制并将其存储到数据湖中。实际上，与其他架构相比，数据网格可能导致数据的更多副本，因为域可能需要从其他域复制数据以完成其数据产品或创建聚合或面向客户的域。保持所有副本同步可能会增加额外的成本和工作量。
类似地，用于星型模式中的统一维度（参见第8章）与其相关的每个事实具有相同的含义。统一维度允许你以相同的方式对事实和度量（如日期或客户维度）进行分类和描述，确保企业范围内的一致报告。统一维度在星型模式解决方案中非常受欢迎。在数据网格中，那些统一维度必须在具有相关事实表的每个域中进行复制。这是大量需要保持同步的重复数据。
你的公司很可能正在购买第三方数据，例如天气、股票或竞争对手数据。在集中式架构中，这由一个人或团队处理，因此同一公司中的两个团队购买相同数据的可能性很小。但是，在数据网格中，每个域都购买自己的数据。你如何防止两个域通过购买相同的数据集浪费资金？数据网格原则似乎没有涵盖这个领域，但你可以通过建立一个集中式团队来处理所有对第三方数据的请求来增强第4原则。
尽管有第3原则，但一些域可能会构建类似的数据摄入或分析平台。在集中式方法中，只有一个团队在构建平台，但在数据网格中，可能会有数十个域这样做。推广分享这些解决方案是个好主意，这样域就不会重复彼此的努力，也不会错过其他域创建的有用解决方案。
可行性
迁移到数据网格是一项庞大的工程，需要对组织变革和技术实施进行巨大投资，远远超过其他数据架构。这将导致成本大幅增加，时间线大幅延长------可能需要数月，甚至数年，才能将其投入生产。要让域能够很好地使用自己创建的报告和仪表板，以至于中央IT可以停止为它们提供支持，需要付出很大的努力。与此同时，除非你是一家全新的公司，否则你将不得不继续运行现有的平台。这可能非常具有挑战性，特别是当新的域从向中央IT提供运营数据转变为将其保留在自己的域内时。
再次强调，数据网格是一个概念，而不是一种技术。它的核心在于在公司内部创建组织和文化变革。Dehghani的书中没有讨论如何利用现有技术构建数据网格。这可能是因为在数据量子、自动化、产品共享、域基础设施设置和协作数据治理等领域存在重大技术差距。
第2原则要求提供技术来公开和共享域，但目前这方面的技术还处于起步阶段。第3原则要求为自动化基础设施供应提供非常复杂的解决方案，但目前的解决方案最多只能做一小部分。在制定和管理第4原则的全局规则的同时，域创建和管理自己的规则意味着严重依赖自动化和编码解决方案来管理数据产品生命周期、将标准作为代码、将策略作为代码、自动化测试、自动化监控，并将策略执行嵌入到每个数据产品中。这需要非常复杂的软件，而这种软件，即使存在，也是非常有限的。公司必须自己构建它，或者直接跳过这一步，从而违反了数据网格的原则。
Dehghani描述了数据产品具有输出数据端口（接口），具有明确定义的合同和API。这些API将提供多模型访问、双时数据和不可变只读访问，并且可以传输大量数据并扩展到大量请求。此外，这些API将跨越一个或多个物理基础设施、多个云和本地主机环境。到目前为止，还没有技术可以支持所有这些。这可能永远不会实现。
此外，API很少与数据一起使用；与数据交互通常留给SQL查询。为所有与数据的交互创建API是一个很大的文化转变，需要的时间远远超过使用SQL查询。
在她的书中，Dehghani引入了一个称为数据量子的逻辑架构单元，它控制并封装了作为数据产品进行自主共享所需的所有结构组件，其他人可以消费。这包括数据、元数据、代码（计算）、策略和基础设施依赖关系。数据和计算被逻辑上作为一个单元连接在一起，但托管代码和数据的底层物理基础设施是分开的。目前还没有这方面的技术。尽管Dehghani已经开始了一家公司，以使用数据产品容器创建数据量子，但可能需要几年时间，她的公司或其他公司才能构建出解决大多数这些要求的组件。
我认为数据量子是一个非常危险的概念。你肯定可以在不使用它的情况下构建数据网格。想想使用数据量子进行数据谱系。如果每个域的元数据仅在数据产品内部可用，要查看其元数据、谱系或数据质量信息，你需要对所有数据产品执行复杂的联合查询。你可以将所有元数据复制到一个中央位置，但这将需要不断同步，并使整体架构变得更加复杂。然后还有安全性问题；你需要更新元数据，如敏感标签、隐私分类和数据位于多个位置的所有权信息。
复制数据的问题也延伸到数据产品。如果它们被复制，它们的元数据也会被复制，导致同一元数据的多个副本需要保持同步。对元数据的任何更新都需要同时在多个数据产品容器上进行，这要求这些容器始终可用且可访问。你可能会面临同一元数据拥有不同所有者的风险。
最后，同时运行数百甚至数千个小型数据产品将极大地增加复杂性，增加基础设施资源和网络的利用率，复杂化配置管理，并引入性能和参考数据一致性方面的挑战。
Dehghani认为，由于尚未创建出数据网格本地技术，"你可以利用数据仓库技术作为底层存储和SQL访问模式，但为每个数据产品分配单独的模式，"因此共享计算。但这将导致集中式基础架构，违反了第1原则，并且失去了使用数据网格的最大好处：技术扩展。
人员
你需要为每个域找到和招聘高质量的工程人员和其他技术熟练的工作者。为中央IT团队找到优秀的人才已经够困难了，但在数据网格中，每个域的任务不仅是学习构建基础设施和分析平台，还要创建和招聘自己的迷你IT团队。如果你有很多域，那么你需要的人数比集中式架构中需要的人数要多得多------这是一种水平组织扩展的巨大权衡。
第3原则旨在消除对深度技术技能的需求，而是使用更高级别的跨职能技能。这通常会促使组织选择来自业务领域的人，而不是具有强大技术技能的经验丰富的人来执行每个产品组的实施工作，尤其是由于很难找到足够的拥有高质量技术技能的人。经验不足的人倾向于构建昂贵、复杂、性能不佳的数据产品。
数据网格假设中央IT数据工程师没有业务和领域知识，因此最好使用熟悉拥有数据的域的人。它进一步假设每个域团队都有必要的技能来构建健壮的数据产品，或者可以获得这些技能。
这并不总是正确的。令人惊讶的是，我看到一些中央IT人员比域专家拥有更多的领域知识！IT人员也了解如何从不同的域中组合数据。有时，运行操作系统的人对自己的数据了解很少，特别是从分析的角度来看；他们只是专注于保持系统运行。如果中央IT数据工程师没有他们需要的领域知识，为什么不让他们获取这些知识，并改进IT与域之间的沟通？这可能比引入一种全新的工作方式更好。
数据网格支持者吹嘘说，与仅具有一个领域深度专业知识的数据专家不同，数据网格鼓励普通人。没有人只做一件事。数据网格设想由具有许多领域中级技能的跨职能团队组成：例如，流式处理、ETL批处理、数据仓库设计和数据可视化，以及软件工程实践，如编码、测试和持续交付（DataOps）。想象一下"样样皆通，但样样不精"。同样，如果你有很多域，这意味着需要填补很多角色，并支付很多薪水。找到和招聘拥有如此广泛技能的人并不容易，更不用说很多人了。这种多技能人员是否比在某一领域拥有多年深厚专业知识的个人更好，这是值得商榷的。
域级别障碍
假设你的域最终被授权让中央IT为其分析添加急需的功能，以便你可以从数据中获得真正的价值。你已经与中央IT规划了未来几个月内创建分析的计划。然后你得知你的公司将建立一个数据网格，你需要雇佣一个全新的团队来创建所需的功能和相应的API。然后你被要求在公司实施第3和第4原则、设计数据域并撰写将指导每个域升级的合同的几个月内推迟项目。你会有什么感觉呢？如果数十个域的人都有这种感觉会怎样？公司不能有一个流氓的域；消费者以及其他域依赖于从每个域获取数据，因此每个域都积极参与到数据网格项目中至关重要。你需要：
- 提供有说服力的激励来弥补额外的工作、麻烦和延迟。告诉他们他们正在为更大的利益而努力是不够的。 获得每个域对实施数据网格的买入。
- 获得高层管理层的支持。 传达一个清晰的愿景，展示给每个域带来的好处。
- 运行试点项目，展示新方法的有效性。
- 提供激励，包括财政和非财政激励，以鼓励参与。
- 建立透明的沟通渠道。
- 通过能力中心或卓越中心提供支持。
- 计划如果一个域不愿意遵守规则该怎么办。这对数据安全性和数据质量标准可能特别麻烦。如果你决定不遵循规则的域不能加入数据网格，你将会有数据孤岛的问题。
- 也可能有一些域即使想加入数据网格也无法加入。也许他们没有预算来建立一个团队来创建分析平台，或者情况迫使他们继续使用无法处理分析平台的旧技术。为了将他们的数据纳入数据网格，你可能需要一个数据网格旁边的集中式架构。
在数据网格的成功中，有效的产品共享至关重要。在数据网格内部和外部共享产品与共享数据非常不同。你需要一种方法让其他域或消费者跟踪公司中所有域及其数据产品。这将需要将所有域元数据编目到某个地方，具有搜索机制和一种请求访问的方式：一种类似于第6章描述的数据市场的机制。
主要的云提供商为共享数据提供了许多软件解决方案，但为共享数据产品提供的解决方案非常少（截至撰写本文时，这些都是最近发布的）。你需要决定：你会购买一个还是自己创建一个？
数据网格导致数据请求向自助模式的转变，这带来了挑战。传统上，域依赖于中央IT部门处理其所有的分析数据需求，这包括从管理数据到解决特定请求，如查询和报告等所有方面。通过数据网格，这一责任是分散的，完全落在各个域的肩上，以满足这些数据请求。潜在的风险是，一些域可能缺乏管理这些任务的专业知识。此外，他们不能简单地复制中央IT实施的解决方案，他们必须改进这些解决方案以显示数据网格的价值。当他们构建自己的独特解决方案时，有可能这些解决方案甚至不如替代的集中式系统有效或健壮。
组织评估：您应该采用数据网格吗？
到目前为止，您已经了解了什么是数据网格以及与之相关的潜在关注点。如果您仍然觉得数据网格是一个选择，下一步就是进行彻底的评估，以确定您的组织是否准备好构建一个成功的数据网格。您可以使用表14-1中的标准，这些标准来源于德赫加尼的著作。德赫加尼建议公司只有在所有标准都有一定程度或高度适用时，才考虑构建数据网格。
根据我的经验，实际情况是，只有极少数的公司------也许只有1%------会发现所有这些类别都有一定程度或高度的适用性。在早期采用者、面向领域和现代工程等方面得分较高的情况特别罕见。
实施成功数据网格的建议
如果您目前拥有数据解决方案并决定构建数据网格，我建议采用集线器-辐射模型，其中您将数据网格构建为集中式数据解决方案的扩展（见图14-1）。您可以首先使用新数据创建新的数据网格域，但根据业务需求，在新域中补充您当前的集中式数据解决方案。随着时间的推移，逐渐将集中式数据迁移到数据网格域中，同时继续添加更多来自新数据的新域，不要试图一次性将所有集中式数据转换为数据网格域。
逐步实施数据网格有助于管理与完全改造现有数据架构相关的风险。如果网格的某一部分出现故障，它将被隔离，不会影响整个系统。您可以更好地控制合规性和安全措施，并有时间建立适当的治理和安全协议。这种渐进式方法还分散了成本和对工作人员的需求。在过渡期间，依赖集中式数据的现有业务流程可以继续顺利运行，最大程度地减少对业务的干扰。
我建议的是一种迭代方法。逐步实施新域使您能够从每个阶段中吸取经验教训，进行必要的调整，并将这些教训应用到后续的域中，从而在长期内打造出更加健壮的系统。此外，它使您能够利用现有的技术投资，同时向更现代的架构迈进。
这种方法也是一种敏捷方法。它为您提供了灵活性，使您能够优先考虑提供更直接价值或与战略业务倡议一致的某些域。它允许与业务需求保持一致，而不是一次性进行强制迁移。您还有机会优化每个域基础设施的性能，并根据该域的特定需求和约束进行定制。
最后，集线器-辐射方法为逐步实现文化转变铺平了道路，促进了数据产品所有者、工程师和业务利益相关者之间跨功能、领域驱动的协作。
这种分步实施数据网格的方法是一种战略方法，允许进行谨慎规划、风险管理，并与业务目标保持一致。它支持从集中式数据架构向分散式架构的渐进过渡，利用了过渡期间的新旧系统。与一次性尝试完全过渡相比，这种方法更具适应性和韧性，后者充满了风险和复杂性。
数据网格的未来
我已经与许多人交谈过，他们认为由中央团队构建整个数据架构的理念正在消失，最终每家公司都将转向去中心化模式。毕竟，集中式模型的扩展性不佳。
这一点在金博尔与因蒙辩论时已经讨论过（见第8章）。在因蒙阵营中，IT将一切都集中管理；但在金博尔阵营中，方法是构建松散集中的主题数据仓库，并使用符合维度和总线架构将它们连接起来。然而，在实践中，你会发现许多领域在隔离环境中构建自己的数据仓库，有时使用不同的技术，导致了去中心化的架构。当人们需要联合和聚合来自多个领域的数据时，他们会创建额外的数据仓库和/或OLAP立方体。
有时这种策略运作良好，但通常会导致重复努力，使用各种不同的技术和产品。这也很困难，通常会使成本失控。公司随后会回归到集中式模型以防止这些问题。
数据网格会导致相同的问题循环吗？这次有何不同？尽管自数据仓库时代以来技术已经取得了长足的进步，但问题实际上并不是技术问题，而是人和流程问题，我们在解决这些问题方面远远没有取得太大进展。无论你提出多么酷炫的新概念和方法，要让人们改变是极其困难的，而数据网格需要大量的改变。
我预测，极少数公司将采用数据网格架构，我不认为这些解决方案中有任何是纯粹的数据网格。对于那些将其解决方案称为数据网格的公司，我估计大部分------也许有90%------将采用领域所有权（原则1），而采用数据作为产品（原则2）的公司则更少，也许只有70%。也许只有极少数公司会将其提升到数据量子的水平。大约三分之一的公司将使用某种形式的自助数据基础设施（原则3：自助数据基础设施作为平台），也许有一半将采用联邦计算治理（原则4）。我预计很大一部分解决方案将限制每个领域可以使用的技术。
与其试图实施数据网格的每个要素，我建议关注如何使您的数据团队能够为客户更快地提供更频繁的价值。从那里开始，您可以逆向工作，确定并采用数据网格的具体要素，以帮助您实现这一目标。
最终，数据网格是集中化与去中心化之间的较量。任何数据网格解决方案中都会始终混合两者。关键在于为您的用例找到正确的平衡。
放大格局：理解数据架构及其应用
在快速技术进步的现代世界中，企业站在一个十字路口上，周围充斥着大量的数据。如果正确利用，这些数据可以解锁前所未有的见解，简化运营，并提供竞争优势。解锁这一潜力的关键在于架构------决定数据将如何存储、处理和访问的框架。
在本书的过程中，我深入探讨了各种数据架构的复杂性、演变和实际应用。现在，在我准备结束这一章节之际，从更高的角度来审视这个领域至关重要。
您有很多选择。您如何知道哪一种对您的组织最合适？为了解决这个问题，让我们从成本和复杂性的角度来看一些每种架构的高级用例：
现代数据仓库
对于处理少量数据并且已经习惯了关系型数据仓库的企业而言，现代数据仓库是最合适的选择，可以实现渐进式过渡。
数据编织
随着企业的成长和多样化，它们经常发现自己在处理来自各种来源的数据，每个来源的大小、速度和类型都不同。数据编织是那些需要一种无缝集成这些多样化数据流的企业的架构选择。
数据湖仓
这可以被视为一种中间解决方案。您应该将数据湖仓视为您的主要解决方案，直到遇到其局限性为止。当您遇到局限性时，您可以将特定数据集转移到关系型数据仓库，以更好地满足组织的需求。
数据网格
为非常大型、面向领域的公司量身定制，数据网格适用于正面临重大可扩展性挑战并且有资源和时间投资于强大解决方案的组织。
这些架构并不是相互排斥的。现实世界很少是绝对的。大多数组织会发现，它们独特的需求需要从多个架构中提取一组特征的拼图。这样的定制解决方案可以结合任何一种或所有这些架构的特点，适应组织特定的数据用例和不断发展的业务能力。
总结
本章讨论了关于数据网格的常见误解，澄清了有效的关注点，并评估了它在各种组织结构中的适应性。我提供了基于真实世界实践和案例研究的关键建议，以确保成功实施数据网格。我们探讨了数据网格在不断发展的技术和商业趋势背景下的未来。最后，我总结了所有的数据架构，帮助您选择最适合您特定业务需求的数据架构。希望您现在既有理论上的理解，又有实践上的见解，这将使您能够就数据网格采用做出明智的决策。
业务的未来与数据的未来密不可分。随着我们的前进，我们选择的架构将决定我们不仅如何存储和访问数据，还有我们的企业如何成长、创新和竞争。以深刻的理解、适应性和对未来的愿景来对待这个选择至关重要。请记住，您今天选择的架构将为您的明天铺平道路。明智地选择，并让您的数据引领前进。
本书的前几章深入探讨了数据架构的技术方面。在第 15 和第 16 章中，我们将探讨人员和流程的关键主题，审视团队组织、项目失败的原因以及项目成功的关键因素。