数据架构 - 数据架构类型

---

---

数据架构是指组织如何组织和管理其数据。不同类型的数据架构解决各种数据挑战。以下是当今使用的一些主要数据架构类型。

集中式数据架构

在集中式数据架构中，所有数据都存储和管理在一个中心位置。用户和应用程序连接到此中心系统以访问或修改数据。此中心系统处理所有数据请求，确保信息在整个组织中保持一致和安全。

• 优点：易于控制和保护数据。所有数据都位于一个位置，因此易于查找。
• 缺点：如果中心系统发生故障，所有数据访问都会丢失。对于远离中心位置的用户来说，速度可能会很慢。

集中式数据架构中的数据流

• 从各种来源收集数据。
• 将其存储在中心系统中。
• 用户从此中心点请求数据。
• 中心系统处理这些请求并返回数据。

分散式数据架构

分散式数据架构将数据分散到多个独立的位置或系统中。每个位置都管理自己的数据，而无需依赖中央权威。用户从最近或最相关的位置访问数据，并且在站点之间共享数据可能需要额外的步骤或协议。

• 优点：本地用户访问速度更快，如果一部分发生故障，其他部分仍可以正常运行。
• 缺点：保持所有位置之间数据一致性可能更具挑战性，并且整体管理可能会变得更加复杂。

分散式数据架构中的数据流

• 数据在本地创建和存储。
• 用户从其最近或最相关的位置访问数据。
• 更新在本地进行，无需中央协调。
• 在位置之间共享数据可能需要额外的流程。

分布式数据架构

分布式数据架构将数据分散到多个连接的系统或节点中。这些节点作为一个单一系统的一部分协同工作，共享工作负载。每个节点都可以独立处理请求，但它们相互通信以在需要时共享数据。中心系统可能会监督所有节点之间数据的分布和访问。

• 优点：提供速度和一致性的良好平衡，并且可以有效地处理大量用户和数据。
• 缺点：设置和管理可能很复杂，并且需要可靠的网络连接。

分布式数据架构中的数据流

• 数据分布在各种连接的节点中。
• 每个节点都可以独立处理请求。
• 节点相互通信以根据需要共享数据。
• 中心系统可能会监督数据的分布和访问。

数据仓库架构

数据仓库架构以结构化的格式从不同来源收集和存储数据，旨在进行分析。它从不同的系统中提取数据，将其转换为适合标准结构的数据，然后将其加载到仓库中。然后，用户可以查询此聚合数据以进行报告、分析和决策制定。

• 优点：有助于整体分析并保留历史数据。
• 缺点：可能成本高昂，并且数据可能并不总是最新的。

数据仓库架构中的数据流

• 从各种源系统提取数据。
• 转换数据以适合仓库结构。
• 将转换后的数据加载到仓库中。
• 用户查询仓库以进行分析和报告。

数据湖架构

数据湖架构以其原始格式存储大量原始数据，接受所有类型的数据，无需预处理。当用户想要分析数据时，他们可以直接从数据湖中访问数据并根据需要进行处理。这允许对相同数据集进行灵活多样的分析类型。

• 优点：可以存储任何类型的数据，并且可以灵活地用于各种用途。
• 缺点：如果管理不当，可能会变得杂乱无章，难以找到特定数据。

数据湖架构中的数据流

• 从各种来源收集原始数据。
• 数据以其原始格式存储。
• 用户可以根据需要访问和分析数据。
• 处理和结构化在使用时进行。

云原生数据架构

云原生架构使用通过互联网访问的远程服务器来存储、管理和处理数据。它允许组织按需使用计算资源，而无需维护物理基础设施。用户可以使用互联网连接从任何地方访问数据和服务，并且系统可以根据需要轻松地扩展或缩减资源。

• 优点：可以从任何地方访问，并且易于扩展或缩减。
• 缺点：它依赖于稳定的互联网连接，并且可能需要考虑安全问题。

云原生架构中的数据流

• 将数据上传到云存储。
• 云服务处理和管理数据。
• 用户通过 Web 界面或 API 访问数据。
• 资源会根据需求自动扩展或缩减。

边缘计算架构

边缘计算架构在靠近其数据源的地方（例如在设备或本地服务器上）处理数据，而不是首先将其发送到集中式系统。这可以更快地处理对时间敏感的数据。然后，只有相关数据或结果才会发送到中心系统以进行长期存储或进一步分析。

• 优点：提供更快的响应时间并减少通过网络发送的数据量。
• 缺点：边缘设备上的处理能力有限，并且管理起来可能很复杂。

边缘计算架构中的数据流

• 数据由设备（例如传感器和物联网设备）生成。
• 在附近的边缘设备上进行即时处理。
• 只有相关数据或结果才会发送到中心系统。
• 中心系统管理长期存储和进一步分析。

微服务架构

微服务架构将应用程序分解成小的、独立的服务，每个服务负责特定的功能并管理自己的数据。这些服务通过定义明确的接口或 API 相互通信。这允许系统的不同部分独立开发、部署和扩展。

• 优点：灵活且易于更新，不同的部分可以使用各种技术。
• 缺点：管理所有组件可能很复杂，并且可能遇到数据一致性问题。

微服务架构中的数据流

• 数据由设备（例如传感器和物联网设备）生成。
• 在附近的边缘设备上进行即时处理。
• 只有相关数据或结果才会发送到中心系统。
• 中心系统管理长期存储和进一步分析。

Lambda 架构

Lambda 架构使用两个并行系统处理数据：一个批处理层用于处理大量历史数据，以及一个速度层用于处理实时数据。然后，服务层结合来自两个层的成果，提供数据的全面视图。这允许系统处理高容量批处理和低延迟实时数据分析。

• 优点：处理实时和历史数据，提供低延迟读取和更新，并提供数据的全面视图。
• 缺点：实施起来可能很复杂，可能导致数据不一致，并且需要管理两个独立的系统。

Lambda 架构中的数据流

• 数据进入系统并发送到批处理层和速度层。
• 批处理层处理历史数据。
• 速度层处理实时数据。
• 服务层结合结果以进行查询。

Kappa 架构

Kappa 架构是 Lambda 架构的一个更简单的版本，它将所有数据视为流。它使用单个流处理系统来处理实时数据和历史数据重新处理，无需单独的批处理层和速度层。这种方法通过对两种数据类型使用相同的代码和基础设施来降低复杂性。

• 优点：比 Lambda 更简单，为所有数据提供一致的处理，并且更易于维护和更新。
• 缺点：对于大型批次效率较低，需要强大的流处理系统，并且仅限于合适的用例。

Kappa 架构中的数据流

• 所有数据都作为流进入系统。
• 流处理器处理实时数据和历史数据。
• 处理后的结果存储在服务层中。
• 查询来自服务层。
• 要重新处理数据，请从头开始重放流。

事件驱动架构

事件驱动架构专注于事件的产生、检测和响应。事件是任何重要的变化，例如用户操作或传感器读数。组件通过发送和接收事件进行通信。当事件发生时，系统会快速处理它并采取必要的措施，通常会触发新的事件作为响应。

• 优点：高度响应；松散耦合的组件；可很好地扩展以进行实时处理。
• 缺点：复杂的设计和调试；事件排序方面的挑战；事件风暴的可能性。

事件驱动架构中的数据流

• 发生事件并发布到事件通道。
• 事件使用者订阅相关的通道。
• 这些使用者接收已发布的事件。
• 然后，使用者处理事件，这可能会触发新的事件。

对等 (P2P) 架构

对等 (P2P) 架构在网络中的平等对等方之间共享任务和工作负载，每个节点既充当供应商又充当消费者。没有中央服务器；每个对等方直接与其他对等方通信，允许在没有中央协调器的情况下共享数据和资源。

• 优点：高度可扩展和可靠，没有单点故障并且资源利用率高。
• 缺点：难以管理和保护，性能可能不均匀，并且存在数据丢失的风险。

对等 (P2P) 架构中的数据流

• 对等方发起数据或资源请求。
• 该请求广播到网络中的其他对等方。
• 具有请求数据或资源的对等方直接响应。
• 发起对等方从多个来源接收数据。

数据网格架构

数据网格架构将数据视为由特定于每个域的团队管理的产品。每个团队处理自己的数据并通过标准化接口使其可访问，而中央治理确保所有数据产品的一致性。

• 优点：提高数据质量，易于扩展，并且可以很好地与业务领域协同工作。
• 缺点：需要文化转变，实施可能具有挑战性，并且可能导致数据重复。

数据网格中的数据流

• 领域团队管理自己的数据产品。
• 通过标准接口访问数据。
• 其他团队根据需要使用这些产品。
• 中央管理确保一切保持一致。

数据织网架构

数据织物架构是一种完整的架构，可跨各种环境连接数据。它使用智能的自动化系统来访问数据所在的位置或根据需要移动数据。这确保了本地、云和边缘设备在分析、数据科学和管理方面的一致功能。

• 优点：简单的集成，在混合环境中运行良好，并提供自动化管理。
• 缺点：设置复杂，需要大量投资，并且需要专业技能。

数据织物中的数据流

• 数据源连接到织物。
• 织物查找并组织数据。
• 用户请求他们需要的数据。
• 织物管理对数据的访问。
• 将请求的数据发送给用户。