项目简介

我行在海量数据在线清理迁移项目的实践中，通过方法创新、算法创新、流程创新和功能创新实现了对业务功能无影响的海量数据在线迁移和常态化清理功能，设计了“以物理存储空间换取实施窗口时间、以线下数据清洗时间换取实施窗口时间”的方法和“基于哈希算法的数据进程分配方法”、“基于完整事务性的在线数据迁移方法”以及“常态化数据清理方法”等原创性的技术实现了无需停业的海量数据迁移，省去了传统数据迁移方法所需的384小时停业实施时间，大幅降低了对业务运营的影响。

项目中所探索出的一个方法论、三个创新性的技术和一个原创性系统，成功破解了业界海量数据迁移和治理中普遍存在的时间长、窗口短、风险高、无先例的难题，化解了传统数据迁移方法与业务连续性、有效数据提炼、常态自动清理和系统安全运营之间的四大矛盾，缓解了快速增长的业务规模对系统数据承载和处理能力所构成的巨大压力。

项目的成功实施节约了每年600万元的硬件扩容成本、人员管理成本和系统维护成本；大幅提升了数据质量，核心数据量由8.2T精简至5.4T；大幅提高了系统性能，联机交易提升了30%、夜间批处理提升了40%、数据库效率提升了50%，为提升全行的数据服务质量，提供了更有价值的海量数据支撑。我行通过本项目已获得了省人民银行科技奖一等奖，申请了三项技术专利并取得了一项软件著作权。

项目所设计的方法和创新的技术对应用系统改动较少甚至不改动，也不限定于应用系统和数据库产品，因此具有普遍的适用性和推广价值，特别是对当前中小银行正处于业务高速发展时期，如何缓解、甚至解决海量数据增长所带来管理压力，为中小银行的数据治理能力、数据挖掘技术和系统架构模式的探索和转型赢得宝贵的战略空间，具有一定的借鉴意义。

1 引言

我行自成立以来，坚持“立足社区，面向三农，面向中小企业，面向县域经济”的市场定位，全面推进各项改革，着力规范内部管理，不断提升服务水平，全力加快业务发展，已成为本省内资产规模最大、营业网点最多、服务范围最广的地方金融机构。我行新一代核心业务系统课题作为我行“十二五” IT 科技规划中首要重大战略课题，从立项之初就受到全行员工的广泛关注与深度参与。在监管部门的正确领导和大力支持下， 2012 年 8 月 11 日成功上线，目前系统运行情况良好。

我行新一代核心业务系统上线以来，随着业务的不断发展，数据量快速增长，且呈现逐渐加快的趋势。目前生产系统数据量为系统上线时的6倍约7T 。经过计算，以当时的存储设备剩余空间，剩余可用时间不超过半年。

在规划存储扩容的过程之中，团队发现一个更致命的问题：核心数据库各方面性能出现开始降低的趋势。季度结息日，经过对历史批量作业完成的时间的趋势分析，数月后批量完成时间几乎接近营业网店开门时间。因此，团队开始了对数据库性能调校和数据清理全面的问题排查和课题研究。

1.1 研究背景

1.1.1 银行业十三五规划要求

《中华人民共和国国民经济和社会发展第十三个五年规划纲要》明确提出要实施创新驱动发展战略，强化科技创新引领作用。信息科技作为银行业金融机构的核心竞争力担负着重要使命。必须加大对新兴技术的探索研究，实现“加快推进国产自主可控替代计划，构建安全可控的信息技术体系”。积极推进新兴技术研究与成果应用，提升银行综合技术实力和科技创新能力，优化在线数据结构，发挥有效数据价值，是银行信息科技工作面临的重要课题。同时随着银行业务结构和业务系统复杂度的日益提高，以及业务量的快速增长，均对信息系统的业务连续性提出了更高的要求，可供计划性的维护时间窗口大大减少，给银行信息系统安全运营带来了巨大的压力。

1.1.2 银行业海量数据管理面临的困难

随着银行业数据量的快速增长，银行业面临的海量数据管理困难总结如下：

1 、传统数据清理方法和有效数据提炼间的矛盾。由于金融业务市场的快速发展、银行数据呈现井喷式增长，但数据质量又普遍不高，从海量数据中挖掘有效数据形同大海捞针，各行均面临数据管理的巨大压力。

2 、传统数据清理方法与业务连续性间的矛盾。为保证金融业务不间断开展，可用于数据维护的时间窗口十分有限，传统的清理方法，处理效率低、速度慢、周期长，严重影响业务连续运行能力。

3 、传统数据清理方法与系统安全运营间的矛盾。传统数据清理方法不仅时间长，而且操作风险高，易引起数据丢失或出错，会给客户带来损失，造成不良的社会影响。

4 、传统数据清理方法与常态自动化清理间的矛盾。传统数据清理方法的特点是突击性、一次性，即使艰难的完成了一次数据清理也不能保证后续数据问题不再发生。

1.1.3 我行面对海量数据增长的现状和困境

近来，随着业务的不断拓展，业务的多样化和数据量快速增长，且呈现逐渐加快的趋势。在此情况下，一方面需要不断的进行存储设备扩容或新购来满足数据库增长的需求，存储设备扩容压力较大。另一方面数据库的各方面性能出现开始降低的趋势，具体体现在：一是数据库增删改查效率低下，交易响应效率变慢，整体核心批处理的执行时间也越来越长，普通日日结批处理完成时间大约需要 10 小时，特殊日处理时间接近 14 小时，对夜间整个业务批量处理总时间、系统的维护有较大影响。二是数据库日常备份时间过长，核心日库备份时间已增长至 18 小时之久，而每日备份时间窗口最大仅有 20 小时，即将面临无法完成日常备份的风险。三是数据库表重组效率变低，操作时长变得不可控，几次数据库的大表重组整理大幅超过窗口维护时间，险些影响网点营业开门酿成生产事故。

面对着生产数据不断增长，核心系统越来越复杂，核心数据库也越来越庞大，我行数据迁移问题也越来越紧迫。但由于现有核心的表结构，存量数据的清理需要完全靠人为实现，比较繁琐，且风险较大，导致新一代核心系统上线以来，一直未能真正进行核心数据的清理。

在此背景之下，本课题组于 2015 年 10 月开始启动海量数据在线迁移及自动化清理模式的创新及研究。旨在克服传统海量数据清理可行性低、风险高等困难，在不中断系统运行的前提下，在极短的窗口时间内完成海量数据的在线清理迁移，建立数据常态优化清理机制，消除数据库性能“天花板”效应，达到数据增长稳定的目标，为金融行业海量数据优化工作开创一种全新、高效的实施方法论。

1.1.4 课题攻克难题的探索历程

按 2015 年初的数据与 2012 年相比，系统日均交易量等指标翻了两番，已经远远超出系统原先规划的空间容量，存储空间经常处于 95% 以上，数次接近 99% ， 2013 年和 2015 年已经进行了两次存储空间扩容，但没有办法从根本上解决存储空间一直快速增长的问题。

为把数据量降下来，课题组对业内常规和非常规清理方法进行了深入调研，并将相关方法论在行业内开展了学习推广和实验验证。相应的方法论如下：

常规方法

（ 1 ） DELETE 方法是最常用的数据库删除数据的方法，该方法执行时会记录数据库日志，删除大量数据会导致数据库日志爆满。使用不记录日志的方法对一直张 22 亿笔数据表进行删除操作即使在规定时间完成数据完整性也无法得到保障。几乎无法进行比对和校验。经过几次的痛苦 DELETE 过程后，发现数据量增长速度已经超过的 DELETE 速度。在测试环境中，使用不记日志的方法进行，删除一天交易流水数据需要 230 分钟。且无法校验数据一致性。存在极大的数据丢失风险。

（ 2 ） Truncate 方法执行时会清除表中的所有数据，不记录数据日志，但是明细表不可能删掉全部的数据，还需要保留至少最近一年的数据；

非常规方法

（ 1 ）现有数据库数据迁移一般采用传统“ DB 加载”的方式，比如 load 、 import 进过大量的数据切分测试

load 、 import 方式虽然速度快且受限于进程数量的限制无法实现对同一张表进行并行加载数据。同时伴随着数据库碎片整理的问题。 load 数据速度快的原因是因为 load 进行数据加载的时候不对数据库“脏页”进行识别。直接将表使用的页全部导入，因此数据库碎片也会被加载到新表中（碎片的产生在是数据库性能降低的根本原因）。经过测试，重新对交易流水表进行碎片整理需要 13 小时以上。

（ 2 ）新建表使用数据同步工具 "CDC" 进行数据复制。计划在复制一张表后对这张不活动的表进行数据清理，之后再进行表的切换，离线完成清理。但是在使用 CDC 的过程中。我们发现 CDC 工具首次对一张表进行同步其底层实现过程如下：第一阶段进行快速数据转存（底层代码基于 load ），第二阶段使用数据库日志进行数据追写。在第一阶段的数据复制过程中，服务器开销超过百分之 70% 以上（不含生产交易开销），根据以往经验，单个作业服务器资源开销超过百分之 50% 就已经会影响生产。而其他复制工具也是大同小异无法满足直接需求。

第一轮工作的验证后，相关部门负责人汇总反馈，基于我行的数据结构、数据量级以及数据质量要求，传统清理方法并不适用。具体来说，经过大量测试和求证，技术瓶颈停留在，数据迁移和转储上。没有一个好的方法把数据从旧表中转移出来，或者从旧表中转移至新表之中。

于是课题组继续在业内考证，发现业内同行普遍面临类似问题单尚未具备较为完整和系统的解决方案，甚至引发重大安全事故：

1 、数据库数据量过大，造成业务系统宕机案例。 2016 年 10 ，某商业银行系统数据库业务人员，在业务系统中进行自定义业务数据查询，执行 sql 语句后。整个生产系统直接宕机，经分析业务人员在进行数据查询时，未进行分页操作，加上数据库数据量巨大。查询语句执行后直接导致应用服务器内存溢出。该故障直接造成服务器停机半小时，生产业务无法办理。网银转账、理财和基金功能均暂不能操作。

2 、数据库备份异常造成的故障案例。 2014 年 7 月，某商业银行核心系统数据库出现故障，导致该行存取款、转账支付、借记卡、网上银行、 ATM 和 POS 业务全部中断。因银行应急恢复处置机制严重缺失，导致系统恢复工作进展缓慢，业务系统中断长达 37 小时 40 分钟，其间完全依靠手工办理。称经初步分析，在季末结算业务量较大的情况下，因备份系统异常导致备份存储磁盘读写处理严重延时，备份与主存储数据不一致，在采取中断数据备份录像操作后，造成生产数据库损坏并宕机的案例，造成全市定点医疗机构和定点零售药店共 700 多家不能刷医保卡 ( 社保卡 ) 就医结算。影响巨大。该故障由于数据库备份太大，恢复时间过长。造成业务中断时间过长。因此缩小数据库备份有助于在发生故障后快速进行恢复。

3 、数据量激增，导致数据库效率陡降案例。 2015 年 2 月，某商业银行因业务量激增，造成柜台部分落地非实时交易、同城票据交换交易处理缓慢。银行业信息系统承载着金融机构核心业务和金融服务的稳定运行，一个环节出现问题，就可能引发“多米诺骨牌”式的传递效应，引发系统性金融信息安全风险，巨大的经济损失尚且可估算，但对银行社会声誉的巨大损失甚至容易引发全社会的恐慌所带来的巨大冲击则是不可估量的。

因业内没有先例可以借鉴，课题组针对我行数据现状继续开展了原创性的难题攻关，分以下三个步骤：

1 、针对如何记录制定分割时间后的增量数据，课题组尝试：

a 、数据库触发器（开销过大影响生产交易）；

b 、使用数据库归档日志，重追交易记录（数据库实例级操作、风险过大且工作量巨大）；

c 、使用应用系统进行双表数据写入（需要进行应用改造及数据改造校验开发、需要一次存量数据的追写）

2 、针对如何快速分离待清理数据，课题组尝试：

a 、数据库分区表 detach ；

b 、数据库索引问题，使用分区索引会导致索引数量过多，占用空间极大。数据库统计信心收集、碎片整理慢；

c 、使用非分区索引在 detach 分区后需要进行“异步索引清除”（后台进行，夜间运行不影响交易）。

3 、针对如何在规定时间内完成海量数据的转存，课题组尝试：

a、在生产环境中建立“副库”提取生产环境需求数据；

b、使用 " 异地数据加工 " 的方法，将生产数据备份恢复到测试环境中提取需求数据。

最终课题组经过我行内部大规模的实验验证，为行内业务提升和行业方法借鉴成功作出看了以下贡献：

1. 使用分区表 detach 达到快速分离分区的效果。使用非分区索引（执行计划开销差异不大），“异步索引清除”通过流程控制调整到凌晨主要批量跑完后执行，不影响批量作业及生产交易。
2. 采用应用系统表双写，对极少量程序改造后完成增量数据记录，加上数据库和业务数据笔数校验完成数据完整性。
3. 采用自创哈希算法把转存数据切分，多进程进行数据导入，保证了实施在规定时间内完成。

1.2 研究意义

随着物联网、云计算等新技术的广泛使用，新型业务的产生，传统业务的转型以及新的服务模式的出现，尤其是web2.0时代带来的交互模式的改变，使得网络世界的数据量爆炸似的增长。面对这些冲击，许多企业和数据中心开始面临一个新的问题——数据迁移。

大数据迁移作为一个IT课题，具有与通常的IT课题相同的风险，比如延迟或预算不足。但与通常的IT课题如信息系统开发相比，人数据迁移由于直接涉及信息系统服务的核心内容：数据，其重要性和敏感度远较普通的IT课题更高，任何迁移结果的不完整都会导致迁移后的系统无法提供预期的服务，会给用户和企业造成无法挽回的损失。

作为数据治理学科的核心要索之一，数据风险管理已经成为大数据时代风险管理的 主要内容™;更进一步地，随着数据中心的持续运行，许多企业不得不面对如下的挑战性问题:怎样进行大数据的迁移？大数据迁移过程的数据风险如何进行控制？如何保证大数据迁移过程中的数据完整性？

数据迁移的实现可以分为四个阶段：初始化阶段、数据迁移实施阶段、测试、生产迁移阶段。数据迁移实施阶段可分为数据卸载、数据完整性检测、结构分析、数据清洗四个步骤。数据卸载就是将原数据库中的数据卸载到迁移平台，然后对其进行数据完整性检测，通过检测之后要对原数据和目标数据进行结构分析，根据结构分析结果进行数据清洗。数据清洗主要是针对原数据,对出现二重性、重复、不完整、违反业务或逻辑规则等问题的数据进行相应的清洗操作。数据完整性是数据结构分析和数据清洗的前提，若数据不完整，那么数据结构分析和数据清洗都无从谈起。

数据完整性分析是数据质量管理的重要组成部分。数据完整性检测主要检测数据在清洗之前是否正确持有原数据库中的数据，防止数据在进行清洗之前发生丢失、篡改等情况。数据完整性面临的风险分析主要是对在数据迁移过程中可能造成数据完整性遭到破坏的因素进行定性和定量的分析，找出造成数据完整性遭到破坏的关键风险源， 并计算因为基本风险事件导致数据完整性遭破坏风险发生的概率，以便在进行数据迁移之前制定详尽的风险控制计划，防止数据完整性遭到破坏等风险的发生。

与传统的IT课题风险相比，大数据不仅仅有着更大的数据量同时也有着更加复杂的异构的数据格式，数据的使用者也非常纷繁多样，潜在的迁移H险更大。由于数据治理的概念刚刚兴起，大数据的定义尚不清晰，数据分类还比较模糊，因而在大数据迁移的过程中会因为数据定义和格式异构问题导致迁移后的数据不一致，这种风险将直接导致数据迁移失败。

尽管对于因大数据迁移过程中发生的风险而造成的损失还没有具体的统计数据，但 是数据迁移过程中发生的各种风险已有大体的统计数据。根据ESG (Enterprise Strategy Group企业战略集团）的一个对700位大数据用户的回访发现，在大数据迁移时候会发生各类问题：

1、64%超过停机时间或导致意外宕机。

2、51%出现不同程度兼容性问题[13]。

3、38%不同程度数据损坏。

4、38%新老系统之间性能的问题[13]。

5、34%不同程度数据丢失。

其中数据损坏发生的概率为38%，数据丢失发生的概率为34%，这两者都是数据完 整性遭到破坏的表现形式。也有统计表明，数据完整性遭到破坏是导致新老系统之间性能问题的关键。

图 1 大数据迁移过程中出现的问题及其发生比例

根据以上阐述可以看出数据完整性对于数据迁移课题有很大的影响，数据完整性遭破坏甚至关系着企业的兴衰。本论文就大数据迁移过程中的数据完整性问题进行研究，具有重要的理论和现实意义。

1.3 研究目的

《中华人民共和国国民经济和社会发展第十三个五年规划纲要》明确提出要实施创新驱动发展战略，强化科技创新引领作用。信息科技作为银行业金融机构的核心竞争力担负着重要使命。必须加大对新兴技术的探索研究，实现主席提出的“加快推进国产自主可控替代计划，构建安全可控的信息技术体系”。积极推进新兴技术研究与成果应用，提升银行综合技术实力和科技创新能力，优化在线数据结构，发挥有效数据价值，是银行信息科技工作面临的重要课题。同时随着银行业务结构和业务系统复杂度的日益提高，以及业务量的快速增长，均对信息系统的业务连续性提出了更高的要求，可供计划性的维护时间窗口大大减少，给银行信息系统安全运营带来了巨大的压力。

另外， 2018 年 5 月 21 日，监管部门发布《银行业金融机构数据治理指引》 ( 以下简称《指引》 ) ，意在“引导银行业金融机构加强数据治理，提高数据质量，充分发挥数据价值，提升经营管理水平，由高速增长向高质量发展转变”。这份指引内容简洁，但是数据治理的很多关键点都明确的指出来了，对于工业企业数据治理有很多可以借鉴和参考的地方，非常值得认真学习：

1. 数据治理指引中的“全覆盖原则”。银行业金融机构数据治理应当遵循原则的第一条，就是全覆盖原则：覆盖数据的全生命周期；覆盖业务经营、风险管理和内部控制流程中的全部数据；覆盖内部数据和外部数据；覆盖所有分支机构和附属机构；覆盖监管数据。这个原则，体现了数据作为战略资产重要性认识。数据治理不是个别部门的事情，也不是局部业务的事情，数据治理是系统工程。数据治理覆盖的是全业务领域；数据治理组织架构涉及董事会、监事会、高级管理层、业务部门——数据治理的组织架构也是需要全覆盖的。这个全覆盖原则，意味着对数据的管控要求提升到了高层战略关注和公司治理的层面。这正是深入推进数据治理所必须的。
2. 数据治理的岗位设置。数据治理指引明确了数据治理的岗位设置。不是兼职的、不是偶尔关注的，而是在数据治理归口管理部门设立满足工作需要的专职岗位，在其他相关业务部门设置专职或兼职岗位。这是推动数据治理的基本保障。

3. 对数据使用的要求，数据价值实现。真实可靠的数据才能发挥数据的价值。数据绝不是看看统计、做做报表那么粗浅；用数据治理推动整个管理的变革，通过数据责任和数据关系重新定义组织中相关角色的活动和协作，相互促进，这是企业把数据作为战略资源的重要意义。数据治理指引中对数据价值实现的描述，也阐述了数据治理和数据分析利用的关系。

   近年来，我行业务快速发展，如何高效维护及管理数据成为关系到业务是否可以安全运营、是否可以从现有数据中发现新的商业机会、重构商业模式的关键。

   本课题旨在研究一种新的技术方法化解传统数据清理方法与有效数据提炼、业务连续性、系统安全运营等之间的矛盾，从而提高银行信息系统运行的稳定性和银行数据价值。

1.4 研究方法

系统地搜集有关海量数据清理的现实状况及历史状况。运用个案研究、测试实验等方式，对各类海量数据清理算法进行系统的了解和比较，并对调查搜集到的大量资料进行分析、综合、比较、归纳，总结规律并形成符合农信自身特色的技术方案。通过数据清理实践中的具体情况，进行分析、优化提炼，并使之进一步系统化、理论化，上升可复制和推广的一种方法。

对数据完整性检测方法的研究可以分成两个阶段，第一个阶段是用传统的 Hash 函数进行检验阶段，第二个阶段是现有的细颗粒度数据完整性检测方法阶段。

Hash 检验是数据完整性检验的重要手段之一。被用来进行数据完整性检验的 Hash 函数有 SHA-256 和 MD5 等函数。近年来对用 Hash 函数来进行数据完整性检测的 研究仍然很多，与之相关的检测方法技术也在不断涌现，比如 Komblum 等人研究的针 对取证的自动筛选技术 _, Roussev 等人提出的针对大数据的相似性衡量技术以及多 分辨率相似性衡量等技术。

用 Hash 函数进行数据完整性检测主要有三种方式，比如对 n 个数据对象进行数据 完整性检测，可以用以下三种方法。

方法 1: 用 1 个 Hash 监督 n 个数据对象；

方法 2: 用 n 个 Hash 分别监督 n 个数据对象；

方法 3: 用 m 个 Hash 监督 n 个数据对象(m < n)

比较以上三个方法，从使用的Hash数目方面考虑，第一种方法使用的最少，方法次之，使用最多的是第二种方法U< m < n. 但是从 Hash 函数对数据对象的监督性 能上考虑，第二种方法监督性能最强，这种方法采用一对一的监督方式，任何一个数据 对象出现问题，都会被检测出来。第三种方法次之，它是采用多对多的方式对数据对象 进行监督，就是说一个 Hash 数同时监督许多个数据对象，同时一个数据对象也被许多个 Hash 值监督。第一种检测方法监督能力最弱，方法 1 采用的是只使用一个 Hash 值监 控多有的对象，在监督的效果上明显差与其他两个。由此可见，监督能力的强弱和 Hash 数 H 之间是矛盾的关系。若想更加准确的进行数据完整性检测，就要牺牲 Hash 的数 H ， 反之想确保 Hash 值得数 H 少，就要忍受监督强度的减弱。

近年来，研究者热衷于用细粒度完整性检验方法进行数据完整性检测，且研究的领 域多集中于计算机取证和云存储领域。

细粒度数据完整性检测的思想是利用数据完整性指示码。数据完整性指示码主要 目的和功能是减少数据完整性检测过程中使用的 Hash 的数目，研究者希望用更少的 Hash 数检测更多的数据对象。完整性指示码就是采用某种理论将多个数据对象排布在 同一个空间中受到同一个 Hash 值的监控，同一个数据分组必须至少受控于两个不同的 Hash 数，所有的数据对象必须均匀受控于所有的 Hash 数。由此可见，细粒度数据完整 性检测方法的实现主要是要构造完整性指示码，但是完整性指示码的构造方法复杂，不易实现。目前已研究的细粒度数据完整性检测方法主要针对单错和多错的数据完整性指 示码。针对单错的情况，可以用超方体单错完整性指示码和组合单错完整性指示码。 对于多错的情况，主要用复数旋转指示码以及有限射影完整性指示码 _ 进行数据完整 性检测。

1.4 研究创新点

1.4.1 独特方法论克难题

经过大胆的假设、小心的求证以及详细的测试，课题组采用了采取新型的数据迁移方法论，包括下述两点：一是“临时存储空间换大量实施时间”即采用应用模块化改造，借用新的物理表空间作为中转来减少实施窗口时间；二是“以安全线下时间换宝贵线上时间”即采用以线下时间（开发测试环境）换取线上数据加工提取的时间来减少实施窗口时间。

通过上述一个方法论的两种创新方法，实现了在无需中断业务运行的情况下,从海量数据中提取有用数据，既不损失数据质量又没有影响业务正常开展。

1.4.2 在数据清理的过程中通过技术创新，保证数据的一致性

采用了“基于完整事务性的在线式数据迁移方法”，根据数据优化的要求，在不限定时间的前提下，对新增数据进行读写分离，允许数据在新老数据表中保证一致性的前提下同时更新，适应不同的实施环节并可提供灵活性和扩展功能，有效实现数据在线迁移，适用于历史数据与新增数据的分离。

**

1.4.3 通过实践了新型的数据优化的方法，同时更好的保证系统业务数据的容量可控

在数据日常维护中，通过实践了新型的数据优化的方法，同时更好的保证系统业务数据的容量可控。独创性的采用“分区表、循环优化”的架构建设，建立了业务数据的自动清理机制，实现业务数据的在线自动清理，提高数据清理自动化程度及空间有效利用率。

1.4.4 优化进程分配算法，提高数据迁移并发效率

利用“基于哈希算法的多进程数据迁移方法”对海量数据进行分类并发多进程导入，可有效缩短数据迁移时间，适用于在线迁移或对于停机窗口有限的离线数据迁移。

1.4.5 课题实施方案及技术具有极高的适用性和可推广性

海量数据迁移及常态化自动清理是各行业IT系统普遍面临的难题，本课题所采用的方法论和创新的技术对应用系统改动较少甚至不改动，也不依赖特定的应用系统和数据库产品，因此具有普遍的适用性和推广性。

2.1 研究现状综述

当前对于大数据迁移的研究 主要是从大数据迁移的质量，迁移计划 , 时间掌控，大数据迁移课题的具体过程，数据迁移过程管理，数据迁移过程中的测试以及测试工具的实现，大数据迁移过程中的成本分析，数据迁移过程中的风险规避以及大数据迁移标准的制定等方面进行研究。对于大数据迁移过程中的风险管理研究并不是很充足，属于刚刚起步阶段。

由于技术基础、管理情况和社会环境方面的差异，我国与西方发达国家在数据迁移方面面临的主要矛盾不同，这点在对数据迁移风险管理理论的研究和应用方面可以体现出来。国外对于大数据迁移风险的研究真正开始于 2010 年，研究成果并不是很多，其中较多的强调风险管理的重要性。在理论研究方面主要包括风险分类、风险分析、风险检测方法。

现有的理论研究从宏观上对大数据迁移方面的风险进行了简单的识别与归类。大数据迁移风险最初被表述为大数据的缺陷或错误，然后逐渐被描述为风险。并按照企业的管理结构将大数据迁移风险分为业务方面风险、信息技术管理风险、数据迁移课题风险、迁移运行风险以及基础设施风险五大类。在业务风险方面，又细分为：营业能力，名誉声望和监管三个方面。信息技术管理风险则包括：数据或信息丢失、目标应用程序的稳定性、切换中止、延长停机时间、课题预算超支、延迟六个方面。数据迁移课题风险包括：完整性风险、语义风险、数据损坏的风险、稳定的风险迁移运行风险、执行时间风险、编制风险。最后的基础设施风险包括软硬件设施的配置，以及迁移所需要的机房环境等。

从风险分类图中可以看出，数据完整性风险可以分为数据损坏风险，数据信息丢失风险，数据语义改变风险。但是现有文献对这些风险没有更深入的分析研究，比如导致风险发生的关键因素以及风险发生的概率等。

我国对大数据迁移的研究还停留在大数据迁移的风险识别阶段，对识别的风险进行分类描述，对其危害程度进行分析。但是针对大数据是怎样迁移的即迁移过程、迁移工具、测试方法等方面，还没有人进行正式的研究。

2.2 研究理论基础

2.2.1 大数据迁移及其过程

数据迁移是一个依靠软件支持的从源程序（应该被关闭）将数据迁移到目标应用程序的过程。数据迁移过程中要移动大量的数据，因其是一个涉及许多不同利益相关者的大规模课题，主要在两种情况之才考虑进行数据迁移。第一种情况是应用程序不能满足系统运行的需要，急需一种新的应用程序来代替，第二种情况是发生在兼并和收购时候。图 2 显示了数据迁移过程中数据的流向。

图 2 、数据迁移过程数据流向

Haller 等人在跟踪访谈和调查了大量的数据迁移课题之后提出了大数据迁移过程模型。他们研究了超过 45 个数据迁移课题，由此得出的数据进行数据迁移过程模型的研究。大数据迁移是个费时费力且充满风险的过程，因为数据对于一个企业的重要程度非同一般。其过程的复杂性、涉及的人员广、数据的海量性等特点，以及技术条件的限制等因素都让大数据迁移过程风险重重。

这些团队涉及到数据迁移的整个过程。数据迁移的整个过程可以分为四个阶段：初始化阶段，数据迁移实施阶段，测试阶段，切换阶段 .

1 、第一阶段初始化包括：竞标策略的制定，数据迁移预分析，迁移平台的建立。

2 、第二阶段数据迁移阶段包括：原数据卸载、数据完整性检测、原 / 目标数据和结构分析、数据清洗、数据转换工作。

原数据卸载律程需要满足以下几个条件：（ 1) 不能妨碍源应用程序的日常操作应用；（ 2) 卸载的数据必须包含所有的数据；（ 3) 经常在论文中被忽略的，但是对于企业来说非常重要的：对于什么时候、应该怎样卸载数据要认真详尽的计划；（ 4) 计划好卸载时间后，核心用户团队将源数据和目标应数据结构的映射到缓存区，实现脚本 ( 卸载需要多次）最后启动提取。需要注意的是，在复制的过程或许需要一些高水平的过滤，附加数据（没有存在于源程序，但是目标应用程序需要）要被添加进来。大数据迁移具体迁移过程如图 3 所示。

图 3 、大数据迁移过程模型

3 、第三步测试阶段包括：迁移运行测试、外观测试、完整性和类型测试、加工性能测试、综合测试等一系列的测试。测试是数据迁移过程中的主要工作，只有经过测试之后才能进行最后一步系统切换。因不是本研究的主要研究内容，在此不具体赘述各个测试的主要过程。

4 、第四步系统切换。系统切换实质上就是生产的迁移，即目标应用程序正式进行业务运行，而源应用程序停止服务。如果目标应用程序运行稳定则数据迁移课题过程结束。之后只要进行系统维护的工作。同样不详细赘述具体过程。

由以上阐述可以看出，大数据迁移课题是个复杂、安全要求较高的课题，在课题中，数据完整性检测是必不可少的工作。除了在数据清洗之前要进行数据完整性检测，在测试环节仍要进行一次数据完整性检测，第一次数据完整性检测是保证数据在清洗之前的数据质量得到保证，后一次数据完整性检测是保证数据在迁移之后与数据清洗之后的数据保持一致，确保数据在迁移过程中没有被破坏。

2.2.2 故障树理论

系统故障树分析，简称 FTA (Fault Tree Analysis) ，即用故障树的形式进行风险分析的方法，用于确定哪些组成部分的故障模式或外层事件或它们的组合，可能导致产品一种己给定的故障模式。

故障树理论从 1961 年首度被提出以后，经过不同国家的研究人员多年的研究和拓展，逐渐的发展成熟。 1965 年，在由波音公司和华盛顿大学组织的学术会议上， Haasl 等人明确了 FAT 的概念。使得这一技术在风险分析领域得到了更进一步的发展。 1977 年， Lapp 和 Powei 提出了非单调关联故障树模型， FAT 技术的发展又走上了另一个高峰。

当前，故障树风险分析技术已经被运用到多个领域，是风险评价和风险评估的重要手段。从上个世纪 80 年代初期，我国开始引入故障树技术，经过多年的研究与应用，故障树技术得到更进一步的发展。多种基于故障树理论的风险分析方法和技术不断涌现。比如清华大学提出的 MFFTAAP 多功能故障树技术； 1989 年天津大学的陈金水教授提出的用矩阵进行故障树分析的新方法。

在故障树的应用和发展过程中，故障树的优点不断显现，可以总结为以下儿方面：

1 、灵活、多用。故障树分析法的灵活性体现在凡是需要进行风险分析的场合都可以使用。工程中大型的装置、课题过程中的风险分析、软件开发过程中的风险分析等都可以借用故障树理论。不仅可以分析由多重因素构成的风险，还可以分析由外部环境造成的风险。

2 、直观、形象。故障树分析法主要借助图形方式将风险状态以及风险状态之间的逻辑关系表示出来在风险分析时，从以构建的故障树中可以非常直观的观察各个风险的状态，风险的形成原因。与常见的风险分析方法不同的是，故障树分析法以图形的方式呈现，既直观又形象。

3 、多目标、可计算。故障树分析法可以被多次利用到同一个课题当中而不产生矛盾，在同一个课题的任何阶段都可以使用。可以用故障树分析法找出在课题运行中会遇到的各种可能引发风险的原因，从而在计划阶段就做好风险规划，进行风险规避，减少在课题运行中，各种风险的发生。另外故障树的定量、定性分析都是非常成熟，且既可手工操作，也可以借助计算机进行辅助分析和计算。

故障树的多重优点为风险分析提供了便利。但是它的缺点也是非常明显的，例如：在故障树的建立阶段，由于不同的人对问题的认识角度和认识程度不一样，会有不同的建树方法，因此会产生很大的分歧，甚至会出现错误的建树。

2.2.3 数据完整性检测理论

Hash 算法是数据完整性检测的主要工具，在数据完整性检测研究的最初阶段， Hash 是主要的研究内容。 MD5 是在 90 年代初由 MIT 的计算机科学实验室和 RSA DATA Security Inc 发明的。经过 MD2, MD3, 和 MD4 发展而来，全称为 Message-Digest Algorithm 5 ， Message-Digest 泛指字节串（ message) 的 Hash 变换，可以将任意长度的字符串转换成固定长度的内容，并且其转化过程与编码方式无关，只与字符串本身的字符有关。

MD5 算法的工作原理是将任意长度的字符最终转换为 128bit 的整数。且计算过程是单向不可逆的行为。也就是说，无法将一个 MD5 信息摘要还原成原本的数据模样。其实质上是一个不存在反函数的函数。

MD5 比之前的 MD2 、 MD3 、 MD4 都更安全。因为这个算法是由 4 个 MD4 步骤组成，当然每个步骤都与 MD4 有所不同。经过大量的实验证明， MD5 是安全可靠的，其反操作在计算量上是不可能实现的，但是随着科学技术的发展，超能计算机的问世， MD5 算法的碰撞课题逐步被发现。

3.1 数据量高速增长带来的潜在问题

3.1.1 清理数据困难，大量不活跃数据长期占用存储资源

我行自2012年新系统上线以来，我行业务发展迅速，业务量高速增长。按照2015年初的数据与2012年相比，日均交易量等指标翻了两番。

1、对于这种超大数据量的表，常规的数据清理方法已经无法胜任。

（1）DELETE

DELETE方法是最常用的数据库删除数据的方法，该方法执行时会记录数据库日志，删除大量数据会导致数据库日志爆满。

（2）Truncate

该方法执行时会清除表中的所有数据，不记录数据日志，但是明细表不可能删掉全部的数据，还需要保留至少最近一年的数据；

2、对于大数据的迁移，如何在尽可能短的时间内完成迁移是当前业内技术难题。

现有数据库数据迁移一般采用传统“DB加载”的方式，比如load、import等方式虽然速度快，但是实现方式都是基于数据库自身技术的实现，且受限于进程数量的限制无法实现并行加载数据。

（1）IMPORT

问题：

a、锁定表

根据是否允许对表进行并行访问，IMPORT会获取对现有目标表的独占（X）或非独占（IX）锁定，导致业务系统等待超时。

b、介质文件占用空间

IMPORT的使用是基于EXPORT导出后的介质，进行导入动作。由于导出介质所需存储空间巨大，致使实施期间需要频繁的进行存储空间的腾挪，浪费了大量的时间。

c、记录日志

对海量数据插入时，执行效率降低，服务器开销增大。极端情况下导致业务中断。

（2）LOAD

LOAD实用工具的导入效率比import/insert高许多，原因是该工具直接针对数据库的页面进行操作，因此节省了绝大部分的导入开销。

问题：

a、字段截断

在装入过程中，LOAD对表对象的列宽有严格要求 假如有一列的宽度为9，但是表中定义该列的宽度为6，因此针对每一行，load工具都对该列进行了截断操作，从而导致整体装入速度大幅降低，且导致数据完整性被破坏。

b、不允许中断

LOAD动作不允许中断，例如：crtl+c或者 kill 命令中断后数据表不可访问。对在线生产业务系统造成灾难性后果。

3.1.2 数据量的增长无法维系数据库系统的原有性能

（1）备份时间长。

数据库备份需要16个小时才能完成。

（2）增删改查效率低下。

（3）倒出数据的时间长，影响外围系统的运行。

（4）执行数据库维护操作时间较长。

对TABLE5表执行一次倒出全量数据需要超过4个小时，4个小时就已经超出每晚维护窗口时间，其它维护操作需要的时间就更长了。

3.1.3 数据的可维护性较差，影响业务运行

维护部门也曾考虑进行数据清理，但每天的维护时间窗口有限，清理的数据量又非常巨大，根据估算，采用传统的清理方法，即使采用“蚂蚁搬家”式的每天清理，就需要持续半年时间才能完成任务，且过一两年后还要再做一次，这给系统运维部门带来巨大的压力，同时也给应用部门带来不便，给我行发展造成不良影响：

1、全人工操作，风险性不可控。

2、特别是存在两难困境。

TABLE5表是24小时运行的用户明细表，它没有执行维护的窗口时间，即使使用连续几个维护窗口，也不可能长时间中断业务来执行维护清理历史数据的任务。

TABLE5海量的数据又决定了它不可能在较短时间内，或短时间中断业务的情况下就可以清理掉如此之多的数据。前面提到过TABLE5表仅执行一次数据倒出就需要四个多小时，这就已经超出每晚的维护窗口时间了；如果使用DELETE每天删除一小部分数据，据估算至少需要半年时间才能出来完成。

3.2 数据完整性中的潜在风险

数据完整性遭到破坏会给数据迁移课题乃至企业带来致命的危害。如果数据完整性遭到破坏而没有被及时检测出来会引发的风险如下：

1 、目标应用程序的稳定性风险

数据完整意味着数据结构完整正确。数据完整性遭到破坏时，有可能是数据结构出现问题。即使所有相关的数据全部成功导入新的应用程序，已迁移数据有可能破坏目标应用程序的稳定性。而数据结构遭破坏，更加加大了对目标应用程序稳定性的威胁。就是说数据完整性影响了目标应用程序的稳定性。

2 、切换中止风险

切换是指将正在运行的系统由原始应用程序切换到目标应用程序，原始应用程序正式成为过去时。切换不成功的最主要的原因就是数据迁移过程中数据发生的错误，应用程序运行正常，但是数据不允许切换，切换不成功说明数据迁移时失败的。

3 、执行时间风险

执行时间风险是指实际的数据迁移执行时间会比预想的长出很多。数据迁移的执行时间与数据量的关系并不是简单的线性关系。再加上数据之间或许存在排序和连接，数据中间发生错误，这更会延长数据迁移的执行时间，大量的数据迁移和错误的数据迁移不仅会延长执行时间，还可能直接导致死机。

4 、意外或长时间的停机风险

意外或长时间停机是指切换需要的实际时间远比计划的时间要长。这就会给公司的业务带来很大延误。比如，生产线或者银行系统在超出预期的时间外不能运行，就会导致银行不能提供服务，生产线不能生产汽车。停机时间决定数据迁移成功或失败的关键，应尽可能的减小停机时间。而数据中途出现错误和丢失导致的数据结构改变会引发停机风险。

5 、兼容性风险

如果在数据迁移过程中数据结构发生变化，可能产生兼容性风险。例如，如果数据的某个参数发生了变化，它将在没有被适当识别的前提下不允许添加客户。然而，如果客户的账户信息存在于原应用程序中，目标应用程序中又存在此约束，原本应该被完全迁入目标应用程序而没有被正确迁入，这时就会产生兼容性风险。

6 、业务完整性风险

业务完整性风险包括两个方面：一方面体现在迁移数据的过程中丢失一个或多个业务对象，另一方面体现在增加了额外的业务对象。业务完整性通过数据完整性来体现。

7 、数据迁移失败风险

这是最直接也是最大的风险，数据迁移失败不仅浪费了大量的人力、物力，对于企业的业务也会产生很大的影响。数据的完整性是决定数据迁移是否成功的重要判断依据之一。倘若迁移的数据是不完整的损坏的，都会对正常的营业产生很大程度的影响。所以要在数据迁移之前要详细做好回退的方案。

8 、盈利能力风险

盈利能力即成本和收入。成本分为直接成本和间接成本，直接成本及数据迁移工程本身的成本依附于其课题预算。间接成本则是由于一些错误的数据迁移产生，比如汽车制造业有 500 辆红色和 20000 辆黑色轿车的订单，如果数据迁移之后，订单变成 20000 辆红色和 500 辆黑色轿车，就会产生上万辆车的订单数据差异，大大增加生产成本。

9 、名誉声望风险

名誉声望对于一个公司来说至关重要。一旦公司信誉受到损坏，重新赢得信誉所需花费巨大。公司的任何一个小失误都有可能影响到公司的名誉，该公司旗下的所有产品都会受到不利影响，直接危害公司的经济利益。

10 、受监管程度风险

公司需要在相关监管部门的监管之下运营。若公司给监管部门的印象是正面的，那么监管部门对于他们来说是让人尊敬的。但是若给监管留下不良印象，对该公司来说，不仅会面临金钱上的处罚，在业务运行中，会面临更多的责难和不便。

由上述阐述可见，数据完整性在数据迁移过程中有着非常重要的地位。数据完整性遭到破坏，数据迁移课题不可能顺利实施。数据完整性风险不是独立存在的，它的产生想将会引发一系列的其他风险，每一个引发的风险又会引起其他类型的 K 险，最终导致数据迁移失败，企业利益受损甚至倒闭。

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执行时长 < 5秒，异步数据处理< 60秒。

（2）服务器CPU开销< 5%。

（3）存储IO开销 < 5%。

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

4.3 课题方案实施

4.3.1 实施架构设计

根据课题要求及困难点，本次课题实施架构归纳为以下三点：

建立分区

1、根据会计日期栏位建立分区表键值。每个会计日期都建立一个分区， 同时建立最大及最小值的分区，以保存数据例外的数据。

2、每天核心系统切日后，需要检查当前会计日期及下一个会计日期的表分区是否建立，如果没有建立，则按照约定的规则建立。然后将保留期限之外的分区进项detach处理（个别表在删除分区之前需要有特殊处理）。

数据迁移
1、对需清理的表建立专用的TableSpace.。在此新的TS上建立与待清理表结构相同的临时表。数据与索引都建立在该TS上。

2、对该表建立分区。分区要覆盖保留期限内的所有数据（同时需建立兜底分区）。

3、首轮迁移考虑到数据量及业务连续性的原因，原则上分为2个阶段进行。第一阶段将可确定的在保存期内的不会修改的数据从源表中导入到目标临时表中。第二阶段将剩余的数据导入到新建的临时表中。两个阶段根据实际情况可以在一日或分多日内实现。

4、数据导入到新表后，经核查无误后，将源表rename ， 然后将临时表更名为源表并做bind操作。

5、迁移完后，可择期将源表删除，以释放存储空间。

6、部分操作需要暂停应用。

归档原则

利用生产现有的历史库当做生产库的扩展数据库（B库）。将生产日库需要清理的表的数据剥离到B库。

根据各个表的实际情况，有以下几种方式：

1、分区表方式。可以通过明确的日期进行清理的（如交易日志等），通过分区表的方式进行数据剥离。将每日detach出来的表导出，然后ftp到扩展库服务器，通过脚本导入到扩展库对应的表中。该表也采用分区表的方式建立。

2、程序清理。对于通过条件进行清理的数据，如销户超过一定期限的账户，需要通过程序进行筛选，然后再筛选出该账户附属的信息，通过程序逐笔进行剥离。将该部分的数据同时写入到扩展库对应的表中。

3、直接通过sql进行删除。删除之前将该部分数据备份成文件，ftp到扩展库服务器上，然后导入到B库中。

要实现生产库数据的剥离，需要对历史库进行相应的升级。目前该数据库分配的存储空间为1T，满足不了今后较长一段时间的数据剥离的空间需求，因此需要对该库进行扩容处理。 同时，为了防止该数据库服务器的硬件故障，需考虑双机模式。

为了减少存储空间的占用，所有建立在扩展库的表都将采用压缩方式建立；同时对有条件的表采用分区表的方式建立，这是为了方便未来的数据归档处理。

5.试点验证与效益情况

5.1 试点效果阐述

课题试点的成功实施，取得了较好的应用效果。一是存储空间大幅释放，共释放空间 3.5T ，降低硬件扩容开销；二是各类数据库表条目大幅缩减，内部户交易明细、存款明细共减少近 36 亿条；三是系统重要指标大幅提升，联机处理效率提升了 30% ，夜间批量效率提升了 50% ，夜间追账效率提升了 100% ，数据库效率提升了 50% ；四是数据清理效率大幅提升，采用分区表机制每日自动清理仅需 1 分钟；五是核心数据库备份效率大幅提升，时间缩短 8.5 小时，效率提高 30% ；六是具有极强的行业适用性和可推广性，实施方案及技术创新不依赖特定的应用系统和数据库产品，适用于全行业。

表 6 、与传统方法对比结果

5.2 效益情况展示

5.2.1 经济效益情况

图 14 、课题收益展示

1 、通过采用独创的银行海量数据在线并发迁移方法论，利用“基于完整事务性的在线式数据迁移方法”、“基于哈希算法的多进程数据迁移方法”、“常态化数据清理方法”三个原创专利技术，实现了一次性数据迁移及清理，无需后续不断投入。以较小的成本实现了传统方法需投入大量人力、时间、物力等才能完成的工作。

2 、可清理历史数据，减少存储耗费。 以湖北我行社课题为例，课题的成功实施共释放存储空间 3.5TB ，内部户交易明细表 GECT 记录数由原 21 亿条降至 1.4 亿条，最大存款明细表记录由之前的 26.7 亿条降至 12.2 亿条，提高数据库运行效率 50% 。初步测算每年节省扩容采购费用约为 600 万元，节约了新购存储设备投入和机房空间、能源等整体使用成本。

3 、自动化清理机制的建立与成功实施可为银行节省在数据管理方面的人力投入。以本课题为例，初步测算成本每年可节约维护费用 200 万。

5.2.2 社会效益情况

本课题为银行数据迁移和清理开创一种新的方法，为后续开展大数据的应用奠定了基础。经过我行从理论到实践的大胆探索，有效完成了海量数据的在线迁移和清理，应用影响小、停机窗口短，在可实践性、可推广性方面有很高的价值。本课题相关技术方法已在某行、某城商行推广并实施成功。

1 、解决了海量数据迁移中的迁移窗口长、效率低效等难题，确保银行重要信息迁移过程中的安全。本课题采用基于“完整事物性的在线数据迁移方法”的专利技术能够满足银行数据量庞大、维护窗口有限的特点。

2 、清理模式适应性强，适用于各类行业、各类技术架构。数据迁移及清理过滤要求可自主定制，算法对操作系统和数据库没有依赖，可适用于其他金融机构进行类似的数据迁移及清理工作，甚至可以应用到以后的数据灾备等其它可以借鉴的课题中。

3 、数据自动运维机制的建立，极大的降低了银行数据运维操作风险。传统数据清理多采用手工迁移方式，工作量极大且误操作概率较高。通过本课题的实践，实现了数据自动化清理，避免人工干预，大大降低了风险。

4 、通过在线数据分离技术，减少了对生产系统运行的性能压力。传统数据加工方法对生产系统造成较大的性能影响，通过本课题原创的在线数据分离技术将在线数据加工工作转化为离线加工，大大降低了数据加工对生产系统的影响，提高了数据加工效率。同时将加工后的海量数据装入数据仓库，提升大数据利用效率。

课题结论

近来，随着业务的不断拓展，业务的多样化和数据量快速增长，且呈现逐渐加快的趋势。在此背景之下，一方面数据库的各方面性能出现开始降低的趋势（数据库备份时间长、增删改查效率低下、数据库重组时间长等）；另一方面需要不断的进行存储设备扩容或新购来满足数据库增长的需求，存储设备扩容压力较大。并且随着数据量的增长，会导致系统运行效率变低的问题。

在此背景之下，本课题组于 2015 年 10 月开始启动海量数据在线迁移及自动化清理模式的创新及研究。旨在克服传统海量数据清理可行性低、风险高等困难，在不中断系统运行的前提下，在极短的窗口时间内完成海量数据的在线清理迁移，建立数据常态优化清理机制，消除数据库性能“天花板”效应，达到数据增长稳定的目标，为金融行业海量数据优化工作开创一种全新、高效的实施方法论。

本课题主要解决以下难点问题并实现了相应的技术实践突破：

1、传统数据库历史数据清理方法的创新，有效地解决了海量数据清理问题。

面对比部分全国性股份制银行还要大的海量数据困境，我行联社的数据清理工作，仅仅只用了9个月时间，历经论证、测试及实施等多个阶段，最终圆满完成了以往认为是不可能实现的任务，行业内实属少见。究其原因是我们采用了创新思路，一是依赖优良的应用架构体系，通过应用层的双写技术，将应用层的逻辑和底层数据库操作分开；二是依靠自我创新，实现哈希数据分区并行多进程插入；三是将分区表技术与自动化运维结合在一起，实现了历史数据的自动化清理。这些理论加实践的创新，助力我们取得成功的关键。

2、在线并行与自动化清理相结合，解决了一直困扰银行业内历史数据安全迁移的担心。

一直以来，银行核心历史数据的安全清理都是困扰相关从业技术人员的难题，费时费力，风险性高，且可能面临多次重复劳动的问题。在吸取以往经验教训后，本次建立了在线并行清理和常态化自动清理机制，这样一劳永逸的解决了重复性劳动给相关管理员带来的挫败感。

3、存储资源大量释放，应用性能大幅提升。

一是通过清理最大6张数据库表数据，共清理了3521GB数据空间，释放了大量存储资源，实现未来3年的发展需要；自动化定时清理，使数据的年度增长量大幅度缩减，又再节省未来1-2年的存储需要，也就是说现在在不增加存储空间的情况下，可以满足未来5年的需要。二是通过清理，大量历史数据从现有生产环境中得以剥离，使生产应用性能得到了大幅提升。

4、没有对现有系统硬件物理架构做任何调整。

所有的改动都在应用层和数据库层，没有设计新的硬件架构的变更，也不用采购新的硬件设备，成本低，性价比高。

5、具有重大的推广价值，可为友行提供借鉴参考意义。

数据常态化清理及大数据迁移是银行业内广泛面临的难题，建立一套长期有效的常态化清理机制以及切实有效的大数据迁移方法不但减轻了数据运维的压力，也大大降低了银行运维风险，在银行业内具有广泛的推广价值。