数据架构 - 数据架构的类型
数据架构是组织组织和管理数据的方式。不同类型的架构可解决各种数据挑战。以下是当今使用的主要数据架构类型。
集中式数据架构
在集中式数据架构中，所有数据都存储并管理在一个中心位置。用户和应用程序连接到此中央系统以访问或修改数据。此中央系统处理所有数据请求，确保信息在整个组织中保持一致和安全。
- 优点:易于控制和保护数据。所有数据都集中在一个地方，便于查找。
- 缺点:如果中央系统发生故障，所有数据访问都将丢失。对于远离中央位置的用户来说，速度可能会很慢。
集中式数据架构中的数据流
- 数据从各种来源收集。
- 它存储在中央系统中。
- 用户从这个中心点请求数据。
- 中央系统处理这些请求并返回数据。
分散式数据架构
分散式数据架构将数据分散到多个独立位置或系统。每个位置管理自己的数据，而不依赖于中央权威。用户从最近或最相关的位置访问数据，站点之间共享数据可能涉及其他步骤或协议。
- 优点:本地用户访问速度更快，如果一个部分发生故障，其他部分仍可正常运行。
- 缺点:在所有位置保持数据一致性可能更具挑战性，总体管理可能变得更加复杂。
分散式数据架构中的数据流
- 数据在本地创建和存储。
- 用户从最近或最相关的位置访问数据。
- 更新在本地进行，无需中央协调。
- 在位置之间共享数据可能需要额外的流程。
分布式数据架构
分布式数据架构将数据分布在多个连接的系统或节点。这些节点作为单个系统的一部分一起工作，共享工作负载。每个节点都可以独立处理请求，但它们会相互通信以在需要时共享数据。中央系统可以监督所有节点上的数据分布和访问。
- 优点:在速度和一致性之间取得良好平衡，可以有效处理大量用户和数据。
- 缺点:设置和管理起来可能很复杂，并且需要可靠的网络连接。
分布式数据架构中的数据流
- 数据分布在各个连接的节点上。
- 每个节点都可以独立处理请求。
- 节点相互通信以根据需要共享数据。
- 中央系统可以监督数据的分布和访问。
数据仓库架构
数据仓库架构以专为分析而设计的结构化格式收集和存储来自不同来源的数据。它从不同的系统中提取数据，将其转换为适合标准结构，然后将其加载到仓库中。然后，用户可以查询这些汇总数据以进行报告、分析和决策。
- 优点:可用于整体分析并保留历史数据。
- 缺点:成本高昂，并且数据可能并非始终是最新的。
数据仓库架构中的数据流
- 数据从各种源系统中提取。
- 数据经过转换以适应仓库结构。
- 转换后的数据将加载到仓库中。
- 用户查询仓库以进行分析和报告。
数据湖架构
数据湖架构以原始格式存储大量原始数据，无需预处理即可接受所有类型的数据。当用户想要分析数据时，他们可以直接从数据湖中访问数据并根据需要进行处理。这允许对同一数据集进行灵活多样的分析。
- 优点:可以存储任何类型的数据，并可灵活用于各种用途。
- 缺点:如果管理不当，可能会变得杂乱无章，难以找到特定的数据。
数据湖架构中的数据流
- 原始数据从各种来源收集。
- 数据以原始格式存储。
- 用户可以根据需要访问和分析数据。
- 处理和结构化在使用时进行。
基于云的数据架构
基于云的架构使用通过互联网访问的远程服务器来存储、管理和处理数据。它允许组织按需使用计算资源，而无需维护物理基础设施。用户可以从任何有互联网连接的地方访问数据和服务，并且系统可以根据需要轻松地扩展或缩减资源。
- 优点:可以从任何地方访问，并且易于扩展或缩减
- 缺点:它依赖于稳定的互联网连接，并且可能存在安全问题需要考虑。
基于云的架构中的数据流
- 数据上传到云存储。
- 云服务处理和管理数据。
- 用户通过 Web 界面或 API 访问数据。
- 资源根据需求自动扩展或缩减。
边缘计算架构
边缘计算架构在靠近源头的地方处理数据，例如在设备或本地服务器上，而不是先将其发送到集中式系统。这样可以更快地处理时间敏感的数据。然后，只有相关数据或结果才会发送到中央系统进行长期存储或进一步分析。
- 优点:提供更快的响应时间并减少通过网络发送的数据量
- 缺点:边缘设备的处理能力有限，管理起来可能很复杂。
边缘计算架构中的数据流
- 数据由传感器和物联网设备等设备生成。
- 在附近的边缘设备上立即进行处理。
- 只有相关数据或结果才会发送到中央系统。
- 中央系统管理长期存储和进一步分析。
微服务架构
微服务架构将应用程序分解为小型、独立的服务，每个服务负责特定功能，管理自己的数据。这些服务通过定义明确的接口或 API 相互通信。这允许独立开发、部署和扩展系统的不同部分。
- 优点:灵活且易于更新，不同部分能够使用各种技术。
- 缺点:管理所有组件可能很复杂，并且可能面临数据一致性问题。
微服务架构中的数据流
- 数据由设备生成，例如传感器和物联网设备。
- 在附近的边缘设备上立即进行处理。
- 只有相关数据或结果才会发送到中央系统。
- 中央系统管理长期存储和进一步分析。
Lambda 架构
Lambda 架构使用两个并行系统处理数据:一个用于处理大量历史数据的批处理层和一个用于处理实时数据的速度层。然后，服务层将两个层的结果结合起来，以提供全面的数据视图。这使得系统能够同时处理大容量批处理和低延迟实时数据分析。
- 优点:处理实时数据和历史数据，提供低延迟读取和更新，并提供全面的数据视图。
- 缺点:实施起来可能很复杂，可能导致数据不一致，并且需要管理两个独立的系统。
Lambda 架构中的数据流
- 数据进入系统并发送到批处理层和速度层。
- 批处理层处理历史数据。
- 速度层处理实时数据。
- 服务层结合查询结果。
Kappa 架构
Kappa 架构是Lambda 架构的简化版本，将所有数据视为流。它使用单个流处理系统来处理实时数据和历史数据，从而无需单独的批处理和速度层。这种方法通过对两种数据类型使用相同的代码和基础架构来降低复杂性。
- 优点:比 Lambda 更简单，为所有数据提供一致的处理，并且更易于维护和更新。
- 缺点:对于大批量处理效率较低，需要强大的流处理系统，并且仅限于合适的用例。
Kappa 架构中的数据流
- 所有数据都以流的形式进入系统。
- 流处理器处理实时数据和历史数据。
- 处理后的结果存储在服务层中。
- 查询由服务层提供。
- 要重新处理数据，需要从头开始重播流。
事件驱动架构
事件驱动架构专注于事件的产生、检测和响应。事件是任何重要的变化，例如用户操作或传感器读数。组件通过发送和接收事件进行通信。当事件发生时，系统会快速处理并采取必要的措施，通常会触发新事件作为响应。
- 优点:响应速度快；组件松散耦合；实时处理扩展性好
- 缺点:设计和调试复杂；事件排序困难；可能引发事件风暴
事件驱动架构中的数据流
- 事件发生并发布到事件通道。
- 事件消费者订阅相关通道。
- 这些消费者接收已发布的事件。
- 然后消费者处理事件，这可能会触发新的事件。
对等 (P2P) 架构
对等 (P2P) 架构在网络中的对等节点之间共享任务和工作负载，每个节点既充当供应商又充当消费者。没有中央服务器；每个对等点直接与其他对等点通信，无需中央协调器即可共享数据和资源。
- 优点:高度可扩展且可靠，没有单点故障，资源利用效率高。
- 缺点:难以管理和保护，性能可能参差不齐，并且有丢失数据的风险。
对等 (P2P) 架构中的数据流
- 对等点发起数据或资源请求。
- 请求被广播到网络中的其他对等点。
- 具有所请求数据或资源的对等点直接响应。
- 发起对等点从多个来源接收数据。
数据网格架构
数据网格架构将数据视为产品由每个领域的特定团队管理。每个团队处理自己的数据并通过标准化接口访问，而中央治理可确保所有数据产品的一致性。
- 优点:提高数据质量，易于扩展，并与业务领域配合良好。
- 缺点:需要文化转变，实施起来可能具有挑战性，并且可能导致数据重复。
数据网格中的数据流
- 领域团队处理自己的数据产品。
- 通过标准接口访问数据。
- 其他团队根据需要使用这些产品。
- 中央管理使一切保持一致。
数据结构架构
数据结构架构是一个完整的架构，可跨各种环境连接数据。它使用智能自动化系统来访问数据，或根据需要移动数据。这可确保在本地、云和边缘设备上具有一致的分析、数据科学和管理功能。
- 优点:集成简单，在混合环境中运行良好，并提供自动化管理。
- 缺点:设置复杂，需要大量投资，并且需要专业技能。
数据结构中的数据流
- 数据源连接到结构。
- 结构查找并组织数据。
- 用户请求他们需要的数据。
- 结构管理对数据的访问。
- 请求的数据已发送给用户。
