数据架构的三大纠缠趋势：数据网格、数据编织和混合架构

一本关于如何调和看似相似但不同的趋势的入门书，这些趋势使数据团队难以解决棘手的“一次无处不在”的问题。

数据团队有一项不可能完成的任务，即一次在任何地方（在本地和所有云中）交付所有内容（数据和工作负载）（几乎没有延迟）。他们在处理必须使用混合架构的现实时，被关于看似独立的新趋势（如数据网格和数据编织）的文献轰炸。这些趋势中的每一个都声称是其数据架构的完整模型，以解决“一次无处不在”的问题。数据团队对于他们是否应该只追随这些趋势之一或选择一个组合感到困惑。从他们现在的数据架构到“理想状态”似乎也没有一条连贯的道路， 这将使他们最终实现成为“数据驱动型组织”的梦想。

在本文中，我们试图展示这些概念如何相互关联，甚至建议同时考虑所有这些概念（喘气！）。我们还将建议客户可以采取的一条路径，从他们所在的地方到他们想要使用他们的数据架构的地方。

首先，我们描述了数据网格和数据编织如何相关联。然后，我们将混合架构添加到组合中，因为它们会一直存在，并且不会只是“在我们都迁移到云端之前的临时状态”。

数据网格（Data Mesh）定义

数据网格是一个概念，用于帮助以可管理的方式扩展公司的数据足迹。它是一组围绕人员、流程和技术 选择的准则，允许公司扩展其数据系统。

图 1. 数据网格概念层次结构

Miro：https ://miro.com/app/board/uXjVO_mem4k=/

与其拥有一个管理公司所有数据的中央团队，不如说应该根据最适合生产和拥有的团队在整个公司范围内分配生成、策划、记录、更新和管理数据的责任那个数据。公司中的每个团队都是该团队拥有的产品或业务功能产生的数据领域的领域专家。该团队或领域专家将对团队产生的数据负责。然后将数据本身视为产品。数据产品不仅仅是数据本身，而是围绕它的一堆元数据——像模式这样简单的东西是给定的。但是更多的动态信息，如新鲜度、统计数据、访问控制、所有者、文档、数据的最佳用途和沿袭，也需要被视为数据产品和数据接口的一部分。

图 2. 数据网格示例

上图中显示了一个数据网格示例，其中包含数据应用程序、数据产品和数据订阅。

1. A1、A2 是数据应用

2. D1、D2等都是数据产品

3. 应用订阅数据产品并生产数据产品

请注意，用于生成、存储和查询实际数据的实际技术可能会有所不同——数据网格甚至没有规定。它也与托管不同域的位置无关。一些域可以在本地，而其他域可以在云中。

数据编织的定义

实现数据网格的一种方法是在数据编织框架内进行技术选择。Data Fabric 是一组技术，用于随时随地（在本地或云中）摄取、存储、处理和管理数据。数据网格是关于人、流程和技术的。数据编织可以看作是数据网格的技术部分。数据网格中的概念映射到数据编织实现中的真实世界工件。

图 3. 映射到数据编织实体的数据网格概念

图 2 中数据网格实现的相应数据编织示例如图 4 所示。

图 4. 对应于图 2 中数据网格示例的数据编织实现

在数据编织实现中，数据网格中的概念映射到数据架构中的真实世界工件。对应于图 4 中的数据网格示例，

1. D1、D2 是数据仓库中的表

2. A1 是一个具有摄取和 SQL 语句管道的应用程序，经过精心编排以按特定计划运行

3. A2 是作为 Spark 作业构建的应用程序，经过精心编排，可在某些数据出现时运行

仅当订阅跨形态或区域时，订阅才能实现为相反方向的复制。透明复制是数据编织中的一项关键功能，它允许在将要使用数据的位置提供数据。底层复制引擎可以将源（生成和更新时）表的更改复制到所有消费者（订阅了数据）。

定义的混合数据架构

“现代数据”的想法是，那些不是在云中诞生或无法完全迁移到云的公司都是在吹捧混合架构的公司。但即使所有计算和存储资源的最终目的地是云，也将有一个不平凡的过渡期。公司将不得不花时间将数据和工作负载迁移到云端。在此期间，根据定义，它们将具有混合架构。因此，业界的要求很明确：必须使混合数据架构变得可行——并且它们将继续存在（在可预见的未来）。

例如，销售团队可能正在犹他州本地数据中心的 teradata 仓库中生成销售数据。然后，研发团队希望将销售数据与他们在 Azure 的 us-west-2 区域的 Snowflake 数据仓库中可能拥有的其他数据集相结合。混合架构应允许研发团队订阅销售数据，并在源数据更改时自动复制数据。

混合架构是用于摄取、存储、处理、管理和可视化不同形式因素的数据的技术选择——在本地以及多个云中，可能会根据需要复制数据。因此，混合架构可以被认为是跨多种形式因素的数据编织的实现。

混合架构可以允许数据生产者在数据中心的本地数据仓库中生成数据和表，并允许云中的数据消费者订阅这些表。对于在云中生成并在本地数据中心使用的数据集，也会发生同样的情况。

Cloudera 一直致力于混合数据架构。您可以在https://blog.cloudera.com/the-future-is-hybrid-data-embrace-it/阅读更多相关信息。通过 Innovation_feedback@cloudera.com 与我们联系，了解我们如何帮助您利用数据架构之旅中的最新数据趋势，成为数据驱动型组织。

资源

什么是数据网格合约？

我们相信元数据——无论是静态的还是动态的——必须在所有数据产品中保持一致，即元数据的数据模型必须是一致的，而与使用的底层技术无关。该数据模型也是在数据的生产者和消费者之间定义的合约结构。 消费者订阅数据生产者生产的数据产品。

混合架构的不同定义是什么？

混合数据架构有很多定义。混合有严格的定义，能够在不同位置之间自动无缝迁移数据工作负载，例如从本地部署到任何云，或从一个云到另一个云。但目前尚不清楚该定义是否真的是市场所需要的。肯定需要更多的客户开发，但公司更有可能想要一个可能更简单的定义，其中混合允许公司不受特定技术或数据生产和消费地点的限制。

还有什么类似于数据网格的？

数据网格和目前正在构建的数据交换之间存在一些思想重叠——如Snowflake数据交换、亚马逊数据交换等。这些交易所纯粹被视为生产者/消费者市场，通常没有与之关联的查询功能。目前尚不清楚这将如何在未来发挥作用。

数据网格也与数据虚拟化有关，因为通过数据虚拟化，人们可以在他们自己的查询引擎中无缝地查询其他人生成的数据。Starburst with Trino 现在正在这样做。Denodo 是数据虚拟化领域较为成熟的参与者之一。具有 Spectrum 和 Athena 的 Amazon Redshift 以及能够从 RDS 进行查询的其他示例。

早在 2011 年，Facebook 在构建足够大的集群以容纳所有数据时遇到了问题。解决这个问题的项目不仅解决了规模问题，还为数据的生产者/消费者模型提供了蓝图。团队将拥有一个“命名空间/数据库”（域）以及该命名空间中的所有数据。然后，团队将在其命名空间中“发布”特定表作为可公开引用的。然后其他团队可以订阅这些表，并获得一个近乎实时的复制表，该表可与他们自己的表一起查询。Hive 表链接( EP2767913A1)是该项目的成果之一。

原文作者：Raghotham Murthy

原文链接：https://blog.cloudera.com/the-top-three-entangled-trends-in-data-architectures-data-mesh-data-fabric-and-hybrid-architectures/