银行核心系统的数据迁移，被称为"数据工程领域中风险最高的任务"。一个客户的账户余额如果差了一分钱，可能引发挤兑恐慌；一条贷款状态的错配，可能导致司法纠纷。
核心系统数据迁移的复杂性
- 数据体量大：核心系统往往积累20年以上的历史数据，单表数十亿行
- 关联关系深：客户、账户、交易、合约、额度、利率、费用之间相互勾稽
- 一致性要求极致：会计恒等式必须时刻成立，每日试算平衡差异必须为0
- 停机窗口极小：24小时核心系统允许停机的窗口通常只有4-8小时
迁移四阶段模型
第一阶段：全量数据初始化
在切换日前数周，将历史全量数据迁移至新核心系统。采用分片并行抽数，按客户号哈希取模划分N个片。
第二阶段：增量数据同步
全量迁移期间，旧核心系统仍在持续产生新交易。通过CDC机制实时或准实时同步。方案包括Oracle GoldenGate、IBM CDC、Debezium订阅 binlog。核心是时序保证：在CDC消息中嵌入事务ID（XID），消费端按XID顺序应用变更。
第三阶段：数据一致性校验
1. 记录数校验：对每张表做新旧系统记录数对比，差异必须为0。
2. 关键字段值校验：对余额、积数、利率等关键数值字段做SUM比对。
3. 关联校验（勾稽校验）：如"贷款余额 = 本金余额 + 应收利息 + 应收罚息"必须在迁移后仍然成立。
4. 抽样明细穿透校验：随机抽取1%客户逐笔明细比对。
第四阶段：切换与回退
切换日的流程： - T-2日：停止旧核心批量作业，做最终一致性校验 - T-1日：新核心系统启用只读模式对外服务 - T-0日：旧核心停止对外交易写入，切流至新核心 - T+1日：新核心完成第一个完整日终跑批
回退方案必须预演：如果在切换后2小时内发现严重数据不一致，必须在停机窗口内切回旧核心。
实战中的三大陷阱
陷阱一：编码与字符集差异 旧核心主机使用EBCDIC编码，新系统用UTF-8。生僻字在转码时可能变为乱码。
陷阱二：浮点数精度累积 贷款利息计算涉及大量乘除和日期天数计算。旧系统用COBOL的COMP-3，新系统用BigDecimal。经年累月的复利叠加后可能出现总分不一致。
陷阱三：状态机隐含规则 旧核心系统中，账户状态的转换往往不是显式规则，而是嵌入在COBOL代码中的IF-ELSE分支。
总结
银行核心数据迁移的"零差错"靠以下方法论保障： 1. 分阶段渐进：全量基线 + 增量追平 + 多层校验 + 切换回退 2. 交叉验证：记录数、字段SUM、勾稽关系、抽样明细，四道校验缺一不可 3. 预演回退：切流方案必须在投产前做至少3次沙箱演练 4. 敬畏细节：编码、精度、状态机、时序——魔鬼藏在每一个不起眼的细节中