📚 课程目录第4章数据库变更管理基础

4. 数据库变更管理基础

在 Snowflake DataOps 的持续交付体系中，代码（存储过程、任务、UDF）的版本化相对直观，而数据库 Schema 的变更管理往往是最容易失控的一环。原因在于：Schema 变更直接作用于有状态的生产数据，一旦执行顺序错乱、脚本不可重复或回滚路径缺失，就可能造成数据丢失或下游任务大面积失败。本节围绕四个相互咬合的机制展开：Schema 迁移、版本化脚本、变更日志与回滚策略。

一、Schema 迁移的本质：把结构变更当作可编排的版本事件

Schema 迁移指的是对数据库对象结构所做的受控变更，包括建表、加列、改类型、加约束、重命名、删除对象等。在 Snowflake 中，这些操作大多通过 DDL 完成，例如：

ALTER TABLE analytics.orders
  ADD COLUMN channel VARCHAR(32) DEFAULT 'unknown';

ALTER TABLE analytics.orders
  ADD CONSTRAINT pk_orders PRIMARY KEY (order_id) NOT ENFORCED;

需要特别注意的是，Snowflake 的主键、外键约束默认是 NOT ENFORCED，它们只作为优化器与文档信息存在，并不阻止重复或非法数据写入。因此“加约束”在 Snowflake 里不等于“数据已合规”，迁移脚本中往往还需要配套的数据校验查询。迁移的核心不是写出一条 DDL，而是让结构变更具备可排序、可重复、可追溯三个属性。

二、版本化脚本：命名、幂等与执行顺序

版本化脚本要求每个变更对应一个唯一编号的文件，按编号顺序执行，且同一编号只执行一次。推荐命名格式为 V{版本号}__{描述}.sql，例如：

V001__create_orders_table.sql
V002__add_channel_column.sql
V003__create_daily_sales_view.sql
V004__add_customer_segment_column.sql

版本号必须单调递增，禁止修改已发布脚本的内容——一旦某个版本已在生产执行，任何修正都应通过新的更高版本脚本完成。这是保证多环境（DEV/QA/PROD）状态一致的前提。

幂等性是版本化脚本的第二个关键。理想情况下，迁移工具通过“版本记录表”保证不重复执行，但脚本本身仍应尽量写成可安全重跑的形式。Snowflake 支持 CREATE OR REPLACE、IF NOT EXISTS 等语法：

CREATE TABLE IF NOT EXISTS analytics.orders (
  order_id     NUMBER(38,0),
  customer_id  NUMBER(38,0),
  amount       NUMBER(12,2),
  created_at   TIMESTAMP_NTZ DEFAULT CURRENT_TIMESTAMP()
);

CREATE OR REPLACE VIEW analytics.daily_sales AS
SELECT DATE(created_at) AS sales_date,
       SUM(amount)     AS total_amount
FROM analytics.orders
GROUP BY 1;

但要注意：CREATE OR REPLACE VIEW 会重建视图，可能影响依赖它的下游对象权限或物化视图，因此对已有对象的结构调整，优先使用 ALTER 而非替换。

三、变更日志：让每一次结构变化都可追溯

变更日志记录“谁在什么时候、对哪个对象、做了什么变更、结果如何”。它既是审计依据，也是排障入口。一个实用的变更日志表可以这样设计：

字段	类型	说明
version	VARCHAR	脚本版本号，如 V004
script_name	VARCHAR	脚本文件名
checksum	VARCHAR	脚本内容哈希，用于检测被篡改
applied_at	TIMESTAMP_NTZ	执行时间
applied_by	VARCHAR	执行角色或用户
status	VARCHAR	SUCCESS / FAILED / ROLLED_BACK
duration_ms	NUMBER	执行耗时

checksum 字段尤其重要：如果某个已执行脚本的内容被改动，checksum 会与记录不符，迁移工具应直接报错并阻止继续执行，避免“同一版本在不同环境产生不同结构”。

四、回滚策略：不是所有变更都能简单撤销

回滚策略必须与变更类型匹配。Snowflake 提供了几个关键能力：Time Travel 可在保留期内查询历史数据，零拷贝克隆可快速复制对象，UNDROP 可恢复被删除的表。但加列、改类型等操作无法通过 UNDROP 撤销，需要显式编写回滚脚本。

常见做法是为每个版本准备对应的回滚脚本，命名如 R004__drop_customer_segment_column.sql：

ALTER TABLE analytics.orders
  DROP COLUMN customer_segment;

对于破坏性变更（删列、删表、改类型），推荐采用“扩展—迁移—收缩”三步法：先加新列并双写，再迁移数据并切换读取，最后在确认无依赖后删除旧列。这样任何一步出问题都能回退到上一步，而不是直接面对不可逆的数据丢失。

五、把四个机制串成一条可执行的发布链

在实际 DataOps 流水线中，这四个机制应当形成闭环：开发者提交版本化脚本 → CI 校验命名规范与 checksum → 迁移执行器按序应用并写入变更日志 → 若失败则调用对应回滚脚本并标记 ROLLED_BACK。一个可参考的发布前检查清单如下：

脚本编号是否连续且大于当前已应用的最大版本？
是否包含对应的回滚脚本，且回滚脚本已在 DEV 验证？
破坏性操作（DROP/ALTER TYPE）是否已通过扩展—迁移—收缩拆分？
变更日志表是否已记录本次执行的 checksum 与执行角色？
下游视图、任务、动态表是否已评估依赖影响？

切勿在生产直接执行未经版本化的临时 DDL。即使是一条 ALTER TABLE ... ADD COLUMN，也应走版本化脚本与变更日志流程，否则多环境结构漂移将难以定位。

总结来说，Schema 迁移解决“改什么”，版本化脚本解决“怎么有序地改”，变更日志解决“改过什么、是否可信”，回滚策略解决“改错了怎么办”。四者缺一，持续交付的数据库层就失去了可重复性与可恢复性。