旧数据清洗与结构转换的核心思路是“先评估后清洗、先映射后转换”，通过数据血缘分析与字段级映射表，按目标数据库的兼容性规则逐层处理，最终用增量验证确认迁移质量。
信创迁移数据清洗步骤：先认清旧数据的真实状态
信创迁移不是把数据从A库搬到B库那么简单,旧系统通常跑了五年甚至十年以上，里面藏着大量“历史包袱”：字段值乱填、编码不一致、重复记录、业务逻辑依赖旧库的隐晦特性，如果直接迁移，后续应用大概率跑不通。
第一步，盘点存量数据。 把源库里的表、字段、约束、索引、存储过程全部列出来，统计每张表的行数、增量频率、空值率、重复率，这一步不用急着写代码，先摸清底数，行业共识认为，超过半数迁移项目的工期延误都源于对源数据质量的低估。
第二步，做数据血缘分析。 找到每个字段从哪张表来、经过哪些转换、最终被哪个应用使用，举个常见例子：旧系统里“客户状态”字段用A/B/C表示，新系统里要求用0/1/2，如果不做血缘分析，你会漏掉存储过程里那几段隐式赋值逻辑。
第三步，建立清洗规则清单。 按字段维度列出现状、目标值、清洗动作、处理人，电话号码字段存在空格和-号，统一去掉非数字字符”“性别字段有男、M、1三种写法，全部映射为标准码”，这张清单就是后续开发的施工图。
数据库迁移字段映射：别让类型转换成了数据杀手
字段映射是整个结构转换的核心,映射表至少包含源字段名、源类型、目标字段名、目标类型、转换规则、失败处理策略，很多团队直接照抄表结构，结果一跑就报错，因为类型兼容性和业务含义是两回事。
常用类型对应关系要提前验证。 比如Oracle的NUMBER(10)迁到GoldenDB可以对应DECIMAL(10)或BIGINT，但如果源数据里有小数，就得保留SCALE，MySQL的DATETIME迁到OceanBase没问题，但老的TIMESTAMP取值范围会卡在2038年，这种情况就需要转为VARCHAR或者拆成年月日字段，建议建一张“源-目标类型兼容性对照表”，每个映射对都标明风险等级。
枚举值映射是另一个大坑。 旧系统里“订单状态”可能用一堆数字，但新系统改成了字符串枚举，做映射时，把源库所有非空的枚举值都SELECT DISTINCT出来，写成字典表。未出现在字典里的值，单独标记为“待确认”，不能默认置空。
索引和约束同样需要转换。 旧库里的复合索引顺序可能不符合新库的优化器习惯，外键关系如果跨越多个库，迁移后要重新设计或去掉，建议在映射表中额外记录“原索引、原约束”以及“目标建议”，给DBA和开发一起评审。
国产化改造旧数据兼容性测试：边转边验，别等最后一把梭
很多项目把清洗和转换写成一个离线脚本,跑完就算完事，结果上线后才发现数据对不上，正确的做法是把兼容性验证拆进每一步。
并行跑批对比
迁移过程中,保留一份原始库的快照，清洗脚本每处理完一批，就同时跑一条统计SQL比对源库和目标库的总行数、关键字段SUM值、非空值计数，任何一个数字对不上，立刻停下来查脚本，而不是调大批次继续跑。
抽样人工复核
自动对比只能发现数量级差异,不一定能看出业务含义是否被扭曲，比如一个日期字段被统一转成字符串“YYYY-MM-DD”后，如果有进程老想拿它做时间戳运算，就会出错，所以每个清洗规则至少抽20条记录，由业务人员人工确认含义没有变化。
反向验证
用目标库的数据反推业务报表,看能不能产出和旧系统一样的统计结果，行业专家指出，这一步最容易被跳过，但它是发现“隐性坏数据”的唯一可靠手段比如那些写了但永远查不出来的脏值，迁移后突然炸了。
实操步骤：一个典型的清洗与转换流程
下面这个流程基于常见信创项目经验,适合业务系统相对集中的场景。
- 导出源库元数据。 用源库自带工具导出所有表的DDL，生成字段清单，同步导出全量数据到临时存储，建议用CSV或Parquet格式，避免源库连接池被拖垮。
- 编写静态清洗规则。 处理空值、去重、格式统一，去重时基于业务主键，而不是物理主键，比如同一个用户ID对应多个手机号，保留最后更新时间最大的那条。
- 处理编码与字符集。 旧库如果用了GBK，需要先转为UTF-8，再检查有没有无法转换的二进制字符，这一步常被忽略，但转换后乱码是最高频的迁移事故。
- 执行字段映射转换。 根据映射表写转换规则，优先用ETL工具的可视化映射，复杂逻辑用脚本实现，转换时强制校验目标库的约束，发现超长度、非法日期、违反非空约束的行，写入错误日志表。
- 加载进目标库。 先加载基础表，再加载业务表，最后处理关联表和维度表，加载时关闭目标库的外键检查，结束后重建索引并重新启用约束。
- 全量校验与增量同步。 全量完成后，记录源库的增量日志（或时间戳字段），做一次增量追平，追平阶段每5分钟比对一次，持续两小时没有差值，才算正式切换。
信创迁移数据丢失如何避免：关键就卡在这几个节点
数据丢失大部分不是技术问题,而是“没人知道一条数据为什么被删了”，要避免丢失，需要守住三个节点。
清洗规则评审。 所有涉及“删除”“替换”“置空”的规则，必须列出具体字段和条件，业务方签字确认，清除2015年以前的日志表数据”算不算丢失？要看这些数据有没有审计价值。
断点续跑机制。 迁移脚本执行到一半挂了，重新跑的时候不要从头来，每个批次的处理结果先写入staging表，再原子提交到目标库，这样即使崩溃，也能定位到断点继续处理。
稽核报表设计。 迁移完成后，出一份包含以下指标的稽核报告：
| 检查项 | 通过标准 |
|---|---|
| 源表与目标表行数差异 | 差异为0 |
| 关键主键重复率 | 目标库为0 |
| 必填字段空值率 | 与源库一致 |
| 外键约束通过率 | 达到100% |
| 抽样字段值匹配率 | 达到99%以上 |
如果上述任何一项不达标,宁可推迟上线，也不要带病切换。
不同场景下的处理差异
不同数据形态的清洗和转换侧重点完全不同。
- 结构化表数据（业务系统）：重点处理字段映射、类型转换、外键关系，操作路径清晰，但工作量大，适合用ETL工具批量处理。
- 文件型数据（报表、附件、XML）：先扫描文件目录，建立文件清单和元数据索引，转换重点在目录结构调整、文件名规范化、内嵌编码识别，这一步必须边转换边做完整性校验，防止文件半截丢失。
- 实时接口数据（消息队列、API日志）：这类数据的清洗不能停，只能做流式转换，规则复杂度低，但异常处理要求高消息格式一变，就要自动抛到死信队列里人工处理。
Q&A：信创迁移数据清洗常见问题
问：旧系统里大量历史数据根本没有业务意义了，还需要清洗吗？
需要,但可以分级处理，先区分“活跃数据”“历史参考数据”“归档数据”，活跃数据按标准流程清洗和转换；历史参考数据只需要保证能查能看，可以简化转换规则，甚至以只读表形式挂到新库；归档数据继续留在旧库，用独立查询通道提供访问，这样能控制清洗范围，避免把精力耗在无意义的字段上。
问：字段映射表由谁维护，遇到源库和目标库语义不一致怎么办？
映射表必须由数据架构师牵头,业务分析师和开发共同维护，语义不一致时，以业务需求为准，而不是谁单方面说了算，比如源库的“金额”字段可能是含税价，目标库要存不含税价，那就必须在映射规则里写明“减税逻辑”，并让财务人员确认。
问：迁移完成后发现还有数据需要调整，怎么处理？
建立一套变更流程,不要直接改目标库，先把变更需求提交到数据治理平台，生成新的映射规则，走一次小范围的“重放迁移”只针对受影响的数据，重新执行清洗逻辑，然后做差异比对，这个过程要保留完整的操作日志，确保可追溯，最终结果以稽核报表为准，确认无误后更新正式库。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/622030.html
