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

广发核心系统项目概要设计书

(数据清理)

V1.0

2013年11月

目录

1概述 (3)

1.1 理论背景 (3)

1.2 需求背景 (3)

1.3 功能清单............................................. 错误！未定义书签。

1.4 关键策略 (4)

1.5 限制/假设............................................ 错误！未定义书签。2术语定义................................................ 错误！未定义书签。

2.1 清理编号 (5)

2.2 清理类型 (5)

2.3 清理时间 (5)

2.4 保留期限 (6)

2.5 清理状态 (7)

3数据结构 (8)

3.1 数据结构描述 (8)

3.1.1 数据清理参数表 (8)

4功能描述 (9)

4.1 数据清理参数表维护 (9)

4.2 技术平台数据下载和清理............................... 错误！未定义书签。

4.3 应用系统数据下载和清理 (9)

4.3.1 应用系统数据下载和清理.......................... 错误！未定义书签。

4.3.2 计算清理日组件 (9)

4.3.3 计算保留日组件 (10)

4.3.4 数据清理控制组件 (10)

5附录 (10)

1概述

1.1理论背景

完整的数据生命周期是：应用系统的数据在生产应用系统中的在线阶段，归档阶段，销毁阶段的单一流向过程。

完整的核心银行系统数据管理流程涉及主机和开放平台，其流程包括：

1、主机数据下载:定期将符合条件的应用数据生成文件，下载至开放平台。

2、主机数据清理:定期将符合条件的应用数据删除。

3、主机数据归档:装载下载的数据文件至开放平台的档案管理系统。

4、归档数据销毁: 定期销毁开放平台档案管理系统中的应用数据。

本文档描述的是主机数据清理的总体方案。

1.2需求背景

历史数据是指各种档案中带有日期项的数据，这些日期项可能是键值之一（如交易历史表），也可能不是键值（例如账户主档中的销户日期），根据这些日期和记录某些状态，就能够确定那些数据已经过期，无需在主机中继续保留而可以被清除。

历史数据清理是保护资源，提高系统性能的重要措施之一，因此数据清理的标准在需求分析阶段就要确定下来，但清理的时间和数据保留的期限却会随着数据量的增长和业务的发展而不断变化。

比如票据业务的需求是“对于已结清的票据记录，如果结清期限超过1年的，允许在年末统一作物理删除”。在这个需求中，数据清理的时间（年末）和数据保留的期限（1年），可能会随着业务的大幅增长而发生改变（例如改为每月末清理，保留半年内数据），但清理的条件“已结清的票据记录”却是固定不变的。

为了降低需求变更所带来的程序修改，我们将“数据清理时间”和“数据保留期限”单独抽取出来，变成可以定义维护的参数，而清理的条件和具体要清理那些数据库表的记录则留给应用程序来完成。

1.3关键策略

数据清理动作统一由应用发起。应用清理程序每天都启动执行，根据处理对象(清理编号)调用数据清理日期查询组件检查当天是否需要进行数据清理；如果需要数据清理，清理日期查询组件则返回记录的最小保留日期（详见接口说明文档），应用根据最小保留日期进行如下处理。

1、档案无需支持24小时。

应用程序扫描需要清理的档案，将符合条件的记录作删除。需要考虑所有必要的条件，包括：记录最后修改日小于最小保留日期；记录属于业务无效的状态；有关联的表的主从记录需要同步删除。

2、档案需要支持24小时(针对双主档)。

第一步：应用程序扫描批量档案，确定需要删除那些档案的那些记录（日期小于最小保留日期的记录），将这些记录的KEY值登记下来生成BSP档案（注意：这些KEY值不一定带有日期数据，例如已销户超过一定期限的活期存款的KEY 值其实是存款账号）。

第二步：根据BSP档案发动BSP处理，通过KEY值真正删除联机档案中的相关记录。这时应用的BSP程序可能还需要再次检查记录的状态和日期，以免发生意外错误（例如已销户的活期存款被销户重开了）。

1.4性能因素

1、采用程序的方式删除记录，系统会登记DB2 LOG，对于一次清理大量的数据会引起系统性能下降。因此在需求分析时，对于涉及大数据量的清理，尽量通过增加清理次数的方式来分散每次清理的数据量。

2、数据清理后一般要对数据库表进行REORG，也可以参照日常系统运行的REORG执行日期，来安排数据清理的运行实施。

2术语定义

数据清理模块的核心数据结构是数据清理参数表，其包含如下要素。

2.1清理编号

清理编号是8位的字符串，它代表了一类数据清理的规则，由应用技术人员维护。为了方便记忆，可以定义为数据库表的名称。

2.2清理类型

对同一个清理编号之下清理规则的再次划分，是20位字符串的自由格式，由应用自己定义和使用。比如对交易历史的清理，在同一清理编号下，不同的模块账号，或者不同的产品可能有不同的清理规则。

2.3清理时间

表示数据清理的时间要求，即在什么时间点来做数据清理，在IBS CORE中，数据清理时间由清理频率和清理周期组成：

清理的启动需要按批量的假期表进行计算，当出现假期跨一个清理周期的时候，仍然以当天的批量处理时间为准。例如定义每天清理一次，每次保留5天以内的数据，且假设国庆节7天都为假期不跑批量，那么在9月30日执行清理的时候，只是清理9月26日前的数据，10月8日上班的第一天仍然可以查询到9月26~30日的数据，而不仅仅是10月3~7日的数据。但在10月8日执行数据清理时，会删除10月4日前的所有数据。

如果遇到清理日是假期而没有运行批量时，系统需要在下一个批量日执行数据清理。

2.4 保留期限

代表数据保留的时间长短要求，在

IBS CORE 中，数据保留时间由保留频率和保留周期组成：

数据保留期限是相对于清理时间而言的，为了不要在月末等特殊日期执行数据清理，清理的时间可能会改在其它日期执行，为避免因此而造成的将一个业务周期的数据拆分成两段的情况，系统提供一个“是否允许按月拆分”的选项，当该选项为“不允许”时，表示数据必须按月为周期进行保留。

例如每个月的3日启动数据清理，要求保留一个月的数据，那么在5月3日清理时，如果是“不允许”按月拆分，系统会保留4月1日~5月3日的数据，如果是“允许”按月拆分，系统就只保留4月4日~5月3日的数据。

系统控制按日保留时，“是否允许按月拆分”选项是不可选的，且必须为“允许”。

清理时间和保留期限之间的参数配置可能会出现不作清理的情况，需要在详细设计时考虑。例如选择按日清理，又要保留一个完整月的数据，那么每月2日以后的清理动作将会是多余的。

2.5清理状态

为了简化和方便参数维护，为每条记录建立清理状态：Y或N。Y-表示清理记录有效；N-表示清理记录无效。

系统不提供参数的删除交易，而是由参数维护人员通过修改删除状态为“N”来实现，这样当希望暂时不作数据清理时，只需要修改清理状态即可。

3数据结构

3.1数据结构描述

3.1.1数据清理参数表

●描述：用于定义数据清理时间、保留期限及其他相关要素。

●表COLUMN描述：

●KEY，INDEX描述：

4功能描述

4.1参数表维护

●功能：对数据清理参数表记录做增加、修改、查询、浏览。系统限定增加、修

改交易只能由总行柜员执行，查询和浏览交易则不作限定。

●输入：参数表中定义的各数据项。

●输出：交易成功画面

●处理：

只允许总行级柜员使用；

增加、修改时更新参数档案（使用统一的参数表）；

增加、修改时登记历史档案，并作改前改后的明细登记；

4.2模块组件

4.2.1清理操作查询组件

●功能：根据会计日期、清理编号等输入，计算当天是否清理日，以及清理的保

留日期；与输入数据相匹配，参数表中指示当日需要进行清理的参数记录可能有多笔，对应输出描述中的数组；绝大多数应用程序调用此组件即可。

●输入：

●输出：

4.2.2计算清理日期组件

●功能：判断当天是否需要进行数据的清理。

●输入：

●输出：

4.2.3计算保留日期组件

●功能：返回最小的保留日期。

●输入：

●输出：

5应用规则

1、并发规则：根据被清理应用表的分PART情况和数据量，确定清理作业是并发方式或非并发方式。如果是对分PART的数据量较大的表，宜采用分PART 方式。

2、关联规则：相关联的应用表的数据清理，在性能允许的情况下，可考虑在相同批量程序作清理，以保证应用数据的一致性，如在同个程序，可以对账户表的待清理记录以及账户在协议表的关联记录穿行进行删除动作。

3、分步规则：判断逻辑简单(如只需判断清理参数的相关字段)的表，用单个程序执行删除动作即可。对判断逻辑复杂，或出于性能因素等原因，可以采用多步骤多程序的方式作清理。如分成如下两步：依照检查逻辑将符合条件的清理记录键值生成文件，根据文件作清理动作。

4、参数规则：根据预估的数据量，结合业务需求，规划应用表的保留期限和清理周期。

5、运行规则：清理作业安排在日终批量完成后运行，清理作业完成后对数据库表进行重组。

6附录

IBS-CORE

平台详细设计书(数据清