用版本化 CSV + Liquibase `loadUpdateData` 安全管理数据库参考数据回滚

来源：Harness 官方博客，作者 Animesh Pathak & Stephen Atwell

核心主张 ：把参考数据（Reference Data）当代码对待，存入 Git、通过 CI/CD 流水线部署，并利用 Liquibase OSS 的 loadUpdateData 实现一键回滚。

核心观点

文章要解决的问题非常具体：大多数团队对参考数据（下拉选项、功能标志、定价档位、状态码等）的管理仍是手工的------直接跑 SQL、在数据库 UI 里改行、无追踪 CSV 导入------由此产生环境漂移、无法回滚、无法追责三大顽疾。

解法并不新鲜，但组合方式很务实：

参考数据放进 Git → 获得 diff、审查、追溯能力
CSV 文件带版本号命名 （subscription_tiers-v1.csv / v2.csv）→ 让"部署哪个版本"一目了然
Liquibase loadUpdateData （而非 loadData）→ 逐行 UPSERT，不会全量覆盖不相关行
在 changelog 的 rollback: 块里直接引用上一版 CSV → 回滚即重新部署旧数据，无需手写逆向 SQL

这是渐进优化，而非范式突破------数据库 CI/CD 的理念早已存在，但参考数据这个细分领域一直是"被遗忘的灰色地带"。文章的价值在于填补这个实践空白。

关键机制：`loadUpdateData` 为什么是核心

loadData 和 loadUpdateData 的区别决定了这个方案能否实用：

特性	`loadData`	`loadUpdateData`
已有记录	跳过或报错	UPDATE
新记录	INSERT	INSERT
幂等性	依赖配置	天然幂等
适合回滚	否（不处理旧行）	是

loadUpdateData 的底层是"检查主键是否存在 → 存在则更新、不存在则插入"的批处理 SQL，因此重复执行同一 CSV 是安全的，这正是把它放进 rollback: 块的前提条件。

完整示例

目录结构

复制代码

reference-data/
├── subscription_tiers-v1.csv   ← 当前生产版本（基准）
├── subscription_tiers-v2.csv   ← 新增 Enterprise 档位

Liquibase Changelog（YAML）

yaml 复制代码

databaseChangeLog:
  - changeSet:
      id: subscription-tier-v2
      author: animesh
      changes:
        - loadUpdateData:
            file: reference-data/subscription_tiers-v2.csv
            tableName: subscription_tiers
            primaryKey: id
            separator: ","
            quotchar: "\""
      rollback:
        - loadUpdateData:
            file: reference-data/subscription_tiers-v1.csv
            tableName: subscription_tiers
            primaryKey: id
            separator: ","
            quotchar: "\""

执行逻辑：

部署时：流水线加载 v2.csv，新增 Enterprise 行，更新已有行
回滚时：流水线重新加载 v1.csv，把被修改的行恢复原值------不需要人工编写任何逆向 SQL

与历史方案的对比

方式	可追溯	可回滚	环境一致性	操作成本
直接运行 SQL	✗	✗ 极难	✗ 常见漂移	低（初始）
手工 CSV 导入	✗	✗	✗	中
Flyway（社区版）	✓	有限（不原生支持 rollback）	✓	中
Liquibase OSS + loadUpdateData	✓	✓ 完整	✓	中（需要学习成本）

文章末尾 FAQ 处也提到了 Liquibase vs Flyway 社区版的差异：Flyway 社区版没有内置 rollback 机制，手动回滚必须写补偿脚本；而 Liquibase OSS 的 rollback: 块是原生支持的。这个差异在参考数据场景下尤为关键。

交叉验证

信源 1：Liquibase 官方博客《Git for the Database: DevOps-Aligned Database Migrations》（2024-06-12）

Liquibase 官方的这篇文章从更宏观的角度印证了原文核心逻辑：近 60% 的应用发布涉及数据库变更，但大多数团队将数据库排除在自动化流水线之外。文章同样强调迁移式（migration-based）方法优于状态式方法 ，理由是状态式方法容易遗漏关键细节和引发冲突------这与原文选择 loadUpdateData 而非全量重载的出发点一致。同时，Liquibase 官方明确对比 Flyway，指向"为何选 Liquibase 而非 Flyway"的专题文章，侧面证实原文 FAQ 里的 Liquibase vs Flyway 对比并非偏颇的自我营销。

信源 2：devladlog.com《Database DevOps: Version Control, CI/CD, and Automated Deployments》（2025-07-07）

这篇来自独立技术博主、聚焦 SQL Server + DACPAC 技术栈的文章，用完全不同的工具链（SSDT、SqlPackage、tSQLt）达成了和原文相同的目标。文章明确使用部署前脚本保存参考数据、部署后脚本用 MERGE 还原 的模式------这和 loadUpdateData 的 UPSERT 思路高度吻合，属于独立验证。值得注意的是，该文章的回滚方案更偏向备份还原（点对点 RESTORE）和蓝绿切换，粒度比 CSV+loadUpdateData 更粗，适合大规模或 SQL Server 特定场景，但在轻量参考数据场景下成本更高。

**综合判断：**两个独立信源均认同"参考数据必须纳入版本控制和 CI/CD"的核心观点，且与原文无矛盾。但它们共同揭示了一点：原文方案对 Liquibase 的依赖较深，不能无缝迁移到 Flyway 或 SSDT 技术栈。

边界与局限（不唱赞歌）

大数据量参考表不适用 ：loadUpdateData 会逐行发 UPSERT，如果参考表有百万行，每次部署都是全量扫描，性能代价不可忽视。这个方案适合行数在千至数万级别的轻量查找表。
CSV 本身的局限：CSV 没有类型信息，日期格式、NULL 处理、特殊字符转义都是潜在坑。文章没有提到这些边界问题。
回滚不是"撤销"而是"覆盖" ：如果回滚期间已有新业务数据引用了 v2 里的新行，重新加载 v1 CSV 只会更新那些行的字段值，不会删除 v2 新增的行 （因为 loadUpdateData 不删除）。若 v2 新增了一整行（比如新的 Enterprise 档位），回滚后该行仍然存在，只是字段值被覆盖回 v1 状态。这个语义需要开发者自己意识到，文章没有提及。
与 Harness 平台强绑定：文章是 Harness 官方博客，Liquibase OSS 的 changelog 语法是通用的，但流水线编排、审批门禁、审计日志等高级特性依赖 Harness Database DevOps 商业产品。开源用户需要自行组装等效能力。

个人启发与行动建议

对开发者：如果你的项目里有任何"直接在生产数据库里改过值"的历史，这篇文章提供了一个成本极低的补救路径------不需要改造架构，只需要：① 把现有数据导出为 v1.csv、提交 Git；② 以后所有改动走 changelog + v2.csv。一个下午可以完成存量补救。

对 DBA/平台团队 ：这个模式的真正价值在于把回滚决策从"事故发生时的应急操作"前置为"部署设计时的预定义步骤"。把 rollback 块写进 changelog 的习惯，比事后写补偿脚本成本低得多、可靠得多。

对决策者：如果团队已经在用 Liquibase（不论 OSS 还是 Pro），这个模式零额外成本即可落地；如果用 Flyway，需要补写回滚脚本或考虑升级到 Flyway Teams；如果用 SSDT/DACPAC 技术栈，参考 devladlog.com 的 MERGE 方案更合适。不要为了这个单一功能换工具链。

延伸思考

loadUpdateData 不删除行的特性，在"参考数据下架"场景下该如何处理？ 一个可行思路是在 CSV 里增加 is_active 软删除列，但这要求应用层配合过滤------这本质上是数据合同问题，值得团队在采用此方案前明确约定。
当参考数据和 schema 变更需要原子性时（比如同时加列和填充新列数据），loadUpdateData 的顺序保证是否足够？ Liquibase 的 changeSet 是顺序执行的，理论上可以组合，但跨 changelog 文件的事务边界在不同数据库驱动下行为不一，这个边界值得压测验证。
GitOps 模式下，谁有权合并参考数据 PR？ 代码 PR 通常由工程师 review，但定价档位、功能标志这类参考数据的修改往往由产品经理或运营发起------如何在技术流程中嵌入"非技术干系人审批"，是这个方案落地时常被忽略的组织问题，也是 Database DevOps 治理成熟度的真实分水岭。

📚 参考来源

Harness Database DevOps: Reference Data Rollbacks

用版本化 CSV + Liquibase `loadUpdateData` 安全管理数据库参考数据回滚