如何在敏捷开发中做好数据迁移

数据迁移是指在系统软件开发中，将具有实际业务价值的数据，依据功能需求或系统开发的要求，在不同存储媒介、存储形式或计算机系统之间转移的过程。

数据迁移是系统开发经常涉及到的一项工作。在企业级应用系统中，新系统的开发，新旧系统的升级换代，以及正常的系统维护，不可避免地涉及到大量的迁移工 作。而在一个以数据为核心的业务系统中，数据的迁移更是无处不在。比如：在以数据仓库为架构原型的系统设计中，ETL（抽取，转换，装载）部分的实现就是 一种数据迁移；对大型数据系统的分布式实施，数据迁移就是整个实施过程的主要部分。而在敏捷实践中，渐进式的数据库开发，更是涉及到大量的数据迁移和同步 工作。

我们时常会听到用户提出这样的要求“我们并不过于关心应用的好坏，但需务必保证数据准确”。的确，在以数据为运营基础的行业里，数据质量本身就是软件质量 的权重部分，尤其在电信、金融和控制领域里，这一特征表现的格外明显。数据迁移也是敏捷开发中相当重要的环节，它影响着各个发布版本的数据质量，而数据质 量又决定着系统的有效性和可靠性，因此高质量地完成数据迁移不容忽视。

数据迁移往往被视为一件很简单的工作。在很多人眼里，数据迁移仅仅是用 sql 语句向相应数据表装载数据的过程。但在实际操作中，数据迁移涉及到很多层面的 因素，如用户需求，系统功能，数据库建模等，若出现问题，将导致开发进展缓慢或质量不高。常见问题有业务系统逻辑模糊、脏数据、遗留系统的技术债和管理债 等。那么如何有效的避免这些问题，提高迁移质量呢？

本文将以 ThoughtWorks 中国公司与客户合作的 CRM 项目为背景，为读者介绍如何在敏捷开发中高质量地处理数据迁移工作，从而在数据层面提高系统质量。

开发背景

A 系统（旧系统）是客户原有的一套 CRM（客户关系管理）系统。系统采用 B/S 架构，使用 sql server 2005 做为后台数据库。旧系统的数据建模设计采用了高度范式化的设计思路，其目的是极度追求灵活性。业务数据被大量拆分并散布存储在上百张数据表里。数 据表内和表之间不存在参照约束。大量的业务逻辑采用存储过程封装以提高效率。存储过程体系相当庞大，且存在复杂的相互调用。数据库中存在一些脏数据，可能 是长期的使用、维护或误操作导致，但没人知道它们有多少，具体存在哪里。应用界面可用性不理想而且系统效率较低，用户常抱怨系统反映迟缓或无反应。数据库 存储的业务数据约 50G 左右。

ThoughtWorks 团队将为客户提供一套新的 CRM 系统用以替换旧系统主要功能。新系统精简整理旧系统功能，并整合了客户的最新需求。在设计上做了巨大变更，以改善界面可用 性，同时为了保障终端用户对系统服务的需要，新旧系统要求能够同时运行并实现数据同步，当终端用户全部过度到新系统后，终止旧系统。在这个过程中，DBA 团队需给予足够的数据保障。

以下为项目版本的发布图。

数据迁移开发方法

1. DBA 需要制定目标并且管理自己的任务

尽管在每个迭代中，团队都会讨论决定如何组织‘需求故事’（story），但是 DBA 仍然需要有自己的‘故事墙’（story wall），并且花时间组织自己的 story。在实际开发中，数据迁移仅仅是 DBA 工作的一部分，DBA 还要完成相应的 story 开发和数据分析，有时还 要给开发人员提供数据支持。混乱的管理会带来开发上的冲突。因此，有效管理任务是做好数据迁移的首要环节。

故事墙是管理这些任务的最好方法。尽管这个故事墙对客户提供的商业价值是间接的，但从整个团队角度来看，任何需要数据的人或程序都是 DBA 的用户， 故事墙有利于管理每个 story 包含的数据需求，避免数据迁移任务与其它数据库开发任务之间的冲突，从而减少重复性工作或修复性工作。DBA 有必要将这种 方法引入到数据库开发中。

DBA 要从商业价值角度决策数据迁移的需求。系统开发中，客户和开发员常常会向 DBA 提出自己的数据迁移要求，但往往这些要求并不具有全局性和决定性，毕 竟他们仅仅是针对一个 story 的需要而提出。如果 DBA 盲目执行，将起到事倍功半的效果。DBA 应当积极参加 IPM（迭代计划会议。它是在每个迭代开始 时的会议，全体成员共同讨论 story 计划完成数量）。无论是直接与用户交互，还是参与团队合作，DBA 有必要将每个 story 内容了解的清清楚楚。通 常，DBA 可以不必像开发人员一样去了解 story 的开发细节，但通过与业务分析师和开发员的沟通，潜在的数据需求自然浮出水面。针对这些数据需求，通过 再次组织并加以优先级，我们很容易回答这些问题：接下来应该完成的任务是什么？它的实际商业价值是什么？谁将需要它？什么时候需要？实践证明，多花些时间 和团队或客户沟通是事半功倍的好方法，而且 DBA 通过了解业务数据可以给开发员更好的指导，减少开发员对数据的误解，有利于提高整体团队的开发效率。

通过对每个 story 的了解，我们总结并制定了针对当前发布版本需要的 7 个数据迁移 story，并且确认了它们的确不存在任务上的重复，也邀请项目经理和客户一起确认了这份计划。如此我们的目标已经制定。

2. 思考实施策略

我们已经管理好所有数据迁移的任务，接下来考虑如何实现。通过以往的经验，我们发现如果没有仔细思考全局和细节问题而直接编写代码，带来的后果是无 法控制的。我们应该首先充分了解这个过程可能存在的风险，然后决定采用什么样的策略，是否可以借助工具提高效率。这里的潜在风险主要包括：

2.1 数据质量

旧系统的数据库建模是一个高度范式化的结构，每个表之间存在相当大的依赖关系。一旦一个表存在脏数据，我们如何保证得到正确的查询结果？

2.2 对原有系统的了解

旧系统的应用程序引入了面向对象的设计方法，并且继承关系数据也被存储在若干张数据表里，如何正确区分这些业务对象和关系，保证在迁移过程中不会制造脏数据？

2.3 业务数据映射

旧系统和新系统之间存在着相当大的业务逻辑差异，我们是否能够将业务逻辑、数据映射到新系统？是否存在不可实现的转换？

在未充分了解这些问题之前，我们无法进一步制定计划，即时给予客户反馈是解决这些问题的最好方法。经过进一步沟通后，我们发现问题的复杂程度远远超过想象，尽管客户对旧系统非常了解，但他们对于某些数据也不能给出明确答案。鉴于这些情况，我们制定了初步的解决策略：

1. 更多的了解旧系统，即时给予反馈。对于那些无法找到答案的问题，考虑是否可以寻求其它资源或忽略没有价值的数据。
2. 尽量细化分割每一个复杂需求，形成多个任务。小粒度任务能够帮助暴露更多问题。
3. 采用测试驱动，确保一套可靠的测试机制。
4. 制定实现框架和阶段性目标。
5. 不要过于乐观的估计进展，每一阶段要留有充分的单元测试。
6. 调整每个迭代的内容，对有较强依赖关系的任务可以放在今后的迭代周期里。

3. 实施数据迁移

新系统的数据迁移包含两个部分：一次性数据迁移和数据同步迁移

一次性数据迁移

一次性数据迁移指仅仅发生在某一个发布版本上线安装时，新旧系统同时处于脱机状态，一部分数据将从旧系统中转移到新系统的过程。

数据同步迁移

数据同步迁移过程发生在新系统运行时，新旧系统同时处于工作状态，双方通过交换数据保证彼此数据的一致性。

同为数据迁移，但因两类迁移各具特点，因此在共同的处理方式上也略有不同。

一次性数据迁移

数据同步迁移

特点

1. 数据量大。

2. 使用频率低（一次性使用）。

3. 转换逻辑复杂，需大量定制映射转换数据。

4. 数据量小

5. 使用频率高（以分钟为单位，周期性运行）。

6. 转换逻辑复杂，少量定制映射转换数据。

7. 需要事务处理以保证数据一致性

共同处理方式

1. 细化任务。
2. 测试驱动。
3. 持续集成

不同处理方式

1. 在执行测试驱动中，应侧重数据质量的测试。应依据不同环境的测试结果，增强测试体系。

2. 工具选择。避免使用第三方工具，直接使用 sql 脚本以提高迁移效率。

3. 保留中间处理结果

4. 在执行测试驱动中，应侧重逻辑映射方面的测试。

5. 工具选择。可考虑使用第三方工具，增强事务控制。

6. 可不保留中间结果

7. 细化任务

依据最初制定的开发策略，当我们遇到复杂的迁移需求时，首先分解每个需求为若干个模块，然后画出整体结构图。以下是某一处数据迁移脚本的模块分割：

最初由于这个部分的迁移逻辑过于复杂，以至于客户对它的处理结果没有信心。但当共同完成这个图表后，大家一致认为它没有像想象中的困难。总而言之，立刻解决一个复杂的问题很困难，但解决其中一个小问题却很容易。

2. 测试驱动

如同编写程序代码一样，我们不仅为实现数据迁移脚本使用了测试驱动，还引入了针对数据库设 计的一些方法。在程序设计中，当代码本身结构良好，单元（类、方法）之间关系清晰，可以直接添加单元测试。现在，我们有了很好的脚本逻辑结构，可以很容易 添加每一步结果的单元测试，这就如同形成了一道安全网，保证异常数据出现时，能够立即发现并加以处理。在实际编写迁移脚本之前，应首先明确测试内容，准备 好测试脚本。

测试内容包括：

• 应产生的符合期望的数据

基于给予的原始测试数据，这一测试过程测试脚本的数据转换逻辑是否正确。以下举例说明：

测试环境：旧系统中存在某个名为’Jason’的客户信息，他的 personId 是 1000101 。

测试目的：当某一客户的信息迁移到新系统的 CUSTOMERS 表后，新系统应该存在该客户信息。

新系统上要运行的测试代码：

<p>DECLARE @personName NVARCHAR(250),</p><p>SELECT</p><p>@personName = personName</p><p>FROM</p><p>CUSTOMERS</p><p>WHERE</p><p>personId = 1000101</p>
<p>IF (@personName <> 'Jason') or (@personName is NULL)</p><p>BEGIN</p><p>INSERT INTO LoadTestErrorLog (errorDescription)</p><p>VALUES ('personName for personId 1000101 is not Jason')</p><p>END</p><p>Go</p>

这里常用的原则是：一段 sql 语句仅用来测试一处期望数据，这样可以减少代码之间的相互依赖性，更准确的定位错误数据。

• 不应当产生的异常数据

异常数据指在迁移过程中出现的不符合逻辑的数据。理论上讲，迁移过程不应当出现异常数据，然而现实情况中，迁移结果总会出现我们不需要的数据。其原因包括 数据源出现异常、实现过程中的误操作、系统应用的 bug 等。总而言之，为了保证这些错误不会出现在最终结果，相应的测试脚本必不可少，也是防止问题进一步 扩大的有效举措。这一测试过程常被用来发现在生产环境中可能出现的问题。以下举例如何测试异常数据：

测试环境：全部或部分生产环境数据

测试目的：将某个客户的信息迁移到新系统的 CUSTOMERS 表后，数据表不应该具有顾客名字为空的记录，如果出现将视为迁移过程的错误。

新系统上要运行的测试代码：

<p>DECLARE @isExistPersonNameWithNULL INTEGER</p><p>SELECT</p><p>@isExistPersonNameWithNULL = count(*)</p><p>FROM</p><p>CUSTOMERS</p><p>where personName is null</p><p>IF (@isExistPersonNameWithNULL> 0)</p><p>BEGIN</p><p>INSERT INTO LoadTestErrorLog (errorDescription)</p><p>VALUES ('personName doesn't contain legal information')</p><p>END</p><p>Go</p>- 数据表的数据量是否符合期望

当数据被迁移至新系统后，应当确保迁移数据量符合应期望值。实现方法多种多样，较简单的方法是直接比较数据迁移前后的数据记录数是否在数值上相等。以下举例说明：

测试环境：全部或部分生产环境数据。

测试目的：客户数据被迁移后，应当确保客户数据没有丢失。

新系统上要运行的测试代码：

<p>DECLARE @NumberofCustomerinOldDB INTEGER</p><p>DECLARE @NumberofCustomerinNewDB INTEGER</p><p>SELECT</p><p>@NumberofCustomerinOldDB = count(*)</p><p>FROM</p><p>oldDB.dbo.persons -- 这是在旧系统中定义的客户表 </p><p>...</p>–省略复杂的过滤逻辑

<p>SELECT</p><p>@NumberofCustomerinNewDB = count(*)</p><p>FROM</p><p>newdb.dbo.CUSTOMERS -- 这是在新系统中定义的客户表 </p><p>where personName is null </p>
<p>IF (@NumberofCustomerinOldDB<>@NumberofCustomerinNewDB )</p><p>BEGIN</p><p>INSERT INTO LoadTestErrorLog (errorDescription)</p><p>VALUES ('not all customers are migrated ')</p><p>END</p><p>Go</p>

最终当把测试 sql 代码片段组装在一起后，我们获得了一批测试脚本，并按照以下流程，通过使用 NANT 工具实现自动化：

NANT 中的实现方法：

<target name="-init " … />

该任务负责初始化测试环境

<target name="-parseDbScripts " … />

该任务负责编译并部署迁移脚本

<target name="-resetTestData " … />

该任务负责重置测试数据

<target name="-executeMigrationScripts " … />

该任务负责执行迁移脚本

<target name="-testMigration " … />

该任务负责执行迁移测试脚本

<p>objectId, parentObjectId,objectType …</p><p>------------------------------------</p><p>Null Null ‘root’</p><p>1 Null ‘contactManager’</p><p>2 1 ‘contact’</p><p>3 1 ‘contact’</p><p>4 Null ‘orgnisation1’</p><p>…</p>

<p>ID， startTimestamp, EndTimestamp, createDate …</p><p>-----------------------------------------------------</p><p>11020011 2008-12-14 09:23:00 2008-12-14 01:23:00 2008-12-14 09:23:00</p>