InteDRC 泓智历史库数据管理系统 数据管理

系统概要:
1.系统建设背景
随着我国银行服务市场全面对外开放，国内各商业银行都感觉到了更大的竞争压力，纷纷推出代理保险、信托等业务，大力发展网上银行、电话银行等。各大银行采取措施应对压力，除了人们可以直接感受到的前端服务的改变外，银行还在加大科技投入，建设新一代综合业务系统、灾难备份中心等，为银行业务创新和风险控制提供支持。从国内银行业的竞争来看，现阶段追求的目标主要是构建以客户为中心的服务体系和以风险控制、盈利分析为核心的管理体系。因此，银行信息化也相应地从以账户为中心，向以客户、管理为中心转变。概括地说现阶段我国银行信息化主要有以下几个方向：

(1) 数据应用系统
大集中后的数据利用。现在很多商业银行已经实现数据的物理或逻辑集中，在数据大集中的基础上进一步利用数据，成为银行下一步信息化建设的重点之一。另外，数据仓库、数据挖掘等的应用也是未来的重点。数据大集中的初步实现，改变了银行分支机构各自为政、客户资源割裂的局面。数据大集中只是实现了分散数据的集中，还得经过数据仓库、商业智能等工具才能把原始信息变成有价值的信息。基于数据仓库的决策支持系统(DSS)能够帮助银行实现对客户的正确识别和经营风险的自动预警。通过数据挖掘技术，能够有效地控制关联企业的信贷风险，建立以客户管理为中心的信贷决策体系和成本控制体系，保证商业银行信贷资金的有效配置和信用风险的有效控制，从而体现商业智能和自动化处理的价值。

(2) 信息安全系统
保障业务连续性。数据大集中也带来了风险集中，加上网上银行、手机银行等业务的发展，信息安全势必成为银行信息化的重点。随着信息技术在银行普遍、深入的应用，信息系统的正常运行已经成为银行业务正常运营最基本的条件之一。意外灾祸、系统故障、人为操作不当、安全管理及措施的漏洞等都有可能造成信息系统不能正常工作，影响到银行业务的正常运营。信息安全越来越成为银行信息化建设与管理中需要密切关注的问题。后台支持系统，加强银行成本控制。市场全面对外开放后，我国金融企业需要发展面向未来的业务模式:混业、跨国、多渠道、增值及联合经营。新的业务模式和市场环境要求新的管理模式：管理集中、风险防范、客户至上、接轨国际和面向未来。国内银行已有较完整的前台业务处理系统，并正在进行数据整合，但尚缺乏强大的后台支持管理系统。目前国内很多银行的企业管理系统基本限于办公自动化等，没有有效的利润分析、风险控制、绩效评估和战略决策支持等功能。参照国外银行的发展，审计和绩效考核等系统也必将成为未来国内银行建设的重点之一。
在近几年来随着银行的迅速发展，网上银行业务操作已经成为一种习惯；海量的数据和频繁的数据查询，已经成为核心业务系统的一个负担，核心系统急需减负；而新建的数据仓库系统以数据挖掘为目的，从数据结构上就不能保证数据查询的需求；由此数据库设计中，正式库、工作库、历史库三库分离的思想孕育而生；一个新的为核心业务系统存放历史数据的数据库的需求迫在眉睫。我们将这个新的系统命名为银行历史库系统，简称HDS。
2. 系统设计思想

(1) 简单性

越是大的数据量，越是要求简单的架构、流程和操作，此原则是HDS建设的最重要原则也是最高原则，其他原则服从或服务于此原则。

(2) 可扩展性

随着银行已有业务的发展和新业务的开发，HDS系统需要不断的拓展数据的来源系统和数据类型，因此需要较强的可扩展性。

(3) 健壮性

考虑到HDS以服务网上银行等电子渠道为基础，应具备7×24不间断运营的能力，具有完善的容错和备份机制。

(4) 松耦合

HDS与源系统、ETL服务器、服务的应用或应用系统，应保持松耦合性。与源系统，通过ETL服务器隔离；与服务的应用或应用系统，通过WEB SERVICE层隔离。
3. 系统层次架构

架构模型采用四层框架模型，四层框架模型是指表现层、Web服务器层、应用服务器层和数据层。如下 三层框架模型

表现层：主要由Web浏览器等客户端设备支持。

应用层：主要功能是完成系统业务逻辑。

数据层：主要作用是存储数据。

从开发角度来看，三层架构适合团体协作开发，不同的人可以有不同的分工。从应用角度来看，系统具有的好的可扩展性和可维护性，同时也增加了数据库和后台应用系统的安全性。三层架构将应用层与数据层剥离，这样用户不再直接提请求给数据库，保证了数据的安全，使得权限控制更加方便。

数据存储:

HDS数据存储为银行提供历史数据的查询和保存功能，但不仅是源系统历史数据的简单堆砌。

1.支持多数据类型

HDS应具有接纳结构化和非结构化数据的能力和架构设计。

2. 支持多数据源

HDS应具有存储多系统历史数据的能力和架构设计。其中包括核心批量、贷记卡、基金等。

3. 数据存储层面

HDS数据存储层面需要考虑数据结构、数据质量、数据完整性以及为今后数据服务所提供的历史追溯提供保障。

(1) 数据结构

HDS数据存储中的表结构在维持原库表结构的基础上，可适当增加类似时间戳字段来适应HDS数据存储的要求。

(2) 数据质量

HDS的数据确保与源系统下发的数据保持一致，但不对数据的逻辑行进行校验和纠错，并不对不多数据库中的逻辑性错误负责。

(3) 数据完整性

HDS数据存储应该能够保存银行业务系统有意义的、含完整业务信息的历史数据表，在业务层面上有关系的数据表应都能够保存。

(4) 历史可追溯性

HDS以对外提供历史数据查询为基础，对数据组织应能够满足用户访问特定历史的要求，可通过某种组织数据的方式来还原客户需要的历史上任何一天的数据表内容。

4. 数据处理

能够实现从历史数据磁带备份库及交行数据汇聚平台导入历史数据进入HDS数据库的功能，且该功能可以实现自动调度运行。

5. 数据范围

HDS以对外提供历史数据查询为基础，将核心批量中所有的交易历史数据进入HDS数据库，与各查询功能相关的资料表的数据也进入HDS数据库；将涉及公务员卡查询的相关贷记卡的数据进入历史库。交易历史表至少将1年的历史数据进入HDS数据库。

数据服务:

HDS系统在实现HDS数据存储的同时也需要而且应该对外提供HDS数据服务。HDS数据服务需要包含技术和业务两个层面，技术层面主要是服务接口，业务层面主要是服务应用。 对于HDS数据服务的使用者而言，HDS服务层之下的内容是透明的，使用者仅与HDS的服务层交互。

1.接口

HDS系统需要在技术层面提供对外服务的接口，对于技术层面的接口以Web Service形式提供服务。

OLTP应用调用

数据导出

2. 服务内容及服务对象

在业务层面提供从核心业务系统到非核心业务系统应用需求的支持（前提是HDS中有支持这些需求的数据）。

核心业务系统应用

非核心业务系统应用

3. 数据可用性范围

HDS仅提供T-1日前的数据的各项服务，T日的数据，由源系统提供数据支持。

4. 数据服务范围

HDS数据服务规范由HDS数据服务实施方负责制定（如服务数据范围、服务数据量、接口格式、数据服务限制等），交行运行监测项目组审核。

5. 数据服务实现

HDS数据服务实现Web Service 需要的中间件平台由HDS数据服务实施方建议，交行HDS项目审核并选型。

6. HDQ应用服务

HDS数据服务需要满足核心系统HDQ的OLTP型应用调用需求，提供HDQ 30秒以内的服务响应及7*24小时服务能力，对于不能满足要求的应用调用以相应的错误码信息予以反馈，调用的规范符合前述的HDS数据服务规范。

7. 数据导出服务

HDS将通过Web Service形式对外提供数据导出服务功能的调用。HDS也必需直接提供Web方式的数据导出服务应用功能。

(1) 数据导出 Web Service接口

HDS数据服务需要实现以Web Service方式提供HDS数据导出的服务接口。

(2) 数据导出 服务应用

HDS系统应提供Web方式的数据导出功能：

数据导出功能仅面向系统管理人员；

系统管理人员可以对敏感字段设定屏蔽规则；

每一个敏感字段可以设定一条或者多条屏蔽规则，其中有一条是缺省规则；

屏蔽方式有：

替换成常量，例如’#####’；

替换成一个表达式。表达式可以包含同表中的其它字段，表达式的内容正确性由系统管理人员保证；

通过Web Service接口方式导出数据时将使用缺省规则进行数据屏蔽；

数据导出基本操作过程要求如下：

选定需要导出的表；

选择需要导出的字段；

如果导出的内容包含敏感字段，则需要选择各个敏感字段是否需要屏蔽以及适用的屏蔽规则；

提交数据导出请求；

异步处理数据导出过程，导出完毕后，由系统管理人员人工在预先设定的位置获取导出文件。

数据导出功能以Web方式提供。

8. 认证和权限控制

HDS对Web Service服务请求方进行认证和权限控制。

数据服务 Web Service ：

Web Service是HDS实现数据服务的主要载体，实现两种Web Service，分别实现HDQ服务，和大数据量导出服务，未来基于HDS数据服务的增加，另行提交Web Service的需求。

权限控制:

HDS作为银行历史数据存储和服务的平台，为更好的履行其被赋予的职责，合理有效的权限控制也是关键的因素。

HDS需要通过ETL服务器访问数据源（数据汇聚平台）实现其历史数据存储功能，通过WEB SERVICE与服务的应用或应用系统进行一定的交互实现其历史数据服务的功能，HDS自身需要进行相应的管理和配置工作。以上这三个环节构成了HDS的权限控制框架，HDS的权限控制需要在HDS建设原则内进行。

1.HDS ETL服务器 数据源

在这个环节中，需要包括如下的权限控制点：

HDS以只读权限从数据源获取数据，只读权限由数据源的DBA授权给ETL服务器访问加以控制，交行HDS项目审核。

ETL服务器能够将从数据源获取的数据写入HDS，写相关的操作由HDS的DBA授权给ETL服务器，交行HDS项目审核。

ETL服务器在此环节中如需要相应的操作系统权限，由涉及的操作系统管理员负责授权，交行HDS项目审核。

2. HDS Web Service 应用（系统）

在这个环节中，HDS对Web Service服务请求方进行认证和权限控制，需要包括如下的权限控制点：

基于Web Service的访问，限定在应用级用户，除HDS自带的系统级用户，不面向其他的个体用户。

应建立用户、用户组、角色、功能的体系，用户、用户组、角色、功能为多对多的关系。

认证初始阶段可采用简单认证方式，未来需迁移到 统一认证平台 进行统一认证。

对应用级用户（组）的权限应可以限制到HDS中的系统、库表、查询的时间范围等，库表字段级的限制，可留待未来实施。

3. HDS 自身配置管理

HDS仅提供T-1日前的数据的各项服务，T日的数据，由源系统提供数据支持。

4. 数据服务范围

在这个环节中，需要包括如下的权限控制点：

HDS配置管理所需要的数据库权限，由HDS的DBA负责，交行HDS项目审核。

HDS配置管理所需要的Application/Web Server权限，由HDS数据服务实施方负责，交行HDS项目审核。

HDS配置管理所需要的ETL服务器权限，由ETL服务器管理员负责，交行HDS项目审核。

HDS配置管理所需要的操作系统权限，由涉及的操作系统管理员负责，交行HDS项目审核。

HDS自身配置管理所需的角色、角色组、功能、功能分配的设计。

数据备份 ：

HDS数据是银行主要的数据基础设施架构的核心组成部分，因此对数据提供持续保护将成为系统运行的重要保障。 HDS数据备份需要提供两个方面的功能：数据存储安全和数据持久可用。

1. 数据存储安全

交行HDS数据存储将保留TB级海量的数据（仅核心部分如果考虑持续10年的HDS数据将达到30TB左右），因此数据一旦发生损坏，其代价将相当高昂。

2. 数据持久可用

HDS数据服务要求数据库提供7*24的服务，进行数据常规在线备份的操作将大大降低系统的性能；另外一旦发生数据损坏，无论何种备份恢复方案将不可能在短时间内完成整个数据库的恢复。因此通过较低成本的数据容错和快速的恢复数据库的机制来解决数据安全性和数据可用性之间的矛盾。