3. 版本控制原理：语义化版本控制（SemVer）在数据模型中的应用

在工程分析平台中，数据模型（包括表结构、字段定义、枚举值、关系约束）的变更直接影响下游 ETL 管道、报表和算法服务。采用语义化版本控制（SemVer）对数据模型进行标记，是确保变更可追溯、兼容性可评估、迁移可自动化的基础。

3.1 语义化版本号规范

遵循 MAJOR.MINOR.PATCH 三部分格式，每个部分均为非负整数，递增规则如下：

3.2 兼容性规则矩阵

数据模型版本间的兼容性决定了迁移策略。以下矩阵定义了常见变更操作对应的版本段和兼容性等级：

3.3 版本号在数据模型中的声明与存储

每个数据模型定义文件（如 JSON Schema、Protobuf、Avro Schema）应在元数据中显式声明版本号：

{
  "schema": "工程分析平台.设备运行记录",
  "version": "2.1.0",
  "description": "设备运行状态与能耗数据模型",
  "fields": [
    { "name": "device_id",   "type": "string",  "required": true },
    { "name": "timestamp",   "type": "datetime","required": true },
    { "name": "power_kw",    "type": "float",   "required": true },
    { "name": "status_code", "type": "integer", "required": false }
  ],
  "compatibility": "BACKWARD"
}

3.4 版本演进与依赖关系图

数据模型之间往往存在引用依赖（如维度表引用事实表的外键）。版本变更需要沿依赖链传播。下图展示了一个典型的数据模型版本依赖拓扑：

3.5 版本号递增决策流程

当数据模型发生变更时，团队应按照以下决策树确定新版本号：

3.6 版本号在 CI/CD 中的自动化校验

在工程分析平台的 DevOps 流水线中，应加入版本号合规性检查步骤：

# 版本号合规性检查脚本（伪代码）
def check_version_compliance(old_version, new_version, changes):
    old_major, old_minor, old_patch = parse_semver(old_version)
    new_major, new_minor, new_patch = parse_semver(new_version)

    if has_breaking_change(changes):
        assert new_major == old_major + 1, "破坏性变更必须递增 MAJOR 版本"
        assert new_minor == 0, "MAJOR 递增后 MINOR 必须归零"
        assert new_patch == 0, "MAJOR 递增后 PATCH 必须归零"
    elif has_new_feature(changes):
        assert new_minor == old_minor + 1, "新增功能必须递增 MINOR 版本"
        assert new_patch == 0, "MINOR 递增后 PATCH 必须归零"
    else:
        assert new_patch == old_patch + 1, "仅修复必须递增 PATCH 版本"

3.7 版本号在模型注册中心的管理

推荐使用 Schema Registry（如 Confluent Schema Registry、Apicurio）集中管理数据模型版本：

• 版本存储：每个 Schema 以主题（Subject）形式注册，每次提交生成不可变的版本快照。
• 兼容性策略：支持 BACKWARD、FORWARD、FULL、NONE 四种模式，与 SemVer 的兼容性规则对应。
• 版本回滚：通过指定版本号回退到历史 Schema，同时触发下游数据视图的重新编译。
• 版本标签：支持为特定版本打标签（如 stable、canary），用于灰度发布。