大数据迁移实践之路_高峰
随着业务的迅速发展，农业银行某系统承担的运行压力越来越大。现阶段，该系统每天的交易量在2300万笔以上，峰值达2950万笔。交易量的攀升导致了后台数据库数据量的激增，从而影响了联机程序响应时间，也增加了系统各类资源开销和后续数据分析的处理时间。为保障系统稳定运行，项目组从增加系统资源、优化资源配置、优化重点程序和升级系统数据库等多个维度对系统进行了综合优化。下面笔者从大表、热表的数据分析和优化角度，阐述对大数据量表进行的存储优化。
大数据迁移实践之路
中国农业银行股份有限公司软件开发中心 高峰 刘杰 闫友祥
一、大表数据分析
目前农业银行某系统工作流数据量最大且访问最频繁的两张核心表：
（1）流程实例表，用于存储系统发起的所有流程实例，包括基本流程、会签流程、补充资料流程和抄送流程；
（2）任务实例表，用于存储每个流程实例的流转记录。
截至2013年4月1日，工作流两张大表的数据量如表1所示。其中任务实例表为系统中数据量最大的一张表，达到了1.2亿。根据ProDBA 抓取的执行次数最多且执行时间最长的前30条SQL 信息中，显示流程实例表和任务实例表压力
表1 目前系统大表数据量
比较大。
大表中的数据按照结束时间和状态两个维度可以区分为三类：（1）正在运行的流程数据，即业务正在办理过程中，尚未结束；
（2）已结束流程一年内的数据，即业务总体流程已经结束，期限在一年内（包含一年）；
（3）已经结束流程一年以上的数据，即业务总体流程已经结束，期限在一年以上（如表2所示）。
事实上，由于存在业务制度等方面的规定，已经结束一年以上的数据基本处于静态无变化的情况，不会发生修改、删除等数据操作，但是占据了一定的表空间，同时也影响了对其他运行中数据的访问效率。为降低大数据量对系统访问的影响，需制定迁移规则，进行数据拆分。
二、拆分规则
根据上述大数据表的数据分布特点，建立三套表结构：运行表、历史表和备份表。运行表仅存储正在运行的流程数据，流程结束后（正常完成或者终止）将基本流程以及其所属子流程相关的所有数据（流程实例、任务实例、流程变量、异常、分支等）实时迁移至历史表。如业务需要将已结束的流程恢复，系统支持流程从历史表实时迁回到运行表继续流转，整个过程对用户是完
全透明的。
由于已完成和终止一年以上的
流程，需恢复的业务需求很少（系
统上线以来未发生过类似业务），因
此由备份表存放第三类数据，形成
三级存储模式如图1所示。历史表
中的数据，每年执行一次批量拆分
操作，拆分至备份表。
为保障数据平稳的迁移，应采
取分布实施的策略。2012年12月8
日，流程结束数据实时迁移到历史
表功能先期投产，因此目前工作流
运行表中存放的数据包含三种情况：
正在运行的数据；2012年5月至
2012年12月结束的流程；2012年
5月前结束一年以上的流程（如图2
所示）。
按照数据三级存储规则，需要
对大数据表进行拆分、剥离及整合，
表2 数据分类
图1 数据三级存储模式
最终实现运行表只存储运行的数据，降低系统压力（如图3所示）。
三、问题分析及拆分策略
1.数据表重命名
数据迁移前需要对流程实例表和任务表进行BCP数据备份，以确保出现异常情况时，可及时恢复数据。任务实例表（1.2亿）和流程实例表（2千万），备份估计需要2~3个小时。数据迁移最终要达到运行
表中仅存放流程正在运行中的数据，
因此采取如下策略，节省BCP备份
时间。
首先，创建任务实例和流程实
例中间表，表结构和运行表保持完
全一致；其次，将运行表中正在运
行的数据迁移至中间表；再次，对
流程运行表和中间表重命名，实现
中间表转换为运行表，运行表转换
为备份表。
如出现数据迁移异常和验证不
通过等情况，由于备份表保存了迁
移当日的全量数据，因此，再次执
行数据表重命名即可解决问题，无
需再对两张大表进行BCP备份。数
据表重命名脚本执行时间，经测试
在1分钟内即可完成，大大减少迁
移时间。
2.数据完整性
一笔完整的流程，包含一条流
程实例和多条任务实例，任务实例
根据流程实例编号和状态等属性，
确定所属流程。迁移方法一：为保
障迁移数据完整，需要根据流程的
状态，查询流程和关联任务的记录，
一次性迁移两张表的记录，如迁移
失败同时回滚，因此，需要进行任
务实例表和流程实例表关联。考虑
到两张表的数据量，此方案将会导
致迁移效率很低。经测试，迁移5
万笔流程（5万条流程和36万条任
务记录)数据约７分钟，循环执行
迁移，迁移完全部流程数据需要约
42个小时。
为提高拆分效率，减少对投产
时间窗口的占用，对拆分方法进行
了优化。迁移方法二：首先，流程
实例表按照ID号升序排列，取前
50万条记录存放至临时表；其次，
将临时表（50万）和任务表（1.2亿）
进行关联，迁移流程所属的所有任
务；再次，再迁移50万条流程记
图 3大数据表拆分目标
2 数据分布
录；最后，删除临时表。循环执行操作，每次迁移，以前一次迁移的最大ID号为条件，再取50万条记录。此方法同样可以保障事务一致性，每次迁移两张表的数据，但是少了表关联的数据量。经测试，迁移50万笔流程（包括流程和任务记录）数据约8分钟，迁移正在运行的数据预计可在1个小时内完成。两种迁移方法对比示意如图4所示。
3.自增字段
任务实例表和流程实例表的主键ID，同为Identity型字段。数据迁移过程中，要保持ID号一致。首先，建表DBO用户和数据迁移操作用户需保持一致；其次，数据迁移脚本中，使用SET IDENTITY_ INSERT 表名 ON命令强制关闭对表的自增字段设置；再次，迁移
完成后，再使用SET IDENTITY_
INSERT 表名 OFF命令再打开自增
字段设置。
4.划分数据拆分批次
对拆分策略和脚本进行测试和
优化后，完成全部迁移仍然需5个
小时左右，因此考虑分批次执行。
在数据拆分规则中，数据被区分为
三类，根据此规则迁移分为两个批
次：一是执行迁移正在运行的数据；
二是执行迁移已经完成流程一年内
的数据。尽可能减小两批次执行的
时间间隔。第一批次执行完成后，
流程运行中的数据不受影响，一年
内已结束的流程如需恢复，将受到
影响。考虑到业务的实际办理情况，
流程结束后再次被恢复的情况很
少，因此分两个批次执行的影响面
积较小。
四、数据迁移方案实践
以迁移正在运行的数据为例，
阐述数据迁移过程。迁移流程结束
一年内的数据到历史表的操作过程
同此，不再赘述。
1.操作步骤
第一，执行脚本查询流程实例
表和任务实例表，获取数据以备验
证。同时查询最大流程和任务I D
号，以备在步骤六中设置自增起
始值。
第二，创建中间表，表结构和
运行表保持一致。
第三，迁移未完成流程数据，
每次迁移50万个流程，检查日志内
容，直到执行影响结果不足50万个，
证明数据迁移完成。
4 两种迁移方法对比示意
第四，执行数据验证脚本，比较此脚本的执行结果和步骤1中的执行结果是否一致。如不一致，后续步骤不再执行。
第五，执行脚本对流程运行表和中间表重命名，执行完成后验证表结构是否一致。
第六，根据步骤一的查询结果，设置运行表自增字段的起始值。
第七，开启工作流WAS，由开发人员进行验证。如验证通过，关闭工作流WAS；如验证不通过，执行应急方案。执行完成后再次进行验证。
第八，进行运行表的索引统计值更新（如图5所示）。
2.应急方案
（1）异常情况一：执行迁移脚本出现时间超长等异常情况，在计划时间窗口内不能正常执行完成。应急方案：迁移脚本未对运行表进行更新和删除等操作，数据未受影响，因此后续操作步骤不再执行，删除中间表即可。
（2）异常情况二：数据拆分完成，开启工作流WAS验证，开发人员验证不通过。应急方案：执行脚本将运行表更名为中间表，备份表更名为运行表，执行完成后，再次由开发人员进行验证，验证通过删除中间表。
3.数据量比较
经过两轮迁移，数据量对比如
表3所示，从中可以看出访问最频
繁的运行表数据量减少95%。
4.结论
数据经过拆分、剥离及整合后
图 5 数据迁移操作步骤
形成了三级存储模式。流程结束后
数据实时转移到历史表，而运行表
数据增量变化不大，因此有效解决
了由于数据量巨大带来的数据访
问响应时间长等问题，提升了系统
性能。
则根据索引定位流程数据，缩小数据查询范围，最终降低系统响应时间。备份表中数据也可转移至其他存储设备进行保存。对备份表中数据查询需求，提供单独的查询、统计及分析服务。FCC
五、未来规划
数据迁移完成后，根据数据增长特点，每年对历史表数据进行一次批量迁移，迁移至备份表存储，而运行表数据不受影响，即消除
表 3迁移前后数据量对比
了对运行中流程的影响。由此带来备份表数据也将不断增大。备份表的存储采用索引存储方式，增加备份数据索引表（如图6所示）。为做到对业务操作的完全透明，如需对备份表的数据恢复，
图 6 三级数据存储结构未来规划