边开车边换轮胎：我的 Oracle → Snowflake 迁移复盘

在 VodafoneZiggo 的时候，我参与了一个大型 Oracle → Snowflake 迁移项目。Oracle 合同即将到期，项目存在不可推迟的截止日期。然而，这套系统承担着公司业务运行的关键职责，全面冻结需求开发会直接损害商业利益。迁移期间，总有一些高优先级需求和 Bug 修复必须继续合入数据库。

这像给一辆行驶中的汽车换轮胎。

我被调入项目时，迁移已经进行到一半，进度亮起了红灯。Oracle 合同的终止日期此前已经多次延期，公司明确决定不能再次推迟。

我的任务，是利用自己在数据、基础设施、Python 和 CI/CD 自动化方面的经验，加快迁移进度。

当时的痛点：一个迁移单元需要数天

Oracle 平台部署在 AWS 上，承载数百 TB 数据。它的物理基础设施与逻辑数据库分开管理。项目将其划分为数十个逻辑数据库单元，再逐个 release 迁移。

每个单元需要同时迁移三个平面：

• DDL：在 Snowflake 建立对应的数据库对象；
• 数据：从 Oracle 复制存量和增量数据；
• ETL 接口：将 Informatica PowerCenter workflows 从 Oracle 适配到 Snowflake。

当时很多步骤依靠人工完成。工程师手工执行 Snowflake DDL；PowerCenter XML 需要人工导出、修改、转换和导入。一次子迁移 release 可能持续数天，最长接近一周。

与此同时，至少 40 位 PowerCenter 开发者仍在提交新需求和 Bug 修复。一次迁移结束时，它使用的源基线可能已经过期。如果 release 失败，团队还要重新判断哪些 SQL 已经执行、哪个 XML 才是最新版本，以及哪个 workflow 版本可以安全恢复。

根因：迁移步骤没有完整自动化

过长的迁移时间制造了第一类 drift：生产系统在持续数天的迁移窗口里继续变化。

人工执行又制造了第二类 drift：不同人员可能基于不同版本操作；一次部分成功的执行，也可能让 Git、Oracle、Snowflake 和 PowerCenter 服务器停留在不同状态。

三个迁移平面还缺少一个可重复的 release 边界。DDL 部署成功，不代表数据已经追平；数据完成同步，也不代表 PowerCenter 接口已经可以切换。

PowerCenter 的转换规则和例外知识集中在人工流程中。团队中最熟悉 PowerCenter 的员工也编写过一些 Python 脚本，但导出、比对、转换、导入、失败处理和版本跟踪仍未形成一条完整路径。

对策：自动化完整的迁移 Release

我在加入项目后的第一周完成了首个自动化 MVP 和 pilot。方案通过 Architecture Board 评审后由团队采用，并在随后四个月的救火过程中持续扩展。

把 DDL 迁移变成 CI/CD release

项目已经有一套初步的 DDL migration mechanism，但工程师仍以手工执行 SQL 为主。

我改进了这套系统，将它接入 GitLab CI/CD。

初始化时，系统从 Oracle 导出 DDL，通过 SQL parser 检查并转换成 Snowflake 语法。后续 release 则应用下一个逻辑数据库单元所需的变化。

流水线会在执行前检查对象是否存在，并比较预期 schema 与实际 schema。无法解释的差异会立即失败。每个 release 保持幂等，执行失败后可以修复并安全重跑，无需依靠个人记录判断哪些 SQL 已经成功。

这套 Python 编排系统覆盖版本化 DDL 转换、执行控制和部署。当时项目没有使用 dbt；它解决了现代数据转换工具通常涉及的部分数据库变更管理问题。

把 DMS 对接集成进 release

团队共同决定使用 AWS DMS 完成 Full Load 和持续 CDC。这是团队的架构决策。

我作为两名 AWS 系统管理员之一，参与 DMS 的技术对接、任务配置和运行，并将相关检查集成进 CI/CD。

每个逻辑迁移单元都有对应的 DMS 任务。初始数据装载通常需要 4–8 小时，并使用高容量的 DMS replication instance。之后，CDC 在其他 release 步骤准备期间继续应用 Oracle 的增量变化。

DMS CDC 是异步持续同步机制，正式切换前仍需检查任务状态、复制延迟和数据对账结果。

开发一次，自动适配 PowerCenter

项目期间无法冻结 PowerCenter 开发。人工同时维护 Oracle 和 Snowflake 两套 workflow，还会增加工作量和 drift。

开发者继续维护 Oracle 版本。我与 PowerCenter 专家合作，把转换规则和例外固化进标准 GitLab pipeline。

开发者触发后，pipeline 大致执行：

1. 从 PowerCenter 服务器导出最新 XML；
2. 与 Git 管理的版本比较；
3. 发现 drift 时停止；
4. 生成适配 Snowflake 的 workflow；
5. 校验并导入转换结果；
6. 在 Git 中记录 release 状态。

转换前重新从服务器导出，可以防止旧 Git 版本覆盖更新的生产修改。这套流程后来成为 PowerCenter 迁移的标准路径。

通过同一个 gate 切换三个平面

自动化将数据以外的主要步骤缩短到小时级。DMS 初始装载需要 4–8 小时，CDC 则让目标端持续追赶 Oracle。一个逻辑数据库单元因此可以在一天内完成多平面迁移。

迁移窗口缩短后，团队可以在窗口内冻结该单元的变更。一次 release 只有在以下条件全部满足后才能切换：

• DDL 转换与 schema comparison 通过；
• DMS Full Load 和 CDC 达到要求；
• 关键数据对账通过；
• PowerCenter 没有未处理的 drift；
• 转换后的 workflow 成功导入；
• 业务侧完成验收。

任意门禁失败，切换都会停止。

稳定期内，Oracle、原 PowerCenter workflows 和 DMS CDC 继续保持可用。切换失败时，PowerCenter 可以返回上一 release，接口重新指向原路径。修复后，团队再次执行幂等 release，重新切换数据、DDL 和 ETL。

结果：从数天缩短到一天以内

一个逻辑数据库单元的迁移 release，从数天、最长接近一周，缩短到一天以内。更短的窗口让受控变更冻结成为可能，也大幅减少了生产 drift 的累积时间。

PowerCenter 开发者原本需要数小时或数天才能获得的反馈，被缩短到几分钟。按照至少 40 位开发者每人每周减少约一到两小时操作时间，再加上 PowerCenter 专家减少的手工工作，我保守估算自动化每周至少减少了 40 小时手工操作。这个数字来自参与人数和原有处理时间的估算，没有使用正式工时统计。

项目最终在 Oracle 合同到期前完成。

这个结果属于整个团队，包括项目经理、AWS 系统管理员、PowerCenter 专家、外包 Snowflake 运维团队、业务用户以及持续交付需求的开发者。

我的贡献是把已有 DDL migration mechanism 改造成幂等 CI/CD release，把 PowerCenter 人工转换建设成能够检测 drift 的标准路径，并把参与开发的 DMS 对接集成到同一个受控迁移 release 中。

这次项目给我留下的结论很简单：自动化首先改变的是迁移窗口。当一次 release 足够短，团队就能在有限窗口内冻结生产变化，让数据、DDL 和 ETL 一起通过明确的门禁切换，并始终保留一条已知的回退路径。