商业银行数据架构建设研究报告.docx
《商业银行数据架构建设研究报告.docx》由会员分享，可在线阅读，更多相关《商业银行数据架构建设研究报告.docx（18页珍藏版）》请在冰豆网上搜索。
商业银行数据架构建设研究报告
商业银行
数据架构建设研究报告
目录
1建设目标和意义3
1.1概述3
1.2建设目标3
1.3建设意义4
2数据构架整体规划4
2.1当前数据架构所面临的问题与挑战4
2.2架构建设原则5
2.3数据架构整体规划6
2.4整体解决方案8
2.5数据处理和存储架构8
2.5.1接口文件区8
2.5.2数据仓库8
2.5.2.1细节数据暂存区SSA（SORStagingArea）8
2.5.2.2细节数据SOR（SystemOfRecord）9
2.5.2.3汇总数据区Summary9
2.5.2.4反馈数据区（FeedbackArea）9
2.5.2.5元数据存储MDR（MetaDataRepository）9
2.5.3数据集市和多维立方体9
2.6数据治理平台规划11
2.7数据标准平台规划11
2.8数据质量管理平台规划12
2.9元数据管理平台规划14
2.10业务与科技能力要求15
2.10.1安全与保密15
1建设目标和意义
1.1概述
国内股份制商业银行经历了近些年的高速扩张和发展，无论在客户群体和业务量上都有了庞大的增长，这推动了银行信息化建设的力度。
各商业银行均投入大量的人才财力物力举全行之力大力推进银行的信息化建设，这使得银行构建了大量的业务系统，包括：
核心系统、个贷系统、对公贷款系统、国际结算系统、网上银行、前置系统等等，这些系统内积累了大量的业务数据，而这些业务数据相对独立，信息共享困难，无法从整个企业和单一视图的角度对数据进行深入分析和挖掘，无法为高层管理和决策提供强有力的依据，无法满足快速变化的市场的需求。
基于此，股份制商业银行纷纷开始构建数据仓库，以业务支撑应用系统的数据以及其他相关数据作为基础数据源，采用科学的数据抽取、整理、存储等方法，建立企业级数据仓库；然后通过丰富的数据分析和挖掘方法找出这些数据内部蕴藏的大量有用信息，对客户、业务、市场、收益、服务、等各方面情况进行科学的分析，从而为市场决策管理者和市场经营工作提供及时、准确、科学的辅助决策依据。
数据架构设计作为数据仓库技术中的一项根本性基础工作，是对系统逻辑体系结构和建模方式的描述，直接决定了数据仓库系统的可管理性和可扩展性，在数据仓库系统的建设过程中具有极其重要的作用。
1.2建设目标
数据架构顾名思义是数据的架构，是研究数据质量、标准的，是确定数据如何存放、流转、分发的。
数据架构要支撑上层业务分析应用。
在数据仓库的建设过程中，数据架构的建设目标包括：
•业务层面
>构建适合股份制银行统一模型，建立业务/客户/产品统一视图
>实现跨部门、跨系统分析，支持现有的各类应用
>支持业务报表、经济资本管理等业务应用
>为各分支机构提供数据支持
•系统层面
>建立统一的、共享的基础数据平台
>保证数据的一致性、可用性和扩充性，提升数据质量
>集成核心、信贷、国业、前置等重要系统的数据
•技术层面
>建立具有先进性、灵活性和可扩展性的企业级数据仓库的总体架构
>建立一套完善的ETL体系完成数据抽取、清洗、加载与转换
•管理层面
>实施平台管理、数据库管理等系统管理
>借助于数据仓库项目建设和维护方法论，完善项目不同阶段的管理
>建立数据标准，制定全行统一的数据标准
>建立数据存储策略和生命周期及集成架构
>建立数据质量管理，推动业务系统改善数据
>建立数据安全机制，确保核心数据的安全性
1.3建设意义
数据架构的建设意义如下：
✓使银行高层领导能够从全局角度出发，推动企业数据的统一规划，便于业务人员对企业数据的分析与理解。
✓可以形成企业的概念模型，帮助企业人员更好地理解业务的核心概念和业务之间的关系。
✓可以明确各个业务部门之间的关系和在分析应用工作中的主要职责，有利于实现统一的报表体系规范，便于实现企业的运营指标分析和统一的口径。
✓形成有效的数据管理体系，保证企业在业务部门众多，内部数据和外部数据复杂的情况下，数据只有唯一事实的特点。
✓可合理利用银行的软硬件资源，统一规划数据存储，避免资源浪费
✓可有效推动业务系统数据质量的提升，尽早发现存在的风险。
2数据构架整体规划
2.1当前数据架构所面临的问题与挑战
当前部分企业采用的数据架构：
当前所面临的挑战有：
✓重复数据太多。
这些重复数据的作用都是相同的吗？
重复的数据占用了更多的存储，增加了硬件和维护的成本。
✓业务系统繁多，数据量重复导致数据量过大，当业务人员需要统一分析某些指标时，相关数据的可访问度很差，既增加了等待的时间，也极易造成结果的不一致性
✓业务系统繁多，数据架构复杂，数据流处理周期过长，增加了数据处理的成本，也增加了出问题的几率
2.2架构建设原则
侧重与数据的采集、处理、输入、输出、管理，以及数据的流向、关系、分布等。
重点：
✧确保系统的整体性能
✧确保架构符合银行业内部的IT信息整体规划和各种规范
✧数据共享使用
✧避免数据冗余和数据复制
✧数据集中化处理
✧数据标准统一、质量可靠
✧确保系统的可扩展性
✧确保系统的可用性
✧确保系统的可靠性
✧确保系统的数据安全性
✧确保系统的合理成本投入
架构设计中需要考虑的7个方面：
✧数据量
✧数据易变性
✧数据的生命周期
✧查询的易变性
✧查询的复杂性
✧跨产品跨部门等的功能性需求
✧访问的并发性
数据架构建设的基本要素如下：
2.3数据架构整体规划
在进行数据架构设计时，要遵循上面提到的原则，结合银行的实际情况，将数据架构的要素都囊括到整体规划中。
数据架构包含内容众多，是一项循序渐进的工作，一般采用迭代式的实施理念，3－5年的开发规划。
整体规划如下：
2.4整体解决方案
上面的整体解决方案中包含如下几个部分：
数据处理设计：
数据流架构定义了数据源、数据处理的阶段、各阶段的输入输出及数据的生命周期。
在整体解决方案中，数据源定义为银行内部的所有重要和必要的业务系统，也包括从外部采集的市场数据。
数据处理阶段包括数据暂存区、细节数据存放区、汇总数据存放区、数据集市存放区、数据反馈区、操作型数据存放区等。
数据管理设计：
根据各数据阶段的定位和数据的价值，定义各数据阶段数据的存放周期、清理原则和策略、数据存放的粒度。
制定统一的数据调度策略、运维监控策略。
数据治理设计：
制定全行级的数据标准规范和流程。
制定详细的数据质量管理平台。
制定合理的元数据管理平台，将所有重要的数据都管理起来，消除数据的二义性，做好血缘分析和影响性分析。
2.5数据处理和存储架构
数据处理架构描述数据在数据仓库系统内如何组织和存储。
数据处理架构的主要模块如下图所示：
2.5.1接口文件区
接口文件区是存储和处理接口文件的区域，如前面章节所述，接口文件区在Unix系统下按照特定的目录结构组织起来。
用Unix的一些系统命令和工具来管理。
对每个目录按照其特定的用途设定对不同用户的访问权限，比如谁能读，谁能写，谁能改等。
2.5.2数据仓库
2.5.2.1细节数据暂存区SSA（SORStagingArea）
SSA的主要目的是支持把接口文件的装载到数据库，对其进行验证和处理，然后把数据整合到SOR内。
验证的方法主要是将新转载的数据与SOR内已有的数据进行查找和比较。
SSA内数据结构的设计原则是最大限度的利用接口文件的数据结构，尽量降低实体的个数，同时很好的支持后续的ETL过程。
当然在物理表的设计上也要考虑数据库的特性。
SSA里面的表的用途基本都是临时的，每次数据装载都会清空，因此对这些表的处理可以不记日志，以加快处理速度。
2.5.2.2细节数据SOR（SystemOfRecord）
SOR是基于BDW开发的一套符合3NF范式规范的表结构。
SOR存储了数据仓库内最细节层次的数据，按照不同的主题域进一步分分类组织。
此模型是整个数据仓库数据模型的核心，其设计为具有足够的灵活性，以能够应对添加更多的数据源，支持更多分析需求，同时也能够支持BDW进一步升级和更新。
2.5.2.3汇总数据区Summary
汇总数据区是为了方便查询和后续多维数据的更新，创建一些常用的中间汇总表，以提高性能和降低后续ETL工作的复杂性。
由于SOR是高度规范化的数据，因此要完成一个查询需要大量的关联操作；同时数据集市中的数据粒度往往要比SOR高很多，对要成生数据集市所需数据也需要大量的汇总计算，因此如果我们把常用的数据预先关联和汇总好，并让其尽量多在多个数据集市的计算中共享，就能大幅度的提高整个ETL工作和数据仓库查询的性能。
2.5.2.4反馈数据区（FeedbackArea）
反馈数据区主要记录的是数据仓库自身生成的结果。
比如用户对营销活动的反馈等。
数据仓库的特性决定了用户在原则上不能直接修改数据仓库中的数据，因此用户的修改数据和其它生成数据必须单独记录，以便于追踪历史和进行比较。
2.5.2.5元数据存储MDR（MetaDataRepository）
元数据存储用来保存关于数据仓库中的过程、数据的信息（日志、数据词典、配置信息等）。
由于各个工具和系统都会生成自己的元数据，同时我们还利用元数据管理工具把这些元数据尽可能的集中存储到数据仓库中的MDR内，因此MDR总的来说只是一个共享元数据供用户集中访问的地方，真正元数据的维护地还是在生成这些元数据的系统或工具内。
2.5.3数据集市和多维立方体
多维数据存储包含一系列多维数据模型（符合星型模式或雪花模式的关系表）。
多维模型尽量采用星型模型。
维表设计为完全反范式化的，维相关的所有层次都合并到最底层的维表内。
当创建数据集市时，要遵守以下的设计原则：
1.数据将会从企业数据仓库里进入数据集市里，为了具体的分析应用，数据将会被重新转化。
2.用多维建模技术创建数据模型。
3.事实表里的键不能包含空值。
4.数据库将会为查询进行优化。
5.如果有可能，企业数据仓库里的关键值将会被重用。
6.ETL的应用程序用来维护参照完整性。
这个环境将提供最大的可用性。
2.6数据治理平台规划
商业银行数据治理的内容，主要包括建立数据治理机制、数据管理制度及流程，以及数据标准制定等。
数据治理的最终目的是提升数据质量，通过有效的数据整合、数据应用与数据服务使企业真正具备业务信息化管理能力。
其中数据应用与数据服务包括面向财务管理、风险管理、绩效考核、客户营销四个方面的支持。
数据治理需从组织架构、管理流程和操作规范、IT应用技术、绩效考核支持四个纬度，对企业数据模型、数据架构（包括数据仓库、数据应用）、数据管理（包括数据质量、数据标准、元数据管理、数据安全等）、数据生命周期等各方面进行全面的梳理、建设并且持续改进。
可以简单概括为：
明确数据治理主体、建立数据质量标准、加强数据生命周期的全过程管理。
数据治理需要动员全行的力量，在行内达成共识，构建合理可行的治理方案。
部门
职责
第一层
各业务部门
负责本条线的数据标准制定和数据质量管理
第二层
科技部、计财部
数据治理小组牵头部门，负责数据标准实施的管理和组织推动，以及数据质量的综合管理
第三层
审计部
负责数据管理、数据应用、数据服务过程的审计、监督、评价
第四层
行高层领导
宏观把握管理，提要求，定方向
2.7数据标准平台规划
2.8数据质量管理平台规划
数据质量是数据仓库的生命，要保证数据仓库的可用性必须保证数仓库内的数据质量。
由于数据仓库内的数据时随着时间的推移、ETL任务的运行动态变化的，因此数据仓库的数据质量也体现在静态和动态两个方面。
静态的数据质量是指ETL逻辑和程序的正确性。
比如指标的计算规则、数据的清理规则、数据的汇总方法、ETL程序的实现，都必须是正确的。
动态的数据质量是指随着ETL程序周而复始的运行，数据仓库内的数据质量必须随时保持可度量和可接受。
可度量是指必须能够有定量化的指标随时对当前状态下的数据仓库的数据质量做出评估。
可接受是指数据仓库内数据的准确性必须随时保持在可接受的范围内。
这就要求在ETL的实现中，不仅在开发阶段要通过完善的数据质量测试来测试计算规则、程序逻辑等来保证数据仓库的静态质量。
同时必须建成数据仓库质量保证机制来使得数据仓库内的数据质量成为可跟踪的和可接受的。
数据质量管理是一个迭代的过程，包含了数据质量管理范围的确定，数据质量问题的识别和数据质量问题的解决以及数据之的监控,数据质量的解决流程涵盖了数据质量管理中的所有环节，包含了数据问题的发现、影响分析、原因探索和解决:
Ø数据质量问题不可能全部解决
Ø数据质量解决流程中应该包含数据质量的监控
Ø基于数据质量问题的影响和解决的难易程度决定解决的优先级
主要的数据质量检查包括以下几个方面：
检查级别
检查内容
是否访问用户数据库
输入项
文件/表级检查
文件名是否符合要求
需要
1、待检查的数据文件
2、检查规则
3、校验文件
文件是否能正常打开或表能否正常访问
文件大小是否正常
文件所包含的记录数是否正常
记录级检查
数据类型和格式检查：
1．日期型数据是否符合要求的日期格式
2．数值型数据是否含有非数字的非法字符
3．其他特定格式的字符型，例如某个字段的起始5个字符必须为‘AAA’
需要
1、待检查的数据文件或表
2、检查规则
值域检查：
待检查的字段取值是否在要求的取值范围区间内
编码规范性检查：
检查编码字段是否完全在引用表的记录中
需要
1．待检查的数据文件
2．检查规则
3．用户数据库中的码表
主键检查：
检查数据文件中作为主键的字段是否唯一
需要
1．待检查的数据文件
2．检查规则
3．用户数据库中的表
外键检查：
检查数据文件中作为外键的字段是否都在作为参照的表中
需要
1．待检查的数据文件
2．检查规则
3．用户数据库中的表
业务指标检查
根据源数据提供方的业务指标校验结果，检查接收到的接口数据生成的指定的业务指标值是否有误
需要
1．待检查的数据文件
2．检查规则
3．业务指标校验文件
业务指标真实性稽核
利用统计学原理与方法针对上传数据生成的业务指标KPI，检查是否正确、合理；根据各指标之间的计算规则，进行指标值的平衡检查；
需要
1．待检查的数据文件
2．检查规则
3．用户数据库中的表
2.9元数据管理平台规划
元数据的管理和存储将会用到文件系统、建模工具、数据库等多种途径。
在数据仓库内，元数据可以被分成三种类型：
业务、技术、和操作型元数据。
1.业务定义（业务元数据）
业务元数据在业务层面最终用户感兴趣的元数据，通常包括业务指标的含义、计算规则，数据概念分类，属性的业务含义等。
2.技术规范（技术元数据）
技术元数据是指支持数据仓库运行的各种技术定义和规范。
它通常是各种配置信息，较少直接被最终用户访问。
比如表的定义，ETLJob的配置，调度信息等。
3.操作状态（操作型元数据）
操作元数据是指数据仓库运行中各个组成部分的实际状态和日志。
它记录了整个数据仓库运行的过程，方便对数据仓库进行跟踪和调试。
这类元数据通常存储在用户定义的表内。
比如数据仓库的各种统计信息，ETL运行日志等。
2.10业务与科技能力要求
数据架构中包含的内容比较广，涉及到银行的内部部门也比较多，对企业内部人员的要求也比较高。
要求各级部门人员要有宏观意识，充分理解数据集成、数据治理给企业带来的丰厚回报，充分认识提高数据质量对防范企业风险的重要性。
对于企业内部的业务人员要求如下：
✧了解数据的重要性。
数据对于银行来说，就是钱，就是利润。
✧了解数据集成的必要性。
渠道整合、数据共享，既能降低他们分析数据的复杂性，又能进行精准营销，提高部门公司利润，体现个人价值。
✧精通本部门本岗位业务处理流程及同其他相关业务、相关部门的对接关系。
✧了解公司的发展战略及本部门的定位，知悉本部门的当前及潜在的业务需求。
✧能制定本部门的相关业务的数据标准。
✧配合技术人员做好需求的收集分析工作。
对于企业内部的技术人员要求如下：
✧精通企业的IT架构和信息化建设蓝图
✧精通企业的IT规范
✧了解构建数据平台的必要性和重要性
✧了解同业的成功案例，并能运用到本企业内
✧了解数据仓库相关的解决方案、相关的产品优劣
✧从技术层面上，熟悉业务系统间的关系及数据处理流向
✧
2.10.1安全与保密
数据仓库的数据安全体现在3个层次，操作系统、数据库、和应用，每个层面都要自己的用户和权限控制。
操作系统层面－任何时候，禁止管理员（系统管理员、软件管理员）以外的人员直接登陆到生产系统。
并且不同层次的管理员分配不同的权限。
比如数据库管理员只能访问数据库软件相关的文件，具有读写权限；只有操作系统root用户读写整个文件系统，能够mount、unmount文件系统。
数据库层面－除数据库管理员外，禁止其它用户或应用使用实例宿主（InstanceOwner）用户。
对每类应用或用户创建独立的用户，并分配给其相应的有限的权限。
应用层面－应用层面的权限控制是数据仓库系统对最终用户进行控制的主要手段。
根据需要可以选择。
升级会员 