中国建设银行信贷资产项目后台数据抽取及挖掘-毕业论文

本科毕业论文(科研训练、毕业设计)题 目：中国建设银行信贷资产项目后台数据抽取及挖掘姓 名：学 院：软件学院系：专 业：软件工程年 级： 学 号：指导教师（校内）： 职称： 指导教师（校外）： 职称： 年 月 日中国建设银行信贷资产项目后台数据抽取及挖掘摘 要随着我行对亿万级信贷数据源处理的不断完善和提高，我行在信贷数据采集规范、数据定义、开发标准、分析模型、报表口径不一致的问题亟待解决。信贷资产项目的目标就是梳理全行信贷信息指标、统一信贷报表口径、改善信贷数据采集规范。本文通过对信贷资产项目现状的描述，引入数据仓库在建行分析和决策上的必要性，及其解决数据格式、语意语法的不一致问题从而实现信息披露的准确性和及时性。本文进一步从信贷资产项目的应用架构介绍了信贷信息数据库，通过完成历史数据的加载和存量数据的迁移这两项核心工作来满足新旧系统的一致性，以及数据的接入、调整与补录业务，从而实现时间的同步，范围、口径、质量、业务的无差别衔接。本文还通过ETL实现数据的抽取转换清洗装载过程，保证加载数据的质量。并利用商业智能工具收集、管理和分析数据，将建行中现有的大量数据转化为有用的信息，帮助建行做出明智的业务经营决策。关键词：数据仓库；数据质量；ETL；商业AbstractWith our constantly improvement and enhancement to the processing of hundreds of millions of the credit data sources, our China Construction Bank has some problems need to be resolved immediately, such as, the collect regulation of credit data, data definition, the development of standards, analysis model, and the inconsistency of the calibre of the report table. The target of the Credit Assets Project is just carding indicators of the whole banks credit information, unifying credit statements calibre, and improving data collect regulation credit.This paper introduces the importance of the Data Warehouse in CCBs decision-making by the description of the Credit Assets Project, and show us how the Data Warehouse solve the inconsistency of the data format and semantic to implement the disclosure of information accuracy and timeliness.The Credit Assets Projects application architecture introduces credit information database, the completion of loading the historical data and relocating the stock data helps meeting the consistency of the old and new systems. The datas access, restructuring business implement time synchronization and non-discriminatory convergence on range, quality and business.This paper also meet the process of data extraction, conversion, cleaning and loading to guarantee the quality of data. And collect, manage and analyze data using business intelligence tools. It helps converting large amounts of CCBs existing data to useful information, and so CCB can make a wise business decision-making.Key words: Data Warehouse; Data Quality; ETL; Business Intelligence目录第一章 引言11.1 信贷资产项目现状11.2 信贷资产项目术语定义1第二章 信贷资产项目总体设计32.1 信贷资产项目目标细化32.2 数据仓库在信贷资产项目中的应用32.3 信贷资产项目应用架构设计6第三章 信贷资产项目详细设计93.1 信贷资产项目系统初始化93.2 ETL163.3 商业智能223.4 数据质量27第四章 信贷资产项目的实现结果294.1 创建数据源连接294.2 Framework模型设计304.3 Report Studio报表设计384.4在ride上发布报表43第五章 总结48致谢49参考文献50ContentsChapter 1 Introduction11.1 Credit Assets Project status11.2 Credit Assets Project definition of terms1Chapter 2 Credit Assets Project overall design32.1 Credit Assets Project goal details32.2 The application of Data Warehouse in Credit Assets Project32.3 Application architecture design in Credit Assets Project6Chapter 3 Credit Assets Project detailed design93.1 Credit Assets Project system initialization93.2 ETL163.3 Business Intelligence223.4 Data quality27Chapter 4 Credit Assets Project achieving results294.1 Creating a data source connector294.2 Framework model design304.3 Report Studio report table design384.4 Publishing report table on ride43Chapter 5 Summary48Acknowledgement49References50iv第一章 引言1.1 信贷资产项目现状我行信贷资产风险十二级分类信贷管理信息系统子项目的启动，在建立信贷资产十二级分类电子化流程的基础上，初步搭建全国统一的信贷资产数据库，支持十二级分类信息的汇总统计，为信贷数据和应用在全行全面实现集中奠定了基础。实施信贷数据全行集中是数据管理的大趋势，信贷数据和应用全行集中后将会进一步提高全行数据管理集约化水平，为在全行范围内整合应用信贷数据奠定基础，有利于在全行范围内实现数据共享，有利于管理信息系统功效的充分发挥，并可进一步降低系统运维成本。随着我行对公、对私信贷业务流程系统的建设推广，信贷数据源不断得到补充和完善，但我行信贷数据采集规范、数据定义、开发标准、分析模型、报表口径不统一问题一直以来没有得到很好的解决，数据一致性和准确性问题屡屡出现。信贷管理信息系统（CMIS）作为全行唯一全口径信贷信息的管理系统，具备构建统一信贷基础指标体系的有利条件。按照数据整合和管控工作要求，我们有必要依托信贷管理信息系统，梳理全行信贷信息指标、统一信贷报表口径、改善信贷数据采集规范，构建稳定、独立、多维的信贷基础指标体系，搭建信贷信息质量监测管理平台，以不断提高数据规范性和标准化程度。1.2 信贷资产项目术语定义数据源系统：为CMIS提供数据的系统，如对公信贷流程管理系统、新一代贸易融资系统、新一代个人贷款业务系统等。目标系统：CMIS为其供给数据的系统，如数据仓库及管理信息系统、内部评级系统、企业征信系统等。信贷资产风险十二级分类：信贷资产风险十二级分类是指信贷经营、管理人员按照规定的标准、方法、流程和要求对信贷资产质量进行全面、及时和准确的评价，在五级分类的基础上，按照风险程度将信贷资产划分为十二个级别的过程，即正常一级、正常二级、正常三级、正常四级、关注一级、关注二级、关注三级、次级一级、次级二级、可疑一级、可疑二级和损失级。信贷资产：是指建设银行通过发放、提供信用及承担信用风险形成的信贷资产，包括：(1) 各类本外币贷款：包括公司类贷款（含固定资产贷款、流动资金贷款、房地产开发类贷款、进出口贸易融资贷款、境外筹资转贷款、银团贷款、法人帐户透支、贴现、买入票据、买方信贷、非银行金融机构贷款、买入企业返售证券、国家特定贷款、受让信贷资产、表外业务垫款等）及零售类贷款（含个人住房贷款、个人再交易住房贷款、个人商业用房贷款、个人住房最高额抵押贷款、个人消费额度贷款、个人汽车贷款、个人权利质押贷款、中央财政贴息国家助学贷款、地方财政贴息国家助学贷款、个人助业贷款、下岗失业人员小额担保贷款等）。(2) 表外业务中的信用证、银行承兑汇票、保证、信贷证明、保理担保付款、贷款承诺（限于已经签定了借款合同或合作协议的帐户透支业务中未支用的额度，借款合同中分期用款尚未支用的贷款）。存量数据：是指新一代信贷管理信息系统在初始化时点的全口径信贷信息数据。历史数据：是指新一代信贷管理信息系统初始化时点前的全口径信贷信息数据。CLPM：对公信贷流程管理系统（Commercial Lending Process Management System）。CID：信贷信息数据库（Credit imformation database）A+P：新一代个人贷款业务系统。CARDLINK：国际卡系统。DCCCCBS：核心银行业务处理系统(Consolidated Core Banking System)。ERPF：企业资源管理财务系统（Enterprise Resource Planning Finance System）。ODS：操作数据存储系统（Operational Data Storage）DW&MIS: 数据仓库及管理信息系统（Data Warehouse & Management Information System）UAAP：信息系统认证授权平台（Union Authentication Authority Platform）。征信（Credit Reporting）：依法收集、整理、保存以及提供信用信息的活动。第二章 信贷资产项目总体设计2.1 信贷资产项目目标细化(1) 应用和数据的全国集中(2) 系统梳理CMIS功能，构建全行全口径信贷信息的统一发布平台(3) 实现信贷风险分类标准的提升，深化分类数据应用，满足对外披露和内部精细化管理要求(4) 整合信贷信息采集渠道，减轻一线人员工作量(5) 构建稳定、独立、多维的信贷基础指标体系和数据质量检核体系，利用灵活的报表工具，满足业务多元化需求(6) 开发可配置接口，持续支持ERPF、征信等系统以及分行CMIS应用数据的供应2.2 数据仓库在信贷资产项目中的应用2.2.1数据仓库的必要性1为了应对当今日趋激烈的市场竞争，提高自身竞争力，商业银行需要提高服务质量、推出新产品来巩固已有客户并在吸引更多的新客户的同时提高经营业绩、控制经营风险，这需要提高管理水平、丰富业务手段。当银行中的各级管理人员在运用各种管理知识管理银行时需要准确了解银行的现状和以往历史来做出判断和决策，因此对管理和运行银行业务的信息系统提出了更高的要求，希望能够从中获取综合银行有效的决策支持信息，及时准确地把握市场变化的脉搏。目前，国有商业银行中现有的信息系统大部分是独立建设的，是基于不同时期、不同的业务需要而建立的各种业务系统，这些业务系统所应用的范围不同，层次也有所差别，互相之间的联系很少，同时还存在不同程度的数据冗余和不一致。虽然基本完成了数据集中的大平台，但是所集中的数据主要是银行业务的核心数据，各省分行的外围系统如中间业务、网上银行、电话银行、电子账单等业务系统中的客户信息和详细交易信息仍以分散的形式存在于不同的业务系统中；另一方面，业务系统所收集的数据在数据的质量、保存时间、数据的更新特性上和应用于分析型信息处理的数据存在差别。因此，要想全面而准确地对银行的现状和历史进行综合分析进而得到决策支持信息就必须在核心业务数据集中的基础上按照统一的规范整合外围系统的数据，并将整合的数据按时间的顺序保存。2.2.2 数据仓库简介数据仓库（Data Warehouse）就是针对上述问题而产生的一种解决方案，它是基于大规模数据库的决策支持系统环境的核心。数据仓库是一个面向主题的、集成的、永久的（数据一旦被写入就不会进行一般意义上的数据更新和删除）且随时间不断变化（按时间保存活动和事件的历史记录）的数据集合，用于支持管理层的决策。数据仓库中的数据按照主题进行组织，主题是与建行相关的事物（物理的项、概念、事件、人和位置）在建行业务中较高层次上的抽象分组，每一个主题对应于建行中某一宏观分析领域所涉及的分析对象。所有的主题处于近似相同的抽象层次，其定义是结构化的，因而彼此是互斥的。通过将来自各个业务系统中用于分析型处理的源数据从事务处理环境的操作型数据中提取出来，再进行清洗和统一格式转换等标准化处理后按照确定好的主题重新组织并存放在数据仓库中，数据仓库将原先存放在多个业务系统中的反应建行局部情况的数据转换成反映整体情况的信息，由此完成从“数据信息”的转变，使得建行最终拥有适应于解决分析型问题的基础数据。数据仓库不是简单地对数据进行的存储，而是在提取各业务系统中分析型数据的基础上对数据进行再组织，将数据转化为信息。数据仓库的建立有利于统一解决多个分散的数源间的不一致问题，包括数据格式不一致、数据的语意和语法不一致，以及时间的不一致等问题。图2-1 数据仓库的整体环境2.2.3 数据仓库在银行信息系统中的应用2在建行的各部门尤其是基层的业务部门，编报各种报表的工作量很大:有本行的报表，有报上级行的报表，有报人民银行的报表，有报银监会的报表，还有大量的临时性通知要求报送的报表或数据。各系统报表繁多、自成体系，由于数据来源不同，经常出现上级行发现下级行报送的报表相互之间不平衡，只有要求下级行更正之后再重新上报的现象，极大影响了报表的准确性；同时，数据上报环节较多，也极大地影响了报表报送的及时性。利用数据仓库技术，建立建行的数据仓库，将各业务系统的基础业务数据通过数据提取、数据分析、数据计算或汇总的整合过程进入数据仓库。在数据仓库的支持下，不仅可以实现商业银行报表的自动生成，而且利用计算机软件技术可以实现整个过程全自动化；不仅可以实现月报表的自动生成，而且可以实现日报表的自动生成，为各项业务的开展提供强大的信息支持。各部门业务人员每天上班进入查询系统，便可以浏览各种业务报表以及各项业务指标的数据。利用数据仓库技术的支持，通过信息生成的自动化，达到信息披露的准确性和及时性，有利于建立健全透明的信息披露体系。近几年我国行正在进行股份制改造，实现在资本市场公开上市对商业银行在信息披露上提出了更高的要求。传统的数据报送是采用由县级基层行统计，经过层层上报及汇总最后到达总行的方法，报表及数据传递的顺序是自下而上的，这无论在准确性还是及时性方面都无法满足资本市场和监管部门信息披露要求。而应用数据仓库技术建立数据仓库后，报表及数据是由总行的数据仓库集中自动生成的，报表及数据传递的顺序是自上而下的，总行及各级下级行均可以通过查询系统查询报表及数据。利用数据仓库技术，建立建行的数据仓库，为银行的信息系统提供强大的基础数据，不仅可以实现报表信息的自动化，而且可以实现决策的信息化，真正做到把数据集中带来的技术优势转化成我国商业银行的竞争优势。在建行总行及各分行都建立了数据仓库之后，总行的报表同样可以通过建立自己的数据仓库，向各分行数据仓库提取自己所需要的数据：不仅提取报表所需要的数据，实现报表生成的全自动化过程；而且还可以提取所需要的明细数据，实现金融风险的管理和监控信息化，为宏观调控提供了科学的决策支持。2.3 信贷资产项目应用架构设计2.3.1 应用架构(1) 应用架构图：图2-2 应用架构图(2) 信贷管理信息系统的五层架构图：图2-3 五层架构图2.3.2 CID数据库(1) 基础区存储来自于源系统的最全面的信贷历史数据，所有建行信贷数据都应当在这个区域中找到，是CID数据库建设的基石。(2) 多维区针对通用业务主题整合相应的业务数据、维度信息和代码表，形成独立的、统一的、完整的数据视图，不同业务主题可以通过共用维度和代码方式进行信息共享和关联。支持最通用、灵活度最高的查询。特点：面向业务主题，不可修改的，明细数据和轻度汇总数据并存，具有通用性，数据可以为多个前端应用所共享。采用星型模型进行设计，配合相应的维度和代码表，可以从多角度来分析各类指标。(3) 应用区针对报表格式的特殊性、查询性能、数据写入等需求，设计相应的数据表，此类数据表是针对前端应用中特定需求而设计的，一般为某个应用所专用，不具有通用性(4) 控制区存储支撑CMIS-II中应用功能运行的信息，包括控制表、ETL调试表等(5) 调整区针对调账需求而设计的数据区域第三章 信贷资产项目详细设计3.1 信贷资产项目系统初始化系统初始化是一个系统新生的第一阶段，CMIS系统初始化在此主要是指CMIS系统完成承接CMIS3.0系统功能的这一过程。它是保证我行信贷CMIS系统功能顺利平移的一个重要阶段。整个初始化过程，包括机构设置、用户管理、系统参数等功能性职能的承继，最核心的工作是实现CMIS系统历史数据的加载和存量数据的迁移，以确保新旧系统对CMIS系统功能的饱和承接。完成CMIS系统初始化后，CMIS将在承接CMIS3.0功能基础上借助CID数据平台,进一步扩充系统数据采集广度、深度，从而提升建行信贷信息数据应用管理水平，满足信息披露、业务管理、风险管理等需要。3.1.1 系统存量数据的处理3.1.1.1 存量数据的策略及指标因CID为已上线平台，且为CMIS数据源,为此不宜采用将CMIS3.0系统初始化基准点的当前数据通过技术手段从CMIS3.0系统导入CMIS系统，而是以CMIS3.0数据为标准、作为依据对CMIS系统初始化基准点的数据进行调整，辅之人工干预，使之与CMIS3.0数据指标映射、时间同步、数据等质、口径匹配，以确保维护后的CMIS相应数据在基准点包容CMIS3.0系统需求，进而实现新旧系统的自然过渡。准确、完整、简便、高效是存量数据初始化的工作原则。CMIS系统存量数据包括基础数据和派生指标，基础指标主要指最小粒度的业务经营指标，一般始发源于单笔业务行为，包括客户信息、合同信息等，这一部份业务数据主要采取业务经营人员人工处理的清洗方式，但需技术上提供辅助支持；派生指标是基于基础指标的再加工，包括汇总、累计、归类等手段，它主要由系统自身通过业务规则加工获取。为此派生指标的清洗主要采取技术手段，由技术人员完成清洗工作。3.1.1.2 存量数据的初始化系统初始化阶段的关键是CID导入CMIS的数据与CMIS3.0数据的比对。通过比对找出两者的差异，进而在CID上采取措施进行人工干预或技术调整，确保数据的可用性。整个初始化阶段的流程：(1) 初始化基准时间点，CMIS系统通过CID完成同一时间点源系统清洗后的数据的加载。(2) CMIS系统对接入的清洗后的系统数据以CMIS3.0数据为标准采取技术手段进行检核，以确保CMIS数据与CMIS3.0数据的一致性，对不一致的数据可以回到CID进行调整（人工或技术）后更新，直到满足两者一致性要求。(3) 经过技术手段验证的CMIS数据，还需进行业务应用验证，主要手段是通过CMIS报表工具生成业务报表，比对CMIS3.0系统生成的业务报表验证两者的一致性,发现并修正差异,直接满足一致性要求。如此通过反复清洗验证,最终实现CMIS系统指标在范围、口径、质量以及业务规则等方面与CMIS系统的无差别衔接。3.1.2 系统历史数据的初始化3.1.2.1 历史数据初始化策略CMIS历史数据的采集主要是以基础指标为基础，以CMIS合同为基础粒度，在此基础上搭建客户信息、账务信息等关联信息，形成CMIS基础指标集。作为CID的数据源系统，如CLPM系统各分行上线时间点不同，有先有后，导致CID中的历史数据各分行有早有晚。因为CMIS3.0历史数据作为全行的标准信贷口径信息披露标准,为此统一以CMIS3.0数据作为CMIS存储标准。历史数据的数据量巨大，为此对于历史数据采取的初始化工作的原则是重点保证、简洁便利。可以考虑在指标范围及时间点上有所取舍，鉴于目前CMIS3.0指标保留历史信息的数据量不多，为此要求采集全集。采集时间点可借鉴CMIS3.0的存储策略，一年以内数据以旬为单位、一年以上数据以月为单位，三年以上数据以年为单位，至少保留五年。3.1.2.2 历史数据初始化历史数据的初始化是建立在存量数据初始化工作成果的基础之上进行的，此阶段工作的核心是进行历史数据的比对工作，通过比对获取CMIS系统中有而CMIS系统中不存在的和两系统交叉有的数据。依据CMIS历史数据保存策略，技术上准备好CMIS3.0历史数据范围和储备数据的时间点。这些数据将作为CMIS系统历史数据的标准。完成以上历史数据初始化的准备工作后,进入初始化阶段,此阶段工作流程:(1) 历史数据直接导入CMIS系统，构成CMIS历史数据，CMIS存量数据的历史数据,以CMIS标准历史数据接入替代CMIS原通过CID接入的历史数据。(2) 对于CMIS有而CMIS3.0没有的基础数据，需要采取人工处理模式，逐笔核对与CMIS3.0的对应关系，实施补录或清理，特殊情况如确属CMIS错误的，按CMIS3.0数据存储模式以CMIS数据为标准处理。(3) 对于系统派生指标，技术上将所有CMIS3.0相应指标直接导入CMIS并单独存储。(4) 全部历史数据加载后，业务部门通过报表工具验收两系统关键时间的数据的一致性。通过评估后完成历史数据的初始化工作。3.1.3 系统数据的接入经过系统初始化，CMIS3.0全量存量数据就与CMIS实现对接。CMIS增量数据采集为了减轻业务经营人员的重复劳动，充分利用其他系统的资源，CMIS系统数据采集采取系统接口的模式，从其他系统接入数据。如接口系统一定时期内不能完全满足数据使用要求，则辅之以人工手段加以完善。3.1.3.1 系统接口的上游系统CMIS系统作为全行统一的信贷资产管理信息数据库，经CID接入CLPM、A+P等系统源数据，为DW&MIS、ERPF等目标系统提供数据。与信贷相关系统之间的关系见下图。图3-1 系统接口上游系统CLPM系统、A+P系统、CARDLINK系统都需向CMIS系统提供与CCBS一致的明细账务数据，从而确保CMIS系统与ERPF总账的对外报送数据的一致性。3.1.3.2 数据调整与补录CMISII项目前期对源系统数据进行了分析，从分析的结果看目前CMIS目标接口源系统尚不能完全满足CMIS数据使用的要求，需要对源系统进行系统改造或辅之以其他手段对CMIS所需数据进行处理方能使用。对公信贷数据源系统CLPM上线一年来，数据质量水平不断提高，但目前阶段还存在一些问题，全量上的不完整，CLPM还不是建行全口径对公信贷业务系统，CCBS与CLPM间账务数据的衔接存在不同步，此外还存在一些CLPM用户业务操作原因导致的不一致。对私方面目前CCBS系统还有一部份个人质押贷款、个人买方信贷、个人其他贷款等业务处理未接入A+P个贷系统。准贷记卡由于CCBS无翻牌机制，ERPF总账生成与传导给CID的明细数据生成时间不同步，导致的差异。3.1.3.2.1 调整方式因为CLPM解决数据质量的问题需要一个相对比较长的时间，而CMISII的项目建设又不能等待，所以考虑在CID环境中对接入的CLPM对公信贷数据进行手工调整。这个方案优点是可以在CMISII项目建设的规定时间内，通过人工调整的方式实现数据的准确、完整；缺点是数据在CID中落地并修改，造成实质上CMISII的两个数据源，另外因为调整数据需要时间，CID和CMISII的数据时效会有延迟。对私信贷数据目前在CID中已经有个贷业务的补录界面和补录功能。待全量个贷数据都接入CID后，通过定时的核对机制，让对私客户经理在CID中补充。在这样的机制下，我们可以满足CID中的个贷信息完整和准确。3.1.3.2.2 业务处理流程CLPM、AP等源系统能够提供的业务指标信息及帐务信息通过CID全部采集到CMIS系统中，在CID中进行数据检核，缺失的业务指标、与CCBS不符的帐务明细数据、与ERPF总帐核对不一致数据均在CID中进行调整，待数据可用后转入CMIS储存应用。系统对人工修改录入的信贷数据进行规则验证，通过验证的数据才允许保存，未通过数据提示与哪项验证规则不一致。图3-2数据调整模式业务处理流程图3.1.3.3 数据存储CMISII的数据存储要应遵循独立存储、贴合应用的原则。CMISII要有自己独立的存储空间，按照不同信贷数据应用内容和业务逻辑、业务口径进行分类存储。在按照应用内容存储的同时还要结合时间点要求。不同的应用内容对时间点和时效的要求也存在不同的需求。 内容时点年报信息披露银监会外部监管人行金融统计管理层决策支持内部部门考核内部管理分行应用每天每旬每月每季每半年表3-1 存储内容表CMISII存储的内容都应该是符合业务逻辑和业务规则的，可以直接发布以及提供分行应用的。存储的数据类型分为客户信息、合同信息和账务数据。CMISII的数据要独立于CID之外单独存储。按照不同的应用内容划分为不同的存储空间。按照时点分为每天、每旬、每月、每季、每半年进行存储。每天的数据的保存周期为一个月；每旬数据的保存周期为一年；每月、每季和每半年的数据保存周期为五年。过期数据要建立备份并永久保存。要建立定期备份制度，并确保备份可正常恢复。3.1.4 数据检核CMISII要建立和CLPM等数据源系统的数据接口，接入所有信贷业务的客户、合同、帐务、风险分类、减值准备等信息和数据。建立和新个贷系统、CCBS系统接口，接入零售信贷业务的客户、合同、风险分类、减值准备等信息和数据。保证接入的数据和系统中历史数据有机的融合，满足信贷信息持续披露要求。为保证最快的数据时效，满足内外部信息展现和披露要求，要建立合理的接口数据传输机制。对公和零售信贷信息一方面要实现系统间批量和自动传递，另一方面还要设置手工调用接口数据机制，包括对同一期数据的重复调用机制，以确保信贷信息能在最短时间内准确接入系统。为保证数据质量，满足内外部信息展现和披露要求，要建立接口数据质量的分级检核机制，确立检核规则，向数据源系统反馈检核差错日志，便于源系统强化数据质量，也有利于CMIS数据应用的把握。3.1.4.1和CCBS明细帐务数据的核对对从CLPM、新个贷系统等数据源系统接入的帐务数据要保证和CCBS中交易流水帐务数据的一致，保证数据源系统和CCBS每笔合同的交易流水摘要的一致。因CCBS中无法准确区分特殊流水摘要，因此要保留系统中手工调整流水摘要功能，能按实际业务区分出特殊流水摘要。3.1.4.2和ERPF汇总帐务数据的核对要执行全行ERPF统一总账制度。在确保和CCBS明细帐务数据一致的基础上，保证系统数据和ERPF汇总帐务数据的一致。对接入的数据要每天进行和ERPF总账数据的核对，如发现和总账数据不一致，要保留手工调整功能，确保每天的帐务数据和总账数据一致。3.1.4.3对有明显错误和缺失的文本信息进行校验系统中除了要建立明细、汇总帐务数据的核对机制，还要建立文本信息的校验规则。因系统中还会保存大量的有关客户、合同的文本信息，这部分信息的准确性，也将极大影响信息披露质量，对明显不符合业务逻辑的文本信息要提示并直接下发给用户，生成错误信息报告提交管理行，并建立督促修改机制。3.2 ETLETL，Extract-Transform-Load的缩写，是数据抽取、转换、清洗、装载的过程。是构建数据仓库的重要一环，用户从数据源抽取出所需的数据，经过数据清洗,最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中去，是BI/DW的核心和灵魂。3.2.1 ETL需求3.2.1.1 源数据范围CMISII系统的数据源范围包括：1对公信贷流程管理系统（CLPM）CLPM主要应用功能包括：系统管理、授权管理、文档管理、台帐管理、集团管理、额度管控、审查审批流程处理以及风险控制等。包括客户信息、评级数据、额度数据、信贷业务数据、担保物数据、合同数据、贷后监控数据、资产保全数据、帐户数据、授信审批数据。到目前为止库中的总数据量达到180G，每天增量3G左右。2个人信贷业务系统（A+P）A+P是结合了A系统的帐务处理和P系统的信贷管理、统计分析功能，是一套全面的个人贷款业务处理系统。A系统包括：个贷账务数据、个贷当天交易数据、个贷历史账务数据、个贷历史交易数据。P系统包括：个贷客户信息、合作方信息、担保信息、贷款补充信息、审批流信息、授信额度信息。另外，也有账务信息是从A系统批量返还的。到目前为止库中的总数据量达到480G，每天增量2G左右。3国际卡系统（ICS）ICS功能是对建行的信用卡业务实行发卡、授权、交易、清算、客服、催收等业务的集中管理。包括贷记卡卡数据、卡帐户数据、申请数据、交易明细数据、帐单数据、催讨数据。4核心业务系统（CCBS）CCBS中抽取准贷记卡业务相关数据，包括卡客户、帐户、交易数据，另外还包括CCBS中的个贷数据。到目前为国际卡和准贷记卡在库中的总数据量达到20G，每天增量600M左右。3.2.1.2 ETL数据质量管理在ETL过程中，应采用专门的ETL数据质量管理工具，对数据质量进行控制，其要求具体如下：1. 保证ETL加载过程的正确性，分析加载日志，并对加载错误有相应的处理方法；2. 保证加载数据的质量，采用各种业务规则和技术规则来校验数据质量；3. 对数据使用过程中发现的数据质量问题，应及时地在ETL加载过程中用相应的方法和对策来处理。3.2.2 ETL体系架构设计3ETL体系架构的设计将充分考虑到ETL系统的稳定性、安全性、可扩展性、可操行性和可维护性，设计界定清晰的ETL体系层次结构，自动化控制的ETL流程，以及数据传输和交换的接口，设计ETL转换处理中实现策略机制，以及数据质量检查手段和方案，规划和设计ETL调度流程管理平台。3.2.2.1 体系架构设计描述图3-3 ETL体系架构图如上图所示，CMISII的ETL体系架构清晰地定义了源数据层、数据仓库层、数据集市层、前端应用层所涵盖的内容与范围。该ETL体系架构为CMISII数据流向的主要环节。整体采用DataStage作为ETL工具，必要数据转换环节可以使用Oralce存储过程。由ETL任务（DataStage JOB或存储过程）和ETL调度监控与日志跟踪管理模块组成。3.2.2.2 源数据层源数据层作为数据导入层的数据抽取源，为整个CMISII提供原始数据。ODS作为源数据获取的唯一入口，以一定频率实现所有源业务系统数据的集中存储，在本ETL体系架构中，ODS控制由源数据抽取、清洗、转换、加载到缓冲区SA的ETL流程，并且由源数据抽取、清洗、转换、加载到SA的整个过程将采取中间处理不落地的方式，实现端对端的ETL过程。3.2.2.3 数据仓库层4采用DataStage完成由CMISII缓冲数据区、基础数据区、汇总数据区汇总的抽取、转换、加载。缓冲数据区是按源系统逻辑存放临时数据，基础数据区是按照逻辑数据模型及主题存放明细数据，汇总数据区是存放对明细数据进行更粗粒度汇总的数据。逻辑上，基础数据区和汇总数据区都属于CMISII粒度不同的数据，整体构成CMISII的数据仓库层，为应用分析和即席查询提供数据支持。数据目前每日都做全量备份。数据粒度是CMISII系统中一个重要的指标。CMISII中数据组织方式的核心思想是在系统中保留最有可能被用户使用的数据，因此，在CMISII中多重的数据粒度是必不可少的。数据粒度不同，对数据量大小的影响和数据处理性能的影响是不同的。从数据量方面来看，数据的汇总程度不同，其数据量将相差很大。数据粒度越小，信息越细节，数据量越大；相反则数据量越小。从数据处理方面来看，细节数据回答综合问题需要访问大量的记录，进行大量的计算；汇总数据回答综合问题，只需访问很少的数据。在进行数据仓库层数据存储设计时，需要在满足需求、适当的数据量和优化数据处理性能几个方面找到平衡点。3.2.2.4 数据集市层采用DataStage完成从CMISII基础数据区和汇总数据区向应用数据集市的抽取、转换、加载。数据集市是按照业务主题和部门需要而建立，它从基础数据区和汇总数据区中提取数据按照应用需求主题进行加工和重组，形成面向业务的明细数据、汇总数据或OLAP分析模型。从逻辑上，应用数据层和数据仓库层都可以对业务提供数据服务，差别在于应用数据层的数据是在数据仓库层上经过计算和加工的，对针对特定应用分析系统，能够提供更多样化更高效更灵活更快响应的数据访问服务，而前端直接访问数据仓库层时，通常需要在前端进行即时在线计算和重组，不具备多维分析功能，也不能保证响应时间在业务的要求范围内。从整体应用分析系统规划入手，基于硬件性能和数据库性能考虑可以在物理上分离数据集市，以单独服务器向某项业务提供服务，达到均衡用户访问压力。对数据集市的大小和规模应该加以控制，一般情况下，每个数据集市应用的数据量应控制在1020GB，否则很容易失去控制，并由于冗余数据的原因导致高成本和低效率。对于OLAP应用，OLAP服务器中的多维数据集的数据量应不超过100MB，维度总数应控制在10个以内。3.2.2.5 前端访问层前端访问层主要包括BI工具、WEB、认证安全、门户四方面的服务。CMISII的前端访问层主要由Cognos、Web Server、Web Application Server、CMISII Portal、用户安全认证等组成。Cognos作为报表平台和OLAP服务平台可与Web集成并整合到Portal中，通过用户认证管理实现业务访问。设计原则：该重用包括组件重用与设计模式重用等方面；架构设计要具备一定的灵活性与扩展性，使得所有的开发人员都可以在这个构架下进行具体的开发工作；作为整个CMISII对外提供应用服务中唯一的门户入口，Portal设计必须保证系统的高稳定性与高性能，选用业界成熟的先进技术与产品作为平台基础框架，并能在客户化的过程中，充分体现产品的技术优势；体现系统可扩展性与可移植性，采用基于J2EE的企业应用框架，使系统可以在不同平台间做平滑移植；安全性上，通过Portal的用户登录和OLAP的用户的2层机制，来保证用户的访问安全。3.2.3 ETL数据处理流程根据建设银行CMISII的数据源和应用需求情况，设计如下，包括数据获取、转换、加载、生成星型结构数据和生成OLAP数据的生成等几个较为重要的数据处理阶段。(1) 获取为了把源数据加载到CMISII数据库中，首先需要先获取这些数据。一般来讲，数据获取包括两种方式：数据源主动(PUSH)：即数据源主动定时将相关数据吐到ETL服务器上。再由ETL服务器对数据进行必要处理（转换、清洗）后加载到数据库；ETL服务器主动(PULL)：即ETL服务器主动到数据源中获取数据。本系统是采取ODS主动向CMISII写数的方式。(2) 加载数据加载是将完成获取、清洗后的源数据加载到CMISII数据库中，数据加载过程需保证加载的快速、稳定，并且考虑到数据加载的维护，本次源数据向数据库加载采用DataStage的Oralce专用组件Oracle Enterprise来完成。(3) 转换转换工作主要分为两部分：加载前的转换：主要是针对数据格式、代码映射以及数据类型转换等。因为这部分工作是由ODS来完成，由此在数据获取中不必对源数据进行预处理。加载后的清洗和转换：主要是针对模型明细数据产生，在明细数据进行汇总计算以及异常数据的过滤。(4) 生成星型模型数据星型模型包括事实表和维表，是基于业务需求分析产生。基于代码表产生维表数据，基于汇总表产生事实表数据，两者关联可以为OLAP分析和汇总查询提供数据源。其中需要注意维表的维护，有些维度并不是每次数据处理都要进行的工作，当源系统的数据发生了某些变化，影响到CMISII维表的某些维度值，此时需要进行此类操作，保证维度值的正确性。(5) 生成OLAP数据用于实现把星型模型数据转移到OLAP服务器中，形成OLAP多维立方体。该处理是通过Cogons Transform来实现的，可以通过ETL程序进行调度和控制。3.3 商业智能3.3.1 商业智能概述商业智能，Business Intelligence，简写为BI，为建行提供迅速分析数据的技术和方法，包括收集、管理和分析数据，将建行中现有的大量数据转化为有用的信息，帮助建行做出明智的业务经营决策的工具。这些数据包括来自建行业务系统的订单、库存、交易账目、客户和供应商等来自银行行业和竞争对手的数据以及来自建行所处的其他外部环境中的各种数据。商业智能的实现涉及到软件、硬件、咨询服务及应用，其基本体系结构包括数据仓库、联机分析处理（OLAP）和数据挖掘三个部分。商业智能的关键是从许多来自不同的运作系统的数据中提取出有用的数据并进行清理，以保证数据的正确性，然后经过ETL过程，合并到一个企业级的数据仓库里，从而得到企业数据的一个全局视图，在此基础上利用合适的查询和分析工具、数据挖掘工具、OLAP工具等对其进行分析和处理（这时信息变为辅助决策的知识），最后将信息呈现给管理者，为管理者的决策过程提供支持。提供商业智能解决方案的著名IT厂商包括微软、IBM、Oracle、Microstrategy、Business Objects、Cognos、SAS等。而建行在商业智能上涉及到的主要工具为Cogons的Framework Manager、Report Studio、Query Studio、ride等。3.3.2 开发报表CMIS系统数据的应用主要有三个方向：CMIS报表展现、CMIS分行应用、CMIS目标系统支持。CMIS报表展现是CMIS系统的核心应用，报表部份包括固定类报表、包括自由定制类报表和数据统计查询类报表。其中固定报表与自由定制类报表主要通过专用报表工具实现报表展现，包括报表的定制、生成、发布、存储等功能，而数据统计查询类报表主要由系统自身功能实现，相比较于专用报表工具，此类统计查询类需求定位于小数据的加工统计和服务于业务经营需要和系统管理需要，相关功能需求参看系统维护部份。3.3.2.1 Cognos固定报表开发流程5Cognos固定报表的开发流程通常包括建立数据源连接、设计模型、发布模型包、开发报表和使用报表（包括查询、浏览、打印和导出报表等）。Cognos固定报表的开发流程图可以概括如下：图3-4 固定报表开发流程Cognos使用了逻辑数据源的概念，将数据源作为自己的内部资源管理，实现了对物理数据源的屏蔽，增加了应用系统的可移植性。建立模型是实现对业务数据按照业务规则进行封装的过程，COGNOS使用了图形化的客户端模型工具Framework Manager来提供一个元数据模型开发的环境。COGNOS的固定报表开发工具Report Studio是基于纯浏览器的实现，能够最大限度的降低维护的成本，提供系统的可用性。3.3.2.2 创建数据源连接在数据源确定了之后使用Cognos开发报表首先要建立到数据源的连接。目前实际开发中用到的数据库连接主要有两种，一种是通过ODBC连接数据库，例如Teradata数据库；另一种是通过数据库自带的客户端连接数据库，例如Oracle数据