2. 数据模型基础回顾：关系模型、文档模型、图模型的核心概念，模型版本化的必要性
在工程分析平台中，数据模型是描述现实世界实体及其关系的抽象框架。不同的数据模型适用于不同的业务场景，而模型版本化则是保障数据一致性与系统演进的基石。本节将回顾三种主流数据模型的核心概念，并阐述为何必须引入模型版本化管理。
2.1 关系模型（Relational Model）
关系模型以二维表（Table）为核心，通过行（记录）与列（字段）组织数据，并利用外键（Foreign Key）建立表之间的关联。其理论基础是集合论与关系代数，强调数据的一致性与完整性。
- 核心结构：表（Table）、行（Row）、列（Column）、主键（Primary Key）、外键（Foreign Key）。
- 操作语言：SQL（Structured Query Language），支持 CRUD 与复杂联接查询。
- 适用场景：事务处理系统（OLTP）、财务系统、ERP 等对数据一致性要求极高的场景。
- 优势：严格的数据完整性约束、成熟的 ACID 事务支持、标准化查询语言。
- 局限：扩展性受限于垂直扩展，对半结构化/非结构化数据支持较弱，表结构变更（Schema Change）成本高。
工程实践提示：在工程分析平台中，关系模型常用于存储元数据、用户权限、项目配置等结构化信息。模型版本化在此处主要关注表结构变更（如新增字段、修改数据类型）的向后兼容性。
2.2 文档模型（Document Model）
文档模型以自包含的文档（Document）作为数据存储单元，通常使用 JSON、BSON 或 XML 格式。每个文档可以拥有不同的字段结构，支持嵌套与数组，天然适配面向对象编程的思维。
- 核心结构：集合（Collection）、文档（Document）、字段（Field）、嵌套对象（Embedded Object）、数组（Array）。
- 操作语言：MongoDB Query Language（MQL）、Couchbase N1QL 等。
- 适用场景：内容管理系统、实时分析、物联网数据采集、日志存储等。
- 优势：模式灵活（Schema-less）、水平扩展能力强、读写性能高、与 JSON 生态无缝集成。
- 局限：缺乏强约束的完整性检查，多文档事务支持较弱（部分数据库已改进），复杂关联查询性能不如关系模型。
关键对比：关系模型强调“先定义结构，再存储数据”；文档模型允许“先存储数据，再定义结构”。这种灵活性在工程分析平台中意味着文档模型更适合存储分析结果、实验配置等频繁变动的数据。
2.3 图模型（Graph Model）
图模型以节点（Node）和边（Edge）为核心，节点表示实体，边表示实体之间的关系。图模型特别擅长处理多对多、层级、网络等复杂关系，其查询语言（如 Cypher、Gremlin）专注于路径遍历与模式匹配。
- 核心结构：节点（Node）、边（Edge/Relationship）、属性（Property）、标签（Label）。
- 操作语言：Cypher（Neo4j）、Gremlin（Apache TinkerPop）、SPARQL（RDF 图）。
- 适用场景：社交网络分析、推荐系统、知识图谱、依赖关系分析、工程物料清单（BOM）管理。
- 优势：关系查询性能极高（尤其多跳查询），模型直观易理解，支持动态模式。
- 局限：大规模全局遍历性能下降，分布式图计算复杂度高，工具生态相对关系模型较小。
2.4 三种模型核心概念对比
| 维度 | 关系模型 | 文档模型 | 图模型 |
|---|---|---|---|
| 数据组织 | 表、行、列 | 集合、文档、字段 | 节点、边、属性 |
| 关系表达 | 外键 + JOIN | 引用或嵌套 | 边（直接连接） |
| 模式灵活性 | 严格（Schema-on-Write） | 灵活（Schema-on-Read） | 较灵活（Schema-Optional） |
| 查询语言 | SQL | MQL / N1QL | Cypher / Gremlin |
| 事务支持 | 强 ACID | 有限（多数支持单文档 ACID） | 支持 ACID（如 Neo4j） |
| 扩展方式 | 垂直扩展为主 | 水平扩展为主 | 垂直 + 水平（分片复杂） |
| 典型工程场景 | 元数据、权限、配置 | 分析结果、日志、实验配置 | 依赖关系、知识图谱、BOM |
2.5 模型版本化的必要性
在工程分析平台的生命周期中，数据模型并非一成不变。业务需求演进、新分析指标引入、合规要求变更、性能优化等因素都会驱动模型变更。若缺乏版本化管理，将引发以下问题：
- 数据不一致：同一字段在不同版本中含义不同，导致历史数据与新数据无法对齐。
- 下游系统崩溃：消费方（如报表、API、ETL 任务）依赖旧模型结构，变更后直接报错。
- 回滚困难：模型变更后发现问题，无法快速恢复到上一个稳定版本。
- 协作混乱：多团队并行开发时，模型变更缺乏沟通与审批，造成冲突。
- 审计缺失：无法追溯模型在何时、因何原因、由谁进行了变更。
典型事故案例：某工程分析平台在未版本化的情况下，将“分析结果”文档模型中的字段
result_value 从字符串类型改为浮点数类型。下游 12 个消费服务中有 8 个因类型不匹配而崩溃，数据恢复耗时 3 天。事后复盘发现，若采用模型版本化策略，可通过兼容性检查提前发现风险。
2.6 模型版本化的核心目标
| 目标 | 说明 | 工程收益 |
|---|---|---|
| 向后兼容 | 新版本模型能正确读取旧版本数据 | 避免历史数据失效，支持渐进式迁移 |
| 向前兼容 | 旧版本消费者能处理新版本数据（通常需降级策略） | 允许消费方按自身节奏升级 |
| 变更可追溯 | 记录每次变更的元数据（版本号、时间、作者、变更说明） | 满足审计合规，支持快速回滚 |
| 多版本共存 | 同一数据存储中同时存在多个模型版本 | 支持灰度发布与分阶段迁移 |
| 自动化验证 | 通过测试套件自动检查版本间兼容性 | 降低人工审查成本，提升发布信心 |
2.7 模型版本化在工程分析平台中的典型场景
- 分析指标变更：新增或修改分析指标（如“疲劳寿命”的计算公式变更），需保留旧版本数据以便对比验证。
- 数据源结构变化：上游传感器或仿真工具输出格式升级，下游模型需同步适配。
- 合规要求更新：如 GDPR、ISO 26262 等标准要求数据保留特定字段或格式。
- 多团队协作：不同团队负责不同分析模块，模型版本化提供清晰的接口契约。
- 灰度发布：新模型版本先在小范围验证，确认无误后再全量推广。