异构信息系统数据迁移方法研究

参考文献 ：
［１］ 王辉 ，来羽 ，陈德祥 ．ＡＳＰ ．ＮＥＴ ３ ．５（Ｃ ＃ ）实用教程 ［Ｍ ］ ．北京 ：清华 大学出版社 ，２０１１ ．
［２］ 王珊 ．数据库系统简明教程 ［Ｍ ］ ．北京 ：高等教育出版社 ，２００４ ． ［３］ 赵大伟 ，陈刚 ．基于 ．ＮＥＴ 的多条件组合查询技术的设计与实现
在对各类数据进行分类以后 ，要确定迁移范围 ，即迁 移哪些数据 、放弃哪些数据 。 从实践中 ，确定数据迁移范 围可将完整性 、完备性 、一致性 、回溯性 、连续性 、实用性和 可测性 ７ 项指标作为依据 ，具体如下 ：① 完整性 ：对单一业 务支持的数据是完整的 ，不存在缺失 ；② 完备性 ：所有业务 功能单元需要的数据都被迁移或者设置 ；③ 一致性 ：不同 业务单元对同一个业务要素的数据一致 ；④ 回溯性 ：对于 老系统中的历史信息 ，切换前后要有机制保证用户能够访 问和使用 ；⑤ 连续性 ：新系统切换后 ，跨越该时点的业务数 据被迁移 ，业务服务能够延续完成 ，并生成与切换前一致 的结果 ；⑥ 实用性 ：考虑到系统切换中 ，新老两个系统是异 构的 ，要充分论证迁移数据的必要性 ，避免过多的无用数 据 ，以免造成切换窗口延长及在新系统内部产生“过敏”数 据 ；⑦ 可测性 ：在系统切换前后 ，需要构建一种机制快速确 认数据迁移的成功 ，对无法测试的数据进行迁移会增加风 险。 ２ ．３ 迁移场景
在迁移范围确定后 ，要分析和确认老系统业务数据在 新系统中的表述形式 ，在迁移策略文档明确描述新老系统 各数据字段映射和关联关系 。 图 ２ 列举了 ６ 种典型的数 据迁移场景 。
图 １ 基于迭代优化的数据迁移流程
２ ．２ 需求分析 为了控制数据迁移的风险 ，减少系统切换当天迁移的
数据量 ，需要将新系统的数据进行分类 ，有针对性地进行
（２）动态业务数据 。 这些数据是老系统业务运营过程 中动态生成的 ，具有不可预见性和变动快的特点 。 历史数 据也属于动态业务数据的范畴 ，由于必须切换时间窗口才 能确定 ，所以无法提前测试 ，是整个迁移中风险较高的数 据。
（３）跨期业务数据 。 这部分数据也是动态数据中的一 部分 ，特别之处在于相关数据跨越切换点时 ，与连续性要 求密切相关 ，是风险最高也是最重要的数据 。 对动态和跨 期数据的处理是切换过程的重点 。
（２）数据转换 。 就是从老系统中提取原始数据 ，按照 需求分析确定的字段映射关系进行转换 。 数据迁移的需 求理解是个不断递进的过程 ，在迭代后期的运维测试中 ， 随着对业务规则理解的不断深入 ，映射关系常常需要调 整 ，这就要求迁移脚本要灵活调整新老数据的映射关系 ， 可以通过构建数据库中间表存储映射关系进行转换 ，尽量 避免硬编码 。
［Ｊ］ ．电脑知识与技术 ，２０１２ ，８（２５） ：６０４５‐６０４８ ． ［４］ ［美］ＪＡＳＯＮ ＰＲＩＣＥ ，邱仲潘 ．Ｃ ＃ 数据库编程从入门到精通 ［Ｍ ］ ．
北京 ：电子工业出版社 ，２００３ ． （责任编辑 ：孙 娟 ）
作者简介 ：李珏峰（１９７９ － ） ，男 ，浙江绍兴人 ，博士 ，银行间市场清算所股份有限公司系统运维部总经理助理 ，研究方向为软件工程 、云 计算 、金融数据分析 。
（３）不同类型的数据库 。 在 Ｏｒａｃｌｅ 等关系数据库成 为主流之前 ，早期大型程序有些采用大型机 ＩＢＭ ＩＭ Ｓ 数 据库 ，有些则采用基于文件系统存储数据 。 对于这些迁 移 ，需要借助厂家的专业工具 。 ２ ．４ ．２ 迁移步奏
在数据迁移的技术实践中 ，可以使用数据提取 、转换 和加载（ＥＴ Ｌ ）工具 ，或者单独编写 ＳＱＬ 批处理脚本 。 在
术实现和迁移验证 ３ 个重要环节 。 鉴于新老系统设计的 差异和复杂性 ，需要进行迁移验证 ，比较迁移后新老系统 的运行差异 ，发现不足 ，通过多次迭代不断优化迁移方案 ， 实现系统切换后业务功能的平稳过渡 。
方案设计 。 （１）基础业务数据 。 从数据特性来看 ，这部分数据在
新系统业务规则确定以后不需改动 。 从迁移角度 ，可以提 前迁移完成并进行反复验证 。
在数据迁移需求明确之后 ，技术人员要设计合适的技 术手段完成数据迁移 。 ２ ．４ ．１ 技术方案
首先需要分析新老系统的存储形式 ，对于不同的数据 存储形式选择不同的技术方案 ，一般分为以下 ３ 种 ：
（１）同一系列的关系数据库 。 这种情况是数据迁移中 最理想的状态 。 一般厂商对于同系列数据库产品会向下 兼容 ，字段类型 、操作语言和数据格式等方面具有一致性 ， 可以减少迁移过程中的转换 ，降低异常数据出现的几率 。
总之 ，数据迁移不是单纯的数据“搬运” ，而是按照全 新的“图纸”进行数据“重构” 。 不仅要对老系统中的业务 数据进行清洗 ，剔除异常数据 ，而且要完成新老系统数据 的映射关系和新业务要素的生成规则 ，并最终用技术手段 予以实现 。
２ 基于迭代优化的数据迁移方法
２ ．１ 流程框架 如图 １ 所示 ，数据迁移的基本流程包括需求分析 、技
０ 引言
信息系统一般在使用数年后都会升级换代 。 从系统 架构角度看 ，一个应用系统可以简单划分为业务数据代码 （程序）和操作数据代码（程序）两部分 。 从某种意义上讲 ， 数据是系统最重要的部分［１‐２］ ，银行等大型金融机构一般 都有数据中心运营业务 ，在容灾方案设计中对于数据的保 障程度一般也优先于应用程序 。 如何把重要的业务数据 从原有的系统迁移到新系统 ，保证新老系统切换时对外服 务的连续性 ，同时保证老系统运行期间积累的大量珍贵历 史数据得以保留 ，降低对终端用户的影响 ，是新系统上线
异构信息系统数据迁移方法研究
李珏峰
（银行间市场清算所股份有限公司 系统运维部 ，上海 ２００００２）
摘 要 ：随着业务和技术的发展 ，运行多年的信息系统常常需要更新换代 ，要将老系统多年运行产生的大量珍贵数据 迁移到新系统 ，以保证系统切换后业务平稳过渡 。 数据迁移不仅是数据的搬运 ，还要完成数据内容和格式的转换 。 从异构信息系统的差异和特点入手 ，介绍了基于迭代优化的数据迁移方法 ，包括需求分析 、技术实现和迁移验证 ３ 个 重要环节及其实施要点 。 通过一个全国性金融信息系统切换的项目实践 ，验证了迁移方法的有效性 ，对同类型异构 信息系统的数据迁移具有重要的借鉴意义 。 关键词 ：数据迁移 ；异构信息系统 ；迭代优化 ；并行运行 ＤＯＩ ：１０ ．１１９０７ ／ｒｊｄｋ ．１４３２５３ 中图分类号 ：Ｔ Ｐ３９２ 文献标识码 ：Ａ 文章编号 ：１６７２‐７８００（２０１４）００９‐０１３２‐０４
（５）多对一合并 。 这种类型的迁移可以参考一对多拆 分场景 。
（６）完全重构 。 在该场景下 ，新系统的业务要素在老 系统中不存在 ，需要根据新系统的业务逻辑重新生成 ，定 义新系统数据的生成规则 ，其构建的难度和工作量最大 。 如果新系统中对于数据库设计的约束不强 ，很容易产生一 致性错误 。
以上场景以外 ，还存在一些老系统中的业务数据没有 迁移到新系统中 ，需要通过技术和业务分析 ，明确原因 ，以 保证核心业务要素 １００％ 覆盖 。 ２ ．４ 技术实现
（２）不同的关系数据库产品 。 近年来 ，关系数据库成 为信息系统的首选 ，Ｏｒａｃｌｅ 、ＤＢ２ 、Ｍ ｙＳＱＬ 等产品成为主 流 ，这些产品虽然都采用了结构化查询语言 （ＳＱＬ ）标准 ， 但是在具体的字段类型 、操作语言和数据格式方面还存在 一定的差异 。 在具体转换时 ，如果需要使用数据库 ＳＱＬ 脚本进行迁移 ，则要对不同品牌的数据库进行转换 ，或者 使用基于程序的数据迁移 ，例如使用 Ｊａｖａ 程序调用不同 产品的 ＪＤＢＣ 驱动进行迁移 。
查询 ，使用字符串拼接对 Ａｃｃｅｓｓ 数据库进行了模糊查询 及多条件组合查询 ，加深了对数据库操作技术的理解 ，发 挥了结构化查询语言的优势 ，强化了数据管理系统的功 能 ，也为后续学习打下了良好基础 。
图 ４ 多条件组合查询结果
３ 结语
本文基于 ＡＳＰ ．ＮＥＴ 实现了对 ＳＱＬ Ｓｅｒｖｅｒ 数据库的
（２）单表合并 。 指原有系统一张表中的多条记录在新 系统中合并到一条记录 。
（３）单表拆分 。 这种类型的迁移与单表合并场景产生 的背景类似 ，可以参考多表合并场景 。
（４）一对多拆分 。 这种类型是指原有系统中一张表中 的一条记录被拆分到新系统中的多张数据库表中 ，这是比 较复杂的场景 ，一般由新老系统不同模块间重新划分变化 引起 ，容易导致数据一致性问题 ，需要考虑两条记录的关 联约束关系 。
的重要步骤 ，也是工程实践的重要课题［３‐６］ 。 本文以上海 清算所新一代综合业务系统上线数据迁移工作实践为基 础 ，总结了数据迁移的目标 、方法 、技术和验证工作 。
１ 数据迁移
数据迁移课题来自于技术和业务两大方面 。 （１）技术角度分析 。 首先 ，老的信息系统由于是多年 前开发 ，应用架构和系统平台过时 ，例如传统的 Ｃ／Ｓ 架 构 、较老的数据库产品 （很多甚至采用文件系统 ） 、老式的 编程语言等 ；其次 ，新开发的系统一般会使用较新的架构 和平台技术 ，例如面向服务的架构（ＳＯＡ ） 、Ｊ２ＥＥ 、云平台 、
Baidu Nhomakorabea ９ 期 李珏峰 ：异构信息系统数据迁移方法研究
· １３３ ·
分布式 、新型关系数据库 、Ｈａｄｏｏｐ 集群等 。 技术上的差异 需要迁移时对数据格式 、存储形式 、数据之间的协同关系 等进行调整转换 。
（２）业务角度分析 。 首先 ，老系统由于年代久远 ，经过 多次开发 ，很多技术文档已经不能准确反映代码的实现 ， 准确地理解老系统中各业务数据的含义是迁移成功的重 要前提 ；其次 ，为了适应后续业务发展 ，新系统的功能设计 往往具有前瞻性 ，引入了更多的业务要素 ，需采用参数化 设计以保证灵活性 ；最后 ，老系统在漫长的生命周期中经 过了多次变更 ，不同阶段的历史数据与不同时期的代码逻 辑和业务数据模型不配套 ，有时还会包含异常数据 ，这些 在老系统内“无害”的数据 ，却有可能引起新系统的“过敏” 反应 。
图 ２ 数据迁移 ６ 个典型场景
· １３４ ·
软 件 导 刊 ２０１４ 年
（１）单表转换 。 是数据迁移中最简单和理想的方式 ， 一般存在于功能变化不大的业务模块中 。 由于新老系统 数据表示方法不一致 ，需要添加必要的映射和逻辑转换 。
数据迁移“完全重构场景”下 ，需要根据实际需要编写存储 过程 ，生成新系统中的业务要素 ，步骤如下 ：
（１）数据清洗 。 该步骤的目的是为了去除老系统中存 在质量问题的异常数据 ，保证迁移成功 。 异常数据大致分 为 ３ 类 ：① 不完整和错误的数据 ：该类数据常常由于老系 统程序不够健全原因导致 ，或者前期异常修复中由于后台 修改数据引入所致 ，例如数据类型编码格式 、不可识别字 符 、日期格式 、数据越界 、部分关联数据缺失等等 ，这就需 要明确老系统各业务数据的定义和关联 ，可以考虑在老系 统中直接处理或者调整 ；② 表述不一致的数据 ：有些在老 系统中属于查看型的业务数据 ，在新系统中成为了业务数 据处理的一部分 ，不一致的表述方式会导致出错 ，例如 ，一 些查看项有时用“是”和“否” ，有时用“Ｔ”和“Ｆ” ，这样在重 构新系统数据时导致程序出错 ，这就需要明确新系统数据 处理的过程和要求 ，有针对性地处理 ；③ 重复的数据 ：在老 系统中由于没有数据库主键约束等原因 ，某些特殊业务流 程会导致重复数据存在 ，老系统使用了更新时间等逻辑判 断选择使用 ，不影响功能 ，新系统由于数据模型与代码设 计的不同 ，这类数据往往会引起系统错误 。 可以考虑通过 新系统数据库主键约束等方式进行识别后过滤 ，或者在条 件允许的情况下 ，在老系统中按照业务规则直接将该类数 据删除 。