大数据迁移实践之路.pdf

⼤数据迁移实践之路 ⼤数据迁移实践之路 随着业务的迅速发展，农业银⾏某系统承担的运⾏压⼒越来越⼤。现阶段， 该系统每天的交易量在2300 万笔以上，峰值达2950 万笔。交易 量的攀升导致了后台数据库数据量的激增，从⽽影响了联机程序响应时间，也增加了系统各类资源开销和后续数据分析的处理时间。为保障 系统稳定运⾏，项⽬组从增加系统资源、优化资源配置、优化重点程序和升级系统数据库等多个维度对系统进⾏了综合优化。下⾯笔者从⼤ 表、热表的数据分析和优化⾓度，阐述对⼤数据量表进⾏的存储优化。 　　⼀、⼤表数据分析 　　⽬前农业银⾏某系统⼯作流数据量最⼤且访问最频繁的两张核⼼表： 　　(1)流程实例表，⽤于存储系统发起的所有流程实例，包括基本流程、会签流程、补充资料流程和抄送流程; 　　(2)任务实例表，⽤于存储每个流程实例的流转记录。 　　截⾄2013 年4 ⽉1 ⽇， ⼯作流两张⼤表的数据量如表1 所⽰。其中任务实例表为系统中数据量最⼤的⼀张表，达到了1.2 亿。根据 ProDBA 抓取的执⾏次数最多且执⾏时间最长的前30 条SQL 信息中，显⽰流程实例表和任务实例表压⼒⽐较⼤。⼤表中的数据按照结束时 间和状态两个维度可以区分为三类： 　　(1)正在运⾏的流程数据，即业务正在办理过程中，尚未结束; 　　(2)已结束流程⼀年内的数据，即业务总体流程已经结束，期限在⼀年内(包含⼀年); 　　(3)已经结束流程⼀年以上的数据，即业务总体流程已经结束，期限在⼀年以上(如表2 所⽰)。事实上，由于存在业务制度等⽅⾯的规 定，已经结束⼀年以上的数据基本处于静态⽆变化的情况，不会发⽣修改、删除等数据操作，但是占据了⼀定的表空间，同时也影响了对其 他运⾏中数据的访问效率。为降低⼤数据量对系统访问的影响，需制定迁移规则，进⾏数据拆分。 　　⼆、拆分规则 　　根据上述⼤数据表的数据分布特点，建⽴三套表结构：运⾏表、历史表和备份表。运⾏表仅存储正在运⾏的流程数据，流程结束后(正 常完成或者终⽌)将基本流程以及其所属⼦流程相关的所有数据(流程实例、任务实例、流程变量、异常、分⽀等)实时迁移⾄历史表。如业务 需要将已结束的流程恢复，系统⽀持流程从历史表实时迁回到运⾏表继续流转，整个过程对⽤户是完全透明的。 　　由于已完成和终⽌⼀年以上的流程，需恢复的业务需求很少(系统上线以来未发⽣过类似业务)，因此由备份表存放第三类数据，形成三 级存储模式如图1 所⽰。历史表中的数据，每年执⾏⼀次批量拆分操作，拆分⾄备份表。 　　为保障数据平稳的迁移，应采取分布实施的策略。2012 年12 ⽉8⽇，流程结束数据实时迁移到历史表功能先期投产，因此⽬前⼯作流 运⾏表中存放的数据包含三种情况：正在运⾏的数据;2012 年5 ⽉⾄2012 年12 ⽉结束的流程;2012 年5 ⽉前结束⼀年以上的流程(如图2所 ⽰)。 　　按照数据三级存储规则，需要对⼤数据表进⾏拆分、剥离及整合，最终实现运⾏表只存储运⾏的数据，降低系统压⼒(如图3 所⽰)。 　　三、问题分析及拆分策略 　　1. 数据表重命名 　　数据迁移前需要对流程实例表和任务表进⾏BCP 数据备份，以确保出现异常情况时，可及时恢复数据。任务实例表(1.2 亿)和流程实例 表(2 千万)，备份估计需要2~3个⼩时。数据迁移最终要达到运⾏表中仅存放流程正在运⾏中的数据，因此采取如下策略，节省BCP 备份时 间。 　　⾸先，创建任务实例和流程实例中间表，表结构和运⾏表保持完全⼀致;其次，将运⾏表中正在运⾏的数据迁移⾄中间表;再次，对流程 运⾏表和中间表重命名，实现中间表转换为运⾏表，运⾏表转换为备份表。如出现数据迁移异常和验证不通过等情况，由于备份表保存了迁 移当⽇的全量数据，因此，再次执⾏数据表重命名即可解决问题，⽆需再对两张⼤表进⾏BCP 备份。数据表重命名脚本执⾏时间，经测试 在1 分钟内即可完成，⼤⼤减少迁移时间。 　　2. 数据完整性 　　⼀笔完整的流程，包含⼀条流程实例和多条任务实例，任务实例根据流程实例编号和状态等属性，确定所属流程。迁移⽅法⼀：为保障 迁移数据完整，需要根据流程的状态，查询流程和关联任务的记录，⼀次性迁移两张表的记录，如迁移失败同时回滚，因此，需要进⾏任务 实例表和流程实例表关联。考虑到两张表的数据量，此⽅案将会导致迁移效率很低。经测试，迁移5万笔流程(5 万条流程和36 万条任务记 录) 数据约7分钟，循环执⾏迁移，迁移完全部流程数据需要约42 个⼩时。 　　为提⾼拆分效率，减少对投产时间窗⼝的占⽤，对拆分⽅法进⾏了优化。迁移⽅法⼆：⾸先，流程实例表按照I D 号升序排列，取前50 万条记录存放⾄临时表;其次，将临时表(50 万)和任务表(1.2 亿)进⾏关联，迁移流程所属的所有任务;再次，再迁移50