总体架构设计介绍讲解

1、UDSF系统总体架构 q总体架构 q物理架构 q技术架构 q数据架构 2 总体架构 哈尔滨银行数据应用总体架构 本期哈尔滨银行数据应 用平台建设架构规划如 下： p数据采集平台： T+1 数据采集、缺失数据 补录 p数据整合平台：基础 数据层模型和加工数 据层模型，ETL管理 p数据推送平台：数据 定制下载,数据接口 文件推送 p通用展现平台：平台 管理功能,经营分析 系统,金融经理考核 系统,报表开发功能 3 物理架构:网络拓扑图 物理架构应用服务器: 1)服务器 DB SERVER 2)服务器 ETL SERVER FILE SERVER WEB SERVER REPORT SERVER

2、说明: ETL,WEB,FILE,REPORT目前 使用同一台服务器,但其在逻辑 上是分离的,未来可以根据规划 需要进行物理分离. 待确认: 未来我行用户使用哪个网段访 问应用系统? 哈尔滨银行数据应用物理架构 4 物理架构:服务器配置 应用服务器软硬件配置(推荐) 物理服务器服务器1服务器2 逻辑服务器DB ServerETL Server FILE Server WEB Server Report Server 硬件配置型号： CPU：8个 内存：16G-32G 网卡：1kM Ethernet 存储：2T 型号：PC SERVER CPU：4个 内存：8G 网卡：2*1kM Etherne

3、t 存储：500G 软件配置操作系统：AIX 数据库：DB2 操作系统：REDHAT LINUX App Server：IBM WebSphere 其它：宇诚WFT,润乾报表 备注各逻辑服务器未来可以根据规划需要进行物理分 离 5 技术架构:前端应用技术 宇诚应用门户宇诚应用门户 通用展现平台 J2EE技术体系 宇诚宇诚EMP 润乾报表润乾报表 平台管理平台管理金融经理考核金融经理考核经营分析经营分析 ETL监控监控数据定制数据定制报表开发报表开发数据补录数据补录图表开发图表开发报表展示报表展示 6 技术架构:后端应用技术 UDSF ETL SHELL 数据采集数据采集 C C/S技术体系架构

4、技术体系架构 总控总控 PROCEDURE宇诚宇诚WFT 7 数据架构:数据源范围 本期哈尔滨银行数据应用平台整合数据源范围如下： p核心系统: 140张 p信贷系统:23张张 p农贷系统:10张 p微贷系统:20张 p中间业务系统:26张 p国际业务系统:13张 p卡前置(银联):2张 8 数据架构:数据分层 9 数据架构:数据层次说明 q源数据层(ODM) n分为增量源数据(1日) /全量源数据两部分. n结构严格贴源,按系统划分主题. n完成统一编码标准化. q基础数据层(FDM) n对数据源中的关键模型按逻辑主题进行重组. n完成对不同系统数据模型的信息整合与计算,如客户信息整合、账户

5、均值等. n为关键模型建立历史变动拉链与月底快照模型. q加工数据层(ADM) n应用汇总指标计算,如经营分析指标库等. n划分主题的共性指标分析, 贷款汇总统计模型等 q应用集市层(MDM) n贴近应用使用的数据模型,一般对应前端一张报表. 10 数据架构:FDM主题划分 11 数据架构:FDM账户主题 q主题说明 n账户主题存放内容为客户持有我行产品所对应的各类账户信息. q二级主题 n存款 n贷款 n银行卡 n债券. q数据源范围 n核心(存款/贷款/债券） n信贷（贷款） n农贷（贷款） n微贷.（贷款） 12 数据架构:FDM账户主题关键点 q存款 n存款静态表拆分对公对私，添加计算

6、账户余额、积数. n账户款项关系表拆分对公对私，添加了关系的变动日期. n活期/定期动态表拆分对公对私，计算余额年/月积数. q贷款 n贷款静态表,动态表信息整合（农贷）,拆分对公对私,计算积数,利息. n整合了分布在各个信贷系统中的账户属性信息,如五级分类,四级分类等. q银行卡 n计算了对应账户的余额,积数. q债券 n计算了债券账户的余额积数. 另外为账户主题的各模型建立了历史变动拉链,月底快照模型. 13 数据架构:FDM账户主题建设示例 14 数据架构:FDM客户主题 q主题说明 n客户主题存放经过UDSF平台整合后客户详细信息. q二级主题 n公共信息 n个人客户 n对公客户 n补

7、充信息 q数据源范围 n核心 n信贷 n农贷 n微贷 n国际结算 15 数据架构:FDM客户主题关键点 q客户信息整合 n对于分布在不同源系统中的客户信息进行整合. n区分对公对私客户信息. n同类信息的系统优先顺序为:信贷-核心-微贷-农贷-国结. q客户合并 n外围系统客户向核心对照识别同一客户,无法识别的生成新的客户编码. n个人客户识别规则:证件类型+证件号码+姓名. n对公客户识别规则:营业执照号+名称. n兼顾核心系统客户合并处理. q客户关联关系 n建立平台客户编码与源系统客户编码关系索引. n建立平台客户编码与各类账户的关联关系索引. 另外为各客户主题模型建立了历史变动拉链模型

8、. 16 数据架构:FDM客户主题建设示例 17 数据架构:FDM总账主题 q主题说明 n存放的内容包括核心系统总账与内部账信息. q二级主题 n总账 n内部账 q数据源范围 n核心 18 数据架构:FDM总账主题关键点 q总账 n整合日总账(网点),日总账(汇总)两张总账模型. n将总账按月存储,将竖表转为横表以减少数据量(约30倍). n计算余额均值类指标. q内部账 n计算余额积数. n建立月底快照,历史变动拉链模型. 19 数据架构:FDM总账主题建设示例 20 数据架构:FDM交易主题 q主题说明 n存放我行发生各类业务的交易事件信息. q主要处理说明 n整合核心系统多张流水表的渠道

9、交易信息 n外围交易登记簿渠道交易 n交易流水柜面交易 n柜员业务量柜面交易（不记入交易流水类的） n批量业务流水批量业务 n通过以上流水汇总满足对渠道交易量,柜员交易量的统计分析 q数据源范围 n核心 21 数据架构:FDM交易主题建设示例 22 数据架构:FDM渠道主题 q主题说明 n存放我行各类渠道以及设备的详细信息. q二级主题 n实柜员信息 n虚柜员信息 q数据源范围 n核心 n卡前置 23 数据架构:FDM渠道主题建设示例 24 数据架构:FDM产品主题 q主题说明 n存放我行发行的各类产品属性信息. q二级主题 n公共信息 n详细信息 q数据源范围 n核心 n中间业务 25 数据

10、架构:FDM产品主题建设示例 26 数据架构:FDM公共主题 q主题说明 n存放机构、员工、参数纬表等公用信息. q二级主题 n统计纬 n平台标准码 q数据源范围 n核心 n中间业务 n信贷 n 27 数据架构:FDM公共主题建设示例 28 数据架构:ADM q建设思路 n采用循序渐进、分期、分阶段建设原则，避免设计空洞、不实用. n本期重点建设两个主题模型经营分析指标库、贷款分析模型. n重点从目前需建设的应用系统需求中的提炼共性需求. nADM数据层设计不宜过“厚”，以免统计口径不一致或粒度不符合业务 需求而重复开发. 29 数据架构:关键点模型设计规范 q包含内容 n表命名规范. n字段

11、命名规范. n表空间及数据文件命名规范. n建模工具规范. 30 数据架构:关键点平台标准码 q目标 n建立平台统一标准代码屏蔽我行各数据源的编码差异. n为未来平台整合新的数据源提供编码参考以及编码整合方法. q标准化原则 n针对源业务系统中,部分共性且代码相对固定、表达意义一致的代码种类，以 及一些关键的统计纬度编码,需要进行编码标准化,比如:币种、性别、借贷别 、证件类型、余额分段等. n标准码分为三级编码形式,标准化后的代码在系统中是唯一的,不发生重复.也 便于索引编码含义. 例如:“账户状态”中“正常” =“1002(账户)0012(账户状态)00001(正常)” 31 数据架构:关

12、键点历史变动拉链表设计 q目标 n拉链算法是目前数据仓库领域使用比较广泛的算法之一，其通常用于记录数 据量很大且记录之间存在一种历史延续性，通过拉链算法可以方便快捷得到 历史时点的状态，同时以最低的数据存储方式保留历史记录. q设计原则 n保留源表所有字段,添加开始日期、结束日期, 采用“左闭右开”的方式. n最新状态记录结束时间为定值2099-12-31. n范围：FDM层关键模型，如账户、客户. n保留周期见“平台数据清理策略”部分. q使用方法 如取“20080131”日状态语句Select * from table_his where start_date 20080131 32 数据

13、架构:关键点月底快照表设计 q目标 n由于客户/账户的余额、利率、账户状态等经常发生变动，同时结合实际业 务需求，通常业务应用会频繁使用月底数据作为报表需求的数据源，为了 提高系统的响应速度，并且提高数据的可操作性，建议对某些客户/账户的 状态信息表进行月底快照保存策略. q设计原则 n增加统计日期字段，每月底批量保存快照信息， n只保留源表关键指标字段以便分析使用，如机构号，帐户状态等。 n对于账户的快照增加计算出的月日均余额、年日均余额、统计积数等统计 指标字段. n范围：FDM层账户主题存储余额以及积数类的数据模型. n保留周期见“平台数据清理策略”部分. 33 数据架构:关键点积数运算

14、 q目标 n基于现有所了解的业务需求看，账户的日均、积数等信息是日常报表经常 统计的指标之一。通常积数的计算公式如下. n而在计算积数的过程中，采用全量更新账户积数的方式却不太现实（海量 数据更新效率低），因此需要在模型设计过程中重点考虑积数的计算过程. 1.以当天增量数据，更新增量记录的积数; 2.积数的计算公式: 3.对于均值的计算过程，需要首先计算截止当天为止的累计积数，然后再除以实际 天数；因此在计算月底快照表中，需要采用积数的计算公式对账户的积数进行统计 后再进行均值计算； 4.在每年1月1号需要对积数进行清零. 34 数据架构:关键点数据清理策略 q目标 n为控制UDSF系统数据容

15、量，保证数据使用效率，在数据存储一定周期后 需要对其进行备份再从UDSF系统中清理掉. n清理的数据范围主要包括流水、历史拉链、快照、周期性统计数据等。 n账户、客户等关键信息表永久保留全量数据. q数据存储周期策略 . 增量文件层增量文件层ODMFDMADMMDM 2个月13个月13个月13年3年以上 35 数据架构:关键点数据备份策略 q目标 n需要日常备份的文件包含三类，UDSF数据库、数据采集平台每日采集的 源系统增量文件以及UDSF卸载至推送平台的推送文件。采集源文件以及 推送文件都以文本文件形式存储，UDSF系统每日会建立单独目录存放可 以直接将其拷贝到备机或磁带中完成备份. q备

16、份策略 n双机热备 n双机冷备 n单机备磁带 . 36 数据架构:关键点数据库规划 q目标 n数据库是哈尔滨银行UDSF系统的核心，它的设计直接关系系统执行的效 率和系统的稳定性。因此在系统开发中，数据库设计应遵循必要的数据库 范式理论，以减少冗余、保证数据的完整性与正确性。只有在合适的数据 库产品上设计出合理的数据库模型，才能降低整个系统的编程和维护难度 ，提高系统的实际运行效率. q规划范围 n数据库分区，用户结构. n表空间、索引空间、日志空间规划. n数据容量评估，清理，备份策略. n数据库优化策略. . 数据采集平台 q技术方案 q采集策略 q部署方案 38 采集平台:技术方案选择

17、q目标 nT+1数据采集的主要功能需要从源系统中采集数据到数据集成平台的源系统 数据文件落地区 q可选方案 n通过专用数据同步工具将源系统生产数据实时同步到数据采集区.例如IBM 的II或HDR、ER. n通过存储设备本身的同步复制软件将源系统生产数据同步到数据采集区. n开发通用的采集程序完成数据采集到落地过程. n核心模块采用通用模式（调度传输），卸数部分自定义采集角本. q实施策略 n上述四种数据采集模式，均各有特点，各有合适的应用场景。UDSF的数 据源也是多种多样，不宜采用统一的数据采集模式；应根据采集数据本身 的特点，来规划数据采集模式。对于哈尔滨银行UDSF项目本身来说，每 日卸

18、载的数据量在可以接受的范围内，采用第1，2两种方案会带来较大的 实施成本和技术难度，我们设计暂用第四种方案完成数据T+1的采集工作. . 39 采集平台:采集策略数据卸载策略 q目标 n对于采集目标表的数据卸载主要有全量卸载和增量卸载两种方式. n全量卸载即日终卸载数据表中全部数据，处理相对简单。 n增量卸载的数据范围为对比上一卸载周期内数据表中新增以及内容发生过 变化的数据记录，一般来说需要根据数据中某一时间戳进行判断，有时可 能需要关联其他数据表的时间戳才能判断出变量数据，那么这就需要对采 集的数据模型进行详细的分析、制订卸数采用的策略. n一般来说各类数据表的卸载策略可参考下面图例. .

19、 40 采集平台:采集策略卸数时间策略 q目标 n采集数据的卸数时间应以其源系统数据库时间为准并且需要充分考虑业务 系统可能发生的日终跑批处理、重启、备份等步骤，规划好每一个业务数 据源的卸数时间窗口，根据与科技、系统维护部门的沟通讨论，共同制定 的各系统卸数时间方案如下. . 系统名主备机选择系统日终处理策略是否能够提供日终结束 标志 其他特殊处理卸载时间策略 核心备份是pubsysctrlinfo时间表翻牌 为准 信贷生产 国际结算生产 微贷生产待核心系统日终结束运 行 可以提供（技术人员修 改程序） 根据生产系统提供的日终结 束标志确定是否卸数 农贷生产待核心系统日终结束运 行 可以提供

20、（技术人员修 改程序） 根据生产系统提供的日终结 束标志确定是否卸数 中间业务生产md_xtcs.zjyw（日期） 卡前置生产sysrunparam表 Paramcode=0007的日期 41 采集平台:采集策略补录数据策略 q目标 n数据补录是为了弥补数据源缺失或者业务系统建设不完善的情况而设置特 殊采集模式。 n数据补录模块的提供是针对不同业务数据库的通用数据录入工具，包括页 面录入和模板录入以及数据入库的审批流程。支持对录入数据的事件处理 （如新增前进行有效性数据检查、新增后进行数据平衡校验等，使用检核 规则来实现）. n数据补录工具服务于各部门、各机构的数据录入人员。该模块使用到“数

21、据集管理”功能. . 42 采集平台:部署方案分布式部署 q目标 n如图所示：采集程 序将在各个数据源 服务器进行部署， 各自完成针对其业 务系统的卸数、存 储、传输等采集步 骤，各个系统的采 集程序无依赖关系 但总体程序处理风 格保持一致。该方 案弊端是采集需要 分散部署，维护困 难； . 43 采集平台:部署方案集中式部署 q目标 n如图所示：采集程 序将集中部署在 UDSF数据库服务 器中，通过DB2的 客户端直接访问各 数据源系统完成对 其数据的卸载。该 方案采集程序主要 集中在一台服务器 上，便于日常的管 理和维护，目前该 方案也是我们目前 建议的部署方案。 . 44 采集平台:关键

22、点 q效率保证 n对各个数据源的采集是独立的，数据源间无依赖关系. n对单个数据源系统采集支持并发处理，允许调整最大并发数. n目前部分数据源表数据量较大，时间字段非索引造成采集语句执行异 常缓慢，这部分需要待全面测试后与科技方探讨解决方案，可能需要 在源系统端加一些时间索引 q质量保证 n所有卸数角本将采用相同的逻辑编写，避免代码方面差异造成的问题. n系统将设计并开发平台数据模型大数核对程序，可以为UDSF平台 ODM的数据表制定关键核算指标，如COUNT、SUM等，与数据源端 进行核对，通过这种方式来校验采集的数据的完整性以及正确性。 . 数据整合平台 q数据加载 q数据整合 q特殊处理

23、 46 整合平台:数据加载-加载策略 q总体策略 n数据加载主要指从源系统采集到的每日增量数据文件装载到UDSF平 台ODM数据层的过程，UDSF系统数据加载分为历史数据加载（ Initial Load）也叫初始和日常数据加载（Incremental Load）. n从架构设计的角度将充分考虑同一套作业同时实现初始和增量装载的 两套功能，每次运行装载处理哪一种加载将由参数来控制。在作业设 计时只需要建立一套增量加载的ETL程序 同样能够处理历史数据加载 和日常数据加载，而不再开发另一套全量加载ETL 程序处理历史数据 加载。 这样只需要开发一套ETL 程序作业，减少了开发工作量，并且 避免了两

24、套程序可能出现的数据算法不一致造成的数据不一致的错误. n对于涉及大量历史数据加载的策略，我们可以采用时间窗口的分段的 方法来处理历史数据量大的表的装载，即我们可以一个一个时间段来 加载历史数据. . 47 整合平台:数据加载-加载策略 q日常处理策略 n全量加载：首先清空ODM（增量）目标表的昨日数据再进行全量数据 加载；进行全量加载的表主要为数据源表中无时间戳或其它标志可以 剥离出每日变量的并且信息量较小信息表、代码表等，这部分包含的 内容一般情况下不会被分析历史状态所使用，无需建立历史变动拉链 表. n增量加载：首先清空ODM中目标表的昨日数据再进行该日增量数据的 加载；增量加载的数据源

25、表中包含时间戳或者唯一流水号、变动标志 等能够准确剥离出每日变化数据的标志字段，如流水表、账户动态表 等. n比较增量剥离： 首先用本日的全量信息文件与上日的全量信息文件进 行比较，将发生过变化或者新增的信息记录剥离出来，再将这些变化 的数据插入ODM模型中。通过这种方式来满足那些数据源表中无时间 戳或则其它标志可以剥离出每日变量的并且需要增量加载并在UDSF 平台保留历史变化痕迹的信息表，如客户地址信息、利率信息等模型 . 48 整合平台:数据加载-加载策略 q初始化数据策略 n考虑到由于历史数据初始化是UDSF上线前一次性将历史数据导入到 UDSF模型的过程，ETL不单独再行开发程序，采用

26、复用增量加载的 JOB,并按实际情况进行手工调整JOB以满足初始化装载需求的方式。 对于数据量特别大的历史表，ETL充分考虑处理的效率，将采取时间 窗口分割的方法来进行分段加载. n初始化加载数据时应先检查UDSF物理数据库，删除索引后再进行数 据加载，加载完成后需要使用脚本重新创建索引. n初始化前的准备：存储的准备，数据的准备. n初始化过程监控： ETL在进行数据初始化过程中需要进行监控，保证 初始化过程的正常运行以及错误的有效记录. n初始化事后检查：数据初始化累计完成数据后，需要对入库数据进行 核对，一般主要对存量的客户数、账户数、交易量、机构和科目余额 进行大数核对，确保初始化进入

27、UDSF的数据的准确性. . 49 整合平台:数据加载-错误数据处理 q错误数据处理 n在数据文件ODM以及ODMFDM加载的过程中数据可能会 因为数据质量或者其它一些原因产生被REJECT的情况，异常数据产 生后，需要一套专门的流程机制来完成数据的：排查定位分类 修改复核提交记录的过程，一般情况下的处理方式如下. . 50 整合平台:数据加载-错误数据处理 qREJECT数据处理 n对于发生REJECT的记录需要添加至目标表对应的REJECT日志文件 中，记录需要保留完整内容以便于问题分析和修正，对于REJECT信 息的修正采用“数据源端修正”以及“手工修正”两种方式，对发生 REJECT的

28、数据源表需要与源系统负责技术人员共同探讨解决方案， 如何可能尽量多采用“数据源端修正”的方式修改错误数据并且重新 采集加载至UDSF平台，否则采用“手工修正”数据文件方式调整记 录内容再完成加载动作. qREJECT数据监控 n在发生REJECT的同时，加载程序需要统计相关的REJECT信息插入 至“REJECT日志统计信息表”中，UDSF平台应用端（WEB）将提 供一张统计报表展示出日志统计信息表中的内容以达到监控的目的。 “REJECT日志信息表”的内容如下. . 序号（自增长)） 加 载 日 期 数据层 （ODM/FDM） 程序名 数据源表 目标表 REJECT记录 数 备用 51 整合

29、平台:数据加载-错误数据处理 qREJECT任务处理 n在UDSF平台数据加载过程中如果发生了REJECT数据情况那么平台 的整体调度过程是否应受其影响，在这里考虑采用为每个加载信息表 设置配置参数的方式来决定平台的整体运行机制. n处理策略目前包含两种选择 1.忽略正常数据继续插入，平台整体ETL调度继续运行。 2.暂停按照ETL出错处理（该任务回滚），暂停该装载JOB以及其 后续的任务。 . 序号（自增长）添加日期 结束日期目标表名 处理策略 备用 52 整合平台:数据整合 q数据整合范围 n客户、账户、产品等逻辑主题模型整合 n账户积数,均值计算. n历史变动拉链 n月底快照 n标准码清

30、晰 n汇总指标的计算 . 53 整合平台:关键点机构撤并 q源系统处理方式 n对于机构的拆分和撤并在这里着重阐述一下UDSF平台的设计方案， 目前哈尔滨银行各应用数据源系统对于拆分和撤并的处理方式不尽相 同，如“国结系统”的撤并处理就比较简单，只是在机构参数表中将 标志置为无效，对于历史数据不做处理。而“核心系统”相对而言处 理略微复杂，主要方式是通过配置表定义撤并任务，在日终完成撤并 或拆分动作，撤并或拆分将刷新部分账户或客户信息表中的机构号码 ，具体的处理方式如图. . 54 整合平台:关键点机构撤并 qUDSF系统处理方式 n核心系统在发生机构拆分或撤并时本身已有了一套机制来完成拆分或

31、撤并的处理动作，那么未来UDSF平台对于发生的机构撤并与拆分该 如何处理？这里有两套方案可供选择. . 方案介绍方案介绍优点优点缺点缺点是否推荐是否推荐 1.1.采集撤并后的数据采集撤并后的数据. . 主要是针对核心而言，因为发生撤并处理时核心各子 系统账户中机构号变更但账户变动日期不做记录，因 此我们需要在数据采集时读取撤并的配置表，将本日 撤并/拆分/并入机构相关的记录或者拆分的账户数据 都当作增量数据采集出来，再加载到UDSF平台中，这 样能保证与核心数据一致 1)处理相对简单 2)数据能够保证 与源系统一致 1)该方案只适合核心 系统数据 不推荐； 虽然说对于核 心某些数据表 撤并的处

32、理相 对容易但还需 要额外设计一 套方案处理其 它信息表，两 套方案并行不 适用 2)获取的变量数据会 包含实际未发生变化 的记录 3)对于平台一些有特 殊要求的表的处理也 不通用，例如总账模 型，需要额外设计处 理细节 2 2重新设计撤并重新设计撤并/ /拆分处理（仿核心系统拆分处理（仿核心系统) ) 1)使用所有采集 到的数据源 1)逻辑相对复杂,对 设计要求较高。 推荐； 参考核心系统的配置表重新设计一套UDSF平台的机构 撤并/拆分处理方案，UDSF配置表每日加载核心配置 表中的配置项，采用与核心同样的程序逻辑来完成加 载到平台的核心数据源模型的撤并/拆分处理；UDSF 平台的处理方案

33、还需要兼顾到其它采集到的数据源表、 拉链表、快照表等，通过在核心系统配置撤并/拆分 任务，UDSF平台完成所有采集数据源撤并/拆分处理 这种模式来处理该类问题 2)平台中只存在 一种设计方案， 设计思路较清晰 2）如果设计或实现 存在缺陷可能造成与 核心系统的数据不一 致 该种方案最明 显的好处就是 可以针对UDSF 平台对撤并/拆 分的需求单独 设计，并且所 有系统的处理 风格能够保持 一致 3)对于机构撤并 的处理集中在一 两支程序中，便 于维护 q撤并处理要点 n刷新FDM，ODM信息表中的归属机构字段 nFDM总账模型中被并机构的年积数要累加到并入机构积数中 n对于统计月汇总交易的模型

34、要考虑将本月被并机构的交易累加到并入 机构统计总量当中 n对于已成历史的交易表，统计表不做刷新处理，保留历史状态。 . 55 整合平台:关键点结息日处理 q处理策略 n目前我行存款/贷款账户的结息周期为每个月20号，这一天存/贷款账 户基本上都将发生变化，采集到UDSF平台的存/贷款信息表也将是接 近于全量的信息，并且相关业务流水明细信息表的记录数也将比较庞 大，但考虑到我行全量账户总数还是在一个可接受的范围内，因此暂 时不考虑另外进行开发而沿用日常加载时的ETL程序进行处理，但需 要该日常加载程序在设计初期将多线程处理等优化处理方案考虑在内. . 56 整合平台:关键点年终结转处理 q处理策

35、略 n年终结转主要涉及的是核心总账主题相关的表，如“内部账分户文件 ”、“日总账”、“周期总账”等。核心的处理方式为每年12月31日 日终完成账户间的结转，最终保留下来的12月31日账务信息为结转后 的信息，这部分信息也将被UDSF平台所采集。但是业务部门经常会 需要12月31日终结转之前的账务数据，因为该数据能够反映出每个账 户以及每个科目一年的真实损益情况，这部分信息对于业务部门相当 重要，这部分数据整合进UDSF平台是相当必要的。但是目前没有渠 道能够让UDSF平台自动采集到这部分数据，针对于这种情况平台初 步设计两种解决方案供选择. 1.数据源端完成结转前数据的备份，UDSF平台自动采

36、集方式 2.业务人员自行备份，通过UDSF平台的补录接口进行信息补录 不管采用上面哪种方式都需要一定的管理要求，比如在12月31日系统 日终处理前必须保证数据的正确备份否则事后很难进行追溯，需要在 管理上加以要求 . 57 整合平台:关键点村镇银行数据的处理 q处理策略 n目前我行发展的村镇银行与我行共用一套生产系统，其业务数据与我 行目前是混在一起的，但业务部门要求在UDSF平台前端展现的报表 中不包含村镇银行的业务数据，对于这种需求平台有两种方案可供选 择. 1. UDSF采集平台采集平台屏蔽屏蔽 指的是UDSF采集平台不采集这部分业务数据使其不进入到UDSF平台中，在物理上隔离 2. U

37、DSF前端应用屏蔽前端应用屏蔽 UDSF平台对数据的采集、整合、汇总等操作也包含这部分内容，平台机构信息表中添加 是否村镇银行的标志字段，在前端展现时进行屏蔽，作到逻辑上的隔离 在与科技部门讨论后决定UDSF平台暂时使用第二种方案来处理。 . 数据推送平台 q总体架构 q实施目标 59 数据推送平台:总体架构 . 60 数据推送平台:实施目标(1)监管系统 q监管系统数据源移植 n“监管报送”系统是我行目前正在使用的一套应用系统，其数据源包 含“核心”，“信贷”等系统。目前“监管报送”系统数据的获取方 式是从“核心”，“信贷”等系统分别采集业务数据，虽则其系统需 求功能逐渐增加涉及的数据源系统

38、范围也越来越广，未来UDSF系统 上线后将成为监管报送系统的唯一数据源，UDSF数据推送平台可以 实现将监管报送需要的业务数据按照其原需求文件格式、文件内容、 传输方式、存储位置等条件传输至“监管报送”系统所在服务器，使 “监管报送”系统不再需要关心数据的获取而只关心本身的应用就可 以了，这样也达到了使其数据源平滑过渡的目标. . 61 数据推送平台:实施目标(2)自定义数据推送 q监管系统数据源移植. . 62 数据推送平台:实施目标(3)指标电子渠道推送 n其主要功能是将UDSF平台计算的重要经营指标数据按照规定的方式 推送至我行“短信平台”、“邮件服务器”等信息传输渠道，再借助 这些渠道

39、本身的功能推送给信息接收者。 n例如UDSF平台每日将我行经营分析类的统计指标卸载为固定格式的 文本文件，再按照与邮件服务器的约定接口完成文件传输，由其每日 通过邮件形式将电子格式的报表发送给对我行经营指标关心的行领导 。再例如每日UDSF平台完成日终后将总体的运行状态指标卸载并推 送至短信平台，由其将平台运行信息通过短信发送至系统运营人员的 手机，使其第一时间了解到平台的运行状况。 n通过推送平台与电子渠道的互动使UDSF平台信息的消费从被动变为 主动，这也是UDSF平台未来发展规划的重要方向。但该功能的实现 与我行电子渠道本身的建设有这重要的联系；功能是否能够实现、实 现效果如何也受各种客

40、观因素的限制。 n另外对于平台推送信息的范围、功能的多少都需要与银行科技部门、 业务部门进行进一步的探讨，建议UDSF平台本期重点建立与其它电 子渠道的交互接口并完成少量指标信息的推送，未来随着平台的不断 建设逐步完善和扩展这部分的功能. . ETL总控平台 q功能架构 qETL监控 q日期翻牌 64 ETL总控平台:功能架构 q管理模块 n流程管理. n调度核心 n任务执行 n日志管理 n任务监控 . 65 q流程监控 nETL流程监控主要是监控整个ETL过程的动态执行情况，可以监控到 ETL当前执行的任务以及相关状态. q作业监控 n通过监控界面实时监控ETL作业的日程和执行情况，并在必要

41、时手工 停止作业的运行. . ETL总控平台:ETL监控 66 ETL总控平台:关键点平台日期翻牌 平台端应用总体实施架构 q实施架构 68 实施架构 通用展现平台 q逻辑架构 q功能架构 q物理架构 q报表发布流程 70 通用展现平台:逻辑架构 PeopleSoft Enterprise Portal 通用展现平台登陆门户通用展现平台登陆门户 平台管理平台管理 经营分析经营分析 管理员普通用户 用户管理 机构管理 通用参数管理 公告管理 报表管理 经营分析报表 平台运行监控 角色管理 权限管理 数据补录 金融经理考核金融经理考核 参数维护 考核报表 71 通用展现平台:功能架构 q经营分析系

42、统 n经营分析报表、部门报表、数据补录、数据订制下载、总账查询、 经营指标查询. q金融经理考核系统 n移植原金融经理考核系统功能 q管理员系统 n机构、用户、角色、权限管理（不同应用系统公用一套机构、用户 、角色，不同系统角色具备的权限可以设置不同). n平台运行ETL监控、错误监控. n公告管理、数据字典管理、通用参数管理. n菜单管理、报表管理. . 72 通用展现平台:物理架构 WEBSPHERE 润乾报表润乾报表.war 超链接超链接 HTTP 门户门户.war应用应用.war 超链接超链接 73 通用展现平台:报表发布流程 report.war WEBSPHERE 菜单菜单 UDS

43、F管理系统管理系统 .rpg.jsp 角色角色 润乾client开发端发布到服务器登陆UDSF管理系统 添加菜单 指定超链地址 将菜单分配给角色 项目情况汇报 q已完成里程碑 q近阶段工作安排 q总体实施计划 q实施难点 75 项目情况汇报:已完成里程碑 日期里程碑交付物描述 2008-11-25项目启动会启动会介绍PPT 启动会会议记要 项目组,科技部门,业务部门,行领导参与, 项目正式启动,确定了项目目标,人员组 织结构,项目计划,沟通渠道等内容. 2008-12-25经营分析系统需求收集结束经营分析系统需求范围收集了各业务部门针对经营分析系统 提出的各类报表需求，项目组将针对 此需求进行

44、分析整理，划定实施范围 以及实施策略。 2008-12-30数据调研结束数据调研报告(数据源范围,数 据源结构,数据源码值说明,数 据源采集策略,数据源问题检 核报告,UDSF平台标准代码) 由科技方相关系统负责人介绍数据源 系统的详细情况,之后项目组根据提供 的数据结构文档,样本数据完成数据调 研工作.目前除信贷系统外的数据源调 研已结束. 2008-12-30UDSF总体设计完成总体设计介绍PPT UDSF平台总体设计 ETL总体设计 数据模型总体设计 展现平台总体设计 数据模型设计标准 ETL实施标准 数据库规划优化方案 由项目组与科技部项目相关人员共同 完成,为UDSF平台实施的总体设

45、计思路、 实施策略、实施规范、关键问题解决 方案.在此基础上完成UDSF平台的各类 详细设计 2009-01-10数据采集平台、采集角本完成采集平台详细设计、程序代码、 数据源采集角本 满足单元测试条件 76 项目情况汇报:已完成里程碑 日期里程碑交付物描述 2009-1-20金融经理考核系统需求分析金融经理考核系统需求说明书项目组通过分析原金融经理考核系统 程序代码分析其目前的功能需求。 2009-2-6数据平台ODM,FDM模型设计完 成 ODM，FDM模型图，数据结 构文档. 贴源数据层，整合数据层的模型设计 整理工作，完成了数据模型的部署， 满足ETL开发条件。 77 项目情况汇报:近阶段工作安排 结束日期工作内容 2009-02-17FD