数据平台系统项目-技术方案

数据平台系统项目-技术方案

LT

数据平台项目

数据平台系统投标书——技术部分

目录

第1页

数据平台系统投标书——技术投标书

3.3.1数据架构设计................32

3.3.2数据模型设计................38

3.3.3灵活查询功能架构............51

3.3.4数据备份与恢复..............52

3.4数据平台应用体系.................56

3.4.1统一报表平台................56

3.4.2数据图表化展示.............127

3.5数据平台设计关键点..............138

3.5.1数据平台性能保障...........138

3.5.2时间窗口...................154

3.5.3备份策略...................155

3.5.4数据模型的历史数据存储....157

3.5.5源系统变更影响分析.........160

第4章软件及推荐硬件设备配置方案.....162

4.1系统软件方案.....................162

4.1.1统一报表平台...............163

北京宇信易诚科技有限公司II

数据平台系统投标书——技术部分

第1章方案总述

1.1前言

我们衷心感谢贵行给予我们这样一个很好的

机会，可以为贵行的数据平台建设提供技术解决

方案和项目实施方案的建议书，并通过我们的方

案建议书为及其应用系统的建设提供帮助。

我们期盼与贵行共同努力，以我们在兄弟分行

和其他银行实施同类项目的经验以及我们使您

的愿景变成现实的能力，为贵行IT建设增添一

个新的里程碑，也为我们与贵行的真诚合作启动

一个良好的开端。

该项目除了可以用宇信易诚所具有的经验和

技术为贵行提供帮助外，我们认为这也是一个与

贵行建立长期战略合作关系的宝贵机会。我们为

这个目标所做出的努力正反映了这一点，我们愿

意建立一个灵活的商务策略，和服务质量有竞争

力的专家团队来满足贵行的需要。

1.2项目背景

随着贵行业务的快速发展，信息系统不断增

多，业务数据量的规模也在急速膨胀。分行数据

整合平台作为贵行的数据整合中心，需紧密衔接

第1页

数据平台系统投标书——技术部分

总行ODS、数据仓库及分行特色系统、并且

需考虑到贵行未来将要建设的系统的接入问题。

根据贵行业务的拓展和条线管理的需要，各业务

部门对决策信息依赖程度不断提高，经常会有一

些高灵活性、多变性、高及时性的信息需求。贵

行目前需要能够满足业务需求快速响应的统一

数据平台，仅依靠传统的数据加工模式对源数据

进行抽取加工操作，由于业务口径的不一致性、

数据质量低下、以及缺乏良好的数据统计分析手

段等问题导致分行范围的决策分析成为难题，不

能充分发挥业务积累的相关数据的作用数据的

及时性和准确性难以保证，给管理和营销增加了

难度。

本次数据报表平台项目承担了分行主要业务

数据的集中和整合及报表应用展示的功能。通过

数据平台的建设，将为零售、公司、同业、绩效、

人力资源、运营等业务提供统一准确的数据支

持，是贵行业务精细化管理能力的重要基础类系

统。数据平台从中远期角度来看，将成为贵行

管理层/经营层洞察经营全貌、优化经营管控水

平、推进战略决策效能、支撑综合运营分析的数

据分析平台。通过数据的集中化、标准化管理，

第1页

数据平台系统投标书——技术部分

实现分行数据的信息共享，构建实现企业数据平

台及相关的管理决策分析应用。

1.1项目目标

贵行数据平台建设项目是搭建一个对接总

行ODS、数据仓库、衔接分行特色业务的数据

平台。从底层的数据平台、DW到上层的BI（商

业智能）展现，数据平台在各交易系统之间、交

易系统和报表分析系统之间实现数据交换，通过

数据的加工、整合实现报表统计和分析。建立基

础数据模型、ETL平台、ETL管理调度平台、

确保数据采集完整、保证ETL数据质量、形成

统一的数据展现。具体目标为：

1、构建统一的、层次合理的、灵活的企业级

数据模型，整合各业务系统数据，形成分行统一

的数据视图，建设成为贵行系统应用的基础数据

平台。

2、建设统一数据应用平台，在实现基础数据

平台的基础上实现统一报表平台，为贵行业务分

析和经验决策提供全面的支持。

1.2项目建设原则

本次项目建设遵循的技术原则如下：

第2页

数据平台系统投标书——技术部分

数据平台的正确建立和合理利用将直接影响

到贵行的未来信息化发展，贵行数据平台建设应

参考以下架构原则，指导和规范未来的数据平台

信息化建设和管理，在项目方案中应该能够体现

以下原则：

1.数据集中原则：

将总行ODS、数据仓库数据、分行特色数据

和应用统一进行管理和运维，保证资源的高度利

用以及通过相关的技术保证数据和应用的绝对

安全和稳定。

2.数据标准分行统一原则：

依据总行的数据字典，减少数据定义的二义

性。未来分行特色应用系统的数据结构是分行数

据结构模型的子集。对分行级数据实行单点维

护，确保分行级数据的可靠性和一致性。

3.数据管理分行统一原则：

统一的存储管理，统一规划使用存储资源，提

高存储资源使用效率。统一的性能管理，根据实

际业务需求，合理分配资源，确保对数据的访问

性能能够满足业务的需要。统一标准的安全管

理，提高数据访问控制能力，降低关键业务数据

的安全隐患。

第3页

数据平台系统投标书——技术部分

4.降低数据冗余和数据复制原则：

减低分行级数据的冗余度，降低数据对存储资

源的需求。各业务系统根据自身业务处理实际需

求，确定对属于其它系统数据的同步需求，制订

出相应的数据复制同步策略并统一进行实施。

第2章系统建设规划

2.1项目建设目标的理解

数据平台的建设对于贵行是一个非常重要的

系统工程，承担着贵行企业数据整合、数据交换

以及数据服务的重任，通过数据平台的建设使得

贵行将自身信息资产切实、有效的管理起来，形

成企业统一信息视图，搭建企业数据治理的框

架，并为统一报表系统提供有效的数据支撑。

2.1.1项目建设范围

贵行数据平台本期项目建设范围，可以从涉

及到的业务范围、涵盖到的组织范围以及数据平

台需要接入的源系统范围三个角度来分析。

2.1.1.1业务范围

本项目的业务范围以贵行零售、公司业务条

线为主，计财、绩效、运营等为辅。

2.1.1.2组织范围

第4页

数据平台系统投标书——技术部分

本项目业务涵盖的组织范围为贵行及辖内

二级分行、支行。

2.1.1.3数据范围

本项目的源系统范围包括目前贵行的主要

业务系统，并需要满足本期数据平台主题应用的

数据需求。

2.1.2项目建设内容

2.1.2.1基础数据平台

基础数据平台技术架构搭建

从总体上规划企业级的基础数据平台，平台

将包含历史数据存储、基础数据平台、统一报表

平台、自动调度监控等内容组成，数据平台要采

用统一的数据标准规范；

基础数据平台ETL监控、调度功能，完成从

原数据仓库数据移植到新数据平台的工作。

ETL子系统实现将各业务系统的数据抽取

至数据平台，并进行数据的清洗、转化、加载等

操作，形成数据分析、决策所需的各种汇总数据

模型、分析模型，最终形成各种报表、查询以及

KPI指标。ETL子系统实现自动化的数据抽取、

数据加载、数据转化、数据卸载、自动化数据重

新加载、加载错误自动处理、脏数据识别等功能。

第5页

数据平台系统投标书——技术部分

基础数据平台数据补录功能

提供数据补录平台功能，包括补录流程

管理、补录模版管理、单笔补录、批量补录等。

通过补录平台实现数据平台无法自动获取的具

备分析价值的数据。

本期基础数据平台数据标准涵盖以下工作

内容：

接口标准：规范数据平台加载数据接口、卸

出数据格式及校验标准

公共代码标准：参考总行ODS与数据仓库标

准与分行特色数据标准；

数据质量管控

数据质量管控是一个长期的过程，依托于数

据管控组织机构、流程的建立和完善。数据平台

一期进行数据质量管控体系的初步探索，主要完

成如下目标：

(1)、建立初步的数据质量管理检查规则，

包括功能性和非功能性规则。功能性规则主要包

括：完整性、唯一性、合法性、准确性等；非功

能性主要包括信息的完整性、一致性、业务稽核

等；

第6页

数据平台系统投标书——技术部分

（2）、根据建立的初步检查规则，进行数据

质量的监测，出具初步的数据质量检查报告；

（3）、根据数据质量检查报告，提出数据质

量提升的解决方案。

2.1.2.2分行级指标体系

借鉴与参考总行统一报表指标体系成果，在

此基础上建立满足分行口径指标体系，扩展分行

指标；满足业务日常固定报表使用的同时提供多

样化的报表展现界面，包括表格展现，各类图形

展现；要求界面友好，易用性强，并能够提供具

性化应用风格支持。

2.1.2.3统一报表平台

构建统一报表平台，实现分行业务应用报表

的集中化管理、一体化服务；具有报表定制、管

理、维护功能；构建分行用户及权限管理体系，

支撑分行业务用户报表应用需求。能够快速响应

各级业务应用人员的报表需求，满足报表批量分

类存档的需要。

2.2分行数据平台的建设目标

2.2.1分行数据平台一期建设目标

基于对贵行系统现状的了解,贵行数据平台一

期的建设目标是:

第7页

数据平台系统投标书——技术部分

1、构建统一的、层次合理的、灵活的企业级

数据模型，整合各业务系统数据，形成分行统一

的数据视图，建设成为贵行数据集中管理和应用

的基础数据平台。

2、建设统一数据应用平台，在实现基础数据

平台的基础上实现统一报表平台，为贵行业务

分析和经验决策提供全面的支持。

3、集成现有对公、零售主要系统业务固定报

表，支撑业务数据使用需求。

4、指标数据按照图表样式进行区间查询展示

数据趋向，波动。

5、将分行原指标体系按照新指标体系进行平

移；

2.2.2分行数据平台二期建设目标

鉴于一期建设主要是搭建主体平台，二期的信

息化建设目标是继续完善平台，丰富平台应用效

果,全面覆盖现有旧综合平台，将重要数据迁移。

具体目标如下：

二期项目中可以集成计财、运营、人力资源等

系统报表;

支持数据图表展示、SQL查询等个性化查询需

求;

第8页

数据平台系统投标书——技术部分

将更多的管理应用系统的数据源迁移至数据

平台；

建立并推广一套完整的需求与技术落地标准

与体系。

可以预见，随着数据平台的不断成熟，业务部

门对数据平台的认知不断提高，会有源源不断的

需求基于数据平台提出，这种变化将使得数据平

台由前期技术部门“推”转变为业务部门的“拉”,

让业务需求作为数据平台持续良好发展的源动

力。

第3章整体设计方案

3.1系统设计方法论

3.1.1方法论

数据平台的项目是一个长期的循序渐进的

过程，也是一个不断创新、修复、完善的过程，

其伴随着应用系统的发展而发展。根据贵行的业

务特点以及企业系统建设的现状和未来发展蓝

图，致力打造一个可扩展的、高可用性的、安全

的、高效的、跨部门的可以快速处理海量数据的

数据平台。

在贵行数据平台建设方面依据可重用性、安

全性、高可用性、可管理性、可扩展性、高性能

第9页

数据平台系统投标书——技术部分

的设计原则采取总体规划，分层实现的方式。纵

向层面自上而下看，贵行数据平台的架构由逻辑

(应用)架构、数据架构、技术架构和物理架构

四个层次组成，每个层次内部又根据设计需要进

行抽象分层，从而形成立体的贵行数据平台项目

架构方法。

逻辑(应用)架构是贵行数据平台项目承载

的应用体系，它描述了贵行数据平台项目所要实

现的应用需求，以及支撑这些应用需求所必须的

公共模块，如调度、监控和元数据管理等工具组

件。

数据架构承载了支撑应用架构所必须的业务

实体关系的分布，它通过数据模型的方式进行组

织，主要分为缓冲数据层(ODS)、基础数据层

(FDM)、加工汇总层(ADM)和数据集市层(MDM)

等四个层次。

技术架构是用于支撑贵行数据平台的数据分

布和流动的技术框架，用到的技术有数据库技

术、数据平台技术、ETL技术、多维计算技术、

数据展现技术等。

作为最底层的物理架构，是对贵行数据平台

物理设备和网络的合理规划部署，它通过有效地

第10页

数据平台系统投标书——技术部分

利用硬件和网络，并能够添加硬件设备进行扩展

为上层架构（技术架构、数据架构、逻辑架构）

提供支撑能力。

贵行数据平台架构方法立体视图

3.1.2设计原则

根据贵行数据平台提出的系统建议的总体原

则，总结我们在多家金融机构建设数据平台经

验，贵行数据平台的设计原则体现如下原则：标

准规范，可扩展，开放，前瞻，高性能，稳定，

安全，易维护，实用，可管理，高可用，可重用。

第11页

数据平台系统投标书——技术部分

系统设计原则

3.1.2.1标准规范

建立标准的ETL开发流程，制定符合贵行数

据平台的代码标准化统一规范，设计应对有高效

数据处理要求及日常低能耗操作的兼容性数据

模型，建设符合贵行数据平台远景目标利益的技

术管理体系。

1.数据模型：制定表名、字段名命名

规范标准。设计基础标准模型及基于基础数

据模型之上的未来建设的应用系统的模型

标准。建立数据质量管理机制，提高贵行数

据平台的数据质量,也是数据平台迈向标准

第12页

数据平台系统投标书——技术部分

化规范化管理的重要环节。

2.ETL处理：将ETL处理程序分类化，

整理规范出各种ETL处理策略。确保ETL

开发人员所开发的ETL程序遵循中信总行

的规范。

3.ETL管理：建设ETL管理平台，将其

纳入贵行的ETL管理体系，形成有贵行特色

的ETL管理制度。

3.1.2.2开放性

系统建设遵循开放原则,适应未来业务和技术

发展，与现有系统进行有序的数据交互。

1.数据模型：数据模型的设计尽量接

口化，关系与抽象并存。应对新出现的业务

种类，同时能够兼容与现有系统进行数据交

互，完成输入与输出系统的角色。

2.ETL处理：ETL程序处理逻辑规则模

块化，应对日益更新的技术发展及业务变

更。

3.相关产品：项目开发过程中使用的

宇信易诚工具类产品可以提供客户相关开

发源码进行二次开发。

第13页

数据平台系统投标书——技术部分

4.后续开发：项目组再实施过程中，

会对客户方科技人员进行相关的技术培训L

使科技人员能够独立的进行ETL程序的开

发、报表开发、数据分发的设置、数据源配

曾笺笺

旦守守

3.1.2.3可扩展性

可扩展性是指数据平台能够支持贵行业务系

统和应用系统发展的需要。在本项目中，具体要

从以下几个方面考虑系统的可扩展性：

1.数据模型：设计基础数据层和数据

预处理层模型时应充分考虑，除了能够容纳

现有源系统的结构设计,还应该尽可能满足

即将要上线的业务系统数据模型，同时还需

要制定一套合理的模型设计规范，使得新上

线的业务系统数据模型能很方便地扩展到

数据平台。

2.ETL处理：需要考虑两个方面的扩展

性,增加新的ETL任务处理以及原有任务所

处理的数据规模加大，ETL处理架构必须能

适应新的变化，需要考虑通过集群的方式来

扩展。

第14页

数据平台系统投标书——技术部分

3.数据交换平台：在设计时应考虑，

随着分发数据规模的扩大和推送节点的增

多，对交换处理和传输处理的性能要求会越

来越高，必须支持集群的方式进行扩展。此

外，数据交换平台还必须提供二次开发接

口，支持SOA服务模式，可以进行应用级的

扩展。

4.服务器：平台中的每一种服务器都

使用集群扩展模式,可以通过对服务器数量

的增加获得更好的数据处理和查询能力。

3.1.2.4高性能

高性能是指在硬件资源有限的情况下,数据平

台应尽可能的支持尽量多的数据服务需求，还能

承受用户峰值时间段压力，使得数据平台能够满

足分行范围内的使用者。在本项目中，高性能的

设计主要体现在以下几个方面：

1.ETL处理：在进行ETL设计时，需要

考虑大数据量条件下的处理效率,确保在规

定的时间窗口内完成ETL处理,特别是一些

特殊日期的ETL处理,例如结息日、月底等。

2.数据交换平台：需要考虑在大数据

第15页

数据平台系统投标书——技术部分

量条件下的文件传输效率,主要也是体现在

一些特殊日期条件下的文件传输，以及特殊

情况下的全量文件传输。

3.数据库设计：对一些海量数据表或

频繁访问的数据表,在数据库设计的时候需

要从数据库设计的角度考虑性能优化机制。

3.1.2.5可管理性

这里所说的可管理性主要是指系统运维的可

管理性。比如：在实际运行过程中，系统能很方

便地对系统的运行状态进行监控，查看数据质量

情况；出现系统异常时，能及时收到消息通知，

并有一套完善的流程来处理数据或系统方面的

异常等等。在本项目中，可管理性的设计具体表

现在以下几个方面：

1.ETL处理：在ETL的总体设计时，确

保系统可以监控全过程的运行状态，并能对

异常情况及时提醒,保存完整的处理日志信

息，并设计相应的错误处理流程。另外，还

需要考虑ETL任务配置的直观图形化。

2.数据管控：在总体设计时，应充分

考虑数据的复杂性，必须能做到多而不乱，

第16页

数据平台系统投标书——技术部分

能够清楚了解系统每一个应用的转换逻辑

和数据含义，在任何环节有变动时，能迅速

的反馈变动产生的影响。

3.数据交换平台：在总体设计时，需

要充分考虑数据交换任务易于配置，传输结

果易于监控。

3.1.2.6高可用性

高可用性是指系统在一些特殊情况发生时,依

靠架构的有效设计，仍然能保证正常运行。在本

项目中，高可用性的设计主要体现在以下几个方

面：

1.数据模型的可用性：模型的设计应

能屏蔽证券业务源系统结构的变化对数据

平台集成平台和将在其上建设的分析应用

系统带来影响O局部数据模型的扩展不会对

其它数据模型产生大的影响。

2.ETL处理的可用性：应充分考虑各源

系统的时间窗口可能存在不一致的情况,避

免出现一个系统的数据时间窗口没有满足

条件，影响到其它所有系统的ETL处理。

3.系统备份：当正在运行的系统出现

第17页

数据平台系统投标书——技术部分

异常时，系统应具备相应的备份恢复机制，

确保系统能及时恢复处理。

4.各个功能模块设计时应考虑自己的

运行管理流程。

3.1.2.7安全性

在本项目中，安全性主要包括两个层面的含

义：一是防止数据服务体系的数据资源被恶意修

改和盗取；二是防止数据在传输过程中被截留和

篡改。在本项目中，安全性的设计具体体现在以

下方面：

1.对于第一个层面的安全性，主要依

赖于各应用系统对用户角色和功能权限的

控制。因此，在编写基于数据服务体系的应

用系统设计开发规范时,应明确要求应用系

统必须充分考虑安全性的设计。若贵行建设

有面向管理系统的统一用户认证平台（UA）,

可以考虑通过UA来管理用户权限。

对于数据范围方面的安全控制要求,在梳理

出贵行数据平台应用需求与目标用户权限

关系之后，通过在程序中对数据进行过滤，

用户无法涉及其权限范围以外的数据，以确

第18页

数据平台系统投标书——技术部分

保数据范围的安全。数据过滤程序可抽象为

一个准确、高效、易管理维护的过滤器。

2.对于第二个层面的安全性，主要依

赖于文件传输过程中的加解密处理。因此，

数据交换平台在进行总体设计的时候需要

充分考虑数据传输过程中的安全性。

3.此外，系统在进行网络规划时，对

系统的安全级别也需要进行分析，必要时需

要提高网络的安全级别，从物理设计层面提

高系统的安全性。

3.1.2.8可重用性

可重用性是指尽可能避免贵行数据服务体系

建设的重复投入，应尽可能考虑包括物理设备、

系统软件、框架组件、规范方法以及业务应用等

多个层面上的复用。在本项目中，可重用性的设

计具体表现在以下几个方面：

1.ETL功能组件：在设计ETL任务处理

流程时，要分析ETL任务的各个环节，尽可

能找出一些公用的ETL组件,进行必要的封

装，便于在模块内复用，进而推广到项目内

进行复用。

第19页

数据平台系统投标书——技术部分

2.数据预处理层的数据模型：在设计

数据预处理层的数据模型时,应充分考虑应

用系统的数据加工需求,尽可能将一些共性

的加工需求在该层实现；并通过这种机制，

不断扩充和完善改成的数据模型，实现加工

数据的复用。

3.知识库的复用：在ETL管理平台中,

应充分考虑知识库的管理和使用流程，以便

运维人员和业务人员复用知识库的经验,来

解决和处理一些日常的问题。

4.组件复用：各模块在开发的过程中,

注意提炼出一些可用共用的公共组件,在模

块内实现复用，甚至在模块间实现复用。

5.硬件部署：在进行硬件部署的规划

时，应充分对系统的处理规模进行分析。如

果性能允许的话，尽可能集中部署，使用现

有设备，在硬件方面实现复用。

3.2数据平台技术体系

3.2.1数据平台逻辑架构

第20页

数据平台系统投标书—技术部分

数据仓库

领

■导

主

应

共

«层

用

数

乎

数

模

集

据I

型

据

市

tf遛

缓Itfl

层

层

分

冲

(工

E发

层

D层

W平

)G

一

D台

・

SI操

I作

层

系

矮

管

理

ODS员

贵行数据平台逻辑架构图

上图为宇信易诚对贵行数据平台的逻辑架构

建议设计图。从逻辑架构上看，数据平台主要分

为下面几个部分：

3.2.1.1数据集成区

数据集成区为总行区域,分行只需要提出对应

接口需求，由数据集成区下发至分行，目前的范

围包含了总行ODS、数据仓库。

3.2.1.2分行分析型数据区

分行分析型数据区包含报表数据区、应用服务

区及访问层区；

报表数据区将总行数仓、ODS数据经分发平

第21页

数据平台系统投标书——技术部分

台下发至分行数据进行整合，选用宇信易诚的

YC.LDM作为参考模型，建立数据缓冲层、基

础整合层、共性加工层、应用集市层。其中基础

整合层模型是用来统一存储整合企业所有源系

统的业务数据；共性加工层数据模型主要是用来

存储一些共性数据指标，为各应用系统提供共同

的基础数据预处理，提高数据共享程度和数据使

用效率。

应用服务区按照报表类别及指标作用划分为

固定报表、即席报表、OLAP、仪表盘等，满足

业务报表需求。

访问层主要对用户角色、操作权限进行管理;

3.2.1.3管理平台区

管理平台区包括任务调度、元数据、数据质量

三大模块。分行需要建设自身的调度平台。可以

采用总行统一调度平台ETLPLUS或宇信公司

USE调度产产品，实现对作业调度、监控和配

制管理，支持各类ETLJOB的调度，能够与主

流ETL工具集成，支持对调度策略、执行过程、

错误日志的实时监控。此外ETL管理平台支持

文件到达监控，ETL集群部署与集群调度以及

针对各个服务器资源的运行情况监控。

第22页

数据平台系统投标书——技术部分

元数据及数据质量使用总行元数据及数据质

量标准,，本期暂不考虑分行自建。

3.2.1.4统一报表展现平台

统一报表展现平台（报表平台）是本期基于数

据平台之上建立的一个报表系统，实现对报表的

统一管理以及统一展现服务，向用户展现数据平

台数据整合的成果。报表平台在功能上需要具备

系统管理、报表管理、报表展现（业务报表需求）、

BI工具集成，报表目录与分类，灵活查询以及

报表统计等功能。通过BI工具开发的报表能够

被报表展现平台无缝集成并且以最方便、最直观

的方式提供给报表的使用者。在本次贵行数据平

台建设中，图表展示、SQL灵活查询均将作为

一类特殊的报表系统的应用。由统一报表展现平

台完成功能集成与发布，向用户提供统一的访问

入口以及应用体验。

3.2.1.5ETL设计关键技术点说明

3.2.1.5.1.1ETL处理策略

原则上因机构撤并造成的新增账户仍以新

增帐户处理，账户间的关系通过机构拆并表进行

对应。如果有脏数据，依据数据情况另行处理。

账户主档表的处理：新增账户直接插入

第23页

数据平台系统投标书——技术部分

拉链表的处理：关闭老账户，以销户方式处

理；新增账户直接插入。

3..2ETL处理流程

源系统数据中心应用系统

机构撤并ETL处理流程

3.2.1.5.2质量检核

3.2.1.5.2.1ETL处理原则

质量检核是数据准确性的外部保证，应尽量

提供检核处理

检核处理不能对ETL处理有较大性能上的

影响

检核处理不能对时间窗口压力过大

3.2.1.5.2.2ETL处理方法

检核作业与该表的数据处理作业封装在同

一个作业组中

3.2.2数据采集设计

第24页

数据平台系统投标书——技术部分

在数据平台架构中，数据采集平台的设计主要

体现在T+1数据采集区技术架构、数据补录、

数据处理平台三个方面的设计。

散■平台

MMMivai

批量采集

EJL统一管理

准实时采集

数据采集模式

3.2.2.1T+1数据采集

T+1数据采集的主要功能需要从源系统中采

集数据到数据集成平台的源系统数据文件落地

区。通用的数据采集方法如下：

1.自行开发通用的数据下载平台，将源系统生

产数据同步到数据采集区。这种模式常用于

核心系统增量数据采集。通过该模式基本上

能按需要来定制开发数据采集程序，灵活性

第25页

数据平台系统投标书——技术部分

大，效率也较高，同时还可以集成增量比对、

乱码校验及修正、压缩打包、拆分并发处理、

传输处理等功能，是一个务实的做法。但该

模式也存在一个致命的问题，那就是如何确

定增量数据的问题？如果通过数据库日志

来获取，难度很大，而且也并不一定可行；

如果通过数据库结构的某个字段来识别，这

完全取决于源系统最初设计时是否考虑了

增量备份的需求；不幸的是，大多数情况下,

并没有考虑。于是，不得不采用先全量下载

的方式，然后传送到数据采集区，再通过数

据采集区来实现增量对比。在这种模式下，

全量数据的传输无疑又是一个新的问题。事

实上，这也正是大部分数据平台目前面临的

实际问题。

2.由源系统本身开发数据下载脚本,在本地生

成数据，然后通过文件传输工具发送到数据

采集区。这种模式常用于核心系统以外的其

他源系统数据采集，这主要是考虑其他源系

统的数据采集量不大，而且各源系统架构多

样化，不适宜采用通用的数据下载工具。这

种模式是一种主动采集模式。

第26页

数据平台系统投标书——技术部分

上述两种数据采集模式，均各有特点，鉴于总

行下发数据都是采集过的，分行只需要将特色系

统数据定时FTP下发即可。

T+1数据采集除了考虑上述采集技术外,还应

该设计T+1数据采集区的存储方式。分行数据

平台仅需按一定的规则存储不同来源基础数据。

通常的做法是，数据采集区的数据以文件的方式

保存，不用加载到数据库。这些数据文件的保存

周期大约为7天左右，最长不应超过一个数据纠

错周期。

3.2.2.2数据补录

数据补录是为了弥补数据源缺失或者业务系

统建设不完善的情况而设置特殊采集模式。在本

方案中数据补录功能采用宇信易诚开发的产品

(YC.RIDP)来实现。

数据补录模块的提供是针对不同业务数据库

的通用数据录入工具，包括页面录入和模板录入

以及数据入库的审批流程。支持对录入数据的事

件处理(如新增前进行有效性数据检查、新增后

进行数据平衡校验等，使用检核规则来实现)。

数据补录工具服务于各部门、各机构的数据录

入人员。该模块使用到“数据集管理”功能。

第27页

数据平台系统投标书——技术部分

3.2.2.2.1检核规则管理

检核规则有两种类型:存储过程、正则表达式，

是用于对录入数据进行合法性检核而定义的规

则。存储过程类型的检核规则必须要有输入参数

和输出字段，其中输入参数得到需要检核的数据

的值，输出参数返回检核结果的标志位。

管理员建立录入任务的时候,可以在检核规则

设置界面设置录入的数据所对应的检核规则，可

以设置数据入库前、入库后、修改前、修改后等

各种检核规则。

检核规则管理

名称查找匚斯建检核双则

—检核规■名称中文名称5555-

length等值检核正则表达式联修改Q聊院

共垓记录页次：Ui页io条球转到第1次GO

检核规则管理

3.2.2.2.2录入任务管理

录入任务是对一项录入工作的总体安排,包括

录入的目标表、操作控制信息、使用的检核规则、

批量录入模板的管理和权限控制等一系列内容。

1.目标表：录入的数据将被保存到这个表中，

目标表也是一个数据集。

2.操作控制信息:控制录入任务是否可以被新

增、修改、删除。

3.检核规则：用于对录入数据进行检核，可设

第28页

数据平台系统投标书——技术部分

置在入库前、入库后、修改前、修改后、

任务分发前、任务分发后等时间点触发

检核过程。

4.批量录入模板：用于批量导入数据。

5.权限管理：设置录入任务的可见机构，用于

控制权限。

录入任务建立并且分发完毕后,管理员可通过

“权限管理”菜单下的“权限对照设置”子菜单，

来修改录入任务的操作权限。

宇信易诚YU5rg।g机构:宇信易诚I樵作员：ride|岗位:系线管理员…|登录时间:2008-06-2009:33:49|退出系统

。一营而一■©£线首理。祝用首映。任某管理。黔电小、。拧表管理。孜的先去。咦H拧布。并去排行。个人信息。帮助

::伤民在所在的惊,娼：R】DE左电可试>黔宪录>7/任寻管理

录入任务管理

名称状赛描迷操作

现买单可用10任务分益上修改&.崎

能否录入可用能否录入IG任务分发N修改&.删除

录入可用■任务分发N修改土城赊

数据录入可用欧任务分发/修改&.峰

共修记录页次：1/1页10条须转到第1页第一页11上一页1下一页|：是后一页­|1|

宇信易诚WCtiCrg

|新建］［的］

宇信晨速做W5■司蝴所有

录入任务管理

3.2.2.2.3数据录入

录入任务定义好之后,用户可以在此界面进行

具体数据的录入。

第29页

数据平台系统投标书——技术部分

数据录入

录入任务：数据录入选择Exce展板：下载上传

IDSSVALUESCORELOCATIONNOTES

夕删除

确定取消

数据录入

用户也可以下载批量录入模板,按模板样式填

好数据之后，可以将批量录入文件上传至服务器

并导入文件中的数据。

文怦9跳耨盘）视图s插入a）格式仙工具CD数据Q）窗口的带助如怦,'记秀湾的汕灯登•-9X

io•回/口手国卷百书活一•：>，▲•道

窗口口M

A1▼齐B4-H4

BCDEFGiHIJKLMNO

=B4HJ10

数据录入

3LOCATIO

IDAPPIDIDSSVALUESCORENNOTES

，

|56|

7

8

9

^

|

^

蜀

如果S入数据超出第一格指定的区域，诺修改第一格的有效区域箱图:第

舞

二格注择，0一期的、1一修改、2一■除

01

符

善

[24

豆

B-

窗

JZIV

>x\数据录入/|<>|

解s

批・录入模板

如果管理员将录入任务定义成不需要审批的

状态，那么录入员将数据写入临时数据后，就可

以直接将它们提交入库。

3.2.2.2.4查询操作

用户可查询录入任务的正式数据和临时数据。

第30页

数据平台系统投标书——技术部分

可对录入任务的各个查询字段输入条件来筛选

数据。

数据录入

查询手段

VALUE

SCORE

查询位置理摩、（临时数据为在临时表中的数据，正式数据为用尸要录入的目标表中的数据）

其做条件

录入日期臼-0*必埴

当前状态；未提交v

确定取洎

录入查询

查询临时数据时，还可以对“未提交”或者“不

通过”的数据进行审批操作。

3.2.2.2.5录入任务审批

用于对用户录入的临时表数据进行审核及入

库操作。

用户录入的数据存放在临时表中，需要对临时

表数据审核之后，才可以正式入库。

数据录入

名亦数薪录入行皴100000000/布日期2008-03-14|新增阑

|IDAPP1DIDSSWALUESCORELOCATIONNOTES5s-

共0条记录页次：1/110条须转到第1页刷新

返回提交审批

录入审批

3.3数据平台数据体系

3.3.1数据架构设计

第31页

数据平台系统投标书——技术部分

数据平台数据架构

数据平台数据架构上可分为以下层次：

♦源系统数据落区

♦缓冲数据层(数据平台-ODM)

♦基础整合层(FDM)

♦共性加工层(ADM)

♦数据集市层(MDM)

3.3.1.1源系统数据落地区

贵行数据平台的数据来源将囊括总行下发数

据、贵行主要系统模块，包括公司、零售、同业、

第32页

数据平台系统投标书——技术部分

绩效、运营、人力资源多个子模块等。数据平台

每日将总行的增量数据将首先以文件形式落地

在源系统数据洛地区内，每日的数据文件以系统

+日期的形式存储在特定的文件目录内，之后由

数据平台的数据加载程序完成从文件向数据库

贴源区装载的过程。源系统数据落地区的文件需

要保留一定的纠错周期，一般保留周期为1周“

个月。

3.3.1.2缓冲数据层(ODM)

该层本质上是业务系统、总行下发数据与数据

平台之间的中间缓存层次，有以下特点：

♦对接总行ODS、仓库下发的主题及汇总数

据

♦基于分行特色业务系统的整理和分析,按

照业务流程进行梳理对关键业务及相关

信息进行抽取整合；

♦可按照需要进行必要的裁剪但不作转换

和聚合处理；

♦不保留历史信息，每日增量、全量业务信

息；

♦缓冲数据层的数据是经过标准化的,在该

入库过程进行数据转换处理动作。

第33页

数据平台系统投标书——技术部分

缓冲层的存储周期一般仅作为缓冲处理保留周

期为1天。

3.3.1.3基础整合层(FDM)

基础整合层(FDM)基于缓冲层主题或非主

题数据，进行处理和转化。总行下发的ODS、

仓库是经过了标准化处理后的，可以直接进行主

题存储。针对