海量数据在线并发迁移模式创新与实践（五）-实施方案

4.1课题研究实现的主要目标

根据我行核心系统目前面临的问题和困难，以海量数据的在线迁移及自动化清理为主要目标，拟定本次核心改造课题主要目标：

1、对“大表”进行分区改造。本期将对如下表进行清理：

表 1、改造表清单

对上述六张表进行分区改造，在改造前，这六张表占用存储总量约40%的空间。

图 4、表储量占比展示

2、建立应用级的自动清理及整理机制，建立规范的数据自动归档机制。达到业务需求的查询要求。

3、改造期间，以不影响业务为前提，尽量缩短停机时间。

4.1.1功能目标

1、更改业务表属性为分区表

使业务数据表变成一种新数据组织方案，即表数据根据一个或多个表列中的值分布到多个存储对象（称为数据分区或范围）中。每个数据分区都是单独存储的。这些存储对象可以在不同的表空间中，也可以在相同表空间中。查询处理同样可以利用分离的数据来避免扫描不相关数据，从而使许多数据仓库样式查询具有更好地查询性能。表分区简化了表数据转入和转出以及管理工作，并且提高了索引位置的灵活性和查询处理效率。

2、使用detach分离待清理分区

对于这种超大数据量的表，常规的数据清理方法已经无法胜任。使用分区表后使用detach从分区表中分离一个分区。从一个分布式表中分离分区从而在相同的分区组创建分布式表。执行 DETACH 操作后产生的表使用 MDC 索引定义而不是其他的索引。对于MDC，在首次访问连接的表时将重新构建索引。在这种情况下，将自动对分离的分区进行索引清除操作。将从执行 DETACH 操作的用户ID继承索引的模式、权限和表空间。

3、释放当前数据库空间

本课题实施完成后共释放存储空间3.5T，内部户交易明细表记录数由原21亿条降至1.4亿条，最大的存款明细表由28亿条降至12.2亿条，进一步提高了夜间批量和联机处理效率，数据库整体效率提升50%，保障了今后五年内存储使用空间，降低了存储扩容采购成本，初步测算为600万元。

4、通过调度工具，实现自动维护作业的调度监控和管理。

人工清理风险高、工作量大也不符合业界自动化运维的发展趋势。为了便于后期建立常态化自动数据清理机制，课题组在制定“一揽子”解决方案时充分考虑这一点将数据迁移的目标表进行了分区表改造，有效的提高了增量数据清理效率和数据库性能。同时利用工作流工具基于夜间批处理任务和时间窗口自动进行数据清理和归档。

5、缩短核心数据备份时间提升核心数据备份效率，实现备份高效化。核心数据库备份时间整体缩短8.5小时，备份效率提高30%。

6、数据分级管理，查询交易分流，降低核心系统负载。我们利用本次课题对数据库结构进行了改造，支撑了对核心系统数据的管理，优化了交易的渠道，降低核心系统的负载。

4.1.2非功能目标

1、安全性

软件安全性轻则造成操作的不方便，重则造成数据的破坏或丢失甚至系统的崩溃和人身的安全，因此，软件安全性是一个不容忽视的重要问题，我们可以简单地把软件的安全性作为一个或多个特定的功能来考虑，从而在软件生命周期的早期就加以考虑。在本课题的最开始就非常注意安全的问题，比如需求中应有安全性的相关设计和代码评审都有专门针对安全性的内容等等，然后进行测试。采取静态分析和功能测试两种方式拦截系统开发时存在的漏洞软件生命周期早期的代码、设计评审对软件安全性的提高非常有效和重要，都以人工评审和自动化工具结合的方法进行。

最终满足和符合采用的安全机制，在应用规定的程度上能保证系统正常运行和安全使用。

2、易用性

易用性是人类工程学的目标。软件的易用性是一个比较有特点的问题，会随着具体产品或课题的特征和要求而有巨大差异，比如手机软件和一般Windows平台下的软件易用性相差很大，又如一核反应堆的关闭序列和一语音信箱的菜单系统的易用性有着天壤之别。即使对于同一个软件，不同的用户也会有不同的感受。在本课题中采取全自动化，无人干预式作业，用户无直接使用感受。在易用性方面特点突出。

3、可靠性

用于衡量软件可靠性的比较直观的指标主要有两个，一个是软件的失效率（failure rate/FR），一个是平均无故障时间（MTBF）。这两者之间的关系是互为倒数的关系。为保证系统的可靠性我们从以下三个方面进行反复验证和测试：

第一、依据每次测试过程中的失效发生状况和发现的缺陷数推算可靠性。

第二，通过对软件持续运行时的失效发生状况推算软件可靠性。

第三，通过错误植入的方式推算软件可靠性。

本系统运行上线半年，失效率小于1‰25。平均无故障时间超过8500小时。

4、系统性能

通过系统上线以来运行情况的跟踪，系统运行稳定，性能良好，各项指标均已达到原来的设计目标，下面是对系统在运行时的各项性能开销：

（1）日数据清理detach执行时长

（2）服务器CPU开销

（3）存储IO开销

（4）服务器内存无额外开销（共享数据库预分配内存）。

（5）系统上线至今未发现故障或者作业失败的情况。

（6）系统上线至今未进行人工干预数据清理。

4.2课题研究的主要思想

本次课题建设依据目前我行核心系统遇到的难点及困难，以海量数据的在线迁移及自动化清理为课题目标，拟定主要建设思想如下：

4.2.1难点一：首次清理数据量巨大，如TABLE5表，存量数据就有28亿条记录。

解决方法及创新点：数据表迁移方法。

图 5、数据迁移方法示范

数据迁移步骤：首先确定业务数据的保留期限和策略，通过数据迁移将原表（T1表）的有效数据迁移至新表（T1new表）。

4.2.2难点二：数据迁移清理时间长，不能满足业务下线需求，特别是TABLE5表，需要24小时在线

解决方法及创新点：基于完整事务性的在线式数据迁移方法（数据分段迁移清理+数据库表并行双写）+ 多进程并发数据迁移。

图 6、基于完整事务性的在线数据迁移过程

图 7、基于哈希算法的数据进程分配

实施过程描述：

1、初始阶段：业务数据通过数据入口写入数据容器 T1表 。

2、数据双写阶段：实施开始时，对数据口进行复制，使实施开始后，新建分区表T2开始记录T1表增量、及变更数据。

3、在线转储阶段：线将实施前T1表数据转入至T3表。转入期间不影响业务使用。

4、数据同步阶段：通过哈希算法进行进程分配，将临时表T2数据追加至T3表中。

5、切换阶段：切断原表数据入口。将T3表投入生产，在线数据迁移完成。

4.2.3难点三：人工清理风险高

解决方法及创新点：建立常态化数据清理规则。

图 8、常态化清理规则展示

实施过程描述：

1、容器转换据阶段：基于分区表分区分离功能，时间业务数据以日为单位进行逻辑分区，将数据装入成可自由分离的分区表中。实现以日为单位的数据，加工，查询，删除，调整

2、数据分离阶段：将待加工区间内的数据进行分离。分离后小表数据量小便于加工，且加工数据时，不影响大表继续对业务系统提供服务。

3、数据加工阶段：对分离出的小表依据业务逻辑进行数据加工（过程中加入各类数据有效性检查步骤），提取有效数据。使用自动的维护脚本检查，在数据提取自动后核对数据完整性，避免数据混乱。

4、数据整合阶段：将加工完毕的数据加入至大表中，保证数据的完整性。

5、自动维护阶段：使用任务调度工具调度、监控、管理自动维护作业。

6、在任务调度工具作业流中加入自动维护脚本，设定报警机制。在整个过程中维护人员无需职守作业。减少了人员参与作业的人力成本，且降低了维护过程中实施人员的误操作风险。