📚 课程目录第1章课程导入

1. 课程导入

欢迎进入《核心银行迁移数据质量验收实战》。在正式进入工具、脚本与验收细则之前，本章先解决三个问题：为什么要做核心银行迁移？为什么数据质量验收是迁移成败的分水岭？这门课将带你掌握哪些可落地的能力？只有把背景、风险和课程地图对齐，后续每一章的验收动作才有明确的判断标准。

一、核心银行迁移背景：不是“换系统”，而是“换心脏”

核心银行系统承载客户、账户、合约、余额、交易流水、利息、费率、额度、担保、总账等关键数据，是银行日常运营的“心脏”。当银行因架构升级、并购整合、信创替换、产品重构或云化改造而启动核心迁移时，本质上是在业务不停机或短停机窗口内，把旧核心的数据、逻辑与状态整体迁移到新核心，并保证迁移后业务连续、账务准确、监管合规。

核心银行迁移通常不是单一数据库搬迁，而是多层同时变化：数据模型变化、产品参数变化、核算规则变化、接口协议变化、批处理时序变化。常见迁移形态包括：

同构迁移：表结构基本一致，主要做数据搬运与清洗，风险相对可控。
异构迁移：新旧模型差异大，需要字段映射、码值转换、拆分合并、补全默认值。
逻辑迁移：不仅搬数据，还要搬利息计算、费用计提、额度占用、总账分录等业务逻辑。
并行切换：新旧核心并行运行一段时间，进行双跑比对与差异收敛。

迁移项目一般经历“现状调研—映射设计—数据清洗—模拟迁移—并行验证—切换上线—上线后观察”等阶段。数据质量验收贯穿始终，尤其在模拟迁移与并行验证阶段，是发现问题的黄金窗口。

核心银行迁移的典型约束：停机窗口极短、监管报送不可中断、客户资金不能出错、历史交易必须可追溯、总分核对必须平衡。任何一条被忽略，都可能从技术问题升级为生产事故。

二、数据质量验收的重要性：迁移成败的“最后一道闸门”

很多迁移项目在技术切换上成功，却在数据质量上翻车。典型表现是：上线后客户余额对不上、账户状态错误、利息少算或多算、总账不平、报表口径漂移。这些问题往往不是切换当天才出现，而是迁移前数据质量验收不充分，导致脏数据、断链数据、映射错误被带入新核心。

数据质量验收的核心目标，不是“把数据搬过去”，而是证明迁移后的数据在完整性、准确性、一致性、唯一性、有效性、及时性六个维度上满足业务与监管要求。它需要回答四个关键问题：

全不全：该迁的客户、账户、合约、流水是否全部迁移，有无遗漏或重复。
对不对：余额、利息、额度、状态、日期等关键字段是否与旧核心一致或符合新规则。
平不平：总分、账户与流水、合约与余额、内外账之间是否平衡。
能不能用：迁移后数据能否支撑开户、交易、计息、报表、报送等真实业务场景。

验收不是一次性动作，而是“规则定义—脚本校验—差异分析—修复复验—签字确认”的闭环。没有闭环的验收，只是抽样看看，无法支撑上线决策。

三、方法流程：从“抽样看数”到“工程化验收”

本课程强调工程化验收方法，而不是依赖人工抽样。一个可复用的验收流程通常包含以下步骤：

建立数据资产清单：明确迁移范围，列出表、字段、数据量、责任人、优先级。
定义验收规则：把业务规则翻译成可执行的校验规则，如“账户余额 = 所有未销户流水合计”。
准备基线数据：从旧核心抽取迁移时点快照，作为比对基准。
执行自动化校验：用 SQL、Python、ETL 工具或专用比对平台批量跑规则。
差异分级与归因：区分致命、严重、一般、提示四级，定位是映射问题、清洗问题还是源数据问题。
修复与复验：修复后必须重跑规则，保留证据链。
出具验收报告：给出通过率、未通过项、风险敞口与上线建议。

例如，校验账户余额一致性时，常用如下 SQL 思路：

-- 校验新旧核心账户余额差异
SELECT a.acct_no,
       a.balance AS old_balance,
       b.balance AS new_balance,
       (b.balance - a.balance) AS diff
FROM old_core.account_balance a
JOIN new_core.account_balance b
  ON a.acct_no = b.acct_no
WHERE ABS(b.balance - a.balance) > 0.01
ORDER BY ABS(b.balance - a.balance) DESC;

执行后若发现大量差异，不能直接判定“新核心错”，而要先检查迁移时点、币种精度、冻结金额口径、是否包含未过账交易等。验收的本质是用证据说话，而不是用感觉判断。

四、案例与场景：一次“余额差一分钱”的复盘

某银行在核心迁移模拟验证中，发现一个储蓄账户新旧余额相差 0.01 元。单看金额极小，但排查后发现：旧核心在利息计提时采用“四舍五入到分”，新核心采用“截断到分”，导致大量账户在批量计息后出现分位差异。若未在验收阶段发现，上线后日终计息将产生海量差异，总分不平，监管报送也会受影响。

这个案例说明：数据质量验收不能只看“大数”，还要看规则级差异。验收清单应覆盖：

验收维度	典型检查项	常见风险
完整性	客户数、账户数、流水数、合约数比对	漏迁、重复迁移
准确性	余额、利率、额度、状态、日期	映射错误、精度丢失
一致性	总分核对、账户与流水、内外账	跨表断链、口径不一致
唯一性	主键、账号、客户号、合约号	主键冲突、重复记录
有效性	码值、日期格式、金额范围	非法码值、空值、越界
及时性	迁移时点、批次时间、流水顺序	时点错乱、顺序颠倒

常见误区：把“数据能导入”当成“数据质量合格”；把“抽样通过”当成“全量通过”；把“差异存在”当成“业务可接受”。验收必须全量、可追溯、有签字。

五、学习目标与整体课程框架

完成本课程后，你将能够：

理解核心银行迁移的数据风险地图，识别关键验收对象。
独立设计数据质量验收规则与校验脚本。
使用 SQL、Python、比对工具完成全量或抽样验证。
对差异进行分级、归因、修复与复验。
输出可支撑上线决策的验收报告与证据链。

课程整体分为六个模块：背景与框架（第1—3章）、数据质量规则设计（第4—8章）、迁移映射与清洗验证（第9—14章）、自动化校验与工具实战（第15—21章）、并行验证与差异收敛（第22—26章）、上线验收与复盘（第27—30章）。每一章都围绕真实迁移场景展开，强调“规则—脚本—证据—结论”的闭环。

学习建议：每学完一章，回到你所在项目的迁移范围，尝试写出至少三条可执行的验收规则。课程结束时，你将拥有一套属于自己的核心银行迁移数据质量验收清单。

核心银行迁移数据质量验收，既是一项技术工作，也是一项风险管理工作。它要求我们既懂数据，也懂业务；既能写脚本，也能做判断。接下来，我们将从迁移背景与风险地图开始，逐步构建完整的验收能力体系。