总体架构设计介绍

UDSF系统总体架构总体架构物理架构技术架构数据架构2总体架构哈尔滨银行数据应用总体架构本期哈尔滨银行数据应用平台建设架构规划如下：数据采集平台：T+1数据采集、缺失数据补录数据整合平台：基础数据层模型和加工数据层模型，ETL管理数据推送平台：数据定制下载,数据接口文件推送通用展现平台：平台管理功能,经营分析系统,金融经理考核系统,报表开发功能3物理架构:网络拓扑图物理架构应用服务器:1)服务器DBSERVER2)服务器ETLSERVERFILESERVERWEBSERVERREPORTSERVER说明:ETL,WEB,FILE,REPORT目前使用同一台服务器,但其在逻辑上是分离的,未来可以根据规划需要进行物理分离.待确认:未来我行用户使用哪个网段访问应用系统?哈尔滨银行数据应用物理架构4物理架构:服务器配置应用服务器软硬件配置(推荐)物理服务器服务器1服务器2逻辑服务器DBServerETLServerFILEServerWEBServerReportServer硬件配置型号：CPU：8个内存：16G-32G网卡：1kMEthernet存储：2T型号：PCSERVERCPU：4个内存：8G网卡：2*1kMEthernet存储：500G软件配置操作系统：AIX数据库：DB2操作系统：REDHATLINUXAppServer：IBMWebSphere其它：宇诚WFT,润乾报表备注各逻辑服务器未来可以根据规划需要进行物理分离5技术架构:前端应用技术宇诚应用门户通用展现平台J2EE技术体系宇诚EMP润乾报表平台管理金融经理考核经营分析ETL监控数据定制报表开发数据补录图表开发报表展示6技术架构:后端应用技术UDSFETLSHELL数据采集CC/S技术体系架构总控PROCEDURE宇诚WFT7数据架构:数据源范围本期哈尔滨银行数据应用平台整合数据源范围如下：核心系统:140张信贷系统:23张农贷系统:10张微贷系统:20张中间业务系统:26张国际业务系统:13张卡前置(银联):2张核心UDSF信贷国际结算农贷中间业务卡前置微贷8数据架构:数据分层财务系统数据核心系统数据中间业务系统数据信贷系统数据国际结算系统数据加工综合经营分析核心信贷中间业务国际结算财务交易公共总账产品渠道账户客户贷款补录数据区补录信息1-源系统数据落地区2-源数据层3-基础数据层4-共性加工层5-应用集市层6-推送数据落地区数据整合数据加载数据整合数据转换数据应用应用供数2-ODM应用供数金融经理考核前置……前置系统数据……系统数据经营…………3-FDM4-ADM报表类应用5-MDM监管报送系统数据6-推送数据短信平台指标数据数据分发文件应用供数9数据架构:数据层次说明源数据层(ODM)分为增量源数据(1日)/全量源数据两部分.结构严格贴源,按系统划分主题.完成统一编码标准化.基础数据层(FDM)对数据源中的关键模型按逻辑主题进行重组.完成对不同系统数据模型的信息整合与计算,如客户信息整合、账户均值等.为关键模型建立历史变动拉链与月底快照模型.加工数据层(ADM)应用汇总指标计算,如经营分析指标库等.划分主题的共性指标分析,贷款汇总统计模型等应用集市层(MDM)贴近应用使用的数据模型,一般对应前端一张报表.10数据架构:FDM主题划分11数据架构:FDM—账户主题主题说明账户主题存放内容为客户持有我行产品所对应的各类账户信息.二级主题存款贷款银行卡债券.数据源范围核心(存款/贷款/债券）信贷（贷款）农贷（贷款）微贷.（贷款）12数据架构:FDM—账户主题关键点存款存款静态表—拆分对公对私，添加计算账户余额、积数.账户款项关系表—拆分对公对私，添加了关系的变动日期.活期/定期动态表—拆分对公对私，计算余额年/月积数.贷款贷款静态表,动态表—信息整合（农贷）,拆分对公对私,计算积数,利息.整合了分布在各个信贷系统中的账户属性信息,如五级分类,四级分类等.银行卡计算了对应账户的余额,积数.债券计算了债券账户的余额积数.另外为账户主题的各模型建立了历史变动拉链,月底快照模型.13数据架构:FDM—账户主题建设示例14数据架构:FDM—客户主题主题说明客户主题存放经过UDSF平台整合后客户详细信息.二级主题公共信息个人客户对公客户补充信息数据源范围核心信贷农贷微贷国际结算15数据架构:FDM—客户主题关键点客户信息整合对于分布在不同源系统中的客户信息进行整合.区分对公对私客户信息.同类信息的系统优先顺序为:信贷-核心-微贷-农贷-国结.客户合并外围系统客户向核心对照识别同一客户,无法识别的生成新的客户编码.个人客户识别规则:证件类型+证件号码+姓名.对公客户识别规则:营业执照号+名称.兼顾核心系统客户合并处理.客户关联关系建立平台客户编码与源系统客户编码关系索引.建立平台客户编码与各类账户的关联关系索引.另外为各客户主题模型建立了历史变动拉链模型.16数据架构:FDM—客户主题建设示例17数据架构:FDM—总账主题主题说明存放的内容包括核心系统总账与内部账信息.二级主题总账内部账数据源范围核心18数据架构:FDM—总账主题关键点总账整合日总账(网点),日总账(汇总)两张总账模型.将总账按月存储,将竖表转为横表以减少数据量(约30倍).计算余额均值类指标.内部账计算余额积数.建立月底快照,历史变动拉链模型.19数据架构:FDM—总账主题建设示例20数据架构:FDM—交易主题主题说明存放我行发生各类业务的交易事件信息.主要处理说明整合核心系统多张流水表的渠道交易信息外围交易登记簿—渠道交易交易流水—柜面交易柜员业务量—柜面交易（不记入交易流水类的）批量业务流水—批量业务通过以上流水汇总满足对渠道交易量,柜员交易量的统计分析数据源范围核心21数据架构:FDM—交易主题建设示例22数据架构:FDM—渠道主题主题说明存放我行各类渠道以及设备的详细信息.二级主题实柜员信息虚柜员信息数据源范围核心卡前置23数据架构:FDM—渠道主题建设示例24数据架构:FDM—产品主题主题说明存放我行发行的各类产品属性信息.二级主题公共信息详细信息数据源范围核心中间业务25数据架构:FDM—产品主题建设示例26数据架构:FDM—公共主题主题说明存放机构、员工、参数纬表等公用信息.二级主题统计纬平台标准码数据源范围核心中间业务信贷……27数据架构:FDM—公共主题建设示例28数据架构:ADM建设思路采用循序渐进、分期、分阶段建设原则，避免设计空洞、不实用.本期重点建设两个主题模型——经营分析指标库、贷款分析模型.重点从目前需建设的应用系统需求中的提炼共性需求.ADM数据层设计不宜过“厚”，以免统计口径不一致或粒度不符合业务需求而重复开发.29数据架构:关键点—模型设计规范包含内容表命名规范.字段命名规范.表空间及数据文件命名规范.建模工具规范.30数据架构:关键点—平台标准码目标建立平台统一标准代码屏蔽我行各数据源的编码差异.为未来平台整合新的数据源提供编码参考以及编码整合方法.标准化原则针对源业务系统中,部分共性且代码相对固定、表达意义一致的代码种类，以及一些关键的统计纬度编码,需要进行编码标准化,比如:币种、性别、借贷别、证件类型、余额分段等.标准码分为三级编码形式,标准化后的代码在系统中是唯一的,不发生重复.也便于索引编码含义.例如:“账户状态”中“正常”=“1002(账户)0012(账户状态)00001(正常)”31数据架构:关键点—历史变动拉链表设计目标拉链算法是目前数据仓库领域使用比较广泛的算法之一，其通常用于记录数据量很大且记录之间存在一种历史延续性，通过拉链算法可以方便快捷得到历史时点的状态，同时以最低的数据存储方式保留历史记录.设计原则保留源表所有字段,添加开始日期、结束日期,采用“左闭右开”的方式.最新状态记录结束时间为定值‘2099-12-31’.范围：FDM层关键模型，如账户、客户.保留周期见“平台数据清理策略”部分.使用方法如取“20080131”日状态语句Select*fromtable_hiswherestart_date=‘20080131’andend_date'20080131'32数据架构:关键点—月底快照表设计目标由于客户/账户的余额、利率、账户状态等经常发生变动，同时结合实际业务需求，通常业务应用会频繁使用月底数据作为报表需求的数据源，为了提高系统的响应速度，并且提高数据的可操作性，建议对某些客户/账户的状态信息表进行月底快照保存策略.设计原则增加统计日期字段，每月底批量保存快照信息，只保留源表关键指标字段以便分析使用，如机构号，帐户状态等。对于账户的快照增加计算出的月日均余额、年日均余额、统计积数等统计指标字段.范围：FDM层账户主题存储余额以及积数类的数据模型.保留周期见“平台数据清理策略”部分.33数据架构:关键点—积数运算目标基于现有所了解的业务需求看，账户的日均、积数等信息是日常报表经常统计的指标之一。通常积数的计算公式如下.而在计算积数的过程中，采用全量更新账户积数的方式却不太现实（海量数据更新效率低），因此需要在模型设计过程中重点考虑积数的计算过程.1.以当天增量数据，更新增量记录的积数;2.积数的计算公式:3.对于均值的计算过程，需要首先计算截止当天为止的累计积数，然后再除以实际天数；因此在计算月底快照表中，需要采用积数的计算公式对账户的积数进行统计后再进行均值计算；4.在每年1月1号需要对积数进行清零.34数据架构:关键点—数据清理策略目标为控制UDSF系统数据容量，保证数据使用效率，在数据存储一定周期后需要对其进行备份再从UDSF系统中清理掉.清理的数据范围主要包括流水、历史拉链、快照、周期性统计数据等。账户、客户等关键信息表永久保留全量数据.数据存储周期策略.增量文件层ODMFDMADMMDM2个月13个月13个月1~3年3年以上35数据架构:关键点—数据备份策略目标需要日常备份的文件包含三类，UDSF数据库、数据采集平台每日采集的源系统增量文件以及UDSF卸载至推送平台的推送文件。采集源文件以及推送文件都以文本文件形式存储，UDSF系统每日会建立单独目录存放可以直接将其拷贝到备机或磁带中完成备份.备份策略双机热备双机冷备单机备磁带.36数据架构:关键点—数据库规划目标数据库是哈尔滨银行UDSF系统的核心，它的设计直接关系系统执行的效率和系统的稳定性。因此在系统开发中，数据库设计应遵循必要的数据库范式理论，以减少冗余、保证数据的完整性与正确性。只有在合适的数据库产品上设计出合理的数据库模型，才能降低整个系统的编程和维护难度，提高系统的实际运行效率.规划范围数据库分区，用户结构.表空间、索引空间、日志空间规划.数据容量评估，清理，备份策略.数据库优化策略..数据采集平台技术方案采集策略部署方案38采集平台:技术方案选择目标T+1数据采集的主要功能需要从源系统中采集数据到数据集成平台的源系统数据文件落地区可选方案通过专用数据同步工具将源系统生产数据实时同步到数据采集区.例如IBM的II或HDR、ER.通过存储设备本身的同步复制软件将源系统生产数据同步到数据采集区.开发通用的采集程序完成数据采集到落地过程.核心模块采用通用模式（调度\传输），卸数部分自定义采集角本.实施策略上述四种数据采集模式，均各有特点，各有合适的应用场景。UDSF的数据源也是多种多样，不宜采用统一的数据采集模式；应根据采集数据本身的特点，来规划数据采集模式。对于哈尔滨银行UDSF项目本身来说，每日卸载的数据量在可以接受的范围内，采用第1，2两种方案会带来较大的实施成本和