数据架构设计与管理全解析

### 数据架构设计与管理全解析 #### 1. 应用设计起点 在数据管理和应用间的数据移动场景中，每个应用都有某种形式的数据存储。即便存在无状态应用将数据存于别处、应用共享同一数据库或进行内存处理的情况，但所有应用都需在某处存储数据。 业务挑战各不相同，每个应用用于解决特定问题，其数据具有独特性。应用的设计和开发过程包含多个阶段： 1. 对业务需求进行概念思考。 2. 将业务知识转化为逻辑应用数据模型，这是对需求更正式、具体的呈现。 3. 基于逻辑设计的非功能需求，创建物理应用数据模型，即应用的真实设计。 在分散和分布式环境中，确定原始和唯一数据的权威来源并非易事。“黄金来源”是指在特定上下文中管理所有真实数据的权威应用。识别黄金来源是数据管理的起点，它对数据治理和数据质量至关重要。通过直接从黄金来源捕获唯一数据，可确保数据的精确性和一致性，便于实施强大的数据治理。同时，在黄金来源处解决数据质量问题，能避免问题在其他地方出现。 由于应用具有独特的上下文，在应用间移动数据时，总是需要进行数据转换，这意味着数据集成是必不可少的。无论采用 ETL（提取、转换和加载）还是 ELT（提取、加载和转换），虚拟或物理、批量或实时处理，都无法逃避数据集成的难题。 应用的角色可分为数据提供者和数据消费者，有时一个应用可能兼具两者角色。在数据集成和分发的场景中，明确应用角色对于责任划分至关重要。对于外部各方，如第三方，它们通常在企业生态系统的逻辑边界之外运行，新的架构需要具备灵活性，允许外部方同时作为数据提供者和消费者，但通常需要额外的安全措施。是否直接消费外部方的数据，取决于外部方是否愿意遵循自身原则以及自身是否需要遵循外部提供者的标准。 以下是应用角色的简单表格说明： | 应用角色 | 描述 | | ---- | ---- | | 数据提供者 | 创建并提供数据 | | 数据消费者 | 使用其他应用提供的数据 | | 两者兼具 | 既提供数据又消费数据 | #### 2. 软件架构的启示 数据集成涉及管理通信复杂性和数据互操作性。微服务架构为软件开发提供了一种新的思路，它将应用拆分为小的独立服务，通过轻量级通信模式进行交互。使用微服务架构的好处包括： 1. 微服务可独立开发、测试和部署。 2. 每个微服务管理自己的运行时和数据，运行在独立的进程中，使设计更具可扩展性。 3. 可根据需要独立扩展或缩减单个应用组件。 4. 编程语言具有灵活性，可根据组件需求选择合适的语言。 然而，随着微服务数量的增加，管理微服务架构的难度也会增大。为避免微服务之间直接通信导致的系统脆弱性，可使用服务网格来控制微服务之间的通信。服务网格将服务间通信的逻辑从单个服务中抽象出来，提供监控、可发现性、优雅关闭、策略执行等功能。它可用于分组和分离微服务，同一组内的微服务可直接通信，与其他组的微服务通信则需通过服务网格。 服务网格适用于同步请求/响应通信，对于异步通信，可使用事件代理。数据网格中，分析数据通过数据产品提供，数据产品具有与服务网格类似的架构优势，被描述为“新的架构量子，架构中具有完成其工作所需的所有结构组件的最小单元”。 以下是微服务架构和服务网格的 mermaid 流程图： ```mermaid graph LR classDef process fill:#E5F6FF,str ```