30天，1000张表逻辑迁移——AI辅助下的数据系统重建实录

一、项目背景：为什么叫"逻辑迁移"而不是"系统搬家"

银行分行间的数据系统迁移，与应用端系统迁移有着本质区别。应用端迁移关注的是"把页面和接口搬到新环境"，而数据系统迁移的核心是"让成熟的加工逻辑在新数据源上跑通"。

某分行A运行多年的数据加工系统，核心逻辑成熟稳定。某分行B需要建立同样的数据加工能力，但面临一个关键差异：

• 数据源不同：两家分行都接收总行下发的数据，但申请批次不同，数据格式略有差异
• 外部数据差异更大：RPA爬取数据、手工统计数据的格式与总行下发数据存在显著差异，需要大量代码适配
• 不是搬家，是重建：B分行从零搭建系统，复用A分行的加工逻辑，但必须兼容B分行接收到的数据格式

这套系统的资产清单： - 1023张DDL建表脚本 - 36个视图 - 22个Oracle包体、25个包头 - 300个SQLLoader控制文件 - 14个Shell调度脚本 - 1833条配置记录、160条*入队规则记录

传统做法的困境：接手一个运行多年的系统，了解全貌是首要难题。靠人工翻阅代码、做笔记、画流程图，单人耗时约10人天，且难以形成可共享的文档。更复杂的是，数据系统迁移还要面对数据格式兼容性这一应用端迁移很少涉及的问题——A分行的代码是基于A分行接收到的数据格式写的，B分行接收的数据字段顺序、类型、长度、日期格式可能完全不同。

我们的策略：采用AI辅助+人工决策的协作模式。不盲目追求最新大模型，而是把AI定位为"超级审计助手"，负责全面扫描、格式差异比对、结构化输出；迁移方案的制定、数据格式兼容层的设计、部署决策仍由项目组成员完成。

二、第一步：系统摸底——用AI扫描"逻辑资产"

目标：让AI先"读懂"系统的加工逻辑，而非数据内容。

通过OpenCode（基于DeepSeek V4 Flash）对项目进行全量扫描，自动生成项目知识文档（AGENTS.md），相当于给B分行团队发了一本"系统说明书"。

知识库涵盖的内容：

关键经验：生成知识库不是最终目的，而是后续所有审计和迁移工作的"导航地图"。有了它，B分行后续参与项目的成员无需再花10人天翻代码，直接看文档即可上手。

三、第二步：代码审计——审逻辑，更审"数据兼容性"

目标：在迁移前，搞清楚"哪些加工逻辑可以直接复用，哪些必须因格式差异而重写"。

以一个实际需求为例：分析4个存储过程中引用了哪些表和视图，并确认各自的DDL文件是否存在，同时评估数据格式兼容性。

完整审计步骤：

1. 从4个存储过程中提取所有被引用的数据库对象，共计44个（34张表+10个视图）
2. 逐一核对每个对象在Tables/和Views/目录下是否存在对应DDL文件
3. 搜索全部22个包体，查明每个对象的数据流向和加工逻辑归属
4. 新增：比对A分行与B分行接收到的同名字段的数据格式差异
5. 综合分析调度依赖链路，形成调度流程图
6. 将分析结果导出为结构化Excel文件

效率对比：

核心发现： - 25个引用对象缺少对应的DDL文件（运行时动态创建或历史遗漏） - 3张中间表在全部包体中均无加工逻辑代码（外部系统写入或已废弃） - 数据格式兼容性风险：同一字段在A分行和B分行的数据格式存在差异

格式差异的四个维度：

重要认知：AI在"找全"和"比对"上有绝对优势，但"判断这25个缺失是合理遗留还是迁移风险"、"NUMBER转VARCHAR是否会影响下游计算精度"必须由人来定。AI负责发现异常，人负责定义风险等级。

四、第三步：数据格式兼容层设计——数据迁移独有的"翻译层"

这是数据系统迁移与应用端系统迁移最大的差异点。应用端迁移很少需要处理"数据格式翻译"，但数据系统迁移必须建立数据格式兼容层。

核心挑战：A分行的代码是基于A分行接收到的数据格式写的。B分行接收的数据： - 总行下发数据：与A分行批次不同，字段顺序、扩展字段个数略有差异 - 外部数据：格式差异显著，如日期字段可能是字符串类型 - RPA爬取数据：网页抓取的数据常有冗余空格、HTML转义字符 - 手工统计数据：Excel导出的数据可能含有合并单元格、非标准日期格式

我们的解法：建立DATA_FMT_MAPPING配置层

总行下发文件 → 格式兼容层 → 标准数据格式 → 加工逻辑 → 业务报表
  ↓              ↓
外部数据  →  数据清洗规则
  ↓
RPA数据   →  特殊字符过滤
  ↓
手工数据  →  非标准格式转换

格式兼容层的具体工作：

1. 字段名映射：A分行叫 TRADE_DATE，B分行叫 TXN_DT → 建立映射表统一字段名
2. 类型转换：B分行某字段是 VARCHAR(50)，但A分行代码按 NUMBER 做数学运算 → 加 TO_NUMBER 转换并处理异常值
3. 日期格式统一：B分行日期是 YYYYMMDD 字符串，A分行代码期望 YYYY-MM-DD → 加 TO_DATE 转换
4. 长度适配：B分行某字段长度 VARCHAR(200)，A分行DDL定义 VARCHAR(100) → 扩字段长度
5. 扩展字段处理：B分行比A分行多3个字段 → 在ODS层增加预留字段，不破坏原有加工逻辑

CTL控制文件必须重写：

300个SQLLoader控制文件定义了数据文件字段到数据库表字段的映射。由于字段顺序和格式变了，不能照搬A分行的CTL*，必须基于B分行实际数据格式重新生成。

AI辅助方式： - 读取B分行样本数据文件（脱敏后） - 比对A分行CTL与B分行数据字典 - 自动生成CTL草稿（字段顺序、类型映射、日期掩码） - 人工审核后批量替换

五、第四步：迁移执行——"四步走"策略

核心原则：先静态、再动态，先Schema、再数据，先兼容层、再加工逻辑。

Step 1：Schema重建（基于B分行数据格式重新设计DDL）

• 不是原样复制A分行的1023张DDL，而是基于B分行接收到的数据格式重新设计
• 处理字段类型差异（如NUMBER转VARCHAR的兼容性处理）
• 扩字段长度（VARCHAR(100) → VARCHAR(200)）
• 增加扩展字段预留位
• 处理字符集差异（如有历史遗留编码问题）

Step 2：配置本地化（1833条记录环境替换）

• DBC_DATAFILE_CFG表中的文件路径、数据源标识（SRC_FLAG）替换为B分行环境
• 区分不同数据源的配置：总行下发、外部数据、RPA数据、手工数据分别配置
• AI辅助：批量读取配置 → 识别含旧环境变量的记录 → 输出差异报告 → 人工确认后批量替换

Step 3：CTL控制文件重写（适配B分行数据格式）

• 300个CTL不是"一致性校验"，而是重新生成
• 基于B分行样本数据格式，定义字段顺序、类型映射、日期掩码
• 特殊处理：RPA数据需要去除HTML标签，手工数据需要处理空值和异常格式
• AI辅助生成CTL草稿，人工审核字段映射正确性

Step 4：调度重建（在B分行从零搭建）

• 14个Shell脚本重新部署，修改路径变量、环境参数、crontab时间窗口
• DB触发器调度重新初始化：作业队列表、触发器状态在B分行新建
• 关键变化：调度对象从"A分行本地业务数据"改为"B分行接收的总行下发文件+外部数据"
• 文件到达检测机制：检测B分行数据落地目录

六、第五步：调度体系的重新搭建——"嫁接"到新的数据源

某分行A的调度设计很有意思——两套调度并行，处理的是本地业务数据。某分行B需要重建这套调度能力，但处理的是总行下发的数据文件。

Shell侧调度：OS级批量处理，靠crontab驱动

s0_1（入队）→ s0_2（分发）→ s0_3（主调度）

DB触发器调度：事件驱动，靠数据库触发器

PROC_JOB_GEN_QUE（生成队列）→ PROC_JOB_EXECUTOR（执行作业）

两套体系如何衔接？ 通过一个"文件检测虚拟任务"——Shell层在文件到达后写入标记文件，DB层触发器扫描到标记后更新作业队列的READY状态。

B分行重建的核心变化： - 文件检测目录：从A分行本地目录改为B分行接收总行下发的目录 - 入队条件：从"本地业务数据生成"改为"总行下发文件到达+RPA数据抓取完成" - 数据频率：A分行某些数据是日频，B分行可能是月频（申请批次不同） - 外部数据触发：RPA抓取完成后需要独立触发入队

与应用端系统迁移的对比：

核心差异：应用端迁移可以"界面先行，数据后补"；数据系统迁移必须"数据格式先通，加工逻辑才能跑"。数据是地基，格式不兼容，上层逻辑全部失效。

七、安全与校验：数据系统迁移的安全红线

数据系统迁移比前端代码迁移更敏感——涉及生产数据、金融合规、断点风险。

我们总结了四步安全校验流程：

1. Schema审计：所有DDL在测试环境先执行，对比A分行与B分行的表结构差异（字段数、类型、索引、分区）
2. 格式兼容性空跑：用B分行样本数据（脱敏）跑通全流程，不处理真实数据。验证字段类型转换、日期转换、数值精度是否异常
3. 配置脱敏：配置表中的FTP路径、IP地址、账号标识等敏感信息，先替换为占位符再审计，最后人工还原
4. 回滚预案：迁移切换窗口期内，保留A分行环境并行参考能力，确保B分行可独立回退

核心原则：AI可以辅助生成校验脚本，但任何进入生产环境的代码，必须经过人工审核+测试环境验证+灰度切换三道关卡。数据格式转换中的精度丢失（如NUMBER转VARCHAR后四舍五入差异）必须由人判断业务影响。

八、提示词设计：让AI读懂"格式差异"

数据迁移的提示词设计，与前端重构不同。前端是让AI把Vue2转成Vue3，数据迁移是让AI从PL/SQL包体和CTL文件中抽取出格式依赖关系，并比对不同数据源之间的差异。

用于数据格式兼容性审计的提示词模板：

你是一名资深的Oracle数据仓库工程师，熟悉PL/SQL包体、SQL*Loader控制文件、数据格式转换。

请分析以下两份资料，完成数据格式兼容性审计：

【资料1：A分行DDL定义】
（此处粘贴表结构定义）

【资料2：B分行样本数据格式说明】
（此处粘贴字段列表、类型、长度、日期格式）

请完成以下任务：

1. 逐字段比对A分行DDL与B分行数据格式，标记差异类型：
   - 字段顺序差异
   - 字段类型差异（如NUMBER vs VARCHAR）
   - 字段长度差异
   - 日期格式差异
   - 扩展字段差异（B分行多出的字段）

2. 对每处差异，评估对下游加工逻辑的影响等级：
   - 高：会导致存储过程编译失败或计算异常
   - 中：需要类型转换但逻辑可保持
   - 低：仅长度扩展，不影响逻辑

3. 为每个高/中等级差异，给出适配建议：
   - DDL修改方案（扩字段/改类型/加转换函数）
   - CTL控制文件字段映射调整
   - 存储过程兼容性修改点

4. 输出格式：Markdown表格，包含字段名、A分行格式、B分行格式、差异类型、影响等级、适配建议。

核心要求：
- 严格基于提供的两份资料比对，不推测未出现的字段；
- 对不确定的映射关系（如B分行某字段可能对应A分行多个字段），用// TODO标注并说明原因；
- 如果存在日期格式转换需求，给出具体的Oracle TO_DATE/TO_CHAR转换函数示例；
- 如果涉及NUMBER与VARCHAR混用，提醒精度丢失风险。

核心技巧：数据迁移的提示词要做到"角色前置、双输入比对、分级评估、给出具体代码"。否则AI会泛泛而谈"需要注意格式差异"——这在金融系统迁移中是灾难性的。必须让AI输出可执行的DDL修改语句和CTL字段映射。

九、沉淀：数据系统迁移的标准SOP

这次迁移不是一次性工作，未来还会有其他分行建立数据加工能力。基于这次实践，我们沉淀出一套标准流程，在原有6步配置流程基础上，前置增加了"数据格式兼容性审计"。

关键认知：数据系统迁移与应用端系统迁移的本质差异——

• 应用端迁移：代码是主体，数据是配角
• 数据系统迁移：数据格式是地基，加工逻辑是建筑。地基不平，建筑无法复用

最后：迁移的核心，从来不是AI，而是"让逻辑在新数据上跑通"

不能盲目追求"用最强的AI模型"，却忽略迁移的本质——AI只是辅助工具，无法替代流程和人工决策。

决定数据系统迁移成败的，从来不是你用了多先进的AI，而是你有没有想清楚： - 源分行的加工逻辑是什么？（知识库） - 目标分行的数据格式差异在哪？（兼容性审计） - 哪些逻辑可以直接复用，哪些必须重写？（适配层设计） - 调度在新数据源上能跑通吗？（验证） - 出了问题能回滚吗？（安全）

清晰的流程、明确的数据格式兼容策略，加上AI的辅助，才能尽可能降低返工、烂尾的可能。

数据系统迁移，核心是"让逻辑适配新数据"，而非"把系统搬到新地方"。重建的是能力，不是副本；翻译的是格式，不是数据。

附：迁移效率对比（统一人天评估）

关键说明：数据系统迁移比应用端系统迁移多出一个数据格式兼容性审计环节（约2人天）和CTL逐文件审核（约3人天），这是应用端迁移不需要的。AI把“翻代码、找差异”的脏活累活从20人天压缩到2人天，但“审结果、定方案、做决策”的10人天省不掉。

作者简介 [可补充：你的姓名、部门、主要项目经历]

关注北银金科逐浪青春，获取更多数据工程与AI实战干货。