银行数据仓库建设之ODS方案.docxVIP

目录1、概述.161.1、中信银行ODS 项目建设背景及思路. 161.1.1、背景. 161.1.2、建设思路. 161.2、中信银行ODS 项目架构方法论. 181.3、逻辑架构. 201.4、数据架构. 211.4.1、数据架构. 211.4.2、指标. 221.5、技术架构. 251.5.1、ETL . 251.5.2、指标服务. 251.5.3、数据展示. 261.6、物理架构. 261.6.1、ODS 总行物理架构. 261.6.2、ODS 分行物理架构. 272、数据模型设计.282.1、数据模型的设计目标. 282.1.1、满足OLAP 分析. 282.1.2、统一业务数据视图，保证数据的一致性. 292.2、数据模型设计方法论. 292.2.1、源系统调研方法论. 292.2.2、源系统调研工作模板. 312.2.3、数据模型设计方法论. 332.3、相关概念. 35中信银行ODS 项目技术方案 第3 页，共281 页2.4、核心逻辑数据模型. 362.4.1、主题域描述. 362.4.2、主题域关系图. 372.4.3、主题域业务规则. 382.5、数据分析模型 客户、产品和绩效主题应用. 432.5.1、统一客户视图 客户关系管理. 432.5.2、统一产品视图 产品管理. 512.5.3、统一渠道视图-渠道分析. 532.5.4、绩效考核框架. 542.6、数据模型的层次化设计. 582.6.1、管道层数据模型（CDM）. 582.6.2、清洗和转换层数据模型（TDM） . 592.6.3、原始层数据模型（ODM）. 592.6.4、逻辑数据模型（LDM）. 592.6.5、应用数据模型（ADM）. 603、数据库设计.613.1、数据量估算方法. 613.2、数据库、表分区设计方法. 613.2.1、面临的问题. 613.2.2、解决方法. 623.2.3、分区及标准. 633.3、表索引设计方法. 663.3.1、索引的存储. 663.3.2、使用索引的时机. 663.3.3、索引列和表达式的选择. 663.3.4、复合索引. 673.3.5、避免对大表的全表扫描. 673.4、代理键设计方法. 683.5、表空间和日志空间规划方法. 69中信银行ODS 项目技术方案3.6、SQL 优化方法. 713.6.1、一般原则. 713.6.2、表连接原则. 713.6.3、有效使用索引. 723.7、如何避免表级锁. 724、ETL 设计.734.1、ETL 总体方案. 734.1.1、设计原则. 734.1.2、总体架构. 734.1.3、ETL 任务. 744.1.4、ETL 过程. 764.1.5、ETL 安全. 774.1.6、方案特点. 774.2、ETL 编程规则. 784.3、ETL 流程设计原则. 804.4、ETL 作业调度设计. 834.5、ETL 作业监控设计. 864.6、ETL 作业开发原则. 874.7、ETL 作业设计原则. 884.8、文件落地处理. 884.9、特殊字符处理. 895、前端展现.915.1、前端展现概述. 915.2、报表制作方案. 925.2.1、查询. 935.2.2、报表. 945.2.3、分析. 955.3、报表开发过程. 96中信银行ODS 项目技术方案 第5 页，共281 页5.4、报表管理平台功能模块设计. 975.5、跨系统报表管理. 985.6、二次开发. 1005.7、报表工具开发经验. 1016、统一权限管理.1026.1、概述. 1026.2、权限管理内容. 1026.2.1、用户信息. 1026.2.2、认证方式. 1036.2.3、资源权限. 1036.2.4、数据权限. 1046.3、权限管理方案. 1076.3.1、逻辑架构. 1086.3.2、物理架构. 1096.4、技术实现. 1106.4.1、建立统一的权限管理平台. 1106.4.2、应用系统. 1146.4.3、报表管理系统. 1146.4.4、报表工具. 1186.5、技术难点. 1236.5.1、单点登录. 1236.5.2、报表管理系统向报表工具的权限同步. 1236.6、实施案例介绍. 1236.6.1、交通银行报表综合管理平台. 1236.6.2、建设银行J2EE_报表管理系统应用集成方案. 1251、概述1.1、中信银行ODS 项目建设背景及思路1.1.1、背景随着银行业务系统的不断发展和变化，不断对管理信息和数据服务的建设和发展提出要求，业务推动数据服务的发展是不变的发展规律，中信银行走过了从分布式业务系统到数据集中；从没有数据交换到网状交换再到未来以ODS 数据交换为核心的数据服务，随着科技规划，中信银行的数据服务可能继续发展成以ODS 为核心的架构，再发展到以总行数据计算引擎ODS（H）和分行计算引擎ODS（B）组成的数据服务。总之，数据服务的建设过程是一个不断的因乱而治、逐步演进的过程。1.1.2、建设思路ODS 项目作为中信银行数据服务的重要组成部分，我们在ODS 项目的建设过程中，需要逐步形成由ETL+指标计算+数据展现作为ODS 项目根本技术手段的建设模式，从而连接源系统和目标系统，再统计汇总并最终以适当的方式展现给数据的使用者，这些都是由业务的抽象特性决定的。因此，中信银行ODS 项目的建设从业务需求上主要满足三类需求：n 面向目标系统或分行提供基础数据的供数需求，这类需求可能为对外供数（如外部监管、外部交换和对帐等）做准备，也可能为计算指标和展现做准备；n 面向业务管理而计算指标数据的统计需求，包含指标的计算和派生，这类需求可能是用来满足为某些系统提供重要参数（如平均市场利率或定价转移参数）或满足外部监管和内部管理需要，也可能是为进一步以合适的方式进行展现做准备；n 面向最终用户的形成报表/图的展现需求，多数情况下都是基于对基础数据、指标数据的基础上通过展现工具将数据变为信息的过程。中信银行ODS 项目技术方案 第17 页，共281 页采集补录转换/标准化集成加工查询/展现指标数据统计需求基础数据供数需求报表/图展现需求图表1、中信银行ODS 项目面对的三类业务需求根据以上抽象的三类应用需求，中信银行ODS 项目架构设计和实现应从六个方面来平衡三大需求的实现，使得有限的资源以较有效的协作方式共同发挥效用：n 可扩展性：保证中信银行ODS 项目根据业务发展合理配置稳步发展，应从业务架构、数据架构、技术架构、物理架构等四个方面考虑中信银行ODS 项目的可扩展性。如业务架构上，应考虑业务应用的扩展性，举个例子，将分行特色应用作为全行共性应用的有益补充，旧时一个典型的应用扩展。数据架构的扩展能力，主要体现在数据分布和数据模型的扩展上。技术架构的扩展能力，主要体现在并行计算、大数据量传输处理和集群展现等扩展能力。物理架构的扩展能力，主要体现在硬件设备的低成本扩展能力；n 高性能：保证中信银行ODS 项目事半功倍，在硬件资源有限的情况下，应尽可能的承载尽量多的应用，又能承受用户峰值时间段压力，使得中信银行ODS 项目能够满足全行范围内的使用者；n 可管理性：保证数据多而不乱，在复杂的总分且网状交互的中信银行ODS 项目体系结构下，能够清除得知晓系统每一个应用的转换逻辑和数据含义，在中信银行ODS 项目任何环节有变动时，能迅速的反馈变动产生的影响，准确的帮助技术管理层判断相应的响应者和负责人，从而保证中信银行ODS 项目的可持续发展；n 高可用性：保证中信银行ODS 项目坚不可摧，主要从集群和负载均衡的角度充分考虑中信银中信银行ODS 项目技术方案 第18 页，共281 页行ODS 项目的健壮性；n 安全性：保护中信银行ODS 项目信息不被恶意盗取，基于UAAP、CSSP 等平台的应用安全保证，另外还包括测试数据的安全保障；n 可重用性：尽可能避免中信银行ODS 项目的重复投入，包括物理设备、系统软件、框架组件、规范方法以及业务应用等多个层面上的复用。n 作为一个完整的中信银行ODS 项目，应综合考虑各种非功能性要求，避免出现“木桶短板”效应。高性能Performance可重用性Reusability可扩展性Extensibility可管理性Manageability安全性Security高可用性Availability设计原则图表2、中信银行ODS 项目设计的考虑因素1.2、中信银行ODS 项目架构方法论在中信银行ODS 项目建设方面依据可重用性、安全性、高可用性、可管理性、可扩展性、高性能的设计原则采取总体规划，分层实现的方式。纵向层面自上而下看，中信银行ODS 项目的架构由逻辑（应用）架构、数据架构、技术架构和物理架构四个层次组成，每个层次内部又根据设计需要进行抽象分层，从而形成立体的中信银行ODS 项目架构方法。n 逻辑（应用）架构：是中信银行ODS 项目承载的应用体系，它描述了总行内部、分行内部以及总分行之间所要实现的应用需求，以及支撑这些应用需求所必须的公共模块，如调度、监控和元数据管理等非应用组件。n 数据架构承载了支撑应用架构所必须的业务实体关系的分布，它通过数据模型的方式进行组织，主要分为管道层数据模型、清洗和转换层数据模型、原始层数据模型、逻辑数据模型和中信银行ODS 项目技术方案 第19 页，共281 页分析数据模型等五个层次。管道层数据模型是为ETL 的数据获取步骤服务的数据模型。管道层数据模型中只存储每次数据抽取增量的数据，在数据抽取任务开始之前要清空管道层数据模型中的表；清洗和转换层数据模型也是为ETL 服务的，是ETL 在过滤、清洗、转换和装载步骤的数据模型；原始层数据模型是数据架构中一个有益的补充，是形态介于数据源与逻辑数据模型之间的一个数据模型；逻辑数据模型是ODS 项目的核心。逻辑数据模型主题域（Subject Area）的数据主要由原子数据粒度的数据构成；分析数据模型用来存储根据需要从基础数据层整合形成类似数据仓库拉链表的整合数据，以及加工汇总形成的指标数据。n 技术架构，是用于支撑ODS 项目的数据分布和流动的技术框架，用到的技术有数据仓库技术、数据库技术、ETL 技术、多维计算技术、数据展现技术等多种技术。从支撑ODS 项目中数据分布分层的角度看，从源系统到最终应用最需要关注的技术框架包含三部分，第一个是ETL技术框架，第二个是指标技术框架，第三个是数据展现技术框架。这三类技术框分别是对三类主要数据需求的支撑，共同特点是，将三类需求均视为可复用的资源进行管理和配置。n 作为最底层的物理架构，是对中信银行总行与分行物理设备和网络的合理规划部署，它通过有效地利用硬件和网络，并能够添加硬件设备进行扩展为上层架构（技术架构、数据架构、逻辑架构）提供支撑能力。逻辑架构数据架构技术架构物理架构图表3 中信银行ODS 项目架构方法立体视图中信银行ODS 项目技术方案 第20 页，共281 页1.3、逻辑架构中信银行ODS 项目需要提供多层次的信息处理环境，从数据横向流向看，建立起“源到数据计算引擎(ODS)再到目标应用”的三层体系结构。各交易系统作为源系统，提供企业原汁原味的交易信息。ODS 作为数据计算引擎互为补充，按照时间窗口和加工深度为不同层次的管理决策应用提供数据加工服务。各管理系统作为目标应用系统，将交易信息转换成管理分析信息，并以合适的方式展现给最终用户。随着中信银行ODS 项目的发展，中信银行ODS 项目并不是单向流动，而是一个闭环，没有完全绝对的源系统和目标系统，也就是说源系统可能是目标系统，目标系统也可能是源系统。举个例子，当利率市场化时，对客户的评级可能直接影响贷款系统中的某笔业务的利率，此时源和目标就和原来不一样了。因此，源系统和目标系统是相对于某个具体应用而言的。由于应用千变万化千差万别，这里不对具体应用作阐述。目标应用既包括基于ODS 数据模型的一些应用，例如操作型报表等，也包括使用ODS 提供的供数服务的应用，如零售银行报表系统等。从纵向角度看，可分为总行、分行两个层次。在分行层面，逻辑架构与总行基本相同，不同的是数据计算引擎的组成。源系统数据除通过ODS下发的核心系统数据外，大多依赖于ODS 向分行下发的标准化数据，另外，分行还有一些特色系统数据；根据需要建立数据集市和目标系统，在目标系统中使用通用展现平台实现不同类型报表和展现方式的整合。为了使总分行的数据形成一体，做到可放可收，还需要一些类似监控和调度的公共服务功能。n 任务调度：对ETL 任务及子任务实现统一的调度服务、应用负载功能。n 安全服务：提供用户的安全访问控制，包括ODS 系统资源和数据资源。n 统一用户管理：实现时基于统一用户认证和管理，基于LDAP 服务的同意权限管理，提供统一的认证和授权。n 监控管理：提供对各种任务、资源的集中监控和管理，在监控功能实现上，需考虑总分行计算引擎的集中监控功能的实现。中信银行ODS 项目技术方案 第21 页，共281 页对公信贷对私信贷信用卡核心国际业务第三方存管中间业务平台网上银行基金代销CallCenter系统管理ETL服务和管理元数据管理数据质量管理安全管理加工汇总数据集市文件传输ETLETL数据分发应用数据区ETL数据源Hyperion Cognos报表工具通用展现平台权限管理报表管理数据补录应用展现应用系统(零售报表风险资产计量)分行特色业务分行特色业务分行特色数据源应用数据区报表工具通用展现平台应用展现ETL数据服务数据分发特色数据(当天)总行分发数据(当天)文件传输分行基础数据区数据区分行MIS系统开发框架(规范)ETL分行通用MIS平台数据服务ALM 财务管理绩效考核原有目标系统源数据分发数据全行基础数据总行数据区功能区分行通用报表图表4 逻辑架构图1.4、数据架构1.4.1、数据架构ODS 的数据架构如下图所示：中信银行ODS 项目技术方案 第22 页，共281 页加工图表5 数据架构图1.4.2、指标为提高应用系统的处理效率，缩短系统开发周期，降低系统开发成本。ODS 为上层应用的共性需求提供一些指标。指标是从基础数据层中抽取数据，按标准的星形模型或雪花模型进行组织。派生指标则在指标基础上进一步整合、汇总而形成。派生指标也可以说是指标经过加减乘除或其他复杂运算而生成的。各类报表则是指标、派生指标的展现。图表6 指标示意图中信银行ODS 项目技术方案 第23 页，共281 页1.4.2.1、指标服务提供分析数据层(ADM)，即提供指标服务的目的是：n 减少数据落地，减少不必要的大数据量搬迁n 加快信息处理速度，提高信息时效性n 整合加工功能，减少重复加工实现指标服务的手段是：n 贴源部署指标加工功能，尽量利用交易系统晚间闲暇时的IT 资源进行指标加工，如源系统条件不具备，则搬迁基础数据到ODS 进行指标加工，若ODS 不适合加工，则进入目标应用加工n 针对业务主题统一设计的ADM，可按业务主题灵活部署，是物理上的全行指标数据库n 基于指标指标联合服务环境实现不落地的派生计算，对于计算代价低或者使用频率低的派生指标现用现算，减少海量的指标数据存储n 基于ODS 架构，在总分行之间灵活部署指标计算加工功能作业，兼容分行特色的同时，充分利用总分行IT 资源中信银行ODS 项目技术方案 第24 页，共281 页图表7 指标架构示意图1.4.2.2、指标管理n 物理指标库：记录分析数据模型的星型模型的结构信息，包含维度表和事实表的表结构信息，以及表间的相互关系；屏蔽不同分析数据模型的物理存储差异；实现对分析数据模型的业务语义转换，形成统一的用户容易理解的多维视图；n 逻辑指标库：根据具体业务应用，对物理指标库进行重新组织，形成特定的指标视图，实现指标重用性和应用针对性的完美结合。逻辑指标库可以认为是一个或多个物理指标库视图。n 将通用展现平台，如本公司公司的RIDE 和指标联合服务环境的结合,打通数据 指标 应用的全过程。中信银行ODS 项目技术方案 第25 页，共281 页1.5、技术架构为了实现支撑中信整体的逻辑架构和ODS 项目，我们需要技术架构来支撑，以支持数据的存储和流动，技术架构主体框架包含ETL、指标服务、数据展示三部分组成。根据这三个不同的组成部分，我们需要建立：1.5.1、ETL所谓的ETL（Extract-Transform-Load，即数据抽取、转换、装载）就是从数据源抽取出所需的数据，经过数据清洗，按照预先定义好的模型，将数据加载到数据库中去，主要包括：数据的抽取、转换、清洗、装载等过程。ETL 解决的主要问题是：不同来源数据的异构性和质量问题。例如：不同业务系统数据模型的差异；业务系统不同时期业务过程的差异；业务系统数据不完备带来的不一致性等等。需要注意的是，ETL 并不是简单的使用工具，也不是简单的进行数据的加工运算，如果把ODS看作是一个人强壮的躯体，那么ETL 就好比是心脏和血管，负责把最新鲜的血液（数据）输送到全身。这要求ETL 的开发使用成熟的ETL 工具、遵循完善的过程规划、具有强大的功能、高度的健壮性和自动化程度。因此，我们需要基于ETL 实施的最佳实践，对ETL 的架构和过程进行规划。ETL 规划是对ETL 的抽象，与ETL 工具和项目无关；ETL 规划是实践和经验的总结，其目的保证数据架构在具体设计和实现时的高质量、高扩展、高效率和组件化，降低实施风险和维护成本；ETL 规划的核心是从组件化的角度出发考虑ETL 的设计和实现，降低和ETL 工具、具体项目之间的耦合度目前，中信银行使用的ETL 工具是DataStage EE。1.5.2、指标服务通过ETL 得到的基础数据，需要根据业务规则，进行加工汇总。指标服务，即根据一定的业务需求，从基础数据生成加工汇总数据，并为最终用户提供数据利用和展示的过程。众所周知，ETL 工作的重点和难点在将数据基础的低粒度的数据到汇总的高粒度的数据和对汇总数据针对不同应用进行加工的过程，指标服务针对的数据对象是分析数据模型。中信银行ODS 项目技术方案 第26 页，共281 页通过指标服