数据网格到底是什么，它真的能替代数据仓库和数据湖吗？

数据网格概念由扎马克·德赫加尼提出，她在2019年的开创性文章《如何从单一数据湖转向分布式数据网格》中指出：

“传统的集中式数据管理模型无法适应快速变化的业务需求，而数据网格通过分布式的方式管理数据，允许业务部门拥有并管理其数据，同时通过标准化的API和自助服务平台实现跨部门的数据共享。”

2022年，德赫加尼的著作《数据网格：大规模交付数据驱动的价值》（Data Mesh: Delivering Data-Driven Value at Scale）正式出版，详细阐述了数据网格的设计原则、实施方法和技术架构，推动了这一概念的进一步普及。

数据网格在2022年的Gartner数据管理技术成熟度曲线中首次出现，被定位在"创新触发"(Innovation Trigger)阶段，虽然是首次出现,但Gartner就预测数据网格会在达到"生产性高原"(Plateau of Productivity)之前就变得过时(obsolete)，如下图所示：

Gartner的这个观点受到争议，一些专家认为Gartner的观点过于偏向供应商和技术，而忽视了实际业务需求。还有一些专家说，数据网格将继续增长，但会被分解为更小的组件，这些组件将被新兴数据工具的其他方面所吸收。

为了更好的理解数据网格，我拿了德赫加尼的《数据网格：大规模交付数据驱动的价值》原版书来读，发现自己小看了数据网格，数据网格讲得可不是一个简单概念，而是围绕数据网格建立的一套架构体系。因此，写读书笔记一篇，分享给大家。

本读书笔记共分为五个部分，与原版书籍目录保持一致，如下所示：

1、数据网格是什么？

2、为什么选择数据网格？

3、如何设计数据网格架构？

4、如何设计数据产品架构？

5、如何开始实施数据网格？

在读完这本英文书籍后，我有一个体会，就是提出一个新的概念不难，但要把这个概念诠释清楚，并且能用一本书来进行系统解读，说明是真的把这个事情想清楚了，这叫做在实践中做学问吧。下面，让我们来看看数据网格的提出者是怎么做的。

一、数据网格是什么？

在当今数字化时代,数据已成为企业的核心资产。然而,随着数据规模和复杂性的不断增长,传统的中心化数据管理方法正面临着前所未有的挑战。数据网格(Data Mesh)应运而生,作为一种革命性的数据管理范式,它为我们提供了一个全新的视角来看待和处理大规模、复杂环境下的分析数据。

数据网格的本质是一种去中心化的社会技术方法。它不仅仅是一种技术架构,更是一种思维模式的转变,涉及组织结构、文化和技术的多个层面。数据网格的核心在于将数据责任分散到最了解数据的业务领域,同时通过标准化和自动化来保证整体的一致性和互操作性。

下图显示了数据网格与早期分析数据管理方法相比的多维技术和组织变革。

1、在组织上，它从由运行数据平台技术的专家集中拥有数据的模式，转变为一种分散的数据拥有模式，将数据的拥有权和责任推回到数据产生或使用的业务领域。

2、在架构上，它从在单一的仓库和湖泊中收集数据转变为通过标准化协议访问的数据产品的分布式网络连接数据。

3、在技术上，它从将数据视为运行管道代码的副产品的技术解决方案转变为将数据和维护它的代码视为一个充满活力的自主单元的解决方案。

4、在操作上，它将数据治理从一个自上而下的集中式操作模型与人工干预转变为一个在网络节点中嵌入计算政策的联合模型。

5、在原则上，它将我们的价值体系从将数据视为可收集的资产转变为将数据视为服务和满足数据用户(组织内部和外部)的产品。

6、在基础设施上，它从两套碎片化和点对点集成的基础设施服务转变—一套用于数据和分析，另一套用于应用程序和操作系统，转变为一套良好集成的基础设施，服务于操作和数据系统。

数据网格建立在四个相互关联的原则之上，这些原则共同构成了其理论和实践的基础:

1、领域所有权:这一原则将数据责任分配给最接近数据的业务领域。它借鉴了领域驱动设计(DDD)的思想,将数据按业务领域进行逻辑分解,由各个领域团队负责管理和共享他们最了解的数据。这种方法不仅提高了数据的真实性和及时性,还能更好地适应业务的变化。

2、数据即产品:将产品思维应用于数据管理是数据网格的一大创新。每个数据集被视为一个"产品",需要具备可发现、可理解、可信赖等特质。这种思维转变促使团队更加关注数据的质量和用户体验,从而提高数据的整体价值。

3、自服务数据平台:为了支持去中心化的数据管理,数据网格需要一个强大的自服务平台。这个平台需要简化数据产品的创建和使用过程,降低技术门槛,使得更多的通用技术人员能够参与到数据工作中来。

4、联邦计算治理:在分散数据责任的同时,数据网格也认识到了全局一致性的重要性。联邦计算治理模型通过自动化和计算来实现政策的执行,平衡了域自主性和全局互操作性。

四个原则是共同必要和充分的。它们相辅相成，每个原则都应对可能由其他原则引发的新挑战。下图 显示了这些原则之间的相互作用。

二、为什么选择数据网格？

今天的问题源于昨天的解决方案，当前的分析数据架构的经历了三代演进，德赫加尼特别指出，以往以技术分区为驱动的方法存在问题：

1、数据仓库架构 

这是最早的集中式数据管理方法，将数据从业务系统抽取、转换后加载到集中的仓库中。虽然解决了数据孤岛问题，但随着时间推移，往往变得复杂难维护。

2、数据湖架构 

为了应对大数据和机器学习需求而生，保留了原始数据形态。但也面临"数据沼泽"的风险，数据质量和可用性成为挑战。

3、多模式云架构 

结合了前两代架构的优点，并利用云的优势。但仍未从根本上解决组织复杂性带来的挑战。

这三代架构虽然在技术层面不断进步，但它们仍有几个共同的局限性：

1、单体性：架构、技术和组织结构都趋向于集中化，难以应对业务的复杂性和变化。

2、中心化的数据所有权：虽然解决了数据孤岛问题，但距离数据源越来越远，影响了数据质量和响应速度。

3、技术导向：架构设计过于关注技术功能，而忽视了业务领域的自然边界。

数据网格从过去的解决方案中学习，并致力于解决它们的缺点。它减少了作为协调瓶颈的集中化点。找到了一种新的方式来分解数据架构，而不会因同步而减缓组织的速度。它消除了数据来源与数据使用之间的差距，并消除了意外的复杂性——即在两个数据平面之间发生的管道。

数据网格的目标是使组织能够大规模获取数据价值，利用数据不仅改善和优化业务，还重塑业务，体现在三个方面：

1、优雅应对变化

• 对齐业务、技术和现在的分析数据

  数据网格的每个业务单元承担分析数据的所有权和管理责任。这是因为离离数据最近的人最能理解存在哪些分析数据以及如何最好地解释这些数据。域名所有权导致分布式数据架构，其中数据工件——数据集、代码、 元数据和数据政策——由其相应的领域维护。

• 缩小分析数据与操作数据之间的差距

  数据网格建议通过以产品形式共享的数据，缩小分析和运营两个层面之间的差距和反馈循环。数据网格在一个新结构下连接这两个层面——一个点对点连接的数据产品和应用的网络。

• 将数据更改本地化到业务领域

  数据网格将变更本地化到各个领域，并赋予它们根据对业务的深入理解自主建模数据的权利，而无需中央协调单一的共享标准模型。

• 减少管道和数据复制的意外复杂性

  数据网格通过创建一个新的架构单元即数据产品量子来解决传统集中式数据交换的复杂性，数据量子对其每种本地访问模式——SQL、文件、事件等——都有一套明确的合同和保证。在访问时对每个接口提供访问控制和政策执行。数据量子封装了转换和维护其数据的代码。数据管道被分解并成为数据量子逻辑的内部实现。数据量子在不需要中介管道的情况下共享数据。

2、保持增长中的敏捷性

• 消除集中式和单体瓶颈

  数据网格采用点对点的方法来服务和消费数据。这种架构使得消费者能够直接发现和使用源数据产品中的数据。

• 减少数据管道的协调

  现有架构基于组件的技术分解——即数据采集、处理、服务等管道任务。这种架构分解风格导致每当交付新的数据源或新的用例时，这些功能之间需要进行大量协调。数据网格摆脱了数据管理的技术分区，转向以领域为导向的分区。以领域为导向的数据产品独立于其他数据产品进行开发和演变。这种以领域为导向的分解减少了实现结果所需的协调。

• 减少数据治理的协调

  数据治理的中央集中化和高度手动的流程抑制了数据共享的灵活性。数据网通过两个功能减少治理协调摩擦:第一、在每个数据产品中自动化和嵌入政策作为代码，第二、将治理的核心责任委托给各个领域的数据产品负责人。

3、提高数据投资回报率

• 通过数据平台抽象技术复杂性

  数据网格批判性地审视现有的技术格局，并将技术解决方案重新构想 为一个数据产品开发者(或用户)-中心的平台。它旨在消除对数据专家的需求，使通才专家能够开发数据产品。

• 将产品思维嵌入各处

  数据网格将我们的思维从将数据视为一个资产转变为将数据视为一个产品。它改变了我们衡量成功的方式，从数据量转向数据用户的满意度。

• 超越界限

  数据量子提供了一组接口，允许任何拥有适当访问控制的人发现和使用数据产品，而不受其物理位置的限制。

三、如何设计数据网格架构？

作者从四个核心原则出发,逐步构建了数据网格的整体架构框架,展现了从理念到实践的推导过程。

1、领域导向的分析数据共享接口

领域所有权原则延伸了领域的边界,要求每个领域控制其数据——操作数据和分析数据，每个领域都提供分析数据共享接口。这一点突破了传统数据架构中领域与分析的割裂,为数据的源头治理奠定了基础。

2、数据产品作为一种架构量子

数据网格将每个数据产品设计为一个"架构量子",它是可以独立部署和管理的最小架构单元。它具有高功能内聚性，即执行特定的分析转换并安全地共享结果作为面向领域的分析数据。它具备执行其功能所需的所有结构组件:转换代码、数据、元数据、管理数据的政策以及与基础设施的依赖关系。这种设计大大提高了数据产品的自治性和可复用性。

3、多平面数据平台

数据网格采用了一种多平面的平台架构设计,主要包括三个平面:

• 数据基础设施(实用)平面:原子服务用于提供和管理物理资源，如存储、管道编排、计算等。

• 数据产品体验平面:更高级的抽象服务，直接与数据产品操作，使数据产品的生产者和消费者能够创建、访问和保护数据产品，以及其他在数据产品上运行的操作。

• 网格体验平面:在互联数据产品网络上运行的服务，例如搜索数据产品和观察它们之间的数据沿袭。

网格体验层依赖于数据产品层的接口，因为它聚合了这些接口，而数据产品体验层则依赖于下层基础设施服务层的接口，因为它抽象了这些接口。

这种分层设计既保证了用户体验的优化,又兼顾了底层资源的高效利用。平台各个平面之间通过API进行交互,保持了良好的解耦。

4、嵌入式计算政策

数据网格采用了一种分布式的治理模式,将各种策略(如访问控制、加密、隐私保护等)以代码的形式嵌入到每个数据产品中。平台提供统一的控制接口,但具体的策略执行则在数据产品的运行时上下文中进行。这种设计既保证了治理的一致性,又避免了中心化治理可能带来的性能瓶颈。

数据网格架构引入了几个逻辑组件，以将数据产品策略作为代码进行管理:

• 数据产品边车：边车是一个实现政策执行和其他需要在网络中标准化的数据产品方面的过程。它由平台提供。它与数据产品作为一个单元进行部署和运行。

• 数据产品计算容器：一种让平台将执行策略封装为一个可部署单元与数据产品的方法。为了简洁，我有时称之为数据容器。

• 控制端口：控制端口提供了一组标准接口来管理和控制数据产品的策略。下图显示了这些逻辑组件。理想情况下，平台提供并标准化与领域无关的组件，例如边车、控制端口实现以及输入和输出端口。

5、以用户旅程驱动的平台设计

多平面数据平台的最终目的是为跨职能领域团队提供服务，以便他们能够交付或使用数据产品。数据网格生态系统中有几个主要的高层次角色，包括数据产品开发者、数据产品消费者、数据产品负责人、数据治理成员、数据平台产品负责人、数据平台开发者等等。

下图示例了一个数据产品开发者的创建和运营数据产品之旅：

在一个与源对齐的数据产品的情况下，该产品从操作系统中获取数据，数据产品开发人员与源应用程序开发人员紧密合作。他们共同设计和实施应用程序如何将其操作数据作为数据产品的输入进行共享。请注意，这些人属于同一个领域团队。

下图示例了平台接口是如何设计来支持数据产品开发的：

下图示例了数据基础设施平台是如何支持数据产品交付的：

四、如何设计数据产品架构？

数据产品是数据网格的核心，需要一个高效、灵活且可扩展的数据产品架构。

1、数据产品的本质

数据产品是数据网格中的基本构建块，它不仅仅是数据的集合，更是一个自治的实体，能够独立管理、处理和提供数据服务。设计数据产品架构的首要任务是理解其本质特征：

• 自治性：数据产品能够独立运行，不依赖中央控制。

• 领域导向：每个数据产品都代表特定的业务领域。

• 可发现性：用户能够轻松找到并理解数据产品。

• 可组合性：不同的数据产品可以组合以创造新的价值。

2、设计思路：可供性（Affordances）导向

设计数据产品架构的核心思路是基于可供性。可供性指的是数据产品能够为用户（人或系统）提供的交互能力。主要的可供性包括：

• 服务数据：提供多样化的数据访问方式。

• 消费数据：从各种源头获取数据。

• 转换数据：处理和分析数据。

• 发现与理解：让用户能够轻松找到并理解数据。

• 组合数据：将不同来源的数据整合。

• 生命周期管理：管理数据产品的整个生命周期。

• 观察与调试：监控数据产品的运行状况。

• 治理：确保数据的正确使用和管理。

这种设计方法确保了数据产品能够适应变化、易于扩展，并持续创造价值。

3、核心功能设计

（1）服务数据

服务数据是数据产品的主要功能，其设计应遵循以下原则：

• 多模态访问：提供多种数据格式和访问方式，如API、文件下载等，以满足不同用户的需求。

• 不可变性：一旦数据被创建，就不应被修改。这确保了分析的可重复性和数据的一致性。

• 双时态性：记录数据的实际发生时间和处理时间。这对于时间序列分析和数据溯源至关重要。

• 只读访问：用户只能读取数据，不能直接修改，以保证数据完整性。

案例：考虑一个客户行为数据产品。它可以同时提供JSON格式的API访问和CSV格式的文件下载。数据包含客户ID、行为类型、发生时间和记录时间。这样的设计允许数据科学家通过API进行实时分析，同时市场团队可以下载CSV文件进行离线分析。

（2）消费数据

数据产品需要从各种源头获取数据。设计考虑包括：

• 多源支持：能够从操作系统、其他数据产品、外部API等多种源头获取数据。

• 跨环境消费：支持在不同环境（如云端和本地）之间获取数据。

• 输入端口：设计标准化的输入接口，便于管理和扩展。

案例：一个销售数据产品可能需要从CRM系统、ERP系统和市场营销平台获取数据。通过设计统一的输入端口，它可以轻松地从这些不同源头获取并整合数据。

（3）转换数据

数据转换是数据产品增值的关键环节。设计考虑包括：

• 灵活性：支持编程式（如使用Python、Java）和声明式（如SQL）转换方法。

• 可扩展性：允许轻松添加新的转换逻辑。

• 版本控制：对转换逻辑进行版本管理，确保可追溯性。

案例：一个客户细分数据产品可能需要结合交易历史、客户属性和行为数据进行复杂的分析。它可以使用SQL进行初步的数据聚合，然后使用Python实现机器学习模型来进行客户细分。

4、可发现性和可组合性设计

（1）可发现性

确保用户能够轻松找到并理解数据产品是关键。设计考虑包括：

• 元数据管理：提供详细的数据字典、数据谱系和质量指标。

• 搜索功能：实现强大的搜索能力，支持关键词、标签和语义搜索。

• 示例和文档：提供数据使用的示例代码和详细文档。

案例：设计一个数据目录系统，之中每个数据产品都有一个详细的登录页面。该页面包含数据描述、样本数据、使用指南和质量指标。用户可以通过搜索框快速找到所需的数据产品。

（2）可组合性

数据产品should能够轻松地与其他数据产品组合，以创造新的洞察。设计考虑包括：

• 标准化接口：定义标准的数据交换格式和协议。

• 语义互操作性：使用共同的数据模型和术语。

• 版本兼容性：确保不同版本的数据产品可以协同工作。

案例：考虑将客户数据产品和交易数据产品组合，创建一个客户生命周期价值数据产品。通过标准化的接口和共同的客户ID，这两个数据产品可以无缝集成，产生更高价值的洞察。

5、管理、治理和观察设计

（1）生命周期管理

使用数据产品清单（manifest）来描述和管理数据产品的整个生命周期。清单should包含：

• 基本信息：名称、版本、所有者等。

• 数据模型：详细的数据结构和关系。

• 访问控制：定义谁可以访问数据及如何访问。

• 质量SLA：承诺的数据质量指标。

（2）数据治理

将治理规则直接编入数据产品中，确保数据的正确使用。设计考虑包括：

• 嵌入式策略：将数据访问、隐私保护等策略直接编码到数据产品中。

• 审计跟踪：记录所有数据访问和使用情况。

• 合规性检查：自动检查是否符合相关法规。

（3）可观察性

设计全面的监控和诊断能力：

• 日志：详细记录数据处理和访问活动。

• 指标：实时监控关键性能指标。

• 跟踪：跟踪数据在整个系统中的流动路径。

案例：设计一个数据产品的dashboard，实时显示数据质量指标、使用情况和处理延迟。当检测到异常时，自动触发告警并提供详细的诊断信息。

6、设计原则总结

• 去中心化：避免单点控制，提高系统弹性。

• 标准化：确保互操作性，但不牺牲灵活性。

• 时间敏感：重视数据的时间维度，支持时间序列分析。

• 可扩展性：设计应该支持轻松添加新功能和数据源。

• 自治性：数据产品应能自我管理和监控。

• 不可变性：保证数据的一致性和可追溯性。

• 多模态：支持多种数据访问方式，满足diverse用户需求。

设计数据产品架构是实现有效数据管理和利用的关键。通过采用可供性导向的设计方法，并遵循上述原则，组织可以创建灵活、可扩展且价值驱动的数据生态系统。这种架构不仅能够提高数据的可用性和可信度，还能更好地适应快速变化的业务需求。

五、如何开始实施数据网格？

启动数据网格是一个复杂而持续的过程，需要技术、业务和组织文化的全面变革。通过将数据网格纳入整体数据战略，采用业务驱动的执行框架，推动组织变革和文化塑造，并制定合理的迁移策略，企业可以逐步建立起一个灵活、可扩展的数据管理架构，为数据驱动的创新和决策提供强有力的支撑。

1、数据网格作为数据战略的核心

启动数据网格的第一步是将其纳入企业的整体数据战略。数据网格不应被视为孤立的技术项目，而应是实现数据驱动业务价值的关键组成部分。

在启动数据网格之前，需要评估组织的准备程度。可以从以下几个方面进行评估：

• 组织复杂度：数据源和用例的数量和多样性

• 数据导向的战略：是否将数据作为战略差异化因素

• 高层支持：是否有高管层面的支持和投入

• 数据技术成熟度：是否将数据技术视为核心能力

• 创新文化：是否属于早期采用者类型

• 工程实践：是否具备现代化的软件工程实践

• 领域导向的组织结构：是否已经按业务领域组织团队

如果组织在这些方面得分中等或较高，那么就具备了采用数据网格的良好基础。

2、业务驱动的执行框架

数据网格的实施应该采用业务驱动的方法，将技术实现与具体的业务价值紧密结合。

（1）识别高价值用例

选择能够快速展示价值的业务用例作为起点。包括以下一些原则：

• 从互补的用例开始

• 了解并优先考虑数据消费者和提供者角色

• 从对平台缺失功能依赖最小的用例开始

• 创建平台服务和数据产品的长期拥有权和预算管理

这些用例应该能够展示数据网格的优势，如跨领域数据集成和实时分析能力。

（2）端到端迭代执行

采用端到端的迭代方法，每次迭代都涵盖从业务需求分析到数据产品开发，再到平台能力构建的完整流程。这种方法能够持续交付价值，并获得快速反馈。

（3）演进式执行模型

数据网格的实施应该遵循一个多阶段的演进模型：

• 探索阶段：选择1-2个领域进行试点，建立基础概念和实践

• 扩展阶段：将成功经验推广到更多领域，完善平台能力

• 提取阶段：优化和巩固已有成果，实现规模化效益

下图展示了数据产品(Data as a Product)在不同发展阶段的特征演变。让我逐一解析每个阶段的特点:

（1）探索/引导阶段 

• 数据产品数量: 少量(Small number of DPs)

• 数据产品功能: 基本功能(Essential affordances)

• 开发重点: 制定标准和合理做法(Set standards, sensible practices)

• 数据产品类型: 低风险(安全性、可靠性)(Low risk (security, reliability))

• 数据产品角色: 主要是源对齐的(Majority source-aligned)

在这个阶段,只创建少量数据产品,主要实现基本功能。开发者专注于建立标准和最佳实践。选择的数据产品通常风险较低,主要是源数据对齐的产品,以确保安全性和可靠性。

（2）扩展/扩大规模阶段 

• 数据产品数量: 大量快速增长(Large number of DPs rapidly growing)

• 数据产品功能: 为快速开发提供大多数功能(Most affordances for rapid DP dev)

• 开发重点: 支持多样性(Support diversity)

• 数据产品类型: 高风险(High risk)

• 数据产品角色: 包括所有类型,包括聚合数据(All including aggregates)

这个阶段数据产品数量快速增长,功能更加丰富以支持快速开发。开发重点转向支持多样性,包括更高风险的数据产品。数据产品类型扩展到包括聚合数据在内的所有类型。

（3）提取/维持阶段

• 数据产品数量: 趋于稳定(Number of DPs stabilizing)

• 数据产品功能: 所有功能都为弹性而设计(All affordances for resilience)

• 开发重点: 优化数据产品(Optimize data products)

• 数据产品类型: 遗留系统(Legacy)

• 数据产品角色: 主要是消费者对齐的(Majority consumer-aligned)

在这个阶段,数据产品数量趋于稳定,所有功能都为提高系统弹性而设计。开发重点转向优化现有数据产品。此时也开始整合遗留系统,数据产品主要以满足消费者需求为导向。

在每个阶段，都应该使用适应度函数来评估进展。这些函数可以包括：

• 领域所有权：参与数据产品开发的领域数量和数据产品使用的增长率

• 数据即产品：数据产品的使用率、用户满意度和数据质量指标

• 自助服务平台：数据产品开发周期、平台服务的采用率

• 联邦计算治理：自动化策略的覆盖率、跨领域数据连接的数量

3、组织变革与文化塑造

启动数据网格不仅是技术变革，更是组织和文化的深刻转型。

（1）培养数据文化

推广数据网格所需的核心价值观：

• 数据责任共担：每个团队都对自己的数据负责

• 跨界数据连接：鼓励跨领域的数据共享和集成

• 用户中心：以数据消费者的需求为导向设计数据产品

• 自主与协作：平衡本地自主性和全局一致性

• 持续变革：构建能适应变化、持久和独立的数据产品

• 自动化优先：通过自动化提高数据共享的速度和质量

（2）调整组织结构

采用团队拓扑的方法重塑组织结构：

• 领域数据产品团队：作为流式对齐团队，负责特定业务领域的数据产品开发和维护

• 数据平台团队：作为平台团队，提供自助服务平台，支持数据产品的开发和运营

• 联邦治理团队：作为赋能团队，制定全局策略和标准，协调跨领域合作

领域数据产品团队负责数据产品的端到端交付，被视为流对齐团队。他们与其他团队共享他们的数据产品作为服务。数据网格平台团队向数据产品团队提供他们的平台能力作为服务。治理团队部分充当赋能团队，支持平台和数据产品团队。治理团队有时与平台团队协作。

（3）引入新角色

创建和定义新的角色以支持数据网格：

• 数据产品负责人：负责数据产品的愿景、路线图和价值交付

• 领域数据产品开发者：负责数据产品的技术实现和运维

• 平台产品负责人：负责数据平台的用户体验和功能优先级

同时，现有角色也需要调整，如首席数据官的角色可能会从直接管理数据转变为更多的赋能和战略指导角色。

（4）技能发展

投资于全员的数据素养提升：

• 为所有人提供基础数据分析和可视化培训

• 为技术人员提供数据建模、数据质量管理等专业培训

• 为管理者提供数据战略和数据治理的培训

创建新的职业发展路径，使更多的通用技术人员能够参与到数据产品的开发和使用中。

4、迁移策略

对于大多数组织来说，启动数据网格意味着从现有的数据架构（如数据仓库或数据湖）迁移。这个过程需要谨慎规划：

（1）避免与中心化架构共存

数据网格的目标是消除中心化瓶颈，因此不应该与现有的中心化数据架构长期共存。

（2）利用现有技术

在专门为数据网格设计的技术出现之前，可以利用现有的数据技术，但要以支持自治和分布式数据产品的方式进行配置。

（3）直接连接源系统

在迁移过程中，应该绕过现有的数据湖或仓库，直接从源系统构建数据产品。这样可以更好地实现领域所有权和缩短源与消费者之间的距离。

（4）原子化演进步骤

迁移应该以原子化的演进步骤进行，每一步都应该减少技术债务和架构熵。例如，创建新的数据产品，迁移现有消费者，并淘汰旧的表格、文件和管道。

结语

至此，这本书的五大部分全部讲完了，自己读来受益匪浅。原书每部分的内容非常丰富，受限于篇幅，我大多只能点到为止，如果大家对相关内容感兴趣，可以去找原书来读。

至于数据网格能否替代数据仓库或者数据湖的问题，我认为德赫加尼低估了数据相对于功能的维度复杂性，也低估了网络的影响程度，更低估了协调的难度，还有企业文化的巨大影响，同时也低估了融合分析通过分布式来实现的巨大技术挑战。

德赫加尼提出的让离业务最近的人去做数据这种理念，非常有道理，但领域要有自主权可以通过租户的形式在大一统的数据湖上进行入驻就能实现，这种方式还能兼顾集中和分散，而且国内采取这种形式的不在少数，只是没有像数据网格那样做的这么彻底，同时我认为，数据网格对基础设施和自动化治理提出了过高的要求，当前的供应商接不住。

但有一点我是非常认可德赫加尼的，就是OLTP团队和OLAP团队要实现彻底的融合，现在能做到这一点的企业很少。但随着AIGC的来临，OLTP和OLAP的融合成为了一种趋势，任何做AI的应用团队，都至少需要配个专业的语料数据工程师。

我在自己负责的管信和数据团队中，做了一些融合尝试，认为效益很大，以前，没有什么驱动力能够捏合这两只团队，现在AI似乎可以。

点击左下角“阅读原文”查看更多精彩文章，公众号推送规则变了，如果您想及时收到推送，麻烦右下角点个在看或者把本号置顶