完整word版数据仓库技术及其在金融行业的应用Word格式文档下载.docx
《完整word版数据仓库技术及其在金融行业的应用Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《完整word版数据仓库技术及其在金融行业的应用Word格式文档下载.docx（22页珍藏版）》请在冰点文库上搜索。
2.1.4.不可更新
这是指在DW中不会更新从源系统中传过来的细节数据。
在进行数据转换时，一般也并不删除原值。
2.2.DW与DM、ODS的关系
2.2.1.DW与DM
DM是数据集市（DataMart），相当于部门级或应用级的数据仓库，一个企业内部一般建有多个DM，不为种类的分析型应用使用。
各DM分别设计和建立，数据标准和数据模型没有统一。
DM建设难度小，容易成功，但随着数据集市越来越多，无法解决数据冗余、数据质量、数据标准不统一、统计数据不一致等问题，无法满足综合分析和智能查询的业务需要。
DW是指企业级数据仓库，一般一个企业内部只建立一个，数据层大集成，可以为所有分析型应用所使用。
由于技术条件的限制，DW在前几年的建设初期，难度很大，遭到过大面积的失败。
目前所指的数据仓库实际上包含了数据集市和前期数据仓库的概念，可以说是数据集市和数据仓库的融合。
数据仓库内部即可建立企业级整合统一的数据层，同时也可建立为部门级决策支持所设计的数据集市。
2.2.2.DW与ODS
ODS是操作型数据存储（OperationalDataStore）。
与DW相同的是，它也是面向主题的；
是集成的（可能是部分集成）。
与DW不同的是，ODS要具有同时支持分析型应用和操作型应用的特性，因此它存储的数据是当前的，需要实时刷新，却不一定要求存储非常大量的历史；
基础数据是随业务而更新的。
ODS也经历了多种应用形式，它曾做在数据仓库的前端，做一些初级的数据整合，数据快进快出，例如这可以支持要求每小时做一次分析的应用。
它也曾作为初级形式的数据仓库，例如支持面向电子商务的ODS。
ODS产生的技术背景是由于早期的DW因为技术条件的限制，不存储细节数据、难以实现频繁的更新和删除，不能支持实时性要求较高的分析应用。
但ODS具有数据同步复杂（一般需要两次数据落地）、数据共享困难、数据冗余、管理复杂等问题。
目前由于条件的成熟，ODS和DW也有走向融合的趋势，在数据仓库内部分为动态数据区和表态数据区，分别相当原来的ODS和DW概念。
2.2.3.走向融合后的DW
集成原来的DW、DM和ODS，融合后的企业级数据仓库，在内部划分出多个数据层次。
在近期业务数据区，能够为一线业务人员提供战术性决策和操作智能；
在长期历史数据区，能够为管理人员提供战略性决策分析和复杂查询。
即可支持部门特色的应用，也可支持跨部门的企业级综合应用。
整合后的企业级数据仓库（EDW）简化了数据管理和维护流程，减少了数据冗余和延迟，减小了投资成本和协调工作，满足多种级别智能型应用的需要，为企业创造长期的价值。
3.数据仓库架构
3.1.数据仓库架构的构成
广义的企业级数据仓库（EDW）包括基础平台和分析型应用。
基础平台又可分为技术架构和数据架构。
技术架构包括ETL体系、数据访问体系、数据存储体系、安全管理体系等；
数据架构包括数据标准、数据质量、数据模型、数据管控、数据接口等。
3.2.数据仓库技术架构
如上图所示，数据仓库技术架构由八个组件组成：
源数据层、ETL服务层、数据服务层、中间服务层、访问控制层、用户层、元数据管理层、安全管理层。
源数据层：
作为ETL层的数据抽取源，为EDW提供原始数据支持。
本层设计要考虑源系统状况和数据抽取方式，确定存储方式、数据量、交付时间、对时间窗口的影响，以及数据文件规范、文件压缩方式、传输模式、文件发送位置等规范信息。
ETL服务层：
完成数据文件转换和加载，并负责管理和调整数据仓库中所有作业的依赖关系，管理整体作业流。
数据服务层：
一般包括四个层次。
数据缓冲区支持ETL处理；
基础数据层基于面向主题的物理数据模型，用于保存数据仓库基础数据；
汇总层是建立在基础数据之上的主题级汇总数据；
应用数据层（数据集市）是建立在基础数据区和汇总数据区之上的一组数据库，分别对应一类应用主题。
中间服务层：
OLAP服务器通过ODBC等接口从数据仓库批量获取数据，按多维设计模型生成立方体，支持BI软件包的多维展现请求。
BI软件包通过ODBC等接口访问数据仓库，支持业务用户的灵活查询和固定报表请求；
还可通过OLAP接口访问多维数据库支持业务用户的多维分析请求。
应用服务器：
提供一个具有高可用性和负载均衡功能的基础平台，以支持BI软件包和其它应用软件包的运行。
访问控制层：
主要包括WEB、认证、安全、门户四方面的服务。
该层为用户层提供HTTP服务、门户的单点登录、用户统一认证、提交用户层请求到中间服务层，对用户实施安全策略，为用户管理报表、查询文档，提供个性化定制等。
用户层：
数据仓库系统用户既包括进行系统建设的开发人员、系统运行人员和系统管理人员，又包括最终使用系统的业务用户，这里主要对业务用户进行描述。
业务分析人员主要是指使用应用界面访问数据仓库系统的总各业务部门、各分行的业务用户。
该类人员使用数据仓库主要生成或预览定义报表，进行相对固定的查询和多维分析。
管理决策人员主要包括各部门的领导、总行和分行领导。
数据仓库系统为管理决策人员分配专门的系统资源，建立最为直观方便的存取界面，为决策人员赋予最大的信息访问权，实现对信息的自由访问。
知识工作者是指各部门、各分行较为高级的用户。
可以对指定的主题、指标进行自定义的灵活分析和比较。
分析的方式包括自定义查询和报表、多维旋转和穿透钻取等。
元数据管理：
元数据管理是将分散在数据仓库各环节的、独立的元数据统一存储在元数据存储库中，并将各个元数据有机的联系在一起，实现对数据流的跟踪管理，向前可以进行数据的血缘分析，向后可进行影响性分析。
安全管理：
安全管理主要包括网络安全、操作系统安全、数据安全和应用安全，这里不做专门介绍。
可参考相关技术资料。
3.3.数据仓库数据架构
数据仓库的数据架构分数数据流向、数据模型、数据标准、数据质量、数据管控和数据保留策略与容量规划六个部分来简单介绍。
数据流向：
一种比较典型的数据仓库数据流设计模式是，先通过ETL服务将源系统数据加载到临时数据区，本区主要用于源系统数据和ETL运行数据暂存；
然后通过数据加工将详细历史数据、客户信息、账户信息、交易信息等数据存储到基础数据区；
然后可定期进行账户信息和客户信息等汇总，将数据存储到汇总数据区；
最后可将应用分析所需的数据存放到应用数据区。
数据模型：
由于数据仓库建设经验的积累，各行业有其比较成熟的数据仓库数据模型，例如在金融行业，Teradata和IBM各有其自己的数据模型。
成熟的数据模型产品对建设数据仓库有一个很好的经验和方法论指导，但客户化依然具有很大的工作量。
数据标准：
数据标准化是一项关键工作。
进行数据标准化工作必须有专职数据管理员，制定配套的管理流程；
数据标准化包括数据映射和制执行准规则，如识别规则、归并规则、重要口径等；
数据标准化工作还包括统一的业务定义，进行总体规划。
数据质量：
数据质量也是一项关键工作，数据质量太差的数据仓库，其应用价值可以几乎为零。
数据质量问题来源广泛、复杂，可以设计或借助现成的数据质量检查系统进行数据质量检查。
保证质量的工作内容主要包括：
定义及初始度量、分析及发现错误、查找问题根源、解决质量问题、监控改进过程、发现及分析改进中的异常。
数据管控：
建立统一的数据管理体系框架，主要有三个层面组成：
管理策略、方法和内部体系，其核心是工作内容包括数据规划、数据标准制订和管理、数据质量管理。
数据管理体系的建立和完善是一个长期持续的过程。
数据保留策略和容量规划：
数据保存周期受三个关键需求驱动：
业务分析的需求；
法规需求、审计与投资者情况披露；
基于历史数据为客户提供额外的服务。
在确定了数据仓库建设策略之后，可以进行数据容量规划，这包括计算用户数据量、计算磁盘空间需求、分析目前容量现状及对策等工作。
3.4.数据仓库应用架构
国际先进银行的企业级数据仓库实践表明，实现需求主要有三种应用模式：
灵活分析、数据挖掘（如评分系统）和应用开发。
应用系统的开发离不开需求的成熟和稳定，只有通过大量的灵活分析和数据挖掘的应用，才能形成成熟稳定的应用需求，反之，使用系统在业务中的大量使用，又会促进分析人员更加深入、有效的分析探索数据。
灵活分析具有IT和业务两方面的知识和技能，利用查询工具进行任意的数据探索和查询，以回答各种未预定义的业务问题；
数据挖掘在灵活分析的基础上对某些业务问题进行数据属性层面的提炼和归纳，如典型的评分模型、违约模型等；
应用系统是指联机或批量访问数据仓库的应用系统，典型的应用有营销管理系统、利润贡献度模块、反洗钱应用、关键指标/平衡计分卡应用。
在进行分析应用的建设规划时，要根据业务需求的急迫程度确定业务实现的优先次序，并制定一个分析型应用的评估模型。
4.ETL设计与工具介绍
4.1.ETL概念
ETL具有如下的含义：
E（Extraction，抽取）、T（Transformation，转换）、L（Loading，加载）、C（Cleansing，清洗）。
ETL是DW系统的基础。
DW中的数据来自源业务系统，ETL的主要功能正是完成对源业务系统的数据抽取、清洗、转换和加工，生成DW中基础层和应用层数据。
ETL过程由处理单元和处理流程两部分组成。
数据转换清洗规则主要体现在处理单元中；
处理流程体现的是处理单元之间的正确顺序。
ETL系统要有运行监控体系，监控是否有异常；
ETL必须实现流程自动化。
4.2.ETL的模式
ETL有E-T-L和E-L-T两种模式。
E-T-L模式一般需要有一个强大的ETL服务器，而E-L-T模式则需要强大的数据库引擎，对ETL服务器的配置要求不高；
E-T-L模式将转换过程从数据库服务器脱离开来，减少ETL过程占用数据库服务器的时间窗口。
可以将查询和加载分离开来，互不影响。
E-T-L模式的工具通常利用元数据实现整个加载转换流程。
E-T-L模式更适合用于从外部数据源直接一步加入目标数据库，同时无需用到目标数据库现有数据的情况。
E-T-L模式不太适用于在加工过程中需用到目标数据库中现有数据的情况，特别是当这个现有数据比较大的情况，例如数据仓库模型中常用的历史拉链算法。
E-T-L模式不太适用于目标数据库内部的再加工，如数据仓库基础层向中间及应用层的加工。
4.3.ETL任务与任务拆分原则
ETL任务：
制订数据接口规范
制订数据采集和传输规范
ETL策略设计
ETL体系结构设计
设计和开发数据采集/传输程序/脚本
设计和开发数据加载程序/脚本
进行数据质量检查
ETL设计和开发总结汇报
构建和测试初始加载的程序和处理流程
构建和测试日常加载的程序和处理流程
撰写ETL系统用户操作和使用手册
ETL任务拆分原则：
ETL任务拆分得太精或太细都不好。
拆分需要考虑如下因素：
性能；
前续任务等候时间；
事务的完整性和及最小化；
任务的易管理性；
脚本的可读性。
ETL任务拆分的最佳实践：
以目标表为单位进行拆分；
以源数据到达时间的不一致性进行拆分；
以算法不同进行拆分。
4.4.业界主流ETL工具简介
DATASTAGE：
Ascential公司，现已被IBM收购
POWERCENTER：
Informatica公司
SUNOPSIS：
SUNOPSIS公司，现已被ORACLE收购
SAGENT：
GROUP1公司
DATAINTEGRATOR：
BO公司
DECISIONSTREAM：
COGNOS公司
TOS（TalendOpenStudio）：
开源软件
其中，Informatica和Ascential公司是领导者。
5.数据仓库前端设计
5.1.企业级数据仓库的应用模式
EDW应用模式可分为：
固定报表、应用系统、灵活查询、数据挖掘。
OLAP/固定报表提供日常业务管理统计，辅助发现业务发展趋势。
固定报表是数据仓库信息共享的主要途径之一，是最重要的展现方式。
部分常用的、能够提炼出共性的灵活查询可能会转化为固定报表。
固定报表信息所涉及的维度和度量是确定的、权威的；
信息具有普遍性，简单和容易理解，对用户要求不高；
固定报表不依赖单一业务系统，需要全局视图。
分析型应用系统绝不仅仅是固定报表随意的堆砌，而是特定的业务逻辑整合，可以帮助用户逐步访问与分析一系列交互式的报表。
分析型应用一定是服务某个业务主题的，例如风险管理、营销管理等。
灵活查询提供解决那些无法预定义的查询分析需求以及查询问题时的详细钻取。
灵活查询随时发生，可由任何部门发起；
有应对突发需求的相应能力；
可能是简单统计或某项明细数据查询，也可能是某种复杂逻辑的处理；
灵活查询具有特定的目标、特有的度量、专用的视角和算法。
数据挖掘是从大量详细数据中提示出隐含的、先前未知的并有潜在价值的信息的过程，主要基于人工智能、机器学习、模式识别、统计学等技术，做出归纳性的推理，从中挖掘出潜在的模式，帮助决策者调整市场策略，减少风险，做出正确的决策。
数据挖掘一般需要跨业务领域进行综合关联分析，信息全面；
针对的是某个特定领域的特定问题，应用范围和服务领域具有专用性；
数据挖掘使用的统计技术和模型的产生结果都具有高度的抽象性；
数据挖掘模型需要进行周期性的回顾和调整。
各应用模式分解参考特征：
项目
固定报表
应用系统
灵活查询
数据挖掘
建设
目标
回答简单、常规的业务管理、统计类问题
支持复杂业务逻辑，完成特定功能
进行数据探索和查询，回答各种未预先定义的业务问题
通过建模归纳提炼数据蕴含的行为模式，侦查数据潜在规律，捕捉历史信息和未来表现之间关系
业务
逻辑
相对简单，可预定义、预加工
服务某特定业务主题
业务问题无法预定义，有特定的目标、度量、专用视角和算法
复杂
面向
用户
普通用户
特定用户
高级用户
数据挖掘专员
使用
频度
固定周期
频繁、周期性出现
随时发生
不高，建模成功以后只需要定期计算评分结果
模式
查询工具+数据开放
用户界面
分析工具
专用软件包
界面
可以有或无
有
无
应用
产出
汇总表、保留结果
依赖具体应用而定
表现形式不唯一，可能是一个查询的运行结果、一些数据、或一个分析模板
主要是评分信息的描述性信息，计算结果保存
数据
特点
范围明确
已有数据结合用户从界面带入的数据
范围不明确，使用明细数据居多
大量明细、历史数据，范广
特殊
技术
软件包或者自行开发
查询分析工具
高级统计分析、人工智能等技术
典型
示例
各机构产品余额统计等
客户关系管理、风险管理等
测算未到期存款余额总量等
申请评分、行为评分、流失评分等
5.2.用户角色和统一用户管理
用户角色：
DW的数据可分为三层：
缓冲层、基础层、语义层（即汇总和应用数据层）。
不同用户访问不同的数据层。
80%的用户只需访问语义层，这一般是普通业务人员；
20%的用户可能访问基础层，但其80%的时间仍然只访问语义层，这一般是高级业务人员和数据挖掘人员；
只有很少的技术用户和审计可能偶尔需要访问缓冲层。
不同用户访问的数据权限不同，例如不同分行的用户需要访问不同的分行逻辑视图。
对不同角色用户需要制定不同的数据开放策略。
统一用户管理：
用户权限和用户角色设置比较复杂，不同工具和软件一般都有自己的用户管理机制。
必须在整个系统范围内实现统一用户管理，由系统管理员对系统内各组件的用户进行统一规划和管理。
5.3.应用系统体系架构
应用系统可以直接基于DW，也可以采用由DW导出数据给外部集市的方式，具体哪种应用采用哪种方式，需要根据实际情况具体分析。
直接基于DW的应用尽可能采用统一Portal入口，多采用B/S架构，绝大部分用户采种统一管理，单点登录。
基于DW也可以为少数高级用户独立开放C/S访问接口，这些用户具有较高的灵活性，通常直接通过数据库用户进行适当的权限管理即可。
基于导出集市的应用通常不集成于统一Portal，可根据自身情况合理选择架构方式，可采用B/S架构也可采用C/S架构。
5.4.主流前端工具及应用
常用OLAP工具：
HyperionEssbase
MicrosoftAnalysisService
OracleExpressServer（9i）/AnalyticWorkspaceManager（10g）
SybaseIQ
IBMDB2Server
CognosPowerplay
常用前端工具：
HyperionClient（Brio）--有业内最好的EIS
BO
Cognos
MSTR
CrystalReport
Excel
6.DW数据模型设计
6.1.关系模型和多维模型
关系模型是使用规范的二维表表示数据以及数据间的关系，设计关系模型要使用规范化理论。
多维模型使用数据立方体（Cube）来表示现实世界中的复杂关系，基本组成是维（Dimension）、度量（Measure）。
维是对数据进行分类的一种结构，用于从特定角度观察数据，例如时间、地区、产品等。
使用维主要用来选择针对期望详细程序的层次的数据、分组对细节数据综合（聚集）到相应的详细程序的数据层次。
度量（指标）是数据的实际意义，一般是一个数据值度量指标，例如销售量、销售额等。
数字型指标和聚集函数是度量的两个组件。
Cube是一个多维模型构成的多维数据空间，其逻辑上相当于一个多维数组。
6.2.多维分析的基本动作
多维模型的分析动作是将Cube中的数据进行可视化展现的方法。
切片：
从立方体中切出一个二维。
如选定时间维1998年1月，取出产品和地区两个维的数据关系。
切块：
从立方体中切出一个小三维。
如选定时间、产品和地区，取出分析数据。
旋转：
改变一个报告或页面显示的内容。
如把一个横向为时间纵向为产品的报表旋转为横向为产品纵向为时间的报表。
钻取：
向上钻取获得更高层更宏观的数据，向下钻取获得到更低层更详细的数据。
6.3.多维数据模型的实现技术
ROLAP（RelationalOLAP）：
利用关系数据库来存储和管理基本数据和聚合数据，并利用一些中间件支持缺失数据的处理。
具有良好的可扩展性。
关系二维表使用两类表（事实表和维表）来表示多维结构。
事实表（Fact）用来存储变量值和维的码值。
维表用来存储维的描述信息，包括层次和类等。
MOLAP（MultidimensionalOLAP）：
利用多维数据库来存放和管理基本数据和聚合数据，其中需要用到稀疏矩阵处理技术。
对预综合的数据进行快速索引。
HOLAP（HybridOLAP）：
利用关系数据库来存储和管理基本数据，利用多维数据库来存储和管理聚合数据。
6.4.维度建模步骤
选取业务处理过程：
业务处理过程由一个或多个源系统存储其活动数据。
建立的第一个模型应该是一个最有影响的模型，它应该对最为紧迫的业务问题做出回答，并且数据是可获取的。
定义事实表的粒度：
事实表的粒度是指事实表每一行的具体含义。
应优先考虑为业务处理获取最有原子性的信息而开发维度模型。
原子数据是所集的最为详细的信息，该数据不能再做进一步的细分。
维度模型的细节性数据是安如泰山的，并随时准备接受业务用户各种分析的需求。
选取维度：
用一组维度表来描述事实，每个维表包含了若干离散值。
这些维度包含所有可能的描述信息。
常见的维表有日期、产品、客户、交易类型等。
维表不能太大，太大可能需要拆分。
确定数字事实：
事实确定要衡量和分析的内容。
如数量或消费金融等。
6.5.Teradata公司的金融行业数据模型产品
Teradata公司有一套预先构建的金融行业DW逻辑数据模型FS-LDM，是一套较成熟的产品，利用它可以直接开始数据仓库模型客户化设计。
FS-LDM包括十大主题。
PARTY（当事人）主题：
当人事是指银行作为一个金融机构所服务的任意对象和感兴趣进行分析的各种个人或团体客户、潜在客户、代理机构、雇员、分行、部门等。
一个当事人可以同时是这当中许多种角色。
InternalOrganization（内部机构）主题：
内部组织机构是指企业的内部组织和业务单元，如分行、客服中心、支行、储蓄所、部门、销售团队等。
在技术上它是一种特殊的PARTY。
不仅包括自身的内部组织机构，还包括其他的内部组织。
PRODUCT（产品）主题：
产品是金融机构销售或提供的可市场化的产品、产品包和服务。
如果有必要，在模型中可以包括竞争对象所提供的产品。
AGREEMENT（协议）主题：
协议是当事人之间针对某种特定产品或服务而签立的契约关系。
例如银行的账户，保险公司的保单等。
包括协议的申请、报价、还价以及开立等完整信息。
AS
升级会员 