异构信息系统数据迁移方法的问题和从策略

　　文献标识码：A 文章编号文章编号：16727800（2014）009013204
　　0 引言
　　信息系统一般在使用数年后都会升级换代。从系统架构角度看，一个应用系统可以简单划分为业务数据代码（程序）和操作数据代码（程序）两部分。从某种意义上讲，数据是系统最重要的部分[12]，银行等大型金融机构一般都有数据中心运营业务，在容灾方案设计中对于数据的保障程度一般也优先于应用程序。如何把重要的业务数据从原有的系统迁移到新系统，保证新老系统切换时对外服务的连续性，同时保证老系统运行期间积累的大量珍贵历史数据得以保留，降低对终端用户的影响，是新系统上线的重要步骤，也是工程实践的重要课题[36]。本文以上海清算所新一代综合业务系统上线数据迁移工作实践为基础，总结了数据迁移的目标、方法、技术和验证工作。
　　1 数据迁移
　　数据迁移课题来自于技术和业务两大方面。
　　（1）技术角度分析。首先，老的信息系统由于是多年前开发，应用架构和系统平台过时，例如传统的C/S架构、较老的数据库产品（很多甚至采用文件系统）、老式的编程语言等；其次，新开发的系统一般会使用较新的架构和平台技术，例如面向服务的架构（SOA）、J2EE、云平台、分布式、新型关系数据库、Hadoop集群等。技术上的差异需要迁移时对数据格式、存储形式、数据之间的协同关系等进行调整转换。
　　（2）业务角度分析。首先，老系统由于年代久远，经过多次开发，很多技术文档已经不能准确反映代码的实现，准确地理解老系统中各业务数据的含义是迁移成功的重要前提；其次，为了适应后续业务发展，新系统的功能设计往往具有前瞻性，引入了更多的业务要素，需采用参数化设计以保证灵活性；最后，老系统在漫长的生命周期中经过了多次变更，不同阶段的历史数据与不同时期的代码逻辑和业务数据模型不配套，有时还会包含异常数据，这些在老系统内“无害”的数据，却有可能引起新系统的“过敏”反应。
　　总之，数据迁移不是单纯的数据“搬运”，而是按照全新的“图纸”进行数据“重构”。不仅要对老系统中的业务数据进行清洗，剔除异常数据，而且要完成新老系统数据的映射关系和新业务要素的生成规则，并最终用技术手段予以实现。
　　2 基于迭代优化的数据迁移方法
　　2.1 流程框架
　　如图1所示，数据迁移的基本流程包括需求分析、技术实现和迁移验证3个重要环节。鉴于新老系统设计的差异和复杂性，需要进行迁移验证，比较迁移后新老系统的运行差异，发现不足，通过多次迭代不断优化迁移方案，实现系统切换后业务功能的平稳过渡。
　　图1 基于迭代优化的数据迁移流程
　　2.2 需求分析
　　为了控制数据迁移的风险，减少系统切换当天迁移的数据量，需要将新系统的数据进行分类，有针对性地进行方案设计。
　　（1）基础业务数据。从数据特性来看，这部分数据在新系统业务规则确定以后不需改动。从迁移角度，可以提前迁移完成并进行反复验证。
　　（2）动态业务数据。这些数据是老系统业务运营过程中动态生成的，具有不可预见性和变动快的特点。历史数据也属于动态业务数据的范畴，由于必须切换时间窗口才能确定，所以无法提前测试，是整个迁移中风险较高的数据。
　　（3）跨期业务数据。这部分数据也是动态数据中的一部分，特别之处在于相关数据跨越切换点时，与连续性要求密切相关，是风险最高也是最重要的数据。对动态和跨期数据的处理是切换过程的重点。
　　在对各类数据进行分类以后，要确定迁移范围，即迁移哪些数据、放弃哪些数据。从实践中，确定数据迁移范围可将完整性、完备性、一致性、回溯性、连续性、实用性和可测性7项指标作为依据，具体如下：①完整性：对单一业务支持的数据是完整的，不存在缺失；②完备性：所有业务功能单元需要的数据都被迁移或者设置；③一致性：不同业务单元对同一个业务要素的数据一致；④回溯性：对于老系统中的历史信息，切换前后要有机制保证用户能够访问和使用；⑤连续性：新系统切换后，跨越该时点的业务数据被迁移，业务服务能够延续完成，并生成与切换前一致的结果；⑥实用性：考虑到系统切换中，新老两个系统是异构的，要充分论证迁移数据的必要性，避免过多的无用数据，以免造成切换窗口延长及在新系统内部产生“过敏”数据；⑦可测性：在系统切换前后，需要构建一种机制快速确认数据迁移的成功，对无法测试的数据进行迁移会增加风险。
　　2.3 迁移场景
　　在迁移范围确定后，要分析和确认老系统业务数据在新系统中的表述形式，在迁移策略文档明确描述新老系统各数据字段映射和关联关系。图2列举了6种典型的数据迁移场景。
　　图2 数据迁移6个典型场景
　　（1）单表转换。是数据迁移中最简单和理想的方式，一般存在于功能变化不大的业务模块中。由于新老系统数据表示方法不一致，需要添加必要的映射和逻辑转换。
　　（2）单表合并。指原有系统一张表中的多条记录在新系统中合并到一条记录。
　　（3）单表拆分。这种类型的迁移与单表合并场景产生的背景类似，可以参考多表合并场景。
　（4）一对多拆分。这种类型是指原有系统中一张表中的一条记录被拆分到新系统中的多张数据库表中，这是比较复杂的场景，一般由新老系统不同模块间重新划分变化引起，容易导致数据一致性问题，需要考虑两条记录的关联约束关系。
　　（5）多对一合并。这种类型的迁移可以参考一对多拆分场景。
　　（6）完全重构。在该场景下，新系统的业务要素在老系统中不存在，需要根据新系统的业务逻辑重新生成，定义新系统数据的生成规则，其构建的难度和工作量最大。如果新系统中对于数据库设计的约束不强，很容易产生一致性错误。
　　以上场景以外，还存在一些老系统中的业务数据没有迁移到新系统中，需要通过技术和业务分析，明确原因，以保证核心业务要素100%覆盖。
　　2.4 技术实现
　　在数据迁移需求明确之后，技术人员要设计合适的技术手段完成数据迁移。
　　2.4.1 技术方案
　　首先需要分析新老系统的存储形式，对于不同的数据存储形式选择不同的技术方案，一般分为以下3种：
　　（1）同一系列的关系数据库。这种情况 是数据迁移中最理想的状态。一般厂商对于同系列数据库产品会向下兼容，字段类型、操作语言和数据格式等方面具有一致性，可以减少迁移过程中的转换，降低异常数据出现的几率。
　　（2）不同的关系数据库产品。近年来，关系数据库成为信息系统的首选，Oracle、DB2、MySQL等产品成为主流，这些产品虽然都采用了结构化查询语言（SQL）标准，但是在具体的字段类型、操作语言和数据格式方面还存在一定的差异。在具体转换时，如果需要使用数据库SQL脚本进行迁移，则要对不同品牌的数据库进行转换，或者使用基于程序的数据迁移，例如使用Java程序调用不同产品的JDBC驱动进行迁移。
　　（3）不同类型的数据库。在Oracle等关系数据库成为主流之前，早期大型程序有些采用大型机IBM IMS数据库，有些则采用基于文件系统存储数据。对于这些迁移，需要借助厂家的专业工具。
　　2.4.2 迁移步奏
　　在数据迁移的技术实践中，可以使用数据提取、转换和加载（ETL）工具，或者单独编写SQL批处理脚本。在数据迁移“完全重构场景”下，需要根据实际需要编写存储过程，生成新系统中的业务要素，步骤如下：
　　（1）数据清洗。该步骤的目的是为了去除老系统中存在质量问题的异常数据，保证迁移成功。异常数据大致分为3类：①不完整和错误的数据：该类数据常常由于老系统程序不够健全原因导致，或者前期异常修复中由于后台修改数据引入所致，例如数据类型编码格式、不可识别字符、日期格式、数据越界、部分关联数据缺失等等，这就需要明确老系统各业务数据的定义和关联，可以考虑在老系统中直接处理或者调整；②表述不一致的数据：有些在老系统中属于查看型的业务数据，在新系统中成为了业务数据处理的一部分，不一致的表述方式会导致出错，例如，一些查看项有时用“是”和“否”，有时用“T”和“F”，这样在重构新系统数据时导致程序出错，这就需要明确新系统数据处理的过程和要求，有针对性地处理；③重复的数据：在老系统中由于没有数据库主键约束等原因，某些特殊业务流程会导致重复数据存在，老系统使用了更新时间等逻辑判断选择使用，不影响功能，新系统由于数据模型与代码设计的不同，这类数据往往会引起系统错误。可以考虑通过新系统数据库主键约束等方式进行识别后过滤，或者在条件允许的情况下，在老系统中按照业务规则直接将该类数据删除。
　　（2）数据转换。就是从老系统中提取原始数据，按照需求分析确定的字段映射关系进行转换。数据迁移的需求理解是个不断递进的过程，在迭代后期的运维测试中，随着对业务规则理解的不断深入，映射关系常常需要调整，这就要求迁移脚本要灵活调整新老数据的映射关系，可以通过构建数据库中间表存储映射关系进行转换，尽量避免硬编码。
　　（3）数据生成。就是迁移的数据按照新系统数据和业务模型要求，生成新系统必须的业务要素数据。
　　（4）数据导入。是完成数据迁移的最后一步，目的是把转换完成的数据插入新系统的数据库。在这一环节中要特别注意两点：①性能调优：数据迁移的时间窗口一般都有严格的控制，新系统数据库的设计又没有专门设置数据迁移，许多索引、主键可能会在大批量数据导入时性能受到影响。这就要求迁移技术人员有针对性地进行性能调优，必要时还要模拟一定的数据量进行数据迁移压力测试；②顺序执行：正常情况下，新系统的业务数据按照业务流程有一定的生成顺序和约束关系，在数据迁移的时候需要尽量遵守新系统的业务逻辑，设定顺序。在完全生成的场景下，如果导入和生成的顺序不对，会导致迁移数据错误。
　　2.5 迁移验证
　　数据迁移对象是动态变化的数据，在业务流程中各种情况都可能出现，在允许范围内对需求分析和迁移脚本进行充分测试和验证是非常必要的。实际工作中，验证测试的工作量甚至超过了需求分析和迁移脚本编写之和，具体的验证方法如下：
　　（1）新老系统数据库核对。这是最基本和快速的方法，通过比对老系统与迁移后新系统的数据条数和业务要素，快速确认迁移中数据清洗、提取、转换、导入等各步骤的执行是否正确。由于数据量非常大，一般采用编写核对脚本进行验证，在迁移后快速执行。这项工作有两个要点：①核对脚本要从需求分析出发，编写人员与迁移脚本的开发团队相分离，避免思维定势；②从性能和有效性角度考虑，可以从多个方面校验数据的正确性，例如对于迁移后的资金明细数据，除了逐条比对，还可考虑比对新老系统的合计数，并且将明细数据与交易流水进行匹配等。
　　（2）新老系统界面核对。这一方法需要大量的测试人力投入。各种数据的展示和处置最终还是在应用代码层面，通过比对和操作新老系统实现相同功能的界面，可以有效验证数据转换的正确性。测试人员对于业务系统的熟悉程度直接影响测试效果。
　（3）并行运行测试。数据迁移的最大特点是不可预见性。由于数据字段状态和关联组合数量很大，需求分析难免会出现遗漏和差错，此时基于迁移需求书的验证方法很难发现分析与实际数据之间的差异，因此应采用并行运行的测试方法。所谓并行运行是使用真实的生产数据，模拟数据迁移切换后的业务系统运行情况，通过连续比对业务结果从而检验迁移的正确性。由于大型信息系统业务流程中通常涉及到许多人工操作，纯粹通过重复操作成本极高，一般采用技术手段模拟。实现方式：①实时并行，即通过开发旁路程序，将进入老生产系统的业务数据和手工操作经过快速转换，实时输入到新系统中。该方法的优点是实时性高，在业务逻辑一致的情况下，可以在新系统稳定运行。数据核对正确的情况下，直接完成新老系统切换，数据迁移风险最小；缺点是会对原有系统的生产环境性能产生压力，如果新老系统存在业务规则改变时，较难实现数据完全一致；②递延并行，即从备份的生产数据中转换必要的操作日志和业务数据，通过接口延迟输入到新系统中。该方法的优点是对生产系统无影响，且可以挑选不同业务时期的备份进行验证，增加迁移测试案例的覆盖率，具有经济、安全、有效的特点。
　　无论采用何种方法都需要开发数据的转换程序和新老系统数据的核对程序。其核心是对新老系统同一时期产生的业务数据连续比对差异，进行分析。此工作 虽然工作量巨大，但却至关重要，效果明显。完备的并行测试不仅能对数据迁移的结果进行验证，而且对新系统功能测试也是重要的补充。
　　2.5 迭代优化
　　受限于新老信息系统的复杂性和业务功能的多样性，通过单次需求分析很难准确把握所有的需求，业务人员对迁移数据的范围和状态映射关系也是在不断的试用中逐渐认识，这就要求数据迁移工作采用迭代演进的开发模式，在需求分析阶段和开发完成以后尽快进入并帐运行测试，认真比对切换前后系统运行的差异，站在支持业务正常开展的角度逐渐完善迁移方案。
　　3 结语
　　银行间市场清算所股份有限公司是经财政部、中国人民银行批准成立的专业机构，为全国银行间市场外汇、债券和衍生产品提供清算、结算、托管等业务服务。新一代核心系统的上线需要从老系统迁移大量数据和单据， 涉及新老系统3 000余张数据库表、数万个字段；新系统基于J2EE，采用面向服务的架构（SOA）和Oracle RAC，配置全新技术架构和业务模型。新老系统数据模型完全不同，属于典型的异构信息系统数据迁移。为了保证迁移的准确有效，技术小组针对差异，在需求分析阶段整理了近百个业务流程的迁移策略，进行数据字段映射和生成规则确定；在技术实现阶段编写5万余行数据转换脚本，并优化了数据库的性能配置以缩短迁移时间；在迁移验证阶段开发了大量的自动化核对脚本，编制了新老系统界面核对手册，并开发了支持递延并行运行测试的模拟程序，对迁移的正确性进行了多重验证。通过4次迭代，优化迁移方案不断验证和优化，最终达到系统平滑切换要求。本文提出的迁移方法流程框架，以及需求分析要点、技术实现手段、迁移验证方法对于其它同类信息系统的迁移具有重要的借鉴意义。
　　参考文献参考文献：
　　[1] 李喆.企业级信息系统数据迁移方法[J].计算机系统应用，2011（1）：182184.
　　[2] 李永良.数据迁移：在新旧系统中切换[J].中国计算机用户，2003（Z2）：2730.
　　[3] 刘海英.管理信息系统升级过程中数据迁移的研究及实现[J].电力自动化设备，2005（5）：3739.
　　[4] 林海.社保数据集成系统ETL研究与开发[J].电脑知识与技术，2012（3）：506507.
　　[5] 郑仕勇.基于XML和中间件的数据迁移模型研究与设计[J].软件导刊，2012（4）：177179.
　　[6] 李秋珍.异构数据库数据迁移工具的设计与实现[J].舰船电子工程，2007（5）：135137.