广发核心系统项目数据清理方案.docVIP

广发核心系统项目数据清理方案 广发核心系统项目 概要设计书 (数据清理) V1.0 11月 目录 TOC \o 1-3 \h \z 1 概述 3 1.1 理论背景 3 1.2 需求背景 3 1.3 功效清单 4 1.4 核心方略 4 1.5 限制/假设 5 2 术语定义 6 2.1 清理编号 6 2.2 清理类型 6 2.3 清理时间 6 2.4 保存期限 7 2.5 清理状态 8 3 数据构造 9 3.1 数据构造描述 9 3.1.1 数据清理参数表 9 4 功效描述 10 4.1 数据清理参数表维护 10 4.2 技术平台数据下载和清理 10 4.3 应用系统数据下载和清理 11 4.3.1 应用系统数据下载和清理 11 4.3.2 计算清理日组件 11 4.3.3 计算保存日组件 11 4.3.4 数据清理控制组件 12 5 附录 13 概述 理论背景 完整的数据生命周期是：应用系统的数据在生产应用系统中的在线阶段，归档阶段，销毁阶段的单一流向过程。 完整的核心银行系统数据管理流程涉及主机和开放平台，其流程涉及： 1、 主机数据下载:定时将符合条件的应用数据生成文献，下载至开放平台。 2、主机数据清理:定时将符合条件的应用数据删除。 3、主机数据归档:装载下载的数据文献至开放平台的档案管理系统。 4、归档数据销毁: 定时销毁开放平台档案管理系统中的应用数据。 本文档描述的是主机数据清理的总体方案。 需求背景 历史数据是指多个档案中带有日期项的数据，这些日期项可能是键值之一（如交易历史表），也可能不是键值（例如账户主档中的销户日期），根据这些日期和统计某些状态，就能够拟定那些数据已通过期，无需在主机中继续保存而能够被去除。 历史数据清理是保护资源，提高系统性能的重要方法之一，因此数据清理的原则在需求分析阶段就要拟定下来，但清理的时间和数据保存的期限却会随着数据量的增加和业务的发展而不停变化。 例如票据业务的需求是“对于已结清的票据统计，如果结清期限超出1年的，允许在年末统一作物理删除”。在这个需求中，数据清理的时间（年末）和数据保存的期限（1年），可能会随着业务的大幅增加而发生变化（例如改为每月末清理，保存六个月内数据），但清理的条件“已结清的票据统计”却是固定不变的。 为了减少需求变更所带来的程序修改，我们将“数据清理时间”和“数据保存期限”单独抽取出来，变成能够定义维护的参数，而清理的条件和具体要清理那些数据库表的统计则留给应用程序来完毕。 核心方略 数据清理动作统一由应用发起。应用清理程序每天都启动执行，根据解决对象(清理编号)调用数据清理日期查询组件检查当天与否需要进行数据清理；如果需要数据清理，清理日期查询组件则返回统计的最小保存日期（详见接口阐明文档），应用根据最小保存日期进行以下解决。 1、档案无需支持24小时。 应用程序扫描需要清理的档案，将符合条件的统计作删除。需要考虑全部必要的条件，涉及：统计最后修改日不大于最小保存日期；统计属于业务无效的状态；有关联的表的主从统计需要同时删除。 2、档案需要支持24小时(针对双主档)。 第一步：应用程序扫描批量档案，拟定需要删除那些档案的那些统计（日期不大于最小保存日期的统计），将这些统计的KEY值登记下来生成BSP档案（注意：这些KEY值不一定带有日期数据，例如已销户超出一定时限的活期存款的KEY值其实是存款账号）。 第二步：根据BSP档案发动BSP解决，通过KEY值真正删除联机档案中的有关统计。这时应用的BSP程序可能还需要再次检查统计的状态和日期，以免发生意外错误（例如已销户的活期存款被销户重开了）。 性能因素 1、采用程序的方式删除统计，系统会登记DB2 LOG，对于一次清理大量的数据会引发系统性能下降。因此在需求分析时，对于涉及大数据量的清理，尽量通过增加清理次数的方式来分散每次清理的数据量。 2、数据清理后普通要对数据库表进行REORG，也能够参考日常系统运行的REORG执行日期，来安排数据清理的运行实施。 术语定义 数据清理模块的核心数据构造是数据清理参数表，其包含以下要素。 清理编号 清理编号是8位的字符串，它代表了一类数据清理的规则，由应用技术人员维护。为了方便记忆，能够定义为数据库表的名称。 清理类型 对同一种清理编号之下清理规则的再次划分，是20位字符串的自由格式，由应用自己定义和使用。例如对交易历史的清理，在同一清理编号下，不同的模块账号，或者不同的产品可能有不同的清理规则。 清理时间 表达数据清理的时间规定，即在什么时间点来做数据清理，在IBS CORE中，数据清理时间由清理频率和清理周期构成：