大数据平台数据治理与建设方案.pptx

1、大数据治理平台解决方案 目录数据治理概述某行数据现状及问题数据治理阶段目标成效和特点数据管理系统建设情况第一部分数据治理概述数据治理意义、作用和价值意义是构建完善、共享、统一管理数据环境的基本保障和重要组成部分是把数据作为资产来管理的有效手段作用确定了一系列岗位角色和相应的责任及管理流程保证了业务数据在采集、集中、转换、存储、应用整个过程中的完整性、准确性、一致性和时效性价值企业进行数据治理的最大驱动力来自数据质量，通过提高数据质量实现更多的业务价值将实现业务目标作为数据管理和服务的核心驱动力，优化数据架构，提升数据仓库/信息化管理系统建设，支持管理能力的提高、精细化和决策的科学性数据战略数据

2、应用与服务数据管理保障机制促进支撑实现支撑数据战略与规划数据组织与职责数据制度与管理流程数据服务管理数据需求管理应用系统建设数据服务数据架构与模型管理数据标准管理数据质量管理元数据管理主数据管理数据保留与归档管理数据安全管理内容管理数据治理框架数据调度与处理大数据平台数据结构化转换大数据分析计算分布式数据库分布式文件系统数据生命周期管理数据平台数据传输数据服务数据集市数据质量检核元数据管理数据管理平台数据应用统计报表基础数据平台贴源层整合层汇总层数据切分数据源业务系统物联网互联网数据交换平台内部数据外部数据其他系统数据接口数据架构数据挖掘高管驾驶舱一、应用（需求）驱动主导数据平台的实现，加强业

3、务的关注和参与二、初期能够快速见效并体现建设价值，不盲目投入三、借鉴同业的成功经验和成果，选择成熟技术架构和解决方案四、重视内部人员培养，建设配套运营制度和管理体系应用是展现数据总线建设效果的门户，因此需要建设业务人员最紧迫和最关注的需求和应用，让业务部门最快参与数据总线的建设当中。实施周期不易过长，规模不易过大，能够快速的见到数据总线带来的效果和价值。尽量参考同行业、同规模、同类型企业行的建设经验，适当创新。前期让公司内IT人员尽量更多、更深入的参与到数据总线的建设中，后期角色以管理为主，尽量与合作伙伴共同建设二期以上。配套的管理规范、技术规范、运营体系。数据平台建设原则第二部分某行数据现状

4、及问题数据应用现状分析-总体情况？综合业务系统信贷管理国际业务系统债券管理系统数据交换平台综合报表平台财务会计部信贷管理部国际业务部资金计划部.客户信息.贷款余额客户信息.贷款余额.客户信息客户信息.客户信息.业务职能不清晰或相互重叠，观察数据视角不尽相同，缺少数据标准与业务统一定义，语轨不一致 IT架构中中都是以部门级应用为主（如计财、资金计划部等），缺乏从大的管理职能（财务、风险、运营等）综合方面的数据整合、数据标准和统一业务定义 缺乏数据梳理，造成行领导看到的数据相互冲突和矛盾 由于业务系统输入的随意性，导致部分关键业务数据质量较差X?567数据应用现状分析-数据架构方面l 由于全行的数

5、据散落在各个业务系统中，没有进行有效整合，形成竖井式架构，造成多个信息孤岛，整体架构缺少一个稳定的、抗源变化的保存最细粒度历史数据的数据层。无法支撑未来共享性应用。集市层客户风险客户一部中间业务汇总数据层主题层报表应用共用主题数据客户风险报表客户一部报表中间业务报表支付报表支付业务ODS层DEP层BDS层其它报表l 业务表现 信息孤岛 数据冗余 共享性差 历史数据缺失l 问题 数据分散，难以管理 没有一个稳定的，抗源变化的数据层综合业务信贷管理国际结算债券核算源系统竖井式架构，造成信息孤岛缺少一个稳定的、抗源变化的数据层客户管理绩效考核没有进行整合，无法共享，不能支持如客户管理等共享性应用数据

6、应用现状分析-数据应用难题l 业务表现 各集市系统指标存在重复 各集市系统在保有存量的同时，不断产生新的指标（增量）集市指标派生无法实现 指标逻辑视图（指标分类）不一致l 问题 重复投入 数据不一致 指标设计、口径不一致 指标难以共享客户风险集市客户一部集市资金计划部借据号期末余额。借据编号期末贷款余额总资产我想看本期贷款余额，看哪个呢？主营业务收入负债总额。我想看客户经营情况信息，有哪些呢？活期存款指标数据怎么不一致呢？l 缺少统一的应用分析标准数据应用现状分析-数据应用难题l 业务表现 各系统存在冗余数据 各系统存在业务含义一致，名称定义不一致的属性 各系统存在含义不一致，名称定义一致的情

7、况 业务代码定义混乱l 问题 重复投入 数据不一致、不准确 难以利用和管理 各系统数据难以共享l 缺少统一的基础数据标准核心贷款分户账表贷款主档代码贷款余额。五级分类标志计息方式信贷管理借据表贷款账号贷款余额。5级分类标志借据计息周期业务含义一致，名称定义不一致数据冗余相同业务代码定义不一致核心五级分类代码信贷管理五级分类代码1 正常01 正常2 关注02 关注3 次级（不良）03 次级4 可疑（不良）04 可疑5 损失（不良）05 损失数据应用现状分析-数据质量方面l 没有归纳并总结数据质量问题，缺少反馈机制,导致长期存在各类数据质量问题。l 业务表现 指标难以共享 数据不一致、不准确l 问

8、题 部分关键业务数据缺失 源系统校验关系缺失及业务人员操作随意13由于信贷管理系统业务人员没有填写或填写错误借据的五级分类信息，导致报表数据不准确，需要手工补录修改不同系统相同客户号对应的客户简称不一致客户号客户简称75682839综合厂97326762国鑫资产客户号客户简称75682839粮食局粮油综合97326762乳山市国鑫资产数据应用现状分析-总结l 随着业务的不断发展和信息化的不断深入，需建设的业务系统越来越多，随着业务系统的数据种类不断丰富完善，数据量的不断增大，如果不采取有效手段解决数据架构、数据标准、数据质量问题，随着信息化建设的深入，这些问题将像雪球一样越滚越大，越积越多。综

9、合报表平台适应性升级改造阶段（问题增加为451个）综合报表平台建设阶段（问题339个）第三部分数据治理阶段目标数据平台逻辑架构数据调度与处理元数据管理数据传输数据生命周期管理非现场报表财会报表客户风险报表.机构客户账户.非现场监管集市财会报表集市风险报表集市高管驾驶舱集市.数据仓库源数据数据应用贴源层整合层汇总层集市层数据管理系统综合业务系统CM2006国际结算系统债券管理系统ETLETL数据切分数据质量检查系统高管驾驶舱当事人协议事件当事人资产.外汇资金系统报文清算系统报价引擎系统整合层作业调度作业调度作业调度ETLCBSCM2006EEBONDPEFESMCS数据平台部署架构数据平台项目建

10、设目标1、发现数据质量问题，推动数据治理工作的开展，建立数据质量检核系统 对源系统进行数据质量检核，发现数据质量问题并统计影响到的报表 对数据质量问题进行归类总结，分析成因和改进建议 建设数据质量检核系统2、分析、梳理业务系统，推动数据标准的建立，统一全行口径 建立基础标准和指标标准框架 确定标准化范围，对重要属性进行标准化3、建立数据仓库模型框架，优化我行数据架构，建设稳定、可扩展的数据仓库 引进业内具有先进水平的金融数据模型，进行客户化改造后，建成符合某行特点的数据仓库模型框架 覆盖某行主要业务系统数据，以便快速高效的为应用系统提供数据 存储历史数据，解决新报表上线才有数的问题。汇总层建设

11、（共性加工）目标建设方法-发现数据质量问题建设内容分析源系统表数据，从及时性、完整性、准确性、有效性、一致性方面对源系统数据进行数据校验，发现并记录数据质量问题，生成数据质量问题报告建设数据质量检核系统，对源系统基础业务数据的进行全面的数据质量检查，并实现重要业务数据质量的周期性动态检查，对发现的数据质量问题生成数据质量报告，反馈给业务部门目标建设方法-发现数据质量问题源系统分析阶段全面分析主要源业务系统数据质量问题检查阶段根据制定的检查规则编写程序，对源系统数据进行检查数据质量问题分析阶段分析有质量问题数据对现有应用的影响；提出解决措施123工作阶段源系统分析阶段1、工作内容 全面分析和消化

12、主要源业务系统 重点分析核心业务系统和信贷两个系统2、工作依据 源系统文档：源系统操作手册、源业务系统设计说明书、源系统数据字典 源系统环境及调研数据3、工作重点 系统内：梳理业务流程、业务逻辑、业务关联、数据库表和字段的设计 系统间：梳理业务关联关系、数据关联关系技术角度分析调研产出物 源系统表结构，包括主键、外键、唯一性约束 源系统表间关系 源系统字段长度和类型业务角度分析调研 源系统表和字段的业务含义 源系统业务规则和流程数据质量检查阶段1、工作内容 梳理和制定数据质量检查规则，定义标准模板 依据数据检查规则，编写程序，对核心业务系统、信贷管理系统的进行检查2、工作依据 系统调研和分析成

13、果 数据质量检查规则的依据调研成果的以下内容进行梳理：业务流程、业务逻辑数据逻辑设计报表数据应用3、工作重点 重点报表用到的表进行分析数据质量分析阶段1、工作内容 分析有质量问题数据对现有报表应用的影响 对数据质量问题的成因进行分析和总结 对数据质量问题的解决措施进行分析和总结2、工作依据 数据质量检查结果 源数据与报表依赖关系3、工作重点 重点分析报表平台的1104等报表存在的部分数据质量问题数据质量反馈系统概述建设目标对业务数据进行数据质量检核，准确掌握业务系统各种数据质量问题，促进基础业务数据质量的提高建设内容 质量检查规则定制 实现质量检查规则的灵活定制 数据质量检查 系统按照预定义的

14、数据质量检查规则，对数据的准确性、有效性、关联性、一致性、及时性进行检查，生成并保存的数据质量检查信息。数据质量分析报告 生成不同类型的数据质量检查报表，对不同的数据质量问题进行分析和展示 架构和功能系统架构数据质量检核与反馈系统检核对象管理导入、查询、修改、删除检查对象检核规则管理新增、删除、修改检核规则检查频度管理制定检查周期和时间权限管理用户建立权限管理问题报告问题查询规则查询打包下载.问题管理维护并管理发现的数据质量问题日志查询报告管理功能分类功能名称功能说明检核对象管理对象编辑修改导入表，修改表和字段的相关属性检核规则管理有效性灵活定制自定义检核规则，实现可视化规则配置和管理关联性一

15、致性准确性及时性检查频度管理检核频度管理质量监控周期频度，可按日、周、月、年等频度制定检核时间问题管理 问题管理对发现的数据质量问题进行进一步的描述和分析，并划分问题归属业务分类报告管理 报告管理质量问题报告查询，并可按照部门、系统、问题进行汇总查询系统管理权限管理管理员、操作员权限设置检核对象配置管理需检核的表系统功能调度管理整合层汇总层集市层贴源层数据质量检查及反馈系统界面数据质量管理建议通过逐套的解决报表数据质量问题，以数据标准为依据，来切实解决基层手工修改报表的问题源头负责制，谁录入谁修改操作层面数据纠错管理层面形成数据质量管理的机制：发现问题，定位问题，解决问题的管理流程IT系统建设

16、层面将数据质量问题检查规则固化到系统中，形成数据质量台账，为解决数据质量问题和考核提供依据数据平台项目建设目标1、发现数据质量问题，推动数据治理工作的开展，建立数据质量检核系统 对源系统进行数据质量检核，发现数据质量问题并统计影响到的报表 对数据质量问题进行归类总结，分析成因和改进建议 建设数据质量检核系统2、分析、梳理业务系统，推动数据标准的建立，统一全行口径 建立基础标准和指标标准框架 确定标准化范围，对重要属性进行标准化3、建立数据仓库模型框架，优化我行数据架构，建设稳定、可扩展的数据仓库 引进业内具有先进水平的金融数据模型，进行客户化改造后，建成符合某行特点的数据仓库模型框架 覆盖某行

17、主要业务系统数据，以便快速高效的为应用系统提供数据 存储历史数据，解决新报表上线才有数的问题。汇总层建设（共性加工）数据标准梳理及归纳数据标准梳理及归纳对我行日常业务开展过程中所产生基础性数据，从业务方面、技术方面、管理三个方面，对数据的业务表达、数据格式、数据关系等方面进行一致约定，从而规范数据在全行内外共享和使用中的一致性和准确性 对数据的管理、应用过程进行统一和规范，明确数据的定义、格式、规则以及数据与数据间的关系 为系统开发实施提供全行统一的规范准则 为数据加工和应用提供统一来源和依据作用定义定义通过对我行经营管理资料的分析，并参考同 业的类似成果以及监管部门要求，梳理 和筛选出直接反

18、映我行业务经营管理 状态的重要指标，并对指标的业务 含义、业务规则、统计口径等内 容进行标准化定义，形成全行一 致的指标数据标准作用 统一全行对各项经营指标的理解和 认识，促进各项经营指标在经营管理 决策中的运用；统一全行指标标准的业务含义、计算口径等内容，从而解决我行取数口径不一致、业务含义不清晰、指标分类不清晰的情况，促进部门间数据共享目标建设方法-数据标准解决的问题数据孤岛数据质量制定了全行统一的标准，实现了业务数据信息统一定义，统一命名、统一来源对于数据质量造成的数据准确性、一致性等问题，找出造成这些问题的原因，违背业务和约束的数据不进入标准体系中举例例如：在标准制定过程当中，对于业务

19、数据之间关联不上的问题，首先要找出关联不上的原因，之后通过和业务人员的有效沟通，制定出以哪一类数据为准的标准，比如信贷管理系统的贷款余额和核心系统的贷款余额不一致，在制定“协议金额”标准的过程当中，必须明确以那个系统的贷款余额为准，且以此贷款余额制定全行标准，从而解决此类问题。例如：不同部门的贷款余额由于取数来源不同而造成差异，通过建立完整的分析数据标准体系后，统一了业务定义和取数口径，有利于全行范围内重复利用，杜绝出现各业务部门多次重复定义类似的指标，并且因为标准的权威性和标准的严格管理，有效防止指标定义和口径的二义性。目标建设方法-数据标准-建设步骤基础数据标准指标数据标准分析数据标准发布

20、执行标准映射数据源和基础标准数据映射数据源和分析标准数据映射标准执行标准定义数据标准基础数据标准发布执行业务定义、业务规则、业务含义、计算口径 业务含义、业务规则、业务描述、数据来源目标建设方法-数据标准-建设内容1.现状分析2.标准定义3.标准映射4.执行建议目前存在问题业务访谈系统调研结合最佳实践分析、诊断形成标准化定义初稿和框架对定义初稿征求意见和讨论根据意见反馈和讨论结果和修正并形成数据标准确定映射的系统范围制定源系统与标准的映射规则根据数据验证映射规则提出标准在未来各影响面执行的遵循原则就标准与现状的实际差异给出具体的执行建议目标建设方法-数据标准-基础数据标准调研调研分析业务字段源

21、业务系统分析调研记录整合层模型数据质量反馈主题实体属性实体属性实体属性代码主题实体属性实体属性实体属性地址主题实体属性实体属性实体属性渠道主题实体属性实体属性实体属性财务主题实体属性实体属性实体属性事件主题实体属性实体属性实体属性当事人资产主题实体属性实体属性实体属性产品主题实体属性实体属性实体属性协议主题实体属性实体属性实体属性当事人主题实体属性实体属性实体属性源系统表名字段名业务含义业务规则业务描述是否代码对应主题对应实体对应属性核心客户信息客户名称否xxxxxxxxxxxxxxxxxxxx实体属性信贷管理贷款客户信息贷款客户名称否xxxxxxxxxxxxxxxxxxxx客户对公客户对公客

22、户名称核心贷款分户账表贷款余额否xxxxxxxxxxxxxxxxxxxx协议协议金额表贷款余额信贷管理贷款借据表贷款余额否xxxxxxxxxxxxxxxxxxxx信贷管理贷款展期台账贷款方式是xxxxxxxxxxxxxxxxxxxx协议贷款展期信息表抵押方式协议贷款信息表贷款方式信贷管理贷款基本信息贷款方式是xxxxxxxxxxxxxxxxxxxxXXXXXXXXXXXXxxxxxxxxxxxxxxxxxxxxXXXXXXXXXXXX模型匹配整合1、名称不同，业务含义相同2、名称相同，业务相同3、名称相同，业务含义不相同目标建设方法-数据标准-基础数据标准框架梳理源系统表名字段名是否代码.业务

23、含义业务描述业务规则对应主题对应实体对应属性基础数据标准框架梳理筛选保留重命名分类整合合并参考补充分析调研记录协议xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx协议贷款贷款余额xxxxxxxxxxxxxx信贷管理xxxxxxxxxxx标准分类标准主题标准中文名称标准英文名称标准依据相关标准标准管理部门业务规则业务描述数据类型长度业务含义源系统数据格式客户对共客户客户名称xxxxxxxxxx信贷管理xxxxxxxxx协议账户合同贷款账户存款账户参考：1、同业标准体系框架2、TD模型的结构与分类目标建设方法-数据标准-基础数据标准定义及确认xxxxxxxxxxxxx

24、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx标准分类标准中文名称标准信息类业务规则业务描述数据类型长度标准依据相关标准标准英文名称业务含义源系统标准管理部门数据格式xxxxxxxxxxxxxxxxxxxxxxxxxxxxx代码标准方案技术人员业务人员整合.定义补充.完善补充.完善沟通.确认技术部分业务部分基础数据标准沟通.确认基础数据标准化方案目标建设方法-基础标准-制定框架 基础数据标准框架属性参考人民银行标准规范文档和他行标准，由3部分22个属性项组成，分别为业务属性、技术属性、管理属性。目标建设方法-基础

25、标准-指标标准建设思路3、制定指标标准（1）指标分析：分析指标的定义、口径、规则、数据来源等内容（2）标准技术定义：技术部门逐项定义指标标准化属性（3）标准业务确认：业务部门修订、确认指标标准2、制定指标标准框架（1）梳理、确定指标分类体系（2）梳理、确定指标标准属性，形成指标标准化定义模板1、筛选重要业务指标（1）研读经营管理资料，梳理重要指标列表（2）参考外部资料，补充完善指标列表（3）讨论指标列表，筛选、确定指标范围目标建设方法-基础标准-指标标准筛选方法1、研读经营管理资料2、参考外部资料3、筛选、确定指标范围经营管理资料：l 行领导讲话l 我行各业务部门的业务经营分析报告l 我行的各

26、类管理报表筛选原则：l 反映我行规模、风险、盈利、业务增长等各方面业务状况的典型指标l 口径稳定不易变化的指标外部资料：l 同业相关建设资料l 城商行银行l 国有银行建设银行l 人民银行、银监会监管指标要求筛选原则：l 监管部门有强制监管要求的指标l 同业用到，与我行业务有关的指标筛选、确认方式：l 项目组内部讨论筛选l 外部需求调研，进行补充和确认目标建设方法-基础标准-指标标准框架制定方法1、梳理、设计指标分类体系2、设计标准化属性设计依据：l 指标的业务共性的归纳及提炼l 参考行内资料l 我行业务分类l 源业务系统操作手册及业务简介文档l 统计集中系统指标分类l 参考外部资料l 监管部门

27、的管指标及指标分l 同业相关资料的指标分类设计原则l 分类体系覆盖筛选出的所有业务指标，并能为每个指标确定唯一的分类l 易于根据业务和指标变化进行扩展设计依据：l 人民银行JRT 0105-2014银行数据标准定义规范l 外部资料设计原则：l 可以从业务、技术、管理不同角度对标准进行全面定义l 对指标标准必须清晰、明确l 满足未来对满足标准进行管理的需要目标建设方法-基础标准-指标数据标准框架指标数据标准框架业务属性技术属性管理属性指标中文名称指标英文名称指标范围类别计算公式业务规则相关指标标准是否手工录入显示精度指标落地系统数据来源系统数据源表数据格式度量单位取值范围归口业务部门业务负责人技

28、术负责人反馈结果描述指标编码指标别名指标定义指标大类指标小类指标来源口径明细取数口径相关基础类数据标准指标生成频度取值精度指标应用-高管驾驶舱指标总览主驾驶舱经营概览专项分析热点地图 从经营概况到具体指标分析今日快报全行7项核心业务指标的展现和分析最重要3项监管指标进行展现和分析指标总览按分类展现全部指标的本期值及与往期的比较值的列表经营概览对某一具体指标进行比较、结构、趋势等方面的分析专项分析从业务角度对一组反映类似业务的指标进行分析热点地图显示全国地图，可以展示各一级分行重要的经营简报数据我的指标规模分析利润分析风险分析主驾驶舱选取13个行领导重点关注的指标展示我的指标根据用户对指标的重视

29、程度，实现指标的个性化定制功能简介指标应用-高管驾驶舱-界面截图数据平台项目建设目标1、发现数据质量问题，推动数据治理工作的开展，建立数据质量检核系统 对源系统进行数据质量检核，发现数据质量问题并统计影响到的报表 对数据质量问题进行归类总结，分析成因和改进建议 建设数据质量检核系统2、分析、梳理业务系统，推动数据标准的建立，统一全行口径 建立基础标准和指标标准框架 确定标准化范围，对重要属性进行标准化3、建立数据仓库模型框架，优化我行数据架构，建设稳定、可扩展的数据仓库 引进业内具有先进水平的金融数据模型，进行客户化改造后，建成符合某行特点的数据仓库模型框架 覆盖某行主要业务系统数据，以便快速

30、高效的为应用系统提供数据 存储历史数据，解决新报表上线才有数的问题。汇总层建设（共性加工）数据仓库层次架构主题 主题是模型按业务划分的最顶层的分类 根据我行业务实际，划分10个业务主题逻辑视图（子主题）逻辑视图是根据实体涉及的业务，将实体划分为不同子集 同一实体可属于不同逻辑视图实体 实体是一组具有业务相关性的属性组成的集合，是描述和构成业务逻辑、业务流程的基本单位 一个实体可能涉及多类业务属性 模型最明细一级结构 对应具体的业务数据项（字段）共性提炼分类分层数据仓库层次架构风险评级主题逻辑视图实体属性当事人主题当事人主题当事人主题当事人主题当事人主题内部机构对公客户对公客户信息对公客户管理信

31、息不良贷款信息对公客户领导信息对公客户资本金构成财务信息客户名称所属领域注册资本企业规模法人代表基本账户开户行机构信息数据仓库模型设计方法TD模型基础模型逻辑模型物理模型TD模型业务剪裁保留与我行业务有关的主题、实体和属性删除与我 行业务无关的主题、实体和属性根据我行业务实际需求对主题进行新增和合并逻辑模型设计复制：系统间业务含义、名称均不重复的字段整合：系统间业务含义相同的多个字段拆分：系统间业务含义不同，名称相同的多个字段物理模型设计当前业务及数据都支持的实体进行理化当前业务不支持或数据不支持的不进行物理化入仓源表及字段范围模型映射目标的建设方法-数据仓库模型框架l 整合层模型设计-基础模

32、型（业务匹配）基础模型是TD模型在我行进行初步客户化后的产物。将TD模型的主题和实体，与我行的实际业务行的实际业务进行对比分析，根据匹配结果对TD模型进行裁剪、合并和扩充，形成匹配我行实际业务的情况的模型框架。营销主题当事人主题Teradata金融模型10.0当事人资产主题产品主题事件主题协议主题地址主题渠道主题内部组织主题财务主题基础模型我行无关业务我行现有关务我行未来关务我行现有业务我行无关业务我行未来业务对公客户合同机构个人业务营销活动保险投资合并当事人主题当事人主题保留内部组织主题营销主题保留增加当事人资产主题产品主题事件主题协议主题地址主题渠道主题财务主题代码主题数据质量反馈业务匹配

33、目标的建设方法-数据仓库模型框架l 整合层模型设计-属性匹配 对源业务系统的字段进行梳理分析，筛选出具体业务价格的字段，将业务字段与基础模型的主题、实体和属性进行匹配分析，根据匹配结果对基础模型的实体、属性进行增删。实体属性基础模型源业务系统业务字段分析匹配?新增属性实体属性保留（整合）并映射新增并映射？沟通确认未来业务相关则逻辑化保留未来业务无关则删除数据仓库模型数据质量反馈主题实体属性实体属性实体属性代码主题实体属性实体属性实体属性地址主题实体属性实体属性实体属性渠道主题实体属性实体属性实体属性财务主题实体属性实体属性实体属性事件主题实体属性实体属性实体属性当事人资产主题实体属性实体属性实

34、体属性产品主题实体属性实体属性实体属性协议主题实体属性实体属性实体属性当事人主题实体属性实体属性实体属性逻辑模型设计-主题划分当事人资产渠道财务产品地域协议事件代码当事人逻辑模型设计-当事人主题当事人是一个独立的人或者一组人组成的机构、团体等，主要分为个人、机构和家庭，他们是和我行有往来或者出于营销、管理等各种需要希望关心和分析的个体或人群。从模型角度考虑，应该包括以下当事人信息：在我行登记注册开立账户的对公普通客户；我行担保客户和我行有业务往来的其他金融机构；机构的内部组织（如分支机构、部门等）；机构的员工（含我行柜员、员工等）；个人信息联系信息关联信息财务信息风险信息评价信息集团信息柜员信

35、息公司信息内部机构外部机构粮棉油对全行客户进行统一识别与数据整合当事人个人当事人家庭机构内部员工柜员外部组织机构内部机构金融 机构（同业）对公客户其它内部组织金融机构内部组织协议地址产品当事人渠道反馈域财务事件当事人资产代码逻辑模型逻辑模型设计-代码主题代码：是指将源业务系统所涉及到的所有代码进行整合，在整合层模型中统一存储，依据前端应用需求的需要，将代码主题的整合分为两大类：简单代码表和复杂代码表，简单代码表指的是只需要关注代码值和代码值业务含义描述；复杂代码表指的应用需求除关注代码值和代码值业务含义描述外，该代码表的其他属性也有应用需求，同样需要关注，这样的码表将作为普通的数据表对待；自定

36、义代码，是属于简单码表的一种。简单码表复杂码表自定义代码分类模式编码表当事人类代码表公共类代码表分类模式枚举值编码表协议类代码表资产类代码表源和目标代码映射关系表事件类代码表财务类代码表对全行业务代码进行统一识别代码当事人类代码表事件类代码表分类模式枚举值编码表源和目标代码映射关系表公共类代码表协议类代码表分类模式编码表协议地址产品当事人渠道反馈域财务事件当事人资产代码逻辑模型逻辑模型设计-协议主题协议地址产品当事人渠道反馈域财务事件当事人资产代码协议是指金融机构与当事人之间针对某种特定产品或服务而签立的契约关系，如账户、客户和银行签订的合同等。当金融机构与客户之间针对某种产品或服务的条款和条

37、件达成协议时，一个协议（Agreement）就会被开立，因此协议是客户和银行往来的重要载体，我行模型包括以下协议信息：我行涉及金额、期限、利率等的具体协议细项的金融账户我行与当事人之间针对某种特定产品或服务而签立的金融合约我行在支付结算业务中使用到的各种银行票据：汇票贷款帐户存款帐户贷款合同抵押合同质押合同贷款借据国际结算银行本票银行汇票其他信息银行承兑汇票客户理财签约 银行与客户之间针对某种特定产品或服务而签立的契约关系，将所有协议和关系，整合和归并协议金融账户申请金融合约贷款账户银行票据存款账户内部账户贷款类合约逻辑模型抵质押合同贷款借据项目额度申请贷款申请项目贷款贷款合同抵质押合同押品信

38、息借据还款计划逻辑模型设计-事件主题事件：可以记录各种与银行相关的活动的详细情况。既可以与资金相关，也可以与资金无关；既可以有客户参与，也可以没有客户参与；既可以与帐户相关，也可以与帐户无关；可以由客户发起，也可以由银行发起。总之它可以记录的范围非常广泛，包括交易数据，比如存款、提款、付款、收取信用卡年费、计算利息和费用、投诉、查询产品、查询地址、查询余额、网上交易等。我行模型包括以下事件信息：存款信息、贷款信息；库存管理、现金管理、账户管理、资产管理；资金调拨、支付结算、现代化支付；报文清算、国际业务；外汇、票据、市场交易、十二级分类、核心账务。同业定期存款汇入贷款缩期事件新棉收购进度采集同

39、业定期存款汇出贷款展期事件商品棉贷款信息采集大额支付事件贷款转移事件粮油库存核查小额支付事件分段计息事件棉花农资库存变动该主题可以记录各种与银行相关的活动的详细情况，进行客户行为分析、重大事件侦测等，以便更好的进行客户细分、客户关怀。事件贷款事件存款事件库存管理事件贷款缩期贷款展期分段计息贷款转移商品棉贷款信息采集粮油库存核查同业定期存款汇入同业定期存款汇出新棉收购进度采集 棉花农资库存变动协议地址产品当事人渠道反馈域财务事件当事人资产代码逻辑模型逻辑模型设计-财务主题财务：主要包括银行的总账信息，是描述科目组织、控制、内部核算等银行核心科目账务以及预算管理有关的内容。该主题抽象地描述了银行内

40、部账务的组织模式，能够适应不同的科目组织体系。我行模型包括以下财务信息：总账（分户）总账明细科目/科目组/科目类：对于科目的层次级别设置和管理财务预算总账科目信贷总账科目内外科目对照关系总账日旬余额日明细内部科目余额 科目与产品对照关系总账月余额月明细内部科目余额 日明细外部科目余额外汇准备金科目余额外汇科目损益余额日明细外部科目余额财务主题抽象地描述了银行内部账务的组织模式，能够适应不同的科目组织体系，它侧重于“财务管理”总账科目总账内外科目对照关系科目产品对照关系信贷总账科目总账日旬余额总账月余额协议地址产品当事人渠道反馈域财务事件当事人资产代码逻辑模型逻辑模型设计-当事人资产主题当事人资

41、产：描述当事人的所有资产，该主题包含两大类的资产，既包含我行自有资产又包含客户所拥有的资产。一个资产可以被多个当事人所拥有，一个当事人可以与多个资产有关。资产可分为实物资产、金融资产与无形资产。客户资产信息的来源很多情况下是在客户申请贷款时所提供的各种担保品信息、抵质押品信息等。我行模型包括以下资产信息：银行自有资产，具体又细分为：银行自有无形资产、固定资产、经营性租赁资产、其他资产等；客户自有资产，具体又细分为：客户抵债资产、客户担保资产、金融资产、实物资产、无形资产等。银行自有资产客户抵债资产客户担保资产经营性租赁资产抵债资产房产抵质押物银行自有无形资产抵债资产设备押品外部评估信息银行自有

42、固定资产抵债资产地产押品内部评估信息客户资产信息的来源很多情况下是在客户申请贷款时所提供的各种担保品信息、抵质押品信息等，将这种信息进行整合和归并资产银行自有资产客户自有资产固定资产无形资产其他资产租赁资产客户担保资产金融资产客户抵债资产实物资产抵质资产房产信息交通运输设备协议地址产品当事人渠道反馈域财务事件当事人资产代码逻辑模型数据映射和ETL开发源表映射文件目标表开发规范合并拆分复制ETL业务含义不同，名称相同，进行拆分业务含义相同、名称不同，进行合并业务含义相同、名称相同，进行合并转换生成新键值代码值转换数据类型转换值域转换值转换ETL开发人员按照映射文件中规定的映射逻辑要求，结合开发规

43、范，编写作业，通过数据源分析，制定加载策略，开发JOB调度直接拷贝加载策略数据源分析常量赋固定值1表间关联/单表操作（LeftJoin,InnerJoin,FullJoin,Union）映射文件通过映射文件，确定表间关系数据映射和ETL开发l 定义源：配置作业源表的表名、表结构等信息l 创建映射：根据作业详细设计中表与表之间及字段之间的映射关系，使用相应的组件实现其数据转换逻辑l 定义目标：配置作业目标表的表名、表结构、加载方式等信息定义源创建映射定义目标项目提交物（总共108项交付文档）目标的建设方法-数据仓库模型框架（4）l 整合层模型建设对应用的支撑整合层的稳定性整合层提供全行统一的业务

44、视图整合层的数据全面性整合层提供明细的数据整合层保留完整的历史数据保证模型对未来业务的业务支持的快速响应，不需要随业务的变化而频繁调整整合层模型形成明确业务含义和数据来源，确保字段业务定义的唯一性，形成全行统一的业务视图保留了业务系统中最细粒度的业务数据，保证整合层可以支持明细级的数据查询和分析应用整合层涵盖我行主要源业务系统的业务信息，提供全面的业务数据，可以为客户、风险、绩效等各类分析应整合层中可以完整保留业务系统的历史数据，保证了对历史类查询分析的支持客户360度统一视图通过整合层模型落地60 贷款 存款 中间业务 利润贡献关联关系 联系人/关键人 统一客户关联 信息视图客户客户360度

45、度统一视图统一视图客户额度信息客户额度信息联系人联系人/关联信息关联信息客户大事记客户大事记交易信息交易信息理财产品信息理财产品信息产品产品/账户信息账户信息国际结算信息国际结算信息资本构成资本构成/股权投资股权投资客户财务信息客户财务信息客户基本信息客户基本信息客户合作协议客户合作协议其它信息其它信息客户基本信息客户额度信息客户财务信息客户关联信息客户关键人信息客户联系人信息客户上市信息客户存款信息客户贷款信息账务交易信息账户日均余额客户考核利润客户管户信息国际结算信息网银交易信息机构信息 整合层模型对客户营销的支持当事人主题协议主题事件主题CRM-客户贡献度分析核心信贷管理对公客户表 客户

46、表存款账户表存款交易明细表客户号客户名称存款余额借据表贷款余额季度存款交易量。债项评级。五级分类同一客户信息整合整合层模型营销策略-客户贡献度分类：存款余额大于xx万，贷款余额大于xxxx万，并且属于正常贷款，且季度存款交易量大于xxx条的为A客户；存款余额大于xx万，贷款余额大于xxxx万，并且属于正常贷款，且季度存款交易量大于xxx条的为B客户；存款余额大于xx万，贷款余额大于xxxx万，并且属于次级贷款，且季度存款交易量大于xxx条的为C客户；通过客户贡献度的分类，制定营销策略，比如贡献度为A的客户，可进行贷款利率上的优惠或存款利率的上浮的方式稳定此利润点客户贡献度分类整合层模型对客户营

47、销的支持当事人主题协议主题事件主题核心信贷管理对公客户表 客户表存款账户表存款交易明细表借据表。债项评级。同一客户信息整合整合层模型营销营销CRM-客户忠诚度分析客户号客户名称是否基本户账户日均余额贷款期限贷款金额现金流量是否异常账户睡眠时间业务量是否异常客户忠诚度分类营销策略-客户忠诚度分类：通过客户忠诚度的分类，忠诚度越大、则是我行重点的目标客户，可作为战略重点客户。如果忠诚度不大，则要进行重点客户关系维护，即精准营销汇总层目标与定位 作为整合层和集市层的衔接，从业务的视角出发，提炼出对数据仓库具有共性的数据访问需求，抽取出公共指标，形成由维度和指标组成的维度模型，对符合要求的数据进行预汇

48、总和预加工。为集市层统一提供规范的、准确的数据。完成整个汇总层的逻辑模型、物理模型的设计并全部实现物理化。并根据业务性质将业务数据，划分为以下七大类主题分类存放和管理建设阶段和步骤2.2参考模型到数据源的匹配2.1数据源到参考模型的匹配1.2当前用到的属性分析1.1参考模型设计3.1物理模型设计一、逻辑模型初步设计二、逻辑模型具体设计三、开发实现2.3应用驱动模型完善业务驱动循环客户需求调研逻辑模型设计3.2数据映射3.3ETL个人、存款、贷款、贷款、信用卡建设重点1.协调业务系统开发商对系统进行讲解，了解具体的业务流程并对开发人员整理出的源业务系统调研提纲中所提出的问题进行解答2.对源系统表

49、对象调研3.对源系统表字段调研4.根据源系统数据验证调研结果5.依据调研结果对模型进行属性的补充完善2.源表调研3.源表字段调研4.验证调研结果1.源系统调研存储策略n 设计思想将汇总层划分为两个存储区域，数据集市应用从历史数据区和快照区获取数据。历史数据区数据集市数据集市数据集市快照区（T-1日，数据日期）应用层数据存储区ODS层、整合层月表历史区流水类表第四部分成效和特点项目成效-中长期价值项目建设特点-多方参与，字段级加工整合层模型业务字段业务答疑业务调研技术调研数据调研模型映射ETL加工结果验证源业务系统公司方业务人员技术人员源系统厂商技术答疑技术讲解业务相关标准定义业务相关标准确认技

50、术相关标准定义技术相关标准确认模型验证数据质量检查分析标准化分析标准映射源系统答疑源系统讲解资料提供系统调研ETL数据质量数据标准项目建设特点-分工协作，共同推动（1）本期项目建设实施过程遵循“技术先行，业务配合”的原则，需要技术部门主导、业务部门解决数据“如何整合”的问题，合作公司解决数据“是什么”的问题技术人员提交标准后，对应的业务部门人员需确认结果,对有异议的结果进行修改和补充，这个过程可能需要经过多次反复确认，从而制定最终的标准化产物并发布，形成全行标准项目建设特点-分工协作，共同推动（1）n 业务部门解决数据“如何整合”的问题 业务部门需要确认技术部门提出的整合规则（标准）是否合适，