数据架构：从所有权到集成与演进的全面解析

### 数据架构：从所有权到集成与演进的全面解析 #### 1. 数据架构决策困境 在软件技术领域，架构设计往往涉及艰难的权衡。采用新数据库（如图形存储）会增加团队需要掌握的技术。依据“根据系统设计来构建组织”原则，相关决策由处理特定组件的团队负责，如租户和跨租户分析团队。 数据集成方面，在分析管理器组件与租户和跨租户分析组件之间，需要做出数据集成决策，且要考虑匿名化需求。若公司要将 TFX 系统提供给多个客户，跨租户分析需整合多个租户的数据，这类似分析环境中数据管道的管理，任务复杂且技术和方法不断发展。 #### 2. 数据所有权与元数据 数据在应用程序中流动并在不同组件间共享，每个组件按自身目的解读数据。在 TFX 平台中，各组件需理解与买卖方相关的交易对手数据元素以及信用证（L/C）。 从架构角度看，明确数据元素的所有权并决定共享方式很重要。所有权指定义特定数据元素的权威系统，即主数据或单一事实来源（SPOT）。忽视数据所有权会导致不同组件对数据的解读不一致，影响业务价值的一致性。 以 TFX 系统组件为例，从数据优先视角出发，可创建关键数据实体与服务的映射表（如下表），以管理数据依赖关系。 | 主要数据实体 | 文档管理器 | 合同管理器 | 交易对手管理器 | 费用和佣金管理器 | 支付服务 | | --- | --- | --- | --- | --- | --- | | L/C 条款 | 主管理 | 消费 | 消费 | | | | L/C 文档 | 主管理 | 消费 | | | | | 商品 | 主管理 | 消费 | | | | | 买方/卖方 | 消费 | 主管理 | 消费 | | | | 银行 | 消费 | 主管理 | 消费 | | | | 支付 | 消费 | | | | 主管理 | | 费用和佣金 | 消费 | | | 主管理 | | 从该表可看出，交易对手管理器和合同管理器管理大部分主要数据元素，其他组件多为数据消费者。文档管理器和支付服务管理的数据元素较少，对其他组件的依赖有限。通过管理数据依赖，团队可确保组件松散耦合，增强系统的可演进性。 确定数据实体由单一组件管理后，需决定数据共享方式。安全的做法是通过引用共享数据，即传递唯一标识数据元素的标识符。这样能保证数据在整个系统中的一致解读，避免分布式系统中的数据一致性问题。但引用数据会增加组件间的通信，带来可修改性与性能的权衡。 例如，若费用和佣金管理器调用导致交易对手管理器负载过高，且所需卖方属性有限且已存在于 UI 中，可直接传递这些属性，以满足性能需求，但需明确记录该决策。 在分布式系统中，管理同一数据集的多次更新可能很复杂。如两个组件同时更新合同管理器中的同一合同，TFX 系统中需在合同管理器和 UI 服务中添加额外逻辑来避免不一致。 元数据是关于数据的数据，对大数据系统和人工智能愈发重要，原因如下： - 大型数据分析系统包含多种格式的多源数据，充足的元数据有助于高效发现、集成和分析这些