新旧系统更替产生的数据迁移问题

标签: 系统 数据 问题 | 发表时间:2014-12-29 15:44 | 作者:wangtf6
出处:http://www.iteye.com

新旧系统更替产生的数据迁移问题

作者:西安项目组夏凯撰文时间:2004.11.08

在信息化建设过程中,随着技术的发展,原有的信息系统不断被功能更强大的新系统所取代。从两层结构到三层结构,从Client/Server到Browser/Server。在新旧系统的切换过程中,必然要面临一个数据迁移的问题。

数据迁移的概念

原有的旧系统从启用到被新系统取代,在其使用期间必然会积累大量珍贵的历史数据,其中许多历史数据都是新系统顺利启用所必须的。另外,这些历史数据也是进行决策分析的重要依据。数据迁移,就是将这些历史数据进行清洗、转换,并装载到新系统中的过程。数据迁移主要适用于一套旧系统切换到另一套新系统,或多套旧系统切换到同一套新系统时,需要将旧系统中的历史数据转换到新系统中的情况。税务、电信、工商、银行、保险以及销售等领域发生系统切换时,一般都需要进行数据迁移。对于多对一的情况,例如由于信息化建设的先后,造成有多个不同的系统同时运行,但相互间不能做到有效信息共享,所以就需要一套新系统包容几套旧系统的问题。

数据迁移对系统切换乃至新系统的运行有着十分重要的意义。数据迁移的质量不光是新系统成功上线的重要前提,同时也是新系统今后稳定运行的有力保障。如果数据迁移失败,新系统将不能正常启用;如果数据迁移的质量较差,没能屏蔽全部的垃圾数据,对新系统将会造成很大的隐患,新系统一旦访问这些垃圾数据,可能会由这些垃圾数据产生新的错误数据,严重时还会导致系统异常。

相反,成功的数据迁移可以有效地保障新系统的顺利运行,能够继承珍贵的历史数据。因为无论对于一个公司还是一个部门,历史数据无疑都是十分珍贵的一种资源。例如税务部门的纳税资料、公司的客户信息、银行的存款记录等。

数据迁移的特点

系统切换时的数据迁移不同于从生产系统OLTP (On-line Transaction Processing),到数据仓库DW(Data Warehouse)的数据抽取。后者主要将生产系统在上次抽取后所发生的数据变化同步到数据仓库,这种同步在每个抽取周期都进行,一般以天为单位。而数据迁移是将需要的历史数据一次或几次转换到新的生产系统,其最主要的特点是需要在短时间内完成大批量数据的抽取、清洗和装载。

数据迁移的内容是整个数据迁移的基础,需要从信息系统规划的角度统一考虑。划分内容时,可以从横向的时间和纵向的模块两个角度去考虑。

横向划分

以产生数据的时间为划分依据,需要考虑比较久远的历史数据如何迁移的问题。由于信息技术的发展,以及我们对计算机依赖性的增强,新系统每天往往需要比旧系统存储更多的信息,同时为了解决数据量高增长带来的性能瓶颈,新系统一般只保留一定时期的数据,比如1年,而把超过保存周期的数据,即1年以前的数据转移到数据仓库中,以便用于决策分析(需建立决策支持系统)DSS系统。对于这种新系统的数据迁移,主要迁移1年以内的数据,1年以前的历史数据需要另外考虑。

纵向划分

以处理数据的功能模块为划分依据,需要考虑在新系统中没有被包含的功能模块,其所涉及数据的处理问题。这类数据由于无法建立映射关系,一般不需要迁移到新系统中。但对于模块间偶合度比较紧密的旧系统,在纵向划分时需要注意数据的完整性。对于这次的数据迁移,旧系统的各个功能模块可以和新系统建立一定的映射关系,因此本次的迁移基本是针对模块做的工作。

数据迁移的方法

数据迁移可以采取不同的方法进行,归纳起来主要有四种方法,即系统切换前通过ETL工具迁移、编写后台数据库程序、系统切换前采用手工录入和系统切换后通过新系统生成。

系统切换前通过工具迁移

在系统切换前,利用ETL(Extract Transform Load)工具把旧系统中的历史数据抽取、转换,并装载到新系统中去。其中ETL工具可以购买成熟的产品(如Infomatic、Business Objects公司的Data Integrator Designer),也可以是自主开发的程序。这种方法是数据迁移最主要,也是最快捷的方法。其实施的前提是,历史数据可用并且能够映射到新系统中。

编写后台数据库程序

在系统切换前,将旧系统涉及到的迁移数据,在新系统中建立相应的数据库表结构,并将旧数据导入相应的表中,然后在新系统中编写后台程序,将历史数据迁移到新系统中。本次我们的迁移是建立一个和正式系统一模一样的数据迁移数据库,将旧系统的迁移数据imp到此迁移数据库中,所有的编码和调试也都在此环境中进行,这样就可以将导入到新系统的数据可能产生的问题,如:字典表数据的转化、外键约束等等,在迁移数据库中全部处理掉,这样得到的数据便可顺利的导入新系统。

系统切换前采用手工录入

在系统切换前,组织相关人员把需要的数据手工录入到新系统中。这种方法消耗的人力、物力比较大,同时出错率也比较高。主要是一些无法转换到新系统中的数据,和新系统启用时必需要而旧系统无法提供的数据采用这种方法,可作为第一种方法的有益补充。

系统切换后通过新系统生成

在系统切换后,通过新系统的相关功能,或为此专门开发的配套程序生成所需要的数据。通常根据已经迁移到新系统中的数据来生成所需的信息。其实施的前提是,这些数据能够通过其它数据产生。

数据迁移的策略

数据迁移的策略是指采用什么方式进行数据的迁移。结合不同的迁移方法,主要有一次迁移、分次迁移、先录后迁、先迁后补等几种方式可供选择。

一次迁移

一次迁移是通过数据迁移工具或迁移程序,将需要的历史数据一次性全部迁移到新系统中。一次迁移的优点是迁移实施的过程短,相对分次迁移,迁移时涉及的问题少,风险相对比较低。其缺点工作强度比较大,由于实施迁移的人员需要一直监控迁移的过程,如果迁移所需的时间比较长,工作人员会很疲劳。一次迁移的前提是新旧系统数据库差异不大,允许的宕机时间内可以完成所有数据量的迁移。

分次迁移

分次迁移是通过数据迁移工具或迁移程序,将需要的历史数据分几次迁移到新系统中。分次迁移可以将任务分开,有效地解决了数据量大和宕机时间短之间的矛盾。但是分次切换导致数据多次合并,增加了出错的概率,同时为了保持整体数据的一致性,分次迁移时需要对先切换的数据进行同步,增加了迁移的复杂度。分次迁移一般在系统切换前先迁移静态数据和变化不频繁的数据,例如代码、用户信息等,然后在系统切换时迁移动态数据,例如交易信息,对于静态数据迁移之后发生的数据变更,可以每天同步到新系统中,也可以在系统切换时通过增量的方式一次同步到新系统中。本次就采用了分次迁移的策略,即按分局分次迁移;对于某些信息也采用了定时更新的手段,以保证数据的正确性。

先录后迁

先录后迁是在系统切换前,先通过手工把一些数据录入到新系统中,系统切换时再迁移其它的历史数据。先录后迁主要针对新旧系统数据结构存在特定差异的情况,即对于新系统启用时必需的期初数据,无法从现有的历史数据中得到。对于这部分初期数据,就可以在系统切换前通过手工录入。比如这次的核定信息、征管鉴定信息、减免税审批结果、发票领购申请/审批等等,就是采用的先录后迁的方式。

先迁后补

先迁后补是指在系统切换前通过数据迁移工具或迁移程序,将原始数据迁移到新系统中,然后通过新系统的相关功能,或为此专门编写的配套程序,根据已经迁移到新系统中的原始数据,生成所需要的结果数据。先迁后补可以减少迁移的数据量。

数据迁移的技术准备

数据转换与迁移通常包括多项工作:旧系统数据字典整理、旧系统数据质量分析、新系统数据字典整理、新旧系统数据差异分析、建立新旧系统数据之间的映射关系、开发部署数据转换与迁移程序、制定数据转换与迁移过程中的应急方案、实施旧系统数据到新系统的转换与迁移工作、检查转换与迁移后数据的完整性与正确性。

数据转换与迁移程序,即ETL的过程大致可以分为抽取、转换、装载三个步骤。数据抽取、转换是根据新旧系统数据库的映射关系进行的,而数据差异分析是建立映射关系的前提,这其中还包括对代码数据的差异分析。转换步骤一般还要包含数据清洗的过程,数据清洗主要是针对源数据库中,对出现二义性、重复、不完整、违反业务或逻辑规则等问题的数据进行相应的清洗操作,在清洗之前需要进行数据质量分析,以找出存在问题的数据,否则数据清洗将无从谈起。数据装载是通过装载工具或自行编写的SQL程序将抽取、转换后的结果数据加载到目标数据库中。

数据迁移的实现

数据迁移的实现可以分为三个阶段:数据迁移前的准备、数据迁移的实施和数据迁移后的校验。

由于数据迁移的特点,大量的工作都需要在准备阶段完成,充分而周到的准备工作是完成数据迁移的主要基础。具体而言,要进行待迁移数据源的详细说明,包括数据的存放方式、数据量、数据的时间跨度,建立新旧系统数据库的数据字典,就是我们常说的参照表;对旧系统的历史数据进行质量分析,新旧系统数据结构的差异分析;新旧系统代码数据的差异分析;建立新老系统数据库表的映射关系,对无法映射字段的处理方法,开发、部属ETL工具,编写数据转换的测试计划和校验程序,制定数据转换的应急措施。我们对于部分由于时间太久而无法对应的数据字典数据,采用建特殊代码并对新系统禁用的方式,以保证迁移的完整性,此部分数据可在今后通过于客户协商采用更好的方式进行修正。

其中,数据迁移的实施是实现数据迁移的三个阶段中最重要的环节。它要求制定数据转换的详细实施步骤流程;准备数据迁移环境;业务上的准备,结束未处理完的业务事项,或将其告一段落;对数据迁移涉及的技术都得到测试;最后实施数据迁移。

数据迁移后的校验是对迁移工作的检查,数据校验的结果是判断新系统能否正式启用的重要依据。可以通过质量检查工具或编写检查程序进行数据校验,通过试运行新系统的功能模块,特别是查询、报表功能,检查数据的准确性。

对数据的检查

数据长度检查:检查数据的有效长度。对于char类型的字段转换到varchar类型中,需要特别关注。

区间范围检查:检查数据是否包含在定义的最大值和最小值的区间中;例如年龄为300,或录入日期在4000-1-1。

空值、默认值检查:检查新旧系统定义的空值、默认值是否相同,不同数据库系统对空值的定义可能不同,需要特别关注。

完整性检查:检查数据的关联完整性。如记录引用的代码值是否存在,特别需要注意的是有些系统在使用一段时间后,为了提高效率而去掉了外键约束。

一致性检查:检查逻辑上是否存在违反一致性的数据,特别是存在分别提交操作的系统。

数据迁移后的校验

在数据迁移完成后,需要对迁移后的数据进行校验。数据迁移后的校验是对迁移质量的检查,同时数据校验的结果也是判断新系统能否正式启用的重要依据。可以通过两种方式对迁移后的数据进行校验。

对迁移后的数据进行质量分析,可以通过数据质量检查工具,或编写有针对性的检查程序进行。对迁移后数据的校验有别于迁移前历史数据的质量分析,主要是检查指标的不同。迁移后数据校验的指标主要包括五方面:完整性检查,引用的外键是否存在;一致性检查,相同含义的数据在不同位置的值是否一致;总分平衡检查,例如欠税指标的总和与分部门、分户不同粒度的合计对比;记录条数检查,检查新旧数据库对应的记录条数是否一致;特殊样本数据的检查,检查同一样本在新旧数据库中是否一致。

新旧系统查询数据对比检查,通过新旧系统各自的查询工具,对相同指标的数据进行查询,并比较最终的查询结果;先将新系统的数据恢复到旧系统迁移前一天的状态,然后将最后一天发生在旧系统上的业务全部补录到新系统,检查有无异常,并和旧系统比较最终产生的结果。

此次迁移的数据检查采用了检查新旧系统的记录数据是否一致,按照行业、按纳税户、按级次、按转化条件等等得到的数据与在旧系统按同样的方式查询是否一致。



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [系统 数据 问题] 推荐:

关于分布式系统的数据一致性问题

- - 互联网 - ITeye博客
现在先抛出问题,假设有一个主数据中心在北京M,然后有成都A,上海B两个地方数据中心,现在的问题是,假设成都上海各自的数据中心有记录变更,需要先同步到主数据中心,主数据中心更新完成之后,在把最新的数据分发到上海,成都的地方数据中心A,地方数据中心更新数据,保持和主数据中心一致性(数据库结构完全一致).

新旧系统更替产生的数据迁移问题

- - 研发管理 - ITeye博客
新旧系统更替产生的数据迁移问题. 作者:西安项目组夏凯撰文时间:2004.11.08. 在信息化建设过程中,随着技术的发展,原有的信息系统不断被功能更强大的新系统所取代. 从两层结构到三层结构,从Client/Server到Browser/Server. 在新旧系统的切换过程中,必然要面临一个数据迁移的问题.

数据库系统load飙高问题解决思路

- - BlogJava-qileilove
数据库服务器器load 飙高的报警,比如:.   如何处理load 异常飙高的报警呢. 本文尝试从原理,原因,解决方法来阐述这类问题的解决思路.   CPU作为服务器的关键资源经常成为性能瓶颈的根源,CPU使用率高并不总是意味着CPU工作繁忙,它有可能是正在等待其他子系统. 在进行性能分析时,将所有子系统当做一个整体来看是非常重要的,因为在子系统中可能会出现瀑布效应.

Redis数据“丢失”问题

- - 今天
Redis大部分应用场景是纯缓存服务,请求后端有Primary Storage的组件,如MySQL,HBase;请求Redis的键未命中,会从primary Storage中获取数据返回,同时更新Redis缓存. 如果少量数据丢失,相当于请求”缓冲未命中“; 一般对业务的影响是无感知的. 但现在Redis用作存储的业务场景变多,数据丢失对业务是致命的影响.

思考系统API设计的问题

- edware_love - C++博客-首页原创精华区
最近正好在思考系统API设计中考量的一些问题,. 我现在的理解是这样的,假设有巨大的真实内存. windows首先将高2G的内存自己占了,用作各种内核对象. 这2G内存共享给每个进程,但进程不能直接访问,只能通过windows给定的函数访问. : 然后每个进程都给他2G内存,进程如果创建自己的对象就放到自己那2G内存里面,如果要建立内核对象就放到共享的那高2G里面去.

搜索系统中的纠错问题

- -
纠错是搜索引擎中一个非常有特色的模块,对用户输入的内容进行改写从而让用户得到正确的结果,有的时候也会带有一些惊喜度,所以纠错技术是一个搜索体验的加分项,近期突然对这块有兴趣,所以就了解了一下. (学习周报本周停,学习内容都在这了). 人非圣贤,孰能无过,别说是搜索的时候,哪怕是我们打字、写作文的时候,都会出现错字,一般的错别字不会对最终目标带来很大影响,且出现频率很低,不拘小节的我们常常会忽略这样的小问题,但是,在搜索场景下,错别字意味着可能就搜不到内容了,对于用户而言,就是需求无法满足,造成了很差的体验,因此在搜索场景中,就很有必要去纠错.

再谈JavaScript的数据类型问题

- 茄 - aimingoo的专栏
 JavaScript的数据类型问题已经讨论过很多次了,但许多人还有许多书仍然沿用着错误的、混乱的一些观点,所以就再细讲一回. 提及这个讨论的原因在于argb同学在我的MSN博客(现在变成了wordproess,在这里)上的一段回复,又更早的起源则是两年前关于《JavaScript征途》一书的大讨论:.

Oracle数据库10个小问题

- - 数据库 - ITeye博客
Oracle 数据库 10 个小问题. Oracle的安装是出名的复杂,特别是在非windows系统中,在网上可以找到遍地的Oracle安装文档,但依然有很多人花了大量时间才安装成功,如果要搭建rac系统,那就更复杂了. 我们也看到Oracle公司也一直在降低安装的复杂度,11g的安装已经比8i,9i方便了一些.

MySQL数据库如何解决大数据量存储问题

- - 数据库 - ITeye博客
利用MySQL数据库如何解决大数据量存储问题. 各位高手您们好,我最近接手公司里一个比较棘手的问题,关于如何利用MySQL存储大数据量的问题,主要是数据库中的两张历史数据表,一张模拟量历史数据和一张开关量历史数据表,这两张表字段设计的很简单(OrderNo,Value,DataTime). 基本上每张表每天可以增加几千万条数据,我想问如何存储数据才能不影响检索速度呢.

对于数据分析与数据挖掘的数据10个问题

- - 乐无限-微信公众号内容聚合站
1,作为支付宝数据首席分析师,你怎么看待“数据挖掘”这个词. 所谓的“数据挖掘”是基于用户的行为挖掘出有价值的东西,以及这个东西被用到商业环境上. 比如非常著名的“啤酒与尿布”的案例,它的背景是在1992年的美国,每周四或者每周五下午5点-7点的时间形成的连锁销售. 但是这个联合销售的方法并不适合任何时间和任何场合,单纯地剥离其背景本身,谈数据挖掘就是一个很泛的事情.