数据网格和企业数据架构的未来

什么是数据网格，它是如何工作的？

数据网格是围绕业务领域组织的数据生态系统模型。它通过自助服务功能进行管理，使跨职能团队能够管理、服务并最终拥有其域中的数据。它可以生成不同的数据产品，为关键业务流程和决策提供信息。

数据网格的三个主要组件

1. 在联合治理下，域数据的所有权

在数据网格体系结构中，数据主要存在于不同域或主题区域的基础结构中，这些域或主题区域对应于不同的业务关注点，例如销售和客户支持。每个域可能都有自己的架构。

跨职能团队（包括产品经理、开发人员、业务分析师以及每个域中的其他人）可以自主地处理自己的数据，并根据需要与其他域共享。这些团队是数据存储位置以及如何加载和转换数据的专家。在某些情况下，他们可能会使用自己的专用数据湖或数据中心将多个数据源连接到其数据网格部分。

每个团队都可以拥有自己的物理数据网格基础结构来管理其域数据。然而，多个架构的共置也是有效的，特别是对于来自经常相互连接的不同域的数据集：如果它们存储在同一个数据库中，它们的性能会更好。因此，数据网格可以是物理的或逻辑的企业数据架构。

即使所有权按域划分，联合治理也有助于防止其变得难以管理。数据互操作性和质量标准，加上DevOps文化，确保了这种数据治理。

2. 关于数据集的产品思考

由于每个业务域都是其各自独立的单元，因此存在域数据变得过于分散的风险，以至于它破坏了整个企业高效协作的前景。这就是应用于企业数据集的产品思维概念在实现数据网格的全部价值方面产生重大影响的地方。

每个域团队都应将其数据资产视为数据产品的组件，其“客户”是组织中的其他用户，例如开发人员或数据科学家，他们需要轻松安全地访问它。例如，人工智能（AI）数据工程师可能需要来自电子健康记录（EHR）系统内运行的程序的分析数据，以改进该软件的算法。

数据网格可以通过连贯的数据产品在整个企业中提供这种程度的便利。每个产品都应该是：

• 可发现：数据产品进入数据目录，其中包含有关其所有权和内容的元数据。此设置可帮助用户可靠地找到所需内容。
• 可寻址：每个可发现的产品也应该是唯一可识别的，以便可以对其进行寻址。在包含各种数据格式（从CSV到公共云存储桶）的环境中，这种编程访问的一致标准至关重要。
• 值得信赖：数据网格平台旨在对域数据所有者制定服务级别目标，管理其数据产品的可信度。这些产品通常不需要更传统、更严格的集中式数据体系结构中常见的相同级别的大规模数据清理。
• 自描述：数据产品应为其预期的数据使用者提供清晰的语义、语法和数据库模式。在数据网格中工作时，“我该怎么使用它？”应该很少（如果有的话）成为一个问题。
• 可互操作：数据网格中的数据产品应跨域相关。例如，将它们连接起来应该很简单，并且不会受到元数据字段或格式差异的阻碍。

将数据网格视为相当于关税同盟的企业数据管理，就像欧盟一样。每个国家都是自己的自治实体，但同时遵守与其他成员交换产品和服务的某些总体标准。同样，域数据团队独立工作，但也遵循各自数据产品特征的全球“规则”。

3. 通过数据基础设施即平台进行自助服务

数据网格的分布模型似乎意味着存在许多重复的数据管道和存储基础架构，每个域一个。这种设置会产生技术复杂性，阻碍快速和可操作的见解。但是，您可以使用与域无关的数据基础架构平台来规避这一点，该平台为企业中的每个团队提供相同级别的自助服务。

这样的数据平台隐藏了潜在的复杂性，并简化了存储、处理和提供数据产品的流程。在当前的云趋势和许多企业现在居住的多云世界中，数据网格应该提供：

• 以任何格式引入任何分布式数据源，在任何维度（例如，查询的数据量或复杂性）或数据架构复杂程度方面具有可伸缩性。
• 多种云可选，以便企业可以使用其分析生态系统最符合当前性能和价格要求的云服务提供商。
• 支持跨本地资源和公共云服务的混合部署。
• 一种开放式设计，使团队能够在构建其域数据产品时使用自己的库、他们已知的语言（SQL、R等）和有据可查的API。
• 集成AI和机器学习（ML），缩短从分布式数据进行高级分析的时间。
• 计算和存储分离，动态满足用户需求，无需IT干预或浪费容量。
• 轻松控制，用于管理混合工作负载并满足多个应用程序的服务级别协议。

为什么选择数据网格？它与其他数据架构的比较

总体而言，数据网格可以提高团队在云中工作的敏捷性，并不断扩大数据源和以创新为中心的项目。

在一个数据源相对较少且整个企业中用例范围狭窄的世界中，传统的数据架构就足够了。但现在，这些集中式模型可能会为需要快速从原始数据源迁移到见解的团队带来瓶颈。

想象一下如果有一个人，比如我们前面提到的在EHR系统上工作的假设AI数据工程师，需要创建一个新的数据产品来满足快速变化的业务需求。它们可能会变慢，因为它们无法自行更改相对较小且不同的组件以进行数据摄取和处理——它们必须让其他人参与并修改整个数据管道。

这种情况就是为什么旧的数据架构通常被描述为“单体”架构——改变它的一部分意味着改变所有部分。相比之下，数据网格平台更像是微服务架构，具有可由多个团队处理的可单独更新的组件。

通过数据网格可实现的灵活性和敏捷性是将其与专门基于集中式数据仓和数据湖构建的其他数据架构区分开来的原因。

数据仓 vs. 数据湖 vs. 数据湖仓与数据网格

这四种数据设计模式并不相互排斥——例如，它们可能在企业中共存，并且具有自己的数据湖的跨职能领域团队。但是，从数据仓到数据湖再到数据网格，由于需要克服某些架构限制，存在可追溯的演变。

数据仓

• 它是什么：一种主题型数据架构，以一致的方式集成详细数据，同时保持其非易失性历史记录。
• 优点：从大量精选数据中生成可操作的见解（例如，在仪表板中），包括创建预测分析和仪表板以推动运营操作。它将来自所有企业源的数据聚合到一个中心位置，并具有一致的治理，支持用于新想法测试的沙盒。
• 局限性：不适用于需要从大量原始数据中存储和提取价值的大数据用例，例如由物联网设备以及网页和移动源创建的大数据用例。

数据湖

• 它是什么：一组长期数据容器，用于管理和优化原始数据，使用通常从云端交付的低成本对象存储。
• 优点：捕获以前丢弃的 “暗数据”以推动以后的创新，并按原样存储数据，而无需先构建数据。该湖还允许人工智能和机器学习服务分析原始信息，有效地捕获见解。
• 局限性：可用于数据湖的现成工具相对较少，这需要丰富的开源软件经验。由于治理有限，孤岛的风险也很高，并且在安全性和易访问性之间平衡问题可能非常困难。

数据湖仓

• 它是什么：数据仓和数据湖的组合。
• 优点：使企业能够通过SQL，机器学习或任何其他过程在数据仓模式下系统地提取见解，同时利用数据湖的庞大规模和低成本。
• 局限性：添加新功能的敏捷性有限，因为一切都是集中的和单一的。数据工程师最终会花费大量时间来清理来自团队的数据，而这些团队缺乏动力确保他们输入信息时的准确性。

数据网格

• 它是什么：一种域名驱动的数据设计模式，在逻辑上或物理上在这些领域工作的团队之间划分。
• 优点：数据网格允许最靠近它的团队自主主动管理数据，并且，因为没有中央瓶颈，可以促成敏捷性的提高。每个团队都可以创建自己的数据产品。
• 局限性：这是一个相对较新的架构，企业仍在努力改进。性能和治理可能会受到影响，因为用户每次都需要通过网络访问不同的数据。如果没有跨域治理和数据语义链接，它可能会变得非常孤立，并产生令人失望的结果。

数据网格可能成为未来数据架构的三个原因

即使有早期的局限性，数据网格也可能成为未来的数据架构，主要有三个原因：

1. 提高敏捷性和卓越的组织扩展

数据网格使团队能够按照自己的方式访问和使用数据，而不必通过单个中央企业范围的数据仓或数据湖的瓶颈。他们可以使用自己的数据仓和数据湖作为数据网格中的节点，加载和查询其域数据，并更快地创建数据产品。

数据工程师不再承担对转储到中央数据仓或湖中的所有不同信息进行分类的负担，因为数据是在许多较小的域中管理的。因此，组织中的每个人都可以使用自助服务数据基础架构平台更快地响应更改并根据需要扩展其工作负载。

2. 明确的数据所有权和问责制

在数据网格出现之前，企业数据的所有权往往不明确，甚至有争议。不同领域的运营团队将他们的数据发送到一个集中的位置，在那里由与组织其他部分隔离的专业数据工程师处理。

这些工程师面临着处理来自他们不一定具有专业知识的领域的数据的艰巨任务。它们还充当了处理同一项目的领域团队之间的中介，致力于创建可供所有人使用的数据集。

在数据网格中，由于领域驱动的设计，所有权是明确的。团队可以遵循自助服务和拉取的方法（而不是上述传统的推送和摄入的方），其中不同的团队在他们熟悉的域中工作，在整个企业中提供数据产品，并根据需要访问其他团队的产品。

3. 提高数据质量和与DevOps一致的文化

由于数据所有权在数据网格中显而易见，因此团队在分发数据产品之前有更大的动力来确保其数据产品的质量。数据网格概念与DevOps基准的紧密联系进一步提高了质量。

DevOps强调通过跨职能团队进行协作，同时持续监控和优化产品。当DevOps原则（如将工作分解为更小、更易于管理的部分以及创建共享的产品愿景）应用于数据网格时，数据架构的不同组件更易于使用、迭代和维护。

这样，更高质量的数据产品可以更快地交付。正如DevOps既是一种文化运动，也是一种技术运动，数据网格需要正确的文化——强调问责制和协作——才能使其技术使业务受益。DevOps本身有助于实现这种文化变革。

构建数据网格：开始之前的关键注意事项

在深入研究数据网格之前，企业应该首先考虑一些关键因素，例如：

规模和业务要求

数据网格非常适合具有众多来源和域的大型组织，在这些组织中，团队之间在谁拥有什么方面存在潜在的摩擦。

如果组织确实选择了数据网格，那么域的分布应该与实际的业务计划紧密结合，例如创建全渠道客户体验或供应链优化。这种一致性为领域数据团队创造了更明确的目标，并确保数据网格提供真正的业务价值，而不仅仅是一个实验。

数据管理和治理专业知识

尽管每个域团队都拥有自己的数据，但这并不意味着不需要企业范围的协调和治理。现代工具使人们更容易开始使用复杂的工作负载，但这些工具的选择和实施仍然需要专家的全面监督。

数据管理专家在指导每个团队开发其流程和产品方面也很有用。在经验丰富的指导下，尽早解决这些问题，可以节省整个公司以后这样做的时间和费用。

架构主机代管和性能

每个域应该有一个单独的数据模式，以消除使用一个模式处理所有数据所产生的瓶颈。在某些情况下，出于性能原因，架构应位于同一位置并进行连接。同时也要记得跨数据网格内所有域的数据集成至关重要。这样做将使您的组织能够通过数据放置策略来推动业务导向的绩效。

这些步骤为高度复杂、经常与其他数据集联接并定期重复使用的工作负载提供了速度和成本的最佳组合——只要高性能数据结构业已存在。

展望数据网格的前景

虽然分布式数据所有权本身并不是一个新概念，但数据网格所需的特定方法足够新，以至于它的实际实现仍然很少见。

但是，许多组织已经在发展其设计模式和云解决方案，以加速数据模型开发，并以与数据网格的影响非常相似的方式更好地为客户提供服务。联系我们，详细了解这一新兴且令人兴奋的数据设计概念的潜力。

了解有关数据网格的详细信息