数字智慧方案5332丨集团企业大数据治理平台解决方案

集团企业大数据治理平台解决方案

集团企业大数据分析平台建设目标通过数据平台和BI应用建设，XXX大数据将搭建统一的大数据共享和分析平台，对各类业务进行前瞻性预测及分析，为集团企业各层次用户提供统一的决策分析支持，提升数据共享与流转能力

统一制定目标和分析模型

600%500%400%300%200%100%0%2004年2005年2006年铁矿石2007年焦煤2008年自定义报表工具

行＋列的简单定义方式

多种格式报表

BI分析工具

云数据推送平台已实现了主要零售及金融业务系统统一定义BI应用

集团企业决策层

统一部署技术基础

供应链XXX系统

POP系统

采购管理系统

集团企业职能管控层

外部非结构化数据

其他业务系统

各级业务操作层

Page2数据治理概述

目录

某集团数据现状及问题数据治理阶段目标

数据管理系统建设情况

第一部分

数据治理概述

数据治理意义、作用和价值意义

是构建完善、共享、统一管理数据环境的基本保障和重要组成部分

是把数据作为资产来管理的有效手段

作用

确定了一系列岗位角色和相应的责任及管理流程

保证了业务数据在采集、集中、转换、存储、应用整个过程中的完整性、准确性、一致性和时效性

企业进行数据治理的最大驱动力来自数据质量，通过提高数据质量实现更多的业务价值

将实现业务目标作为数据管理和服务的核心驱动力，优化数据架构，提升数据仓库/信息化管理系统建设，支持管理能力的提高、精细化和决策的科学性

数据治理框架

数据战略

数据应用与服务

促进

数据服务管理

数据需求管理

数据服务

应用系统建设

实现

数据管理

内容管理

支撑

数据战略与规划

数据组织与职责

保障机制

数据制度与管理流程

数据架构

数据源

数据

业务系统

数据结构化转换

数据交换平台

大数据分析计算

分布式数据库

分布式文件系统

贴源层

数据平台

整合层

基础汇总层

数据平台

数据服务

数据集市

数据应用

统计报表

数据挖掘

高管驾驶舱

其他系统

大数据平台

数据接口

数据切分

数据质量检核

数据传输

数据

管理

平台

物联网

元数据管理

数据平台建设原则

一、应用（需求）驱动主导数据平台的实现，加强业务的关注和参与

应用是展现数据总线建设效果的门户，因此需要建设业务人员最紧迫和最关注的需求和应用，让业务部门最快参与数据总线的建设当中。

二、初期能够快速见效并体现建设价值，不盲目投入

实施周期不，规模不，能够快速的见到数据总线带来的效果和价值。

三、借鉴同业的成功经验和成果，选择成熟技术架构和解决方案

尽量参考同行业、同规模、同类型企业行的建设经验，适当创新。

四、重视人员培养，建设配套运营制度和管理体系

人员尽量更多、更深入的参与到数据总线的建设中，后期角色以管理为主，尽量与合作伙伴共同建设二期以上。配套的管理规范、技术规范、运营体系。

第二部分

某集团数据现状及问题

数据应用现状分析-总体情况

业务职能不清晰或相互重叠，观察数据视角不尽相同，缺少数据标准与业务统一定义，语轨不一致

IT架构中中都是以部门级应用为主（如计财、资金计划部等），缺乏从大的管理职能（财务、风险、运营等）综合方面的数据整合、数据标准和统一业务定义

客户信息

客户信息

行领导

贷款余额

客户信息

贷款余额

客户信息

…..

…..

客户信息

…..

…..

…..

业务人员

财务会计部

信贷管理部

国际业务部

资金计划部

…….

X\567数据交换平台

综合业务系统

信贷管理

国际业务系统

债券管理系统

……

数据应用现状分析-数据架构方面由于全行的数据散落在各个业务系统中，没有进行有效整合，形成竖井式架构，造成多个信息孤岛，整体架构缺少一个稳定的、抗源变化的保存最细粒度历史数据的数据层。无法支撑未来共享性应用。

业务表现

信息孤岛

数据冗余

共享性差

竖井式架构，造成信息孤岛

其它

报表

……

绩效考核

客户管理

客户

风险

报表

缺少一个稳定的、抗源变化的数据层

客户

一部

报表

中间

业务

报表

支付

报表

客户风险

客户一部

中间业务

支付业务

历史数据缺失

主题层

报表应用共用

主题数据

集市层

DEP层

源系统

综合业务

信贷管理

没有一个稳定的，抗源变化的数据层

没有进行整合，无法共享，不能支持如客户管理等共享性应用

国际结算

债券核算

数据应用现状分析-数据应用难题客户风险集市

缺少统一的应用分析标准

业务表现

各集市系统指标存在重复

各集市系统在保有存量的同时，不断产生新的指标（增量）

集市指标派生无法实现

指标逻辑视图（指标分类）不一致

借据号

期末余额

主营业务收入

负债总额

。。。

我想看本期贷款余额，看哪个呢

客户一部集市

用户

借据编号

期末贷款余额

总资产

。。。

我想看客户经营情况信息，有哪些呢

问题

用户

部

指标设计、口径不一致

指标难以共享

活期存款指标数据怎么不一致呢

数据应用现状分析-数据应用难题缺少统一的基础数据标准

业务表现

各系统存在冗余数据

各系统存在业务含义一致，名称定义不一致的属性

各系统存在含义不一致，名称定义一致的情况

业务代码定义混乱

相同业务代码定义不一致

核心贷款分户账表

业务含义一致，名称定义不一致

贷款主档代码

贷款余额

五级分类标志

计息方式

。。。

数据冗余

问题

信贷管理借据表

各系统数据难以共享

核心五级分类代码

借据计息周期

。。。

信贷管理五级分类代码

01正常

02关注

03次级

04可疑

05损失

1正常

2关注

3次级（不良）

4可疑（不良）

5损失（不良）

数据应用现状分析-数据质量方面没有归纳并总结数据质量问题，缺少反馈机制,导致长期存在各类数据质量问题。

业务表现

指标难以共享

数据不一致、不准确

由于信贷管理系统业务人员没有填写或填写错误借据的五级分类信息，导致报表数据不准确，需要手工补录修改

问题

部分关键业务数据缺失

源系统校验关系缺失及业务人员客户号

客户简称

75682839综合厂

不同系统相同客户号对应的客户简称不一致

75682839粮食局粮油综合

1497326762乳山市国鑫资产

数据应用现状分析-总结

随着业务的不断发展和信息化的不断深入，需建设的业务系统越来越多，随着业务系统的数据种类不断丰富完善，数据量的不断增大，如果不采取有效手段解决数据架构、数据标准、数据质量问题，随着信息化建设的深入，这些问题将像雪球一样越滚越大，越积越多。

综合报表平台适应性升级改造阶段（问题增加为451个）

综合报表平台建设阶段（问题339个）

第三部分

数据治理阶段目标

数据平台逻辑架构

源数据

CBSCM2006EEBOND贴源层

综合业务系统

CM2006国际结算系统

债券管理系统

外汇资金系统

报文清算系统

报价引擎系统

数据仓库

整合层

当事人

协议

事件

当事人资产

…….

数据应用

集市层

非现场监管集市

财会报表集市

ETL

风险报表集市

高管驾驶舱集市

…….

作业调度汇总层

机构

客户

账户

…...

非现场报表

财会报表

客户风险报表

…..

ETLETL作业调度作业调度高管驾驶舱

数据

切分

数据生命周期管理

数据质量检查系统

数据传输

MCS数据管理系统

数据平台部署架构

省行1：心跳三层交换机省行数据库服务器数据加载程序（完善后）数据传输平台配置库总行：新购置Web应用负载均衡器状态线新购置Web应用负载均衡器三层交换机已有应用服务器（2台）（188.1.6.107/188.1.6.108）

v4.3

v3.2

客户一部报表应用

中间业务报表应用新购置明细报表应用服务器（6台）Weblogic11gv4.3v3.2新建客户风险报表应用原有应用节点扩充数据切分应用（完善后）元数据管理应用心跳省行应用服务器v4.3数据传输平台应用心跳新购置数据平台ETL服务器(8台)RedHatEnterpriseLinux5(Advanced)MOIA4.4agentDataStage8.5EE（内置Websphere）调度平台代理节点数据平台ETL工程DS8.5管理应用三层交换机三层交换机新购置调度服务器（1台）

RedHatEnterpriseLinuxserverrelease5.5MOIA4.4server调度平台主节点省行文件服务器心跳心跳··省行2~30农发行内网数据传输平台应用已有数据库服务器（2）台）（188.1.6.105/188.1.6.106）调度平台代理节点平台ETL工程（优化后）DS8.5管理应用集市物理模型数据传输平台配置库已有文件服务器（2台）（188.1.6.111/188.1.6.112）Oracle10gMOIA配置库DS8.5SANFCSwitchFC阵列SANFCSwitch数据平台项目建设目标

1、发现数据质量问题，推动数据治理工作的开展，建立数据质量检核系统

对源系统进行数据质量检核，发现数据质量问题并统计影响到的报表

对数据质量问题进行归类总结，分析成因和改进建议

建设数据质量检核系统

2、分析、梳理业务系统，推动数据标准的建立，统一全行口径

建立基础标准和指标标准框架

确定标准化范围，对重要属性进行标准化

、建立数据仓库模型框架，优化我行数据架构，建设稳定、可扩展的数据仓库

引进业内具有先进水平的金融数据模型，进行客户化改造后，建成符合某集团特点的数据仓库模型框架

存储历史数据，解决新报表上线才有数的问题。

汇总层建设（共性加工）

目标建设方法-发现数据质量问题分析源系统表数据，从及时性、完整性、准确性、有效性、一致性方面对源系统数据进行数据校验，发现并记录数据质量问题，生成数据质量问题报告

建设数据质量检核系统，对源系统基础建设

内容

业务数据的进行全面的数据质量检查，并实现重要业务数据质量的周期性动态检查，对发现的数据质量问题生成数据质量报告，反馈给业务部门

目标建设方法-发现数据质量问题1源系统分析阶段

全面分析主要源业务系统

工作阶段

2数据质量问题检查阶段

根据制定的检查规则编写程序，对源系统数据进行检查

分析有质量问题数据对现有应用的影响；提出解决措施

源系统分析阶段

1、工作内容

全面分析和消化主要源业务系统

重点分析核心业务系统和信贷两个系统

产出物

技术角度分析调研

源系统表结构，包括主键、外键、唯一性约束

源系统表间关系

源系统字段长度和类型

2、工作依据

源系统文档：

《源系统操作手册》、《源业务系统设计说明书》、《源系统数据字典》

源系统环境及调研数据

业务角度分析调研

源系统表和字段的业务含义

源系统业务规则和流程

系统内：梳理业务流程、业务逻辑、业务关联、数据库表和字段的设计

系统间：梳理业务关联关系、数据关联关系

数据质量检查阶段

1、工作内容

梳理和制定数据质量检查规则，定义标准模板

依据数据检查规则，编写程序，对核心业务系统、信贷管理系统的进行检查

2、工作依据

系统调研和分析成果

数据质量检查规则的依据调研成果的以下内容进行梳理：

业务流程、业务逻辑

3、工作重点

重点报表用到的表进行分析

数据质量分析阶段

1、工作内容

分析有质量问题数据对现有报表应用的影响

对数据质量问题的成因进行分析和总结

对数据质量问题的解决措施进行分析和总结

2、工作依据

数据质量检查结果

重点分析报表平台的1104等报表存在的部分数据质量问题

数据质量反馈系统概述

建设目标

对业务数据进行数据质量检核，准确掌握业务系统各种数据质量问题，促进基础业务数据质量的提高

建设内容

质量检查规则定制

实现质量检查规则的灵活定制

数据质量检查

系统按照预定义的数据质量检查规则，对数据的准确性、有效性、关联性、一致性、及时性进行检查，

生成不同类型的数据质量检查报表，对不同的数据质量问题进行分析和展示

架构和功能

系统架构

数据质量检核与反馈系统

功能分类

检核对象管理

系统功能

功能名称

对象编辑

有效性

关联性

检核规则管理

一致性

灵活定制自定义检核规则，实现可视化规则配置和管理

功能说明

修改导入表，修改表和字段的相关属性

贴源层

整合层

汇总层

检核对象管理

调度管理

导入、查询、修改、删除检查对象

权限管理

检核规则管理

新增、删除、修改检核规则

用户建立

权限管理

准确性

及时性

检查频度管理

检核频度管理

权限管理

检核对象配置

质量监控周期频度，可按日、周、月、年等频度制定检核时间

问题报告

对发现的数据质量问题进行进一步的描述和分析，并划分问题归属业务分类

质量问题报告查询，并可按照部门、系统、问题进行汇总查询

管理员、操作员权限设置

管理需检核的表

维护并管理发现的数据质量问题

日志查询

系统管理

数据质量检查及反馈系统界面数据质量管理建议

管理层面

通过逐套的解决报表数据质量问题，以数据标准为依据，来切实解决基层手工修改报表的问题

形成数据质量管理的机制：发现问题，定位问题，解决问题的管理流程

源头负责制，谁录入谁修改

IT系统建设层面

将数据质量问题检查规则固化到系统中，形成数据质量台账，为解决数据质量问题和考核提供依据

数据平台项目建设目标

1、发现数据质量问题，推动数据治理工作的开展，建立数据质量检核系统

对源系统进行数据质量检核，发现数据质量问题并统计影响到的报表

对数据质量问题进行归类总结，分析成因和改进建议

建设数据质量检核系统

2、分析、梳理业务系统，推动数据标准的建立，统一全行口径

建立基础标准和指标标准框架

确定标准化范围，对重要属性进行标准化

、建立数据仓库模型框架，优化我行数据架构，建设稳定、可扩展的数据仓库

引进业内具有先进水平的金融数据模型，进行客户化改造后，建成符合某集团特点的数据仓库模型框架

存储历史数据，解决新报表上线才有数的问题。

汇总层建设（共性加工）

数据标准梳理及归纳

定义

对我行日常业务开展过程中所产生基础性数据，从业务方面、技术方面、管理三个方

面，对数据的业务表达、数据格式、数

据关系等方面进行一致约定，从而

规范数据在全行内外共享和使用

中的一致性和准确性

定义

通过对我行经营管理资料的分析，并参考同

业的类似成果以及监管部门要求，梳理

和筛选出直接反映我行业务经营管理

状态的重要指标，并对指标的业务

含义、业务规则、统计口径等内

作用

对数据的管理、应用过程进行统

数据标准

梳理及归纳

容进行标准化定义，形成全行一

致的指标数据标准

作用

一和规范，明确数据的定义、格式、

统一全行对各项经营指标的理解和

认识，促进各项经营指标在经营管理

决策中的运用；统一全行指标标准的业务含义、计算口径等内容，从而解决我行取数口径不一致、业务含义不清晰、指标分类不清晰的情况，促进部门间数据共享

目标建设方法-数据标准解决的问题制定了全行统一的标准，实现了业务数据信息统一定义，统一命名、统一来源

例如：在标准制定过程当中，对于业务数据之间关联不上的问题，首先要找出关联不上的原因，之后通过和业务人员的有效沟通，制定出以哪一类数据为准的标准，比如信贷管理系统的贷款余额且以此贷款余额制定全行标准，从而解决此类问题。

数据孤岛

数据质量

对于数据质量造成的数据准确性、一致性等问题，找出造成这些问题的原因，违背业务和约束的数据不进入标准体系中

举例

例如：不同部门的贷款余额由于取数来源不同而造成差异，通过建立完整的分析数据标准体系后，统一了业务定义和取数口径，有利于全行范围内重复利用，杜绝出现各业务部门多次重复定义类似的指标，并且因为标准的权威性和标准的严格管理，有效防止指标定义和口径的二义性。

目标建设方法-数据标准-建设步骤基础数据标准

标准定义

业务含义、业务规则、业务描述、

数据来源……

指标数据标准

业务定义、业务规则、业务含义、计算口径

……

数据标准

标准

映射

数据源和基础标准数据映射

数据源和分析标准数据映射

分析数据标准发布执行

目标建设方法-数据标准-建设内容1.现状分析

2.标准定义

3.标准映射

4.执行建议

目前存在问题

业务访谈

系统调研

形成标准化定义初稿和框架

对定义初稿征求意见和讨论

根据意见反馈和讨论结果和确定映射的系统范围

制定源系统与标准的映射规则

提出标准在未来各影响面执行的遵循原则

就标准与现状的实际差异根据数据验证映射规则

给出具体的执行建议

目标建设方法-数据标准-基础数据标准调研源业务系统业务字段

模型匹配

整合

实体属性

实体属性

实体属性实体属性实体属性

实体属性实体属性实体属性

实体属性实体属性实体属性

实体属性实体属性实体属性

实体属性实体属性整合层模型

当事人主题

协议主题

实体属性

实体属性实体属性实体属性

实体属性实体属性产品主题

渠道主题

地址主题

代码主题

数据质量反馈主题

调研分析

分析调研记录

实体属性实体属性当事人资产实体属性主题

事件主题

财务主题

实体属性

实体属性实体属性实体属性

实体属性实体属性源系统

核心

信贷表名

客户信息

贷款客户台账

贷款基本信息

XXXXX字段名

客户名称

贷款客户是否代码

否

否

是

X……

……

业务含义

xxxxx业务规则

xxxxx业务描述

xxxxx……

xxxxxxxxxxxxxxxxxxxx对应主题

客户

对应实体

对公客户

对应属性

……

…

1、名称不同，业务含义相同

……

xxxxxxxxxxxxxxx对公客户名称

管理

协议

XXX信息表

贷款信息表

XXXX贷款方式

XXXXX…

信贷管理

贷款方式

XXX3、名称相同，业务含义不相xxxxxxxxxxxxxxx同

……

……

xxxxxxxxxxxxxxx…

…

XXX目标建设方法-数据标准-基础数据标准框架梳理分析调研记录

源系统

字段名

是否代码

业务规则

业务含义

业务描述

……

对应主题

对应实体

对应属性

……

表名

…..

基础数据理筛选保留

整合合并

重命名

分类

参考补充

数据格式

长度

标准管

理部门

余额

贷款账户

……

……

xxxxxxxxxxxxxxxxxx……

……

……

……

xx……

……

存款账户

……

……

……

目标建设方法-数据标准-基础数据标准定义及确认整合.定义

补充.完善

业务人员

补充.完善

技术人员

沟通.确认

沟通.确认

业务部分

基础数方案技术部分

代码标准方案

数据格式

长度

标准管

理部门

xx……

xxx……

xx……

xxxx……

xx……

xx……

xxxxxxxxxxxxxxxxxx……

xxxx……

xxxx……

xxxxxxx……

……

目标建设方法-基础标准-制定框架

基础数据标准框架属性参考人民银行标准规范文档和他行标准，由3部分22个属性项组成，分别为业务属性、技术属性、目标建设方法-基础标准-指标标准建设思路1、筛选重要业务指标

（1）研读经营管理资料，梳理重要指标列表

（2）参考外部资料，补充完善指标列表

（3）讨论指标列表，筛选、确定指标范围

2、制定指标标准框架

（1）梳理、确定指标分类体系

（2）梳理、确定指标标准属性，形成指标标准化定义模板

（1）指标分析：分析指标的定义、口径、规则、数据来源等内容

（2）标准技术定义：技术部门逐项定义指标标准化属性

（3）标准业务确认：业务部门修订、确认指标标准

目标建设方法-基础标准-指标标准筛选方法1、研读经营管理资料

经营管理资料：

行领导讲话

我行各业务部门的业务经营分析报告

我行的各类管理报表

2、参考外部资料

外部资料：

同业相关建设资料

城商行银行

国有银行某著名企业

人民银行、银监会监管指标要求

3、筛选、确定指标范围

筛选、确认方式：

项目组讨论筛选

外部需求调研，进行补充和

筛选原则：

确认

的指标

目标建设方法-基础标准-指标标准框架制定方法1、梳理、设计指标分类体系

设计依据：

指标的业务共性的归纳及提炼

参考行内资料

我行业务分类

源业务系统操作手册及业务简介文档

统计集中系统指标分类

参考外部资料

2、设计标准化属性

设计依据：

人民银行《JRT0105-2014银行数据标准定义规范》

外部资料

设计原则：

据业务和指标变化进行扩展

可以从业务、技术、管理不同角度对标准对指标标准必须清晰、明确

满足未来对满足标准进行管理的需要

目标建设方法-基础标准-指标数据标准框架指标数据标准框架

业务属性

指标编码

指标别名

指标中文名称

技术属性

指标落地系统

数据来源系统

数据源表

数据格式

度量单位

取值精度

管理属性

归口业务部门

业务负责人

技术负责人

反馈结果描述

指标英文名称

指标范围类别

计算公式

业务规则

显示精度

相关基础类数据标准

指标定义

指标大类

指标小类

取数口径

指标应用-高管驾驶舱

功能简介

从经营概况到

具体指标分析

主驾驶舱

我的指标

热点地图

经营概览

规模分析

专项分析

利润分析

指标总览

风险分析

今日快报

指标总览

专项分析

现和分析

对某一具体指标进行比较、结构、趋势等方面的分析

主驾驶舱

选取13个行领导重点关注的指标展示

显示全国地图，可以展示各一级分行重要的经营简报数据

我的指标

根据用户对指标的重视程度，实现指标的个性化定制

指标应用-高管驾驶舱-界面截图数据平台项目建设目标

1、发现数据质量问题，推动数据治理工作的开展，建立数据质量检核系统

对源系统进行数据质量检核，发现数据质量问题并统计影响到的报表

对数据质量问题进行归类总结，分析成因和改进建议

建设数据质量检核系统

2、分析、梳理业务系统，推动数据标准的建立，统一全行口径

建立基础标准和指标标准框架

确定标准化范围，对重要属性进行标准化

、建立数据仓库模型框架，优化我行数据架构，建设稳定、可扩展的数据仓库

引进业内具有先进水平的金融数据模型，进行客户化改造后，建成符合某集团特点的数据仓库模型框架

存储历史数据，解决新报表上线才有数的问题。

汇总层建设（共性加工）

数据仓库层次架构

主题

主题是模型按业务划分的最顶层的分类

根据我行业务实际，划分10个业务主题

逻辑视图（子主题）

逻辑视图是根据实体涉及的业务，将实体划分为不同子集

同一实体可属于不同逻辑视图

实体

实体是一组具有业务相关性的属性组成的集合，是描述和构成业

务逻辑、业务流程的基本单位

一个实体可能涉及多类业务

属性

模型最明细一级结构

对应具体的业务数据项（字段）

数据仓库层次架构

主题

对公客户

机构

当事人主题

当事人主题

当事人主题

当事人主题

当事人主题逻辑视图

风险评级

……

……

实体

……

不良贷对公客户领导对公客户资本对公客对公客户管理财务信机构信息

……

………………

属性

客户名称

所属领域

注册资本

企业规模

法人代表

基本账户

开户行

……

数据仓库模型设计方法

TD模型业务剪裁

保留与我行业务有关的主题、实体和属性

删除与我

行业务无关的主题、实体和属性

TD模型

入仓源表

及字段范围

物理模型设计

当前业务及数据都支持的实体进行理化

根据我行业务实际需求对主题进行新增和合并

基础模型

模型

映射

逻辑模型设计

复制：系统间业务含义、名称均不重复的字段

逻辑模型

当前业务不支持或数据不支持的不进行物理化

物理模型

目标的建设方法-数据仓库模型框架整合层模型设计-基础模型（业务匹配）

基础模型是TD模型在我行进行初步客户化后的产物。

将TD模型的主题和实体，与我行的实际业务行的实际业务进行对比分析，根据匹配结果对TD模型进行裁剪、合并和扩充，形成匹配我行实际业务的情况的模型框架。

Teradata金融模型10.0当事人主题

业务匹配

我行无关业务我行无关业务

个人业务

营销活动

保险投资

……

当事人主题

基础模型

地址主题

地址主题

协议主题

渠道主题

协议主题

渠道主题

我行现有业务我行现有关务

对公客户

合同

保留

增加

代码主题

保留

数据质量反馈

财务主题

产品主题

财务主题

产品主题

目标的建设方法-数据仓库模型框架数据仓库模型基础模型

实体属性

实体属性

实体属性实体属性实体属性

实体属性实体属性实体属性

实体属性实体属性实体属性

实体属性实体属性实体属性

实体属性实体属性整合层模型设计-属性匹配

业务字段

对源业务系统的字段进行梳理分析，筛选出具体业务价格的字段，将业务字段与基础模型的主题、实体和属性进行匹配分析，根据匹配结果对基础模型的实体、属性进行增删。

源业务系统

分析匹配

保留（整合）并映射

新增并映射

当事人主题

新增属性

协议主题

产品主题

当事人资产主题

事件主题

财务主题

渠道主题

地址主题

代码主题

数据质量反馈主题

实体属性

实体属性实体属性实体属性

实体属性实体属性实体属性

实体属性实体属性实体属性

实体属性实体属性实体属性

实体属性实体属性实体属性

未来业务无关则删除

逻辑模型设计-主题划分

当事人资产

当事人

财务

协议

渠道

代码

产品

地域

逻辑模型设计-当事人主题逻辑模型

当事人

地址

代码

产品

协议

渠道

反馈域

财务

事件

当事人资产

当事人

个人当事人

家庭

机构

金融机构

组织

其它

组织

当事人是一个独立的人或者一组人组成的机构、团体等，主要分为个人、机构和家庭，他们是和我行有往来或者出于营销、管理等各种需要希望关心和分析的个体或人群。从模型角度考虑，应该包括以下当事人信息：

在我行登记注册开立账户的对公普通客户；

我行担保客户

和我行有业务往来的其他金融机构；

机构的组织（如分支机构、部门等）；

机构的员工（含我行柜员、员工等）；

对全行客户进行统一识别与数据整合

联系信息

关联信息

风险信息

评价信息

柜员信息

公司信息

机构

外部机构

粮棉油

逻辑模型设计-代码主题

逻辑模型

当事人

地址

代码

产品

协议

渠道

反馈域

财务

事件

当事人资产

代码

当事人类代码表

公共类代码表

协议类代码表

事件类代码表

映射关系表

分类模式编码表

代码：是指将源业务系统所涉及到的所有代码进行整合，在整合层模型中统一存储，依据前端应用需求的需要，将代码主题的整合分为两大类：简单代码表和复杂代码表，

简单代码表指的是只需要关注代码值和代码值业务含义描述；

复杂代码表指的应用需求除关注代码值和代码值业务含义描述外，该代码表的其他属性也有应用需求，同样需要关注，这样的码表将作为普通的数据表对待；

自定义代码，是属于简单码表的一种。

对全行业务代码进行统一识别

复杂码表

自定义代码

当事人类代码表

公共类代码表

资产类代码表

协议类代码表

源和目标代码映射关事件类代码表

财务类代码表

系表

逻辑模型设计-协议主题

逻辑模型

当事人

代码

协议

渠道

反馈域

财务

事件

当事人资产

地址

产品

协议

金融账户

申请

金融合约

协议是指金融机构与当事人之间针对某种特定产品或服务而签立的契约关系，如账户、客户和银行签订的合同等。当金融机构与客户之间针对某种产品或服务的条款和条件达成协议时，一个协议（Agreement）就会被开立，因此协议是客户和银行往来的重要载体，我行模型包括以下协议信息：

我行涉及金额、期限、利率等的具体协议细项的金融账户

我行与当事人之间针对某种特定产品或服务而签立的金融合约

我行在支付结算业务中使用到的各种银行票据：汇票

银行与客户之间针对某种特定产品或服务而签立的契约关系，将所有协议和关系，整合和归并

款计划

贷款

合同

抵质押合同押品信息

借据

合同

贷款帐户

抵押合同

国际结算

其他信息

存款帐户

质押合同

银行本票

银行承兑汇票

贷款合同

贷款借据

银行汇票

客户理财签约

逻辑模型设计-事件主题

逻辑模型

当事人

地址

代码

产品

协议

渠道

反馈域

财务

事件

当事人资产

事件

贷款事件

存款事件

库存管理事件

事件：可以记录各种与银行相关的活动的详细情况。既可以与资金相关，也可以与资金无关；既可以有客户参与，也可以没有客户参与；既可以与帐户相关，也可以与帐户无关；可以由客户发起，也可以由银行发起。总之它可以记录的范围非常广泛，包括交据，比如存款、提款、付款、收取信用卡年费、计算利息和费用、投诉、查询产品、查询地址、查询余额、网上交。

我行模型包括以下事件信息：

存款信息、贷款信息；

库存管理、现金管理、账户管理、资产管理；

资金调拨、支付结算、现代化支付；

报文清算、国际业务；

外汇、票据、市场交易、十二级分类、核心账务。

该主题可以记录各种与银行相关的活动的详细情况，进行客户行为分

析、重大事件侦测等，以便更好的进行客户细分、客户关怀。

进度采集

信息采集

存核查

同业定期存款汇入

同业定期存款汇出

大额支付事件

小额支付事件

贷款缩期事件

贷款展期事件

贷款转移事件

分段计息事件

新棉收购进度采集

商品棉贷款信息采集

粮油库存核查

棉花农资库存变动

缩期

展期

转移

计息

库存变动

逻辑模型设计-财务主题

财务：主要包括银行的总账信息，是描述科目组织、控制、核算等银行核心科目账务以及预算管理有关的内容。该主题抽象地描述了银行账务的组织模式，能够适应不同的科目组织体系。

我行模型包括以下财务信息：

总账（分户）

总账明细

科目/科目组/科目类：对于科目的层次级别设置和管理

财务预算

财务主题抽象地描述了银行账务的组织模式，能够适应不同的科目组织体系，它侧重于“财务管理”

逻辑模型

当事人

地址

代码

产品

协议

渠道

反馈域

财务

事件

当事人资产

总账科目

总账内外科目对照关系

总账日旬余额

科目产品对照关系

总账月余额

信贷总账科目

信贷总账科目

内外科目对照关系

日明细科目余额

科目与产品对照关系

月明细科目余额

日明细外部科目余额

外汇科目损益余额

日明细外部科目余额

外汇准备金科目余额

逻辑模型设计-当事人资产主题逻辑模型

当事人

地址

代码

产品

协议

渠道

反馈域

财务

事件

当事人资产

资产

银行自有资产

客户自有资产

当事人资产：描述当事人的所有资产，该主题包含两大类的资产，既包含我行自有资产又包含客户所拥有的资产。一个资产可以被多个当事人所拥有，一个当事人可以与多个资产有关。资产可分为实物资产、金融资产与无形资产。客户资产信息的来源很多情况下是在客户申请贷款时所提供的各种担保品信息、抵质押品信息等。我行模型包括以下资产信息：

银行自有资产，具体又细分为：银行自有无形资产、固定资产、经营性租赁资产、其他资产等；

客户自有资产，具体又细分为：客户抵债资产、客户担保资产、金融资产、实物资产、无形资产等。

客户资产信息的来源很多情况下是在客户申请贷款时所提供的各种担保品信息、抵质押品信息等，将这种信息进行整合和归并

设备

产信息

银行自有资产

经营性租赁资产

银行自有无形资产

银行自有固定资产

客户抵债资产

抵债资产房产

抵债资产设备

抵债资产地产

客户担保资产

抵质押物

押品外部评估信息

押品评估信息

数据映射和ETL开发

ETL开发人员按照映射文件中规定的映射逻辑要求，结合开发规范，编写作业，通过数据源分析，制定加载策略，开发JOB调度

数据源分析

加载策略

源表

映射文件

开发规范

目标表

合并

拆分

复制

常量

业务含义相同、名称不同，进行合并

业务含义相同、名称相同，进行合并

业务含义不同，名称相同，进行拆分

直接拷贝

赋固定值

生成新键值

1ETL映射文件

通过映射文件，表间关联/单表操作（LeftJoin,InnerJoin,FullJoin,Union）

确定表间关系

数据映射和ETL开发

定义源：配置作业源表定义源

创建映射

定义目标

的表名、表结构等信息

创建映射：根据作业详细设计中表与表之间及字段之间的映射关系，使用相应的组件实现其数据转换逻辑

定义目标：配置作业目标表的表名、表结构、加载方式等信息

项目提交物（总共108项交付文档）目标的建设方法-数据仓库模型框架（整合层模型建设对应用的支撑

保证模型对未来业务的业务支持的快速响应，不需要随业务的变化而频繁调整整合层模型

形成明确业务含义和数据来源，确保字段业务定义的唯一性，形成全行统一的业务视图

整合层提供全行统一的业务视图

整合层的数据全面性

整合层涵盖我行主要源业务系统的业务信息，提供全面的业务数据，可以为客户、风险、绩效等各类分析应

整合层的稳定性

的数据查询和分析应用

整合层保留完整的历史整合层中可以完整保留业务系统的历史数据，保证了对历史类查询分析的支持

客户360度统一视图通过整合层模型落地客户额度信息

对公客户统计与分析管理

联系人/关联信息

客户基本信息

客户额度信息

客户财务信息

客户关联信息

客户关键人信息

客户联系人信息

客户上市信息

客户存款信息

客户贷款信息

账务交

账户日均余额

客户考核利润

客户管户信息

国际结算信息

网银交

机构信息

……

客户基本信息

统计数据

业务规模统计

资金流向统计

额度信息统计

客户分类统计

授信客户统计

行业客户统计

……

客户财务信息

客户大事记

资本构成/股权投资

客户360度

统一视图

交

国际结算信息

理财产品信息

ETL客户合作协议

产品/账户信息

其它信息

关联关系

联系人/关键人

统一客户关联

信息视图

61整合层模型对客户营销的支持整合层模型

当事人主题

核心

对公客户表

存款交表

存款账户表

。。。。。。

CRM-客户贡献度分析

客户号

客户名称

信贷管理

同一客户信息整合

协议主题

存款余额

贷款余额

五级分类

季度存款交

客户贡献度分类

-客户贡献度分类：

存款余额大于xx万，贷款余额大于xxxx万，并且属于正常贷款，且季度存款交于xxx条的为A客户；

存款余额大于xx万，贷款余额大于xxxx万，并且属于正常贷款，且季度存款交于xxx条的为B客户；

存款余额大于xx万，贷款余额大于xxxx万，并且属于次级贷款，且季度存款交于xxx条的为C客户；

通过客户贡献度的分类，制定营销策略，比如贡献度为A的客户，可进行贷款利率上的优惠或存款利率的上浮的方式稳定此利润点

整合层模型对客户营销的支持整合层模型

当事人主题

核心

对公客户表

存款交表

存款账户表

。。。。。。

CRM-客户忠诚度分析

客户号

客户名称

信贷管理

同一客户信息整合

协议主题

是否基本户

账户日均余额

贷款金额营销

贷款期限

账户睡眠时间

现金流量是否异常

业务量是否异常

客户忠诚度分类

营销策略-客户忠诚度分类：

通过客户忠诚度的分类，忠诚度越大、则是我行重点的目标客户，可作为战略重点客户。如果忠诚度不大，则要进行重点客户关系维护，即精准营销

汇总层目标与定位

作为整合层和集市层的衔接，从业务的视角出发，提炼出对数据仓库具有共性的数据访问需求，抽取出公共指标，形成由维度和指标组成的维度模型，对符合要求的数据进行预汇总和预加工。

为集市层统一提供规范的、准确的数据。完成整个汇总层的逻辑模型、物理模型的设计并全部实现物理化。

并根据业务性质将业务数据，划分为以下七大类主题分类存放和管理

建设阶段和步骤

一、逻辑模型初步设计

二、逻辑模型

具体设计

业务驱动循环

2.1数据源到参考模型的匹配

2.2参考模型到

三、开发实现

3.1物理模型设计

1.1参考模型设计

3.2数据映射

1.2当前用到的属性分析

数据源的匹配

2.3应用驱动

模型完善

3.3ETL个人、存款、贷款、贷款、信用卡

建设重点

2.源表1.协调业务系统开发商对系统进行讲解，了解具体的业务流程并对开发人员整理出的源业务系统调研提纲中所提出的问题进行解答

2.对源系统表对象调研

3.对源系统表字段调研

4.根据源系统数据验证调研结果

调研

1.源系统调研

3.源表字段调研

4.验证调研结果

存储策略

设计思想

将汇总层划分为两个存储区域，数据集市应用从历史数据区和快照区获取数据。

数据存储区

历史数据区

月表历史区

ODS层、整合层

流水类表

应用层

数据集市

数据集市

数据集市

快照区

（T-1日，数据日期）

第四部分

成效和特点

项目成效-中长期价值

进一步扩展了数据范围，容纳了新数据，实现对业务数据的全覆盖，当未来有新的业务需求时，保证了数据架构的稳定性

支撑全行级的数据应用，数据平台可提供全行级的最细粒度数据，满足未来建设决策支持系统如：客户关系管理、资产负债管理、管理会计、信用风险管理、管理

支撑数据挖掘，支持各业务部门进行客户价值分析、客户行为分析、货款偿还预测分析、客户信用政策分析、业务关联分析等数据挖掘应用

项目建设特点-多方参与，字段级加工公司方

系统调研业务调研

技术调研

数据调研

标准化分析

源业务系统业务字段

业务人员

技术人员

技术讲解

技术答疑

技术相关标准定义

技术相关标准确认

源系统厂商

源系统讲解

资料提供

源系统答疑

业务答疑

ETL

数据标准

数标准映射

业务相关标准定义

业务相关标准确认

结果验证

项目建设特点-分工协作，共同推动（本期项目建设实施过程遵循

“技术先行，业务配合”的原则，需要技术部门主导、业务部门解决数据“如何整合”的问题，合作公司解决技术人员提交标准后，对应的业务部门人员需确认结果,对有异议的结果进行修改和补充，这个过程可能需要经过多次反复确认，从而制定最终的标准化产物并发布，形成全行标准

项目建设特点-分工协作，共同推动（业务部门解决数据“如何整合”的问题

业务部门需要确认技术部门提出的整合规则（标准）是否合适，以便解决信息孤岛和准确性问题，整合规则分为两个方面，分别为：系统间整合规则和系统内整合规则，确认内容如下：

对技术部门提出的，名称相同，业务含义相同的数据整合标准是否认可

对技术部门提出的，名称不同，业务含义相同的数据整合标准是否认可

对技术部门提出的，名称相同，业务含义不同的数据整合标准是否认可

业务部门需要确认技术部门提出的标准定义是否准确、恰当、合适，以便解决业务定义和取数口径不一致的问题，标准内容有：

标准信息分类（大类、小类）

标准名称和标准业务定义

基础标准产出物

项目建设特点-分工协作，共同推动（合作公司解决数据“是什么”的问题

提供最新的完整的技术资料，主要包括操作手册和数据字典，对于调研过程当中的问题给予及时的答疑，这些问题主要包括

业务问题

业务术语不明，比如在调研过程当中的“反担保贷款”等业务术语不明

业务关联不明，比如借据号和准贷证有什么业务联系

业务用途不明，比如对表和字段如何使用存在疑问（自定义标识、多个备注字段）

数据质量问题

主外键关联不上

主键冲突

提供的资料或数据间相互矛盾

数据治理

1、数据治理框架建设阶段

明确数据的发展目标，数据的体系规划，数据的政策制度，数据需求的整合、数据应用与服务

信息化建设委员会

决策层

成立数据治理领导小组

信息化建设委员会项目审查小组

管理层

执行层

信贷管理部

国际业务部

财务会计部

资金计划部

风险管理部

……

……

数据标准管理流程-标准管理组织架构和角色定义发起、组织数据标准的新建

协调跨领域变更与重大变更核准

组织数据标准定期复审

监控标准执行项目的进展与效果

数据标准的发布、备案、版本管理

行外数据标准化组织的联系

行业标准发展状况的跟踪

审定数据标准建立方案

审议数据标准重大变更

核准数据标准复审

审定和推行数据标准执行方案

指定标准执行项目的业务牵头部门

推动标准在全行的使用落实

指派数据管理员与业务专家

数据标准管理领导小组

（负责分管资金计划部的行领导）

数据标准管理办公室

（资金计划部）

数据标准业务专家

（各业务部门业务专家）

配合数据管理员完成其他数据标准管理事项

数据管理员

（资金计划部）

标准的一致性解释

金融标准委员会相关标准的复审和落实

系统管理员

（信息科技部）

数据标准管理工具的运营与维护

数据标准管理工具的用户设置与权限管理

第五部分

数据管理系统建设情况

数据管理平台概述

省行平台

省行1省行2省行3……

数据传输

元数据管理系统

元数据

数据获取

数据仓库

当事人

数据管理数据传输平台