基于拓扑的数据架构理解

数据架构可以根据其操作模式或拓扑进行分类，包括数据结构、数据中心和数据网格。这些有什么区别？系好安全带。

之前，当我解释基于速度的数据架构时，我详细介绍了 Lambda 和 Kappa 架构。但这仅仅是故事的开始。

数据架构可以根据数据速度进行分组，例如 Lambda 和 Kappa，另一种分类方法是技术无关的操作模型。如果您一直关注此数据基础系列，您肯定还记得，任何组织中都存在三种类型的操作模型：集中式、分散式和混合式。

在这里，我将更详细地描述三种基于拓扑的数据架构：数据结构、数据网格和数据中心。

集中式数据架构：数据中心

数据中心是集中管理数据的架构。可以将其视为一个数据交换中心，其核心是无摩擦的数据流。

数据中心充当信息中心存储库，与其他系统和客户连接，允许它们之间共享数据。端点通过向数据中心提供数据或从数据中心接收数据与之交互。中心提供了一个中介和管理点，使企业内的数据流动方式可见。

数据中心架构通过连接数据的生产者和消费者来促进这种交换。开创性的工作是 Gartner 的研究论文《实施数据中心：架构和技术选择》，于 2017 年发表。Gartner 建议了一种技术中立的架构来连接数据的生产者和消费者，这比点对点替代方案更有优势。随后的研究进一步发展了这个概念，导致了目前对数据中心属性的定义。

中心根据其用户定义的模型进行结构化和使用。数据管理员制定治理策略以确保数据隐私、访问控制、安全、保留和安全信息处置。开发人员可以使用 API 或提取-转换-加载 (ETL) 过程等集成策略来处理存储在中心内的数据。持久性属性定义应使用哪种类型的存储库来存储这些数据（例如数据湖、数据仓库或数据湖仓库）以及存储的不同参数，例如原始支持、存储系统和存储层。

实施数据中心架构有助于

• 将常用数据整合和简化为一个中心点
• 建立有效的数据控制系统以提高数据质量
• 确保数据流的可追溯性
• 提供对公司活动的统计监控
• 提高对交换数据的了解
• 逐步建立公司数据模型

Gartner 建议企业可以使用专门的、专用数据中心。例如，分析数据中心可能会收集和共享信息以供下游分析过程使用。或者，应用程序数据中心可以用作特定应用程序或套件的域上下文。

在数据中心中实施数据集中化确保数据从中心源管理，并保持统一的愿景，同时确保数据可从许多不同的点访问。这样做的好处是它可以最大限度地减少数据孤岛，促进协作，并提供对整个企业中出现趋势和影响的可见性。

但是，数据集中化也存在挑战。如果没有加速器或某种自助服务策略，流程可能会很慢。结果，请求完成的时间越来越长。企业无法快速前进，改善客户体验和提高收入的机会就会失去，仅仅因为它们无法快速实现。

这是 Gartner 最近更新数据中心概念的原因之一，它允许组织以互联方式运行多个中心。这样，数据中心可以利用数据集中化并通过赋予业务线更多责任和权力来利用分散化。

数据中心最常见的用途是数据仓库。数据仓库是一个用于报告和分析的中心数据中心。通常，数据仓库中的数据是高度格式化和结构化的，用于分析用例。因此，它是最古老、最完善的数据架构之一。

1989 年，Bill Inmon 提出了数据仓库的概念，他将其描述为“一个面向主题、集成、非易失性且随时间变化的数据集合，以支持管理的决策。”虽然数据仓库的技术方面已经发生了重大变化，但原始定义仍然具有重要意义。

传统上，数据仓库使用 ETL 从应用程序系统提取数据。提取阶段从源系统提取数据。转换阶段清理和标准化数据，以高度建模的形式组织和实施业务逻辑。

ETL 的一种变体是提取-加载-转换 (ELT)。在数据仓库架构的 ELT 模式下，数据或多或少直接从生产系统移动到数据仓库中的暂存区域。在这种情况下，暂存表示数据处于原始形式。而不是使用外部系统，转换直接在数据仓库中处理。数据以批处理方式处理，转换后的输出写入表和视图以供分析使用。

在大数据时代开始时，数据湖作为另一种集中式架构出现。其理念是（也是现在）创建一个中心存储库，在该存储库中存储所有类型的结构化和非结构化数据，没有任何严格的结构限制。数据湖旨在通过提供无限的数据供应来赋能企业。

数据湖的最初版本始于 Hadoop（HDFS）等分布式系统。随着云变得越来越流行，这些数据湖迁移到基于云的对象存储，这可能取决于极低的存储成本和几乎无限的存储容量。数据湖不会依赖于存储和计算紧密耦合的单片数据仓库，而是存储了各种大小和类型的海量数据。

它引起了很多炒作。但是，第一代数据湖（数据湖 1.0）存在重大缺陷。数据湖本质上变成了一个垃圾场，产生了诸如“数据沼泽”和“暗数据”之类的术语，因为许多数据项目未能实现其最初的承诺。随着数据量呈指数级增长，管理变得越来越困难，并且缺乏模式管理、数据编目和发现工具。此外，最初的数据湖概念本质上是只写，这给 GDPR 等法规的到来带来了巨大的麻烦，这些法规要求有针对性地删除用户记录。数据处理也是一项重大挑战，相对基本的数据转换（例如联接）需要实现复杂 MapReduce 作业。

各行各业的参与者一直在努力改进数据湖概念，以充分发挥其潜力并应对第一代数据湖的局限性。例如，Databricks 推出了数据湖仓库的概念，它建议将数据湖和数据仓库融合在一起。数据湖仓库包含数据仓库中发现的控制、数据管理和数据结构，同时仍将数据存储在对象存储中并支持各种查询和转换引擎。特别是，数据湖仓库支持原子性、一致性、隔离和持久性 (ACID) 事务。这与最初的数据湖有很大不同，在最初的数据湖中，您只需将数据导入，永远不会更新或删除它。

分散式数据架构：数据结构

数据分散化是一种数据管理方法，它通过在组织部门之间分发数据存储、清理、优化、输出和使用来消除对中心存储库的需求。这有助于在处理大量数据时降低复杂性，并解决诸如模式更改、停机、升级和向后兼容性等问题。

数据织网最初被创建为一个分布式数据环境，它能够从各种存储库中摄取、转换、管理、存储和访问数据，用于商业智能 (BI) 工具和运营应用程序等用例。它提供了一个互连的网络层，通过利用对当前和推断的元数据资产的持续分析，来集成与数据相关的流程。为了最大化效率，它使用了诸如主动元数据管理、语义知识图谱和嵌入式机器学习/AutoML 功能等技术。

这个概念在 2016 年由 Forrester Research 的 Noel Yuhanna 在 Forrester Wave: Big Data Fabric 中提出，并在之后得到了更新。Yuhanna 的论文描述了一种面向技术的方法，它将不同的数据源整合到一个统一的平台中，使用 Hadoop 和 Apache Spark 进行处理。目标是通过创建一个自动化的语义层来提高敏捷性。这将有助于加速数据价值的交付，同时最大限度地降低管道复杂性。

多年来，Yuhanna 进一步发展了他的 Big Data Fabric 概念。他对数据织网的当前愿景是，它们可以解决某些类别的业务需求，例如创建对客户、客户智能和与物联网相关的分析的全面视图。数据织网的组件包括 AI/ML、数据目录、数据转换、数据准备、数据建模和数据发现。它还提供了治理和建模功能。

Gartner 也采用了“数据织网”这一术语，并对其进行了类似的定义。这家分析公司将其描述为“一种新兴的数据管理和集成设计，它能够支持各种运营或分析用例，跨越多个部署平台，提供灵活、可重用且增强的的数据集成管道、服务和语义”。

数据织网结合了不同的数据集成技术，同时使用主动元数据、知识图谱、语义和机器学习 (ML) 来改进其设计过程。它们将这些技术组织成五个内部属性。

在织网中，主动元数据包含被动数据元素的目录，例如模式、字段类型、数据值和知识图谱关系。知识图谱存储和可视化多个数据实体之间复杂的关联关系。它维护数据本体，帮助非技术用户解释数据。

在 AI 和 ML 功能的帮助下，数据织网可以帮助和增强数据管理活动。它还提供了集成功能，可以动态地将不同的数据摄取到织网中进行存储、分析和访问。自动化数据编排允许用户在整个过程中应用 DataOps 原则，以实现敏捷、可靠和可重复的数据管道。

数据织网是一种与技术无关的架构。它的实现允许您为批处理过程和实时流式传输扩展大数据操作，从而在云、混合多云、本地和边缘设备上提供一致的功能。它简化了不同环境之间信息的流动，以便为分析应用程序或业务流程提供一组完整的最新数据。通过提供预配置的组件和连接器，它减少了时间和成本，因此无需手动编码每个连接。

去中心化数据架构：数据网格

数据网格于 2019 年由 Zhamak Dehghani 提出，他认为 去中心化的架构是必要的，因为集中式数据仓库和数据湖存在缺陷。

数据网格是一个框架，它允许业务领域拥有和操作其特定领域的数据，而无需集中式中介。它借鉴了分布式计算原理，在这种原理中，软件组件在作为系统一起运行的多个计算机之间共享。这样，数据所有权分散在各个业务领域，每个领域负责创建自己的产品。从理论上讲，数据网格可以更容易地对收集的信息进行语境化，从而生成更深入的洞察，同时促进领域所有者之间的协作，根据特定需求创建定制的解决方案。

Dehghani 后来修改了他的立场，提出了构成这种新范式的四个原则：面向领域、数据即产品、自助服务和联邦治理。

面向领域

数据网格的概念基于将分析数据、其元数据以及为最接近数据的人提供服务所需的计算的责任去中心化和分布式。这使得组织的数据生态系统能够持续变化和扩展。

为了实现这一点，数据网格会将组件分解成组织单元或业务领域，这些单元或领域将更改或演变本地化到该边界上下文中。通过这样做，这些组件的所有权可以分布在最接近数据的利益相关者之间。

数据即产品

现有的分析数据架构的一个问题是，发现、理解、信任和使用高质量数据可能很困难且昂贵。随着更多团队以去中心化的方式提供数据（领域），这个问题只会变得更糟，这将违反第一个原则。

为了解决与数据质量和数据孤岛相关的挑战，数据网格必须将领域提供的分析数据视为产品，并将该产品的消费者视为客户。该产品成为新的架构单元，应该作为单个量子进行构建、部署和维护。它确保数据消费者可以轻松地在多个领域中发现、理解和安全地使用高质量数据。

自助式数据基础设施

基础设施平台允许领域团队自主创建和使用数据产品，而无需担心构建、执行和维护安全且可互操作解决方案的底层复杂性。自助式基础设施应该提供一个简化的体验，使数据领域所有者能够专注于核心目标，而不是担心技术细节。

自助式平台功能分为多个类别或平面

• 基础设施配置平面支持配置运行数据产品和产品网格的组件所需的底层基础设施。
• 产品开发人员体验平面是数据产品开发人员使用的主要界面。它简化并抽象了与支持开发工作流程相关的许多复杂性，提供了比通过配置平面提供的抽象更高的抽象级别，更易于使用。
• 网格监管平面提供了一种管理和监管整个数据产品网格的方法，允许对所有连接的产品进行全局控制。这包括诸如质量监控、性能、安全协议评估和提供访问控制机制等功能。好处？在管理大型互连数据产品网络方面更加灵活。

联邦治理

数据网格的实施需要一个治理模型，该模型支持去中心化和领域自我主权、通过动态拓扑实现互操作性以及平台对决策的自动化执行。将全球治理和互操作性标准集成到网格生态系统中，使数据消费者能够从在同一个系统中组合和比较不同的数据产品中获得价值。

数据网格将这些原则组合成一个统一的、去中心化和分布式系统。前提是数据产品所有者拥有一个自助式共享基础设施，支持以开放但受治理的方式运行数据共享管道。这使开发人员能够高效工作，而不会牺牲对他们领域数据资产的治理或控制。

数据网格与传统方法不同，在传统方法中，管道和数据被视为具有共享存储基础设施的独立实体进行管理。相反，它在给定领域内以边界上下文的粒度查看所有组件（即管道、数据和存储基础设施），以创建集成的产品。这在可扩展性和定制性方面提供了更大的灵活性，同时提供了对不同部分如何交互的更好可见性。
我们如何将所有这些整合在一起？数据类型正在增加，使用模式显着增长，并且在以数据中心或织网的形式构建基于 Lambda 和 Kappa 架构的管道方面，重点得到了重新强调。无论按速度分组还是按它们提供的拓扑类型分组，数据架构都不是正交的。到目前为止，我在这些博文中描述的数据架构和范式可以根据特定需求进行使用。当然，它们也可以混合在数据网格等架构中，其中每个数据产品都是一个独立的工件。我们可以想象这样一些场景，其中在某些数据产品中实施 Lambda 架构，而在其他数据产品中则采用 Kappa 架构。

想要了解更多信息？我们的白皮书 金融服务现代数据层的最佳实践，讨论了现代化僵化且缓慢的 IT 遗留系统的步骤。