一 为什么需要数据网格

许多组织都构建了中央数据湖和数据团队，希望基于数据来推动业务发展。然而，在最初的几次快速胜利之后，他们注意到中央数据团队经常成为瓶颈。团队无法足够快地处理管理层和产品负责人的所有分析问题。这是一个大问题，因为及时做出数据驱动的决策对于保持竞争力至关重要。例如：黑色周期间提供免费送货是个好主意吗?客户是否接受更长但更可靠的运输时间?产品设计更改如何影响结账率和退货率?

数据团队希望快速回答所有这些问题。然而，在实践中，他们遇到了困难，因为在操作数据库发生更改后，他们需要花费太多时间来修复损坏的数据管道。在剩下的不多的时间里，数据团队必须发现并理解必要的业务域数据。对于每个问题，他们都需要学习业务知识才能提供有意义的见解。获得所需的业务域专业知识是一项艰巨的任务。

另一方面，组织还构建了领域驱动设计、自治领域团队和去中心化微服务架构。这些领域团队拥有并了解他们的领域，包括业务的信息需求。他们自行设计、构建和运行Web应用程序和API。尽管了解领域和相关信息需求，领域团队仍必须联系超载的中央数据团队以获得必要的数据驱动见解。

随着组织的最终发展，领域团队和中央数据团队的情况变得更糟。解决这个问题的一个方法是将数据的责任从中央数据团队转移到领域团队。这就是数据网格概念背后的核心思想：分析数据的面向领域的去中心化。数据网格架构使领域团队能够自行执行跨域数据分析并互连数据，类似于微服务架构中的API。

二 什么是数据网格

数据网格一词由ZhamakDehghani创造2019年，它基于四个众所周知的基本原则：

域所有权原则要求域团队对其数据负责。根据这一原则，分析数据应该围绕域组成，类似于与系统的有界上下文对齐的团队边界。遵循领域驱动的分布式架构，分析和操作数据所有权从中央数据团队转移到领域团队。

数据作为产品原则将产品思维哲学投射到分析数据上。这个原则意味着域外的数据也有消费者。领域团队负责通过提供高质量的数据来满足其他领域的需求。基本上，域数据应该像任何其他公共API一样对待。

自助数据基础设施平台背后的理念是将平台思维应用于数据基础设施。专门的数据平台团队提供与领域无关的功能、工具和系统，以便为所有领域构建、执行和维护可互操作的数据产品。借助其平台，数据平台团队使领域团队能够无缝地使用和创建数据产品。

联邦治理原则通过标准化实现所有数据产品的互操作性，由治理组通过整个数据网格来推动。联邦治理的主要目标是创建一个遵守组织规则和行业法规的数据生态系统。

三 如何设计数据网格

数据网格架构是一种分散的方法，使域团队能够自行执行跨域数据分析。其核心是具有负责团队及其运营和分析数据的领域。领域团队获取运营数据并构建分析数据模型作为数据产品来执行自己的分析。它还可以选择发布带有数据合约的数据产品来满足其他领域的数据需求。

领域团队在全局策略上与其他人达成一致，例如联合治理组中的互操作性、安全性和文档标准，以便领域团队知道如何发现、理解和使用数据网格中可用的数据产品。数据平台团队提供的与领域无关的自助数据平台使领域团队能够轻松构建自己的数据产品并有效地进行自己的分析。赋能团队指导领域团队如何对分析数据进行建模、使用数据平台以及构建和维护可互操作的数据产品。

让我们详细了解数据网格架构的核心组件及其关系：

1.数据产品

数据产品是一个逻辑单元，包含用于处理和存储分析或数据密集型用例的域数据的所有组件，并通过输出端口将它们提供给其他团队。您可以将其视为模块或微服务，但用于分析数据。

数据产品连接到源(例如操作系统或其他数据产品)并执行数据转换。数据产品在一个或多个输出端口提供数据集。输出端口通常是由数据合约定义的结构化数据集。下面是一些例子：

• 包含多个相关表的BigQuery数据集

• AWSS3存储桶中的Parquet文件

• AzureDataLakeStorageGen2中的增量文件

• Kafka主题中的消息

数据产品由领域团队拥有。团队负责数据产品整个生命周期的运营。团队需要持续监控并确保数据质量、可用性和成本。

下面是数据产品设计示例：

2.数据合约

数据合约是定义数据提供者与其消费者之间交换数据的结构、格式、语义、质量和使用条款的文档。它涵盖：

• 数据产品提供者，包括所有者和访问的输出端口

• 数据使用条款和条件

• 提供的数据属性的架构和语义

• 质量属性，例如新鲜度和行数

• 服务级别目标，例如可用性和支持时间

• 使用数据的账单详细信息

虽然数据合约代表了接口规范，但提供数据的实际实现是数据产品的输出端口。

当不同团队或组织单位之间交换数据时，数据合约就会发挥作用。首先，也是最重要的，数据合约是一种沟通工具，用于表达对如何构建和解释数据的共同理解。它们使语义和质量期望变得明确。在后期的开发和生产中，它们还充当代码生成、测试、模式验证、质量检查、监控、访问控制和计算治理策略的基础。数据合约还可用于消费者驱动的契约测试的输入端口，以验证数据是否按指定提供。

数据合约规范定义了YAML格式来描述所提供数据集的使用条款和属性。

3.联邦治理

联合治理组通常组织为一个行会，由参与数据网格的所有团队的代表组成。他们就全球政策达成一致，这是数据网格中的游戏规则。这些规则定义了领域团队如何构建他们的数据产品。

互操作性政策是起点。它们允许其他领域团队以一致的方式使用数据产品。例如，全局策略可以定义提供数据的标准方式是作为AWSS3上相应域团队拥有的存储桶中的CSV文件。

接下来，必须有某种形式的文档来发现和理解可用的数据产品。一个简单的策略可以是带有一组预定义元数据的wiki页面，例如数据产品的所有者、位置URL和CSV字段的描述。

以安全的方式访问实际数据产品的统一方法可以是在AWSIAM中使用由域团队管理的基于角色的访问。

隐私和合规性等全球政策也很常见。考虑保护个人身份信息(PII)或特定行业的法律要求。

4.数据抽取

领域团队如何将其运营数据提取到数据平台中?根据领域驱动设计原则设计的软件系统包含作为可变实体/聚合和不可变领域事件的数据。

领域事件非常适合纳入数据平台，因为它们代表相关的业务事实。如果存在消息传递系统，则可以通过附加额外的消息使用者将域事件转发到数据平台。数据可以实时采集、处理并转发到数据平台。通过这种流式摄取，数据在到达时会小批量发送，因此可以立即用于分析。由于域事件已经被明确定义，因此除了PII数据的重复数据删除和匿名化之外，在清理和预处理方面几乎没有什么可做的。有时，还建议定义和摄取包含仅与分析用例相关的信息的内部分析事件，以便不必修改域事件。

许多业务对象作为实体和聚合保存在SQL或NoSQL数据库中。它们的状态随着时间的推移而变化，最新的状态仅保留在数据库中。具有状态的实体的有力候选者是物品、价格、客户数据或运输状态。对于分析用例，通常需要拥有最新状态和一段时间内的状态历史记录。有多种方法可以摄取实体。一种方法是每次实体更改时生成并发布具有当前状态的onCreate/onUpdate/onDelete事件或实体监听器。然后可以使用流式摄取来摄取数据，如上所述。当无法更改操作软件时，可以使用变更数据捕获(CDC)直接监听数据库更改并将其流式传输到数据平台。最后，可以设置传统的计划ELT或ETL作业，将数据导出到文件并将其加载到平台中，其缺点是没有实时数据，导出之间没有所有阶段更改，并且需要一些合并导出数据的工作再次。然而，它们对于大型机等遗留系统来说是一个可行的选择。

5.数据转换

深入研究数据产品中的数据组织，我们可以看到流经不同阶段的不同类型的数据。操作数据通常作为某种原始和非结构化数据被摄取。

在预处理步骤中，原始数据被清理并结构化为事件和实体。事件较小、不可变且高度面向领域，例如OrderPurchased或ShipmentDelivered。实体代表业务对象，例如状态随时间变化的货物或物品。这就是为什么实体通常表示为快照列表、历史记录，最新快照是当前状态。

在实践中，我们经常看到手动输入或导入的数据。例如，通过电子邮件以CSV文件形式发送的预测数据或业务代码的文本描述。

来自其他团队的数据被集成为外部数据。当使用来自其他管理良好的团队的数据产品时，这种集成可能会以非常轻量级的方式实现。在从遗留系统导入数据的情况下，外部区域充当辅助加强层。

聚合数据来回答分析问题。领域数据可以通过定义数据合约发布给其他团队。数据合约通常由一个视图实现，即使底层数据模型发生变化，该视图也是稳定的。

6.数据清洁

干净的数据是有效数据分析的基础。通过数据网格，领域团队负责执行数据清理。他们了解自己的领域，并且可以确定需要处理其领域数据的原因和方式。

引入数据平台的数据通常以其原始的原始和非结构化格式导入。使用列式数据库时，这可能是每个事件的一行包含CLOB事件负载字段，可以是JSON格式。现在可以对其进行预处理以使数据干净：

• 结构化：将非结构化和半结构化数据转换为分析数据模型，例如，通过将JSON字段提取到列中。

• 减轻结构变化：当数据结构发生变化时，可以减轻结构变化，例如用合理的默认值填充空值。

• 重复数据删除：由于大多数分析存储系统都是仅附加的，因此无法更新实体和事件。删除所有重复条目。

• 完整性：确保数据包含商定的时间段，即使在摄取过程中出现技术问题也是如此。

• 修复异常值：识别并纠正可能因错误而出现的无效数据。

从实现的角度来看，这些预处理步骤可以实现为投影原始数据的简单SQL视图。可以通过公共表表达式来组织查询(CTE)并可以通过用户定义的函数进行增强(UDF)，例如用于JSON处理。作为替代方案，清理步骤可以实现为对主题进行操作的lambda函数。可以使用dbt等框架构建更复杂的管道，但也需要掌握更多技能。

7.数据分析

为了获得洞察力，领域团队查询、处理和聚合他们的分析数据以及来自其他领域的相关数据产品。

SQL是大多数分析查询的基础。它提供了强大的功能来连接和调查数据。数据平台应该有效地执行连接操作，即使对于大型数据集也是如此。聚合用于对数据进行分组，窗口函数有助于跨多行执行计算。笔记本有助于构建和记录探索性发现。

当人类通过视觉感知数据、趋势和异常时，会更容易理解它们。有许多出色的数据可视化工具可以构建漂亮的图表、关键绩效指标概述、仪表板和报告。它们提供易于使用的UI来深入、过滤和聚合数据。例如：Looker、Tableau、Metabase、Redash。

为了获得更高级的见解，可以应用数据科学和机器学习方法。这些支持相关性分析、预测模型和其他高级用例。需要特殊的方法、统计和技术技能。例如：scikit-learn、PyTorch、TensorFlow。

8.数据平台

每个组织的数据平台可能有所不同。数据网格是一个新领域，供应商开始在其现有产品中添加数据网格功能。

从所需的能力来看，可以区分分析能力和数据产品能力：分析能力使领域团队能够构建分析数据模型并执行数据驱动决策的分析。数据平台需要以自助服务的形式获取、存储、查询和可视化数据的功能。典型的数据仓库和数据湖解决方案，无论是本地还是云提供商，都已经存在。主要区别在于每个领域团队都有自己的隔离区域。

更先进的数据网格数据平台还提供额外的与领域无关的数据产品功能，用于创建、监控、发现和访问数据产品。自助数据平台应该支持领域团队，以便他们能够快速构建数据产品并在其隔离区域的生产中运行它。该平台应该支持领域团队发布他们的数据产品，以便其他团队可以发现它们。这一发现需要所有去中心化数据产品的中心入口点。数据目录可以通过不同的方式实现：作为wiki、git存储库，甚至已经有基于云的数据目录的供应商解决方案，例如SelectStar、Google数据目录或AWSGlue数据目录。然而，数据产品的实际使用需要领域团队访问、集成和查询其他领域的数据产品。平台应支持、监控和记录数据产品的跨域访问和使用。

更先进的数据平台支持策略自动化。这意味着，不是强迫域团队手动确保不违反全局策略，而是通过平台自动执行策略。例如，所有数据产品在数据目录中具有相同的元数据结构，或者在数据摄取期间自动删除PII数据。

有效地组合来自多个域的数据产品，即在几秒钟内进行大型跨域连接操作，确保了开发人员的接受度和满意度。这就是为什么查询引擎对数据平台的架构有很大的影响。具有单一查询语言并支持独立区域的共享平台是一个很好的起点，因为一切都高度集成。这可能是GoogleBigQuery，其中包含多个项目中的表，可通过GoogleDataCatalog发现这些表。在更加分散和分布式的数据网格中，诸如Presto之类的分布式查询引擎仍然可以在不导入数据的情况下执行跨域联接，但它们有其自身的局限性，例如有限的下推要求需要传输所有底层列数据。

四 数据网格示例

当团队使用其他领域的数据产品时，就会出现网格。使用来自上游域的数据可以简化数据引用和查找(例如获取文章的价格)，而来自下游域的数据可以分析效果，例如A/B测试(例如转化率的变化)。来自多个其他领域的数据可以聚合以构建全面的报告和新的数据产品。

让我们看一个简化的电子商务示例：

域可以根据数据特征和数据产品用途进行分类。我们采用ZhamakDehghani的分类：

1.源对齐

在此示例中，在线商店沿着客户旅程细分为多个域，从产品搜索到结账再到支付。在数据网格中，这些域将其数据作为数据产品发布，以便其他人可以访问它们。工程师对自己的数据进行分析，以改进他们的操作系统并验证新功能的商业价值。他们使用域邻居的数据来简化查询并深入了解下游域的影响。这些领域数据可以称为源对齐的，因为它们发布的大多数数据产品与其操作系统中生成的领域事件和实体密切对应。

2.聚合的

对于复杂的子系统，团队只专注于交付由其他领域的各种数据产品聚合而成的数据产品，这可能是高效的。一个典型的例子是360°客户视图，其中包括来自多个领域的相关数据，例如帐户数据、订单、发货、发票、退货、帐户余额和内部评级。对于不同的有界上下文，全面的360°客户视图很难构建，但它可能对许多其他领域有用。复杂子系统的另一个例子是构建需要增强数据科学技能的复杂机器学习模型。明智的做法是，数据科学家团队使用结账数据和360°客户视图来开发和训练推荐模型，而另一个团队则使用该模型并专注于在在线商店或促销电子邮件中呈现计算出的推荐。

3.消费者导向

在公司中，还有一些业务部门需要来自整个价值流的数据来做出明智的决策，这些部门的人员是业务专家，但不是工程师或技术专家。管理和控制需要来自所有领域的详细报告和KPI来识别优势和偏差。营销人员使用自己的优化工具(例如GoogleAnalytics或AdobeAnalytics)对客户旅程中的所有步骤进行漏斗和网络分析。在这些领域中，数据模型针对特定部门的需求进行了优化，因此可以被描述为消费者一致的。与消费者保持一致的报告通常是中央数据团队的主要任务之一。通过数据网格，面向消费者的领域团队专注于满足某一特定业务领域的数据需求，使他们能够获得深入的领域知识并不断开发更好的分析结果。通过构建集成的领域团队或通过工程团队为业务提供领域数据即服务(例如支持C级或控制)，业务和IT的联系更加紧密。他们的数据通常用于分析和报告，但不需要作为其他领域的数据产品进行发布和管理。

五 域团队的建设过程

正如数据团队还有一段旅程要继续一样，每个领域团队也必须继续一段旅程，成为数据网格的贡献者。每个团队都可以在准备好时按照自己的节奏开始他们的旅程。好处已经在旅途中显现出来。团队将很快从第一个数据驱动的决策中获益，开始大量使用更多、更好的数据来获得更深入的见解。数据网格随着每个将数据作为产品共享的团队而发展，从而实现数据驱动的创新。

为了使这一过程取得成功，团队需要三件事：高层管理人员清晰的数据网格愿景，让每个人都朝着同一个方向前进;支持性环境，包括易于使用的自助数据平台，让工程团队能够继续工作数据分析的学习路径，以及以自己的方式和步调行走旅程的高度信任环境。

1.0级没有数据分析

您的团队负责一个领域并构建和运营独立的系统包括必要的基础设施。构建这些系统需要付出相当大的努力，而且高度关注卓越的交付。这些操作系统现在生成域数据。

数据分析根本不相关。

2.1级操作数据库查询

在生产中，您可能必须调查事件并需要分析有多少客户受到影响。此外，一些利益相关者可能对您的数据有疑问，例如“哪些库存商品在过去六个月内尚未售出?”或“上一个黑色周期间的运输时间是多少?”要回答所有这些问题，您可以向操作数据库发送分析查询。随着时间的推移，您还可以进行一些初步的探索性分析，以更深入地了解系统的行为。

这会增加生产数据库的负载，并且您可能会想要更改生产数据库以更好地支持分析查询，例如创建其他索引。您可以将额外的负载卸载到只读副本。但分析查询的编写仍然缓慢且繁琐。

3.2级分析自己的数据

考虑到分析查询缓慢且难以编写的痛苦，您尝试了数据平台团队正在推广的自助数据平台。例如，您现在可以访问GoogleBigQuery。在此平台上，您的团队开始通过从Kafka获取消息来构建分析数据模型。这是您的第一个数据产品。该数据平台允许您通过可维护且快速的查询来分析覆盖您自己系统的数据，同时保持操作数据库的架构不变。您将学习如何构建、预处理、清理、分析和可视化分析数据，尽管其中大部分是您已经熟悉的SQL，但需要学习的内容还有很多。

由于现在可以快速回答有关您自己的数据的问题，您和您的产品负责人现在进入了制定数据驱动决策的周期：定义假设并用数据进行验证。

4.3级分析跨域数据

分析您自己的领域数据是一个很好的开始，但将其与其他领域的数据相结合才是神奇的开始。尽管数据分散，但它可以让您获得全面的视图。例如，针对UI更改对转化率的影响进行A/B测试，或者构建用于欺诈检测的机器学习模型，其中包括之前的购买历史记录和当前的点击流行为。这要求其他团队以您的团队可以发现、访问和使用的方式共享他们的数据产品。这是网格开始自行形成的时候。

当团队成为数据网格的消费成员时，它开始对数据网格的互操作性和治理产生兴趣。理想情况下，团队将向数据网格治理小组派遣一名代表。

如果您是第一个团队，您可能必须暂时跳过此步骤并进入第4级并成为第一个为其他人提供数据的人。

5.4级发布数据合约

根据其他团队的需求，您可以通过发布数据合约的方式与其他团队共享您的数据。例如，您提供已确认、已拒绝和已中止的订单，以便其他人可以将其事件与转化率相关联。您不再只是数据产品的消费者，而是数据产品的发布者。您为其他团队创造价值。但同时，从长远来看，它会增加您的责任和运营职责。

发布的数据产品必须符合联合治理组定义的全局策略。你必须了解并理解当前的全球政策。现在，您最迟需要参与联邦治理小组并为其做出贡献。

六 数据团队的建设过程

数据网格主要是一种组织结构，并且完全符合团队拓扑的原则。它将数据的职责转移给由数据平台团队和数据支持团队支持的领域团队。所有团队的代表聚集在一个联合治理小组中来定义共同标准。

如今，在许多组织中，中央数据团队负责广泛的分析任务，从数据工程和管理数据基础设施到创建C级报告。这样的中央数据团队会遭受认知超载，包括领域、技术和系统知识。数据网格缓解了这一点。

数据网格为中央数据团队成员提供了新的视角，因为他们的分析和数据工程技能仍然非常必要。例如，它们非常适合为喜欢在基础设施上工作的人们建立数据平台。他们中的一些人可以组建一个数据支持团队作为内部顾问，帮助领域团队完成他们的旅程。无论他们的新角色如何，他们中的许多人都将在数据网格联合治理组中再次聚会，共同塑造数据网格的未来。

然而，真正的思维转变发生在创建新的以数据为中心的领域时，如上图所示。让我们看一下大型中央数据团队通常基于整体数据仓库或数据湖生成的典型管理报告。通过数据网格，创建这些管理报告的数据工程师与专门的产品负责人一起构建了一个新的领域团队。作为新领域团队的工程师，他们现在可以专注于新领域和消费者。这使他们能够随着时间的推移获得深入的领域知识，从而产生更好的报告和持续优化。此外，他们从使用单一数据仓库转向使用其他领域的数据产品。这种转变是由数据产品需求驱动的渐进过程，加速了数据网格的形成。产品负责人与其他领域团队就所需的数据产品进行协商，并确保新领域团队将来构建的报告和其他产品能够满足业务需求。

随着现有领域团队在其旅程中进行越来越多的数据分析，中央数据团队成员的另一个观点是加入其中一个团队。凭借现有知识，他们可以向团队中的其他人传播和教授他们的知识和技能，从而加速领域团队迈向数据网格的旅程。重要的是，他们要成为团队的正式成员，而不是在领域团队内建立数据子团队。除了他们的知识和技能之外，数据工程师还可以将中央数据团队的职责和工件带到他们的领域团队中。例如，以前由中央数据团队完成的客户分析将由推荐领域团队负责。

数据科学家通常也是集中组织的。这就是为什么他们的未来在组织方面与中央数据团队的未来非常相似。他们关注的数据网格中的数据产品是机器学习功能和模型。当加入现有的领域团队时，这样的机器学习模型可能会完全集成到微服务中。因此，数据网格能够实现此类基于机器学习的服务，因为所需的MLOps功能可以方便地构建在数据网格之上。