视频
数据 101：数据科学基础
了解更多
Redis 8 来了——并且是开源的
了解更多
分享
数据架构可以根据其操作模式或拓扑进行分类，包括数据网格、数据中心和数据网状。 它们之间有什么区别？ 准备好了。
之前，当我解释基于速度的数据架构时，我详细介绍了 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) 工具和运营应用程序之类的用例。 它提供了一个互连的 Web 状层，可以通过利用当前和推断的元数据资产上的持续分析来集成与数据相关的流程。 为了最大限度地提高效率，它使用了诸如主动元数据管理、语义知识图和嵌入式机器学习/AutoML 功能之类的技术。
这个概念由 Forrester Research 的 Noel Yuhanna 于 2016 年在Forrester Wave：大数据底座中提出，此后不断更新。 Yuhanna 的论文描述了一种面向技术的方法，将不同的数据源整合到一个统一的平台中，使用 Hadoop 和 Apache Spark 进行处理。 其目标是通过创建一个自动化的语义层来提高敏捷性。 这将加速数据价值的交付，同时最大限度地降低管道的复杂性。
多年来，Yuhanna 进一步发展了他的大数据底座概念。 他目前对数据底座的愿景是解决特定类型的业务需求，例如创建客户的全面视图、客户情报以及与物联网相关的分析。 数据底座的组件包括 AI/ML、数据目录、数据转换、数据准备、数据建模和数据发现。 它还提供治理和建模能力。
Gartner 也采用了“数据底座”这个术语，并对其进行了类似的定义。 该分析公司将其描述为“一种新兴的数据管理和集成设计，可以实现灵活、可重用和增强的数据集成管道、服务和语义，以支持跨多个部署平台的各种运营或分析用例”。
数据底座结合了不同的数据集成技术，同时使用主动元数据、知识图、语义和机器学习 (ML) 来改进其设计过程。 它们将它们组织成五个内部属性。
在底座中，主动元数据包含被动数据元素的目录，例如模式、字段类型、数据值和知识图关系。 知识图存储和可视化多个数据实体之间的复杂关系。 它维护数据本体，以帮助非技术用户解释数据。
在 AI 和 ML 功能的帮助下，数据底座可以协助和增强数据管理活动。 它还提供集成功能，以动态地将不同的数据摄取到数据底座中，以便存储、分析和访问。 自动化数据编排允许用户在整个过程中应用 DataOps 原则，以实现敏捷、可靠和可重复的数据管道。
数据底座是一种与技术无关的架构。 它的实现使您可以扩展大数据操作，以用于批处理和实时流式传输，从而在云、混合多云、本地和边缘设备上提供一致的功能。 它简化了不同环境之间的信息流动，以便为分析应用程序或业务流程提供一整套最新的数据。 通过提供预配置的组件和连接器，它可以减少时间和成本，因此无需手动编写每个连接的代码。
数据网格由 Zhamak Dehghani 于 2019 年提出，她认为由于集中式数据仓库和数据湖的缺点，去中心化架构是必要的。
数据网格是一个框架，使业务领域能够拥有和运营其特定领域的数据，而无需集中的中介机构。 它借鉴了分布式计算原则，其中软件组件在多个计算机之间共享，这些计算机作为一个系统一起运行。 这样，数据所有权分散在各个业务领域，每个业务领域都负责创建自己的产品。 从理论上讲，数据网格允许更容易地对收集的信息进行情境化，从而产生更深入的见解，同时促进领域所有者之间的协作，以根据特定需求创建量身定制的解决方案。
Dehghani 后来修改了她的立场，提出了构成这种新范式的四个原则：面向领域、数据即产品、自助服务和联邦治理。
数据网格概念基于分散和分配分析数据、其元数据以及为最接近数据的人员提供服务所需的计算的责任。 这使得组织的数据生态系统能够持续变化和扩展。
为此，数据网格会沿着组织单元或业务领域分解组件，从而将更改或演变定位在限定的上下文中。 这样，这些组件的所有权可以分配给靠近数据的利益相关者。
现有分析数据架构的一个问题是，发现、理解、信任和使用高质量数据可能既困难又昂贵。 随着越来越多的团队以去中心化的方式提供数据（领域），问题只会变得更糟，这将违反第一个原则。
为了解决与数据质量和孤岛相关的这些挑战，数据网格必须将领域提供的分析数据视为产品，并将该产品的消费者视为客户。 该产品成为新的架构单元，应构建、部署和维护为一个单一的量子。 它确保数据消费者可以轻松地发现、理解和安全地使用跨多个领域的高质量数据。
基础设施平台允许领域团队自主创建和使用数据产品，而无需担心构建、执行和维护安全且可互操作的解决方案的底层复杂性。 自助服务基础设施应提供简化的体验，使数据领域所有者能够专注于核心目标，而不是担心技术细节。
自助服务平台的功能分为多个类别或层面
数据网格的实施需要一种治理模型，该模型支持去中心化和领域自主权、通过动态拓扑实现互操作性以及平台自动执行决策。 将全局治理和互操作性标准集成到网格生态系统中，使数据消费者能够通过组合和比较同一系统中的不同数据产品来获得价值。
数据网格将这些原则组合成一个统一的、去中心化的和分布式系统。 前提是数据产品所有者拥有一个自助服务、共享的基础设施，该基础设施支持以开放但受控的方式工作的数据共享管道。 这使得开发人员能够提高效率，而不会牺牲对其领域数据资产的治理或控制。
数据网格与传统方法不同，在传统方法中，管道和数据被视为具有共享存储基础设施的独立实体。 相反，它在给定领域内的有界上下文的粒度下查看所有组件（即管道、数据和存储基础设施），以创建一个集成产品。 这允许在可扩展性和定制方面具有更大的灵活性，同时提供对不同部分如何交互的更好可见性。
我们如何将所有这些整合在一起？ 数据的类型越来越多，使用模式也显着增长，并且人们重新强调以数据中心或数据底座的形式构建具有 Lambda 和 Kappa 架构的管道。 无论按速度还是它们提供的拓扑结构进行分组，数据架构都不是正交的。 到目前为止，我在这些博客文章中描述的数据架构和范例可以根据给定需求适当地使用。 当然，它们可以混合在数据网格等架构中，其中每个数据产品都是一个独立的工件。 我们可以想象在某些数据产品中实施 Lambda 架构，而在其他数据产品中采用 Kappa 架构的场景。
想要了解更多细节？ 我们的白皮书金融服务现代数据层的最佳实践讨论了 IT 遗留系统现代化改造的步骤。
