智慧银行审计平台解决方案

1、信雅达智慧银行审计平台解决方案目 录 TOC o 1-2 h z u HYPERLINK l _Toc54797003 第1章 系统概述 PAGEREF _Toc54797003 h 4 HYPERLINK l _Toc54797004 1.1项目背景 PAGEREF _Toc54797004 h 4 HYPERLINK l _Toc54797005 1.2项目目标 PAGEREF _Toc54797005 h 4 HYPERLINK l _Toc54797006 1.3建设原则 PAGEREF _Toc54797006 h 5 HYPERLINK l _Toc54797007 第2章 产品优

2、势 PAGEREF _Toc54797007 h 7 HYPERLINK l _Toc54797008 2.1技术优势 PAGEREF _Toc54797008 h 7 HYPERLINK l _Toc54797009 2.2功能优势 PAGEREF _Toc54797009 h 10 HYPERLINK l _Toc54797010 第3章 总体架构设计 PAGEREF _Toc54797010 h 13 HYPERLINK l _Toc54797011 3.1审计系统整体架构 PAGEREF _Toc54797011 h 13 HYPERLINK l _Toc54797012 3.2功能逻

3、辑 PAGEREF _Toc54797012 h 17 HYPERLINK l _Toc54797013 3.3数据架构 PAGEREF _Toc54797013 h 19 HYPERLINK l _Toc54797014 3.4网络架构 PAGEREF _Toc54797014 h 34 HYPERLINK l _Toc54797015 3.5运行环境配置 PAGEREF _Toc54797015 h 36 HYPERLINK l _Toc54797016 3.6安全和访问控制 PAGEREF _Toc54797016 h 37 HYPERLINK l _Toc54797017 3.7系统性

4、能方案 PAGEREF _Toc54797017 h 39 HYPERLINK l _Toc54797018 3.8系统性能指标 PAGEREF _Toc54797018 h 39 HYPERLINK l _Toc54797019 第4章 系统主要功能 PAGEREF _Toc54797019 h 41 HYPERLINK l _Toc54797020 4.2非现场审计平台 PAGEREF _Toc54797020 h 46 HYPERLINK l _Toc54797021 4.3现场审计平台 PAGEREF _Toc54797021 h 71 HYPERLINK l _Toc54797022

5、 4.4知识库管理 PAGEREF _Toc54797022 h 92 HYPERLINK l _Toc54797023 4.5内控评价平台 PAGEREF _Toc54797023 h 98 HYPERLINK l _Toc54797024 4.6问题管理与风险评估平台 PAGEREF _Toc54797024 h 111 HYPERLINK l _Toc54797025 4.7统计分析平台 PAGEREF _Toc54797025 h 116 HYPERLINK l _Toc54797026 4.8基础管理平台 PAGEREF _Toc54797026 h 133 HYPERLINK l

6、_Toc54797027 第5章 系统运维管理 PAGEREF _Toc54797027 h 151 HYPERLINK l _Toc54797028 5.1运行监控 PAGEREF _Toc54797028 h 151 HYPERLINK l _Toc54797029 5.2容灾设计 PAGEREF _Toc54797029 h 152 HYPERLINK l _Toc54797030 5.3备份策略 PAGEREF _Toc54797030 h 158 HYPERLINK l _Toc54797031 第6章 审计模型库 PAGEREF _Toc54797031 h 160 HYPERLI

7、NK l _Toc54797032 6.1信雅达模型专题清单 PAGEREF _Toc54797032 h 160 HYPERLINK l _Toc54797033 6.2员工舞弊及道德风险识别类模型 PAGEREF _Toc54797033 h 164 HYPERLINK l _Toc54797034 6.3客户欺诈及违约风险类模型 PAGEREF _Toc54797034 h 165 HYPERLINK l _Toc54797035 6.4客户风险信息内外渠道收集及分析（黑名单客户管理） PAGEREF _Toc54797035 h 167 HYPERLINK l _Toc54797036

8、 6.5银监 EAST 总量分析模型清单 PAGEREF _Toc54797036 h 168 HYPERLINK l _Toc54797037 6.6银监 EAST 现场检查模型清单 PAGEREF _Toc54797037 h 168 HYPERLINK l _Toc54797038 6.7典型模型审计思路 PAGEREF _Toc54797038 h 170 HYPERLINK l _Toc54797039 6.8模型创新 PAGEREF _Toc54797039 h 171第一部分 技术解决方案第1章 系统概述项目背景银行业务快速发展和创新对审计工作提出了更大的挑战，为了提高审计效率，

9、规范审计流程，适应国内外审计大环境的要求，建设一套包括非现场审计、现场审计、内控评价及管理信息等审计功能为一体的具备完善的风险识别、分析和和监控管理的审计系统平台成为当务之急，目的是能够规范日常审计工作流程，防范业务风险，提升审计效率和效果、改善经营管理水平，进而更好更有效地打造银行业务风险的第三道防线。审计系统是以风险为导向，通过系统开发，对交易和管理数据进行自动采集和存储， 逐步实现指标分析、模型监测预警、查询查证、审计流程标准管理、文档与知识库支持功能的信息化审计平台，实现连续的风险审计功能。项目目标建设审计系统的总体目标是要建立一个多功能的综合审计平台，该系统应具有完备的数据分析、监测

10、预警、辅助决策、审计管理和统计查询等诸多功能，从风险控制的知度， 对金融机构的内部原始交易数据及外部经济数据进行基于流程的综合分析，揭示内部控制体系中的重大风险。（一） 平台可以通过风险预警功能基于大量的审计风险点与监测模型建立自动化预警机制，并提供预警处理、案例管理、风险报告等非现场审计工作流程管理；通过审计查证分析功能基于大量的查证模型与业务经验为审计查证思路与过程提供灵活定制的辅助工具。（二） 平台可以通过以现场审计工作处理流程以及档案管理为基础的项目管理功能， 实现日常办公自动化以及规划化；通过程序化审计功能，为各个业务条线的日常审计工作建立标准化与流程化的审计程序，提供相关业务审计过

11、程中审计要点、注意事项以及审计结论等的自动提示与底稿生成。（三） 平台可以建立灵活的内控评价体系，通过发起评价项目实现审计实体的评价过程管理，并提供业务状况、风险状况以及审计工作的统计分析与风险报告功能。（四） 平台可以通过审计用户管理、权限管理、日志管理、个人管理、配置管理、监控管理等系统管理与维护功能，实现统一的基础管理平台，同时实现对系统安全性的控制。系统功能定位：本系统的设计宗旨在于在满足辅助审计日常工作的基础上，提升本行的风险评估与案件防控能力，进而实现为改善经营提供有力佐证与决策支持的战略目标。主要功能定位如下：1、全面防控风险的审计监测管理平台本系统与行内其他业务系统和管理系统进

12、行无缝对接，系统支持准实时或事后多种方式进行业务数据源的自动化数据采集，系统在后台进行风险监测分析并在前台界面展示风险预警提示。2、全面辅助审计工作的自动化办公平台本系统为审计执行人员及管理人员打造全新辅助办公平台。系统不仅能支持审计执行人员辅助开展非现场审计监测、现场审计作业、营业机构风险评估、总分支机构内部控制评价等日常审计工作，而且支持审计管理人员完成审计业务流程和监测规则的灵活设置以及动态的业务追踪分析。3、提供改善经营管理决策参考的支持平台本系统基于通过现场审计、非现场审计监测、营业机构风险评估、总分支机构内控评价和内部审计质量评估结果的统计分析，为本行领导层及时提供审计工作情况、本

13、行风险状况进而调整经营管理战略的参考信息来源。建设原则该系统的主要目的是整合本行各业务系统数据，利用先进的审计方法和经验，规范审计流程。根据本行业务特点以及未来发展要求，借鉴国内外同业成熟的技术和经验，建设一个较完善的风险评估、监测、预警和防范平台，有利于规范日常审计工作，防范业务风险，提升审计效率和效果，改善经营管理水平。本系统应能满足今后 35 年内系统进一步扩充与发展的需要。系统应具有：开放式原则：该系统的应用主体不仅仅只是审计部人员使用，而应包括管理审计工作行领导、各被审计(检查)对象、各业务管理部门及其他用户。可扩展原则：系统数据来源应具有可扩展性能，未来根据工作需要，可将新系统数据

14、方便快捷的接入本系统，同时可根据需要进行快捷的二次开发。易维护原则：各模块之间必须具备很强的定制功能，业务人员可根据业务流程和管理的变化自行对基础参数进行适当维护，使得业务操作、管理模式等可灵活调整。易操作原则：系统应具有友好的用户操作界面，操作方法方便简单、易学易懂。可转换原则：系统应具有各模块功能之间能相互快速连接，满足审计人员各自的操作习惯。科学管理原则：各功能实现上要具有强大管理功能，不仅要实现作业流程的电子化， 更要实现有效的审计管理，提高审计管理水平。安全性和可靠性原则：系统应对数据的访问、传输、下载、分析、应用等操作具有加密功能或设置严格的权限控制体系。第2章 产品优势技术优势技

15、术架构先进信雅达公司自成立以来，一直注重技术的创新与发展，审计产品在技术研发与工具平台应用上使用公司最新的技术成果，以快速开发平台、全文搜索引擎、规则引擎、工作流引擎及报表引擎为基础平台支撑平台构建产品功能，使得系统架构组件化、模块化，更易于系统的拓展和维护。产品平台化审计产品基于信雅达自主知识产权的快速应用开发平台（SUNFAP）实现的，该平台作为审计产品的核心组件，为系统的功能扩展、性能优化、信息安全提供快速灵活的基础架构， 便于二次开发。审计产品实现了统一的数据管理平台、灵活的模型管理平台、丰富的审计报表管理平台、完善的工作流平台；使得审计产品在整体平台上开发便捷、扩展灵活。方便商业银行

16、审计业务的扩展和数据的变更，审计思路多变等业务应用的二次开发。产品设计引入先进的界面框架审计产品引入了先进的界面框架，增强了产品用户界面多样化、个性化，极大提高用户体验，提高产品访问效率。基于工作流技术的系统业务流程管理系统集成了信雅达公司自主工作流产品（SunFlow），实现系统各业务流程的灵活定义、参数化配置以及各流程节点的实时动态跟踪查看。灵活方便功能强大的模型定制平台系统提供完全可视化模型探索平台，审计人员不用掌握熟练的计算机技术通过托、拉、拽等方式即可定制创新审计模型。该平台实现模型的探索、创新、验证、发布的一体化操 作。为丰富审计模型库，保持模型生命力，持续监测发现行内风险提供方便

17、快捷的手段。 该平台还集成了可视化的审计专业数据分析工具，可在模型探索过程中利用数据分析工具对任意数据进行分析处理。利用搜索引擎技术实现全文检索系统封装了先进的搜索引擎技术，实现审计依据、工作底稿、审计问题等审计内容的全面检索功能，提升审计工作效能。方便实用主流的文档编辑组件系统封装了主流的文档编辑组件，支持 WPS、WORD 等常用办公软件，实现审计工作底稿模板化，使得审计工作底稿自动生成，大幅提高审计工作效率。可视化的资金流向分析工具系统利用 Flash 技术，开发设计了客户资金流向分析工具，系统可自动生成客户账户资金流向，也可手工分析编制客户账户资金流向图，利用该工具，可进一步的确认风险

18、。功能优势丰富多样强大的查询查证手段系统提供的数据追踪、模型关联、审计分析工具、资金流向分析工具、外部影像档案 调阅等实用方便的查证手段能使审计人员从多维度、多层次的对风险线索进行排查和确认， 减少审计人员现场作业时间，大大提高审计工作效率。现场审计与非现场审计一体化现场审计平台与非现场审计平台功能有机结合，非现场风险线索为审计项目实施提供立项参考和问题查证，现场检查过程对非现场审计发现的风险线索进行现场排查和验证， 实现现场审计平台和非现场审计平台一体化。全面的审计工作监控与督导功能系统提供对各项审计工作的进度监控与工作监督功能，使得相关领导能及时查看相关责任人的工作情况，及时督促指导相关人

19、员工作。多维度、多层次的风险统计分析功能系统可按项目、审计人员、审计对象、审计期限等不同维度对系统发现风险进行统计分析，并定期自动生成风险报告。参数化的审计风险抽样功能系统提供丰富实用的审计风险抽样功能，可对抽样维度进行自定义配置，同时系统提供常用的数据抽样方法。方便审计人员抽样，提高抽样效率以及抽样的科学性和合理性。丰富的知识库与成果引用功能信雅达公司一直注重研究、梳理银行各业务流程环节风险点，形成丰富的风险点库及问题词条体系。同时系统提供对审计工作案例的自动全面收集管理功能，提供方便的在线成果引用功能。可自定义的个性化一站式工作平台提供个性化的自定义工作平台，用户可在自己的岗位权限范围内根

20、据自己的习惯自定义个性化的办公平台，操作界面友好，布局合理；待办事项提醒功能，则为用户提供一站式的工作处理界面，方便系统的使用，提高工作效率。第3章 总体架构设计审计系统整体架构业务数据层业务数据是本系统的数据来源，包括行内各业务系统数据及第三方数据。系统利用自主开发的ETL 工具或者第三方ETL 工具自动加载各业务系统数据至审计数据库，第三方数据可通过 ETL 加载或者通过前台页面功能手工加载。业务系统数据核心业务系统信贷管理系统财务管理系统银行卡系统电子银行系统报表系统中间业务系统对账系统第三方数据政府、银监、人行、海关、税务、工商、水气煤电公布的不良信用企业 、网上收集的不良信息、黑名单

21、、影子银行、广告（信用卡代办广告）、信用卡套现等系统支撑平台智能引擎组件规则引擎：将业务模型从应用程序代码中脱离出来，形成模型规则库，负责模型规则解析、执行等操作。计算分析引擎：包括事中模型和批量模型计算分析，负责接收输入数据，调用模型规则引擎，计算出模型结果。报表工具：负责系统各类报表的设计、修改等功能。搜索引擎：负责知识管理平台中全文搜索服务。工作流引擎：负责系统中审计项目流程、问题整改跟踪等作业流程的配置、流转驱动服务。公共控制服务批量作业管理：应用于模型批量运行的管理，包括模型批量运行、模型数据查询分析等。模型配置管理：模型规则的配置，包括模型的添加、修改、删除等操作。日志管理：系统日

22、志查询、备份和清理。参数管理：系统运行各类参数的增加、修改、删除等。权限管理：系统权限、角色权限、用户权限的管理，包括系统权限的新增、修改、删除以及用户权限的新增、修改、删除等操作。数据管理：负责系统业务数据的转换、加载，备份和清理等操作。系统监控：包括 ETL 运行监控、模型跑批计算监控、系统用户监控等。应用服务平台系统主要为业务人员提供基础管理平台、监测预警平台、审计审查平台、项目管理平台、程序化审计平台、内控评价平台等功能。应用服务接口影像视频接口：系统与行内影像平台、账户档案管理系统、信贷档案管理系统、视频监控平台实现连接，实现业务数据与视频监控、影像档案在风险监管工作中的一体化应用。

23、短信接口：预警监测产生的信息可以通过短信平台接口发送；另外问题管理与风险评估平台中，下发问题的同时会通过短信平台接口发送至问题整改人。另外包括统一认证、OA 接口、邮件接口等其他接口。授权用户审计系统的用户包括：主管领导、审计管理、审计执行、技术支持等。主管领导主要负责本行审计工作管理、督查及审计资源调配与管控，一般多为行领导、审计委员会成员或审计部门负责人等。审计管理该类用户负责日常审计工作的管理控制，包括非现场审计、现场审计(检查)、内控评价、知识管理等核心工作，一般为审计部门的中层或基层管理领导或项目主审人。审计执行该类用户执行审计管理领导层分配的工作任务，执行非现场审计、现场审计(检查

24、)、内控评价及知识管理等基层工作，包括预警线索处理、协查分析、现场审计(检查)、内控评价执行、审计质量评估执行、知识管理等多个工作岗位。技术支持该类用户主要对本系统进行日常运维管理，多为信息科技部人员或审计部门内部 IT 技术人员。功能逻辑该系统主要包括基础支持应用、审计业务应用、辅助办公应用三大类系统应用功能；其中基础支持应用包括基础管理平台和知识管理平台；审计业务应用包括现场审计平台、非现场审计平台、问题管理与风险评估平台、内控评价平台四大核心工作平台；辅助办公应用包括审计质量评估平台、信息统计分析平台、个人工作平台三大辅助平台。系统中各个平台功能的主要的逻辑关系说明如下图：1、基础管理平

25、台是整个系统运行基础，它通过后台功能为现场审计平台、非现场审计平台及其他平台提供审计检查数据和作业支持。2、知识管理平台为审计工作作业的开展提供外部法规、内部制度、项目方案、审计要点、评价模板的参考支持，同时将日常审计工作成果进行信息标准化存档。3、现场审计平台与非现场审计平台功能结合。模型配置管理为非现场审计和现场审计作业提供查询查证模型配置、探索、发布、固化等管理。查询查证管理为非现场审计和现场审计作业提供查询查证工作平台。非现场审计为现场审计作业提供立项参考和检查清单；现场审计过程可对非现场审计发现的风险线索进行现场排查和验证。4、问题管理与风险评估平台同现场审计、非现场审计平台相关联，

26、现场审计、非现场审计发现的问题在该平台中统一集中汇总、统一分类管理、统一分配整改跟踪(外部审计、检查发现的问题也在该平台统一管理)。同时，该平台以内、外部审计发现的问题为依据， 对违法违规违纪人员进行违规积分管理，并对营业机构开展风险评估，风险评估的结果为现场审计提供审计重点。5、内控评价平台对被评价对象进行相对独立的内部控制评价，可调用知识管理平台评价模板，同时参考问题管理与风险评估平台的问题整改情况作为评价重要依据。6、信息统计分析平台为审计工作人员提供非现场审计、现场审计、内控评价、内审质量评估等平台审计信息的汇总统计分析和查询功能。7、个人工作平台为审计管理人员和执行操作人员提供办公自

27、动化工作平台。该平台与本行 OA 系统关联使用。informaticaGreenplum数据架构审计数据集市审计基础数据管理审计应用审计信息化平台审计功能系统交易系统数据仓库审计元数据管理第三方数据其它系统信用卡系统财务系统国际结算集中运营网银系统影像系统票据系统信贷系统核心系统源系统审计系统数据架构图参数组件模型配置管理审计数据区外部数据自定义数据客户风险统计统计全科目交易流水审计工作管理平台基础管理平台审计数据平台非现场审计平台框架组件批处理作业日志组件数据访问组件数据字典组件通讯组件数据统计分析组件权限管理RBAC指标引擎计算引擎规则引擎模型探索预警指标数据UIA数据归集数据审计模型库审

28、 计 导出数据审计资料库标签库管理文件数据区域数据缓冲区DATA POOL数据处理区STA目统计类类统计全科 客户风险授信交易 卡片信息 信贷管理审计中间层数据公共信息类会计记账 客户信息交易流水信贷管理类卡片信息类授信交易客户信息会计记账公共信息类审计系统业务数据从各业务系统中经数据处理区加载到审计基础数据存储区，经计算分析引擎，模型分析工具，后台服务程序以及业务人员分析确认后自动把数据存储于审计数据库中。ODS层数据核心系统信贷系统票据系统影像系统网银系统集中运营国际结算财务系统信用卡其他系统 第三方数据数据库规划和设计策略审计系统需要海量数据，所以数据库规划尤为关键。以下是审计基础数据库

29、设计过程中关注的几个设计要点。数据压缩策略将表存储在磁盘上时,如果对数据行空值和系统缺省值使用诸如压缩之类的功能,则表可能占用较少的空间通过数据压缩,可以使用较少的数据库页来存储数据,从而节省磁盘存储空间由于每页可以存储更多的逻辑数据,因此访问同样多的逻辑数据时需要读取的页数将会少一些这意味着压缩还可以节省磁盘 I/OI/O 速度也会加快,因为可以将更多的逻辑数据高速缓存在缓冲池中采用压缩技术的优点是：使用更少的存储；增加 I/O 吞吐量；以将更多的数据高速缓存在缓冲池中。采用压缩技术的缺点是：有少量的 CPU 消耗。表分区策略表分区功能是一种数据组织方案,根据一个或多个表列中的值将表数据划分

30、到多个称为数据分区或范围的存储对象中每个数据分区都是单独存储的这些存储器对象可位于不同的表空间和/或相同的表空间中跨多个存储器对象对表数据进行分区的能力为数据库管理员提供了更高的可伸缩性和灵活性,同时提高了性能和控制能力采用表分区技术的优点是：将大表按照某种关系分成若干个逻辑小表，可以减少数据扫描，提高效率；为数据库管理员提供了更高的可伸缩性和灵活性。采用表分区技术的缺点是：数据库管理员有较高的要求。元数据管理建立审计系统一个重要的工作是元数据管理。元数据管理就是描述业务审计数据信息， 用于建立、管理、维护和使用系统。元数据模块是系统中的关键组件，贯穿于审计系统的各个部分。元数据相关工作大致包

31、括元数据采集、元数据存储和元数据访问几个环节。元数据采集元数据采集是元数据管理流程的第一步。系统中元数据采集的来源有三个：ETL、业务数据文件、数据导入模块。元数据存储通过元数据库集中存储来自不同系统和环境下的元数据，形成元数据基准，减少元数据访问时对源系统的影响和依赖：面向开发人员的在线的数据字典、术语表、代码表；面向设计人员的实体关系、数据加工过程、影响分析；面向业务人员的业务用户指南，有业务元数据定义和数据使用提示。元数据访问对外提供统一的元数据访问服务，将元数据存储细节以及差异屏蔽在服务内部。系统数据分布应用服务器上传临时文件目录用户导出文件目录数据库服务器UIA数据指标数据外部导入数

32、据参数表审计基础数据元数据落地数据文件目录ETL服务器DATAPOOL数据处理目录数据仓库服务器交易数据数据环境是整个系统的数据存储环境，这个环境分为如下三个区域：ETL 服务器这个区域存放的是从一些从源系统中卸载过来的数据文件：数据缓冲区（DATAPOOL）：存放准备处理的数据文件；数据处理区（STA）：存放当前需要处理的数据文件，这些数据文件在下次同类数据处理前被删除。数据库服务器审计基础数据区业务基础数据，包括客户类、服务渠道类、产品类等数据；导入数据，通过 ETL 功能组件导入到系统中的外部数据；公共数据，由外部获取的公共信息资料，如外汇汇率。审计数据区存放审计功能相关的数据资料，包括

33、：审计资料库，即审计项目的备份资料以及审计资料；审计模型库，即审计模型的脚本；UIA 数据，即审计模型的结果数据，存储于数据库表中；标签库，即审计数据标签管理；归集库，即审计抽样、预警、指标等结果数据的归集管理。数据仓库服务器应用服务器用户上传导入数据；审计导出数据，即审计过程中导出的疑点数据。ETL 处理架构ETL 总体逻辑架构系统ETL 总体逻辑架构图如下：ETL 在架构上可以划分为 4个组成部分，ETL 任务、ETL 调度ETL监控、数据质量。他们以元数据为中心进行交互和协作。其中各部分的功能如下：ETL 任务：完成具体的数据 ETL 工作。ETL 调度：控制所有 ETL任务的运行。ET

34、L 监控：跟踪监控 ETL任务的运行。数据质量：跟踪系统的数据质量，详见“4 数据质量管理”章节。源系统接口规范由行方（或双方）制定接口规范及传输机制，包括源系统命名规范、接口文件命名规范、字段内容格式约定、抽取策略等。1、项目组在制定数据接口规范时将考虑如下方面：数据内容：确定需要的数据表，以及表中的每个数据项，包括数据项的长度、类型等。数据格式：指文件格式，如文本文件、字段变长分隔符分隔。编码格式：ASCII 码、EBCDIC 码等。命名规范：文件命名、目录命名等。数据周期：数据传输的频率，如每日、每周、每月、不定期。2、抽取策略数据抽取对各业务系统的依赖性强，应该根据各业务系统实际情况制

35、定相应的抽取策略。这些策略包括以下定义：抽取周期日内、日、月。接口增量方式日内增量：指抽取一天内某时间段（如 1 小时）发生变化的、新产生的数据最新状态快照。每日增量：指抽取每日 00：0024：00 发生变化的、新产生的数据最新状态快照。每月增量：指抽取每月 1 日 00：00 时始至月末最后一日 24：00 止，发生变化的、新产生的数据最新状态快照。每日全量：指抽取每日 24：00 时，所有数据的最新状态快照。每月全量：指抽取每月月末最后一日 24：00 时，所有数据的最新状态快照。每日新增数据：指抽取每日 0：00 至 24：00，此时间范围内新产生的数据。每月新增数据：指抽取每月 1

36、日 00：00 时始至月未最后一日 24：00 止，此时间范围内新产生的数据。抽取方式初始抽取：是指按照项目建设时点要求，首次从各源业务系统系统中将相关的数据一次性的抽取，初始抽取的数据范围包括抽取时最新状态为有效的所有数据，初始抽取时的数据周期将在数据接口单元的描述中根据具体情况描述。定期抽取：是指根据不同的数据内容，按照数据抽取周期，在指定的时间内对数据进行抽取的方式。定期抽取分为新增、增量或全量抽取。对于某些接口单元的数据，抽取周期既有日增量或者日新增数据抽取又有月全量抽取时， 其抽取月全量数据的当日，同时需要抽取此日增量或者日新增数据。根据源系统数据的不同特性，可以使用增量或全量抽取数

37、据。对于增量表的初始化，在上线前需要全量抽取。3、数据接口数据接口架构如下图 ：接口文件区是系统架构内存放接口文件和对接口文件进行处理的地方。系统中的中的 ETL 程序负责维护此区域。为了合理的组织接口文件区的内容，我们把接口文件区按如下目录结构组织，假设$DEL_home 代表接口文件区根目录（IFS：Interface File Staging）：目录内容$(DEL_Home)inb所有源系统传过来的接口文件$(DEL_Home)wrkETL过程中的临时文件和ETL文件处理结束后结果文件的存放地$(DEL_Home)arc备份文件$(DEL_Home)logETL处理日志及拒绝文件存放地$

38、(DEL_Home)out导出文件inb(Inbox)-当前正在处理的接口文件。每个接口文件传输到这里后，首先根据文件验证规则进行一致性检查，验证通过后，就表明这个文件是有效的，然后将此文件登记到数据集市的调度系统内，然后针对这个文件可以进行进一步的处理。wrk(Work)-工作目录。基于文本的 ETL 程序在此目录内把接口文件转换成可以装载的load 文本，load 成功后，此文件连通原始接口文件可以压缩后放到 arc 目录下做备份处理。如果ETL 过程中发现文件错误，则将错误文件放到 log 目录下。log-日志目录。ETL 运行过程中的日志和发生错误的接口文件都存放在此目录。out-导出

39、目录。需要传给外部系统的数据，全部安装目标系统分类放在此目录内。arc-备份目录。存放历史接口文件。接口文件处理完毕后，将按业务类型和日期移动到此目录。然后在此目录完成数据备份。通常接口文件以固定的时间间由源数据系统把数据传输接口文件区，在源数据系统和数据平台之间都应该有一个握手机制来保证文件传输的完备性，即因为在网络上传输数据文件需要时间，系统如何知道文件是否已经传完了。在接口规范上，我们要求源数据系统在传输完每个数据文件后，立刻创建一个与数据文件同名并以“.end”结尾的文件，文件内容为空或包含一些简单的数据文件验证信息，来告诉数据平台这个文件已经传完了。ETL 任务管理ETL 任务完成具

40、体的数据 ETL 工作，下面按照数据处理的阶段的不同分别介绍ETL 任务。1）ETL0： ETL0 完成数据的抽取、接口文件的生成，和把数据传输到接口文件区。此任务原则上由源数据系统厂商负责，生成符合接口规范要求的接口文件，然后把接口文件传输到数据仓库的接口文件区内，供数据仓库进一步处理和使用。2）ETL1：ETL1 完成对接口文件进行处理，然后验证数据并对数据做转换和计算处理， 最后把数据加载到数据平台层。接口文件处理其主要任务包括验证接口文件的完整性，和进行初始的数据转换工作，具体内容可以参照前面数据源和数据接口部分。如果文件处理失败，拒绝文件和错误信息都会储存在 log 目录下，然后在数

41、据库内记录错误日志，根据相应的触发条件向管理员发送短信、Email 等警告信息。问题定位和解决后， 把更新后的文件再次传输到 Inbox 目录下，并重置错误任务的状态，这样此接口文件就可以重新加载到数据暂存区内。数据验证数据验证工作是基于一些特定的业务规则进行数据有效性和引用完整性的验证。数据转换、计算和加载按数据平台层模型结构转换并加载到数据平台层的主表内。在此阶段也可能涉及一些数据转换和计算工作，比如通过 Join 关联不同的表，或生成一些新的指标等。装载时如果有错误发生，会生成错误信息，同时在文件或表内记录不能装载或删除的记录。如果问题严重到需要拒绝整个装载文件，我们会在数据库内标识此次

42、装载失败，然后操作回滚。数据成功装载到数据平台层后，源数据接口文件转移到备份目录下，视需求情况进行压缩备份。3) ETL2:ETL2 完成将数据平台层的数据同步更新到应用数据层。应用数据层包括明细数据、汇总数据、多维数据、指标数据和知识库数据。数据平台层的结构化数据经过ETL 处理，会先后更新到明细数据、汇总数据和多维数据及指标数据。指标数据和知识库数据通常也可以由应用系统层直接更新维护。ETL 调度管理ETL 调度模块负责所有 ETL 数据处理任务的调度及顺序逻辑控制，具有如下功能：任务触发当 Job 的启动条件满足用户预先设定的条件时，自动加载 Job并运行。Job 的触发条件包括时间条件

43、和任务条件两种，ETL 调度模块应同时具有这两种任务触发机制：时间触发指定 Job 在特定的时间点开始运行。比如每天的凌晨 1 点；或每月的5 号的凌晨 1 点。事件触发发生特定的事件后 Job 自动运行。比如接口处理 Job 要在其依赖的接口文件全部到达后自动启动；或一个 Job 其所有前置 Job 成功运行完成后自动启动。时间和事件的结合多个条件组合都满足后自动运行 Job。比如要求月接口文件处理 Job 在其所有接口文件全部到达并且时间在每月的 5 号的下午 6 点之后运行。任务排序对 ETL Job 运行的先后顺序进行排序，任务排序体现在如下 2个方面：依赖关系任务之间具有逻辑上绝对的

44、先后关系，一个任务的启动必须依赖于其前置任务的成功完成。对其前置任务主要考虑与的关系，也即只有当其所有前置任务完成后才启动任务。优先级如果两个或多个任务同时满足启动条件，任务的执行先后顺序可以通过任务的优先级来决定，具有较高优先级的 Job 将优先运行。全局任务同步对于运行在不同机器和系统上的 ETL 任务，调度模块可以对其进行同步。比如机器 1 上的任务 1 完成后触发机器 2 上的任务 2。并行执行同时允许多个任务并行执行。可以设置各类 Job 的并行度。并行度有如下 2 个层次：不同机器任务之间的并行比如要求不同机器上的任务如果没有相关性的话，其运行应该相互不影响。机器 1 上的任务 1

45、 和机器 2 上的任务 2 可以同时运行。同一机器内部任务的并行对于运行在同一个机器上的任务，如果没有相关性的话可以并行运行。比如两个 ETL 装载任务，没有相关性，并且优先级相同，可以设置为两个任务同时启动。任务管理允许用户灵活的添加新的任务、设置任务的触发条件、和依赖关系。能方便的重置任务状态，重启和结束任务运行等。ETL 监控管理ETL 维护中最重要的就是随时监控 ETL 任务的运行情况，因此为了降低系统维护人员的劳动强度，提供友好的 ETL 监控功能是必要的。ETL 监控提供如下功能：全程全方位监控监控各个环节的 ETL 任务统一监控所有机器所有类型的 ETL 任务多种手段任务运行失败

46、任务运行结束时间延迟多途径自动报警浏览界面短信通知邮件通知数据质量管理数据质量问题系统数据质量问题按照问题的来源和具体原因，可以分为信息、技术、流程、管理四个问题域。1、信息问题域信息类问题是由于对数据本身的描述理解及其度量标准的偏差而造成的数据质量问题。产生这部分数据质量问题的原因主要有：元数据描述及理解错误、数据度量的各种性质得不到保证和变化频度不恰当等。2、流程问题域流程类问题是指由于系统作业流程和人工操作流程设置不当造成的数据质量问题，主要来源于系统数据的创建流程、传递流程、装载流程、使用流程、维护流程和稽核流程等各环节：3、技术问题域技术类问题是指由于具体数据处理的各技术环节的异常造

47、成的数据质量问题，它产生的直接原因是技术实现上的某种缺陷。数据质量问题的产生环节主要包括数据创建、数据获取、数据传递、数据装载、数据使用、数据维护等方面的内容。4、管理问题域管理类问题是指由于人员素质及管理机制方面的原因造成的数据质量问题，如人员管理、培训和奖励等方面的措施不当导致的管理缺失。数据质量管理体系数据质量管理工作涉及到收集数据质量检查规则、部署数据质量检查规则、执行数据质量检查规则、分析数据质量检查规则。数据质量管理体系架构如图所示：数据质量管理主要包括三大部分： 1、数据质量模型：数据质量模型是包括用来存储数据质量检查规则、检查任务的内容，同时还可以存放检查结果、检查结果临时数据

48、等内容。2、ETL 调度检查任务：大量的数据质量检查规则由 ETL 调度负责执行，调度按照制定的频率、优先级、依赖调度相应的检查规则，并将检查结果返回到数据质量模型中。ETL 执行的检查规则分别针对数据质量的三大对象：数据文件、数据库对象以及业务规则。3、数据质量应用：数据质量应用是用来提供给数据质量管理员、以及其他相关用户对数据质量管理子系统的访问接口，用户可以通过应用直接进行数据质量的管理、浏览、分析功能数据质量检核规则数据质量管理需要对关键的数据进行监控，质量监控是通过制定质量检核规则并在特定的系统上运行来实现。数据质量检核规则是对数据质量问题监控的机制，这些检核规则的制定需要遵循一定的

49、原则，按照一定的方式进行分类，选择运行机制在系统中部署。检核规则制定原则1、通用性数据质量的检核规则要能够代表大多数的数据质量问题，能够在相似的场景中使用， 相同的类型的质量问题可以使用同一种规则进行检核。防止重复制定检核规则。2、重要性数据质量的监控主要对重要数据进行监控，重要数据是那些产生质量问题会对系统产生重要影响的，并需要大量投入去清洗的数据。数据质量监控需要将系统资源用于重要数据监控上，重要性可以从业务和技术角度进行评估。3、简洁性数据质量的监控在生产系统运行，监控重要的数据质量问题，由于业务系统资源的要求，不能消耗太多的系统资源进行质量监控，因此数据质量的检查应该是简明的，容易理解

50、和执行的。检核规则分类检核规则按照检核内容与方式可以分为业务检核规则和技术检核规则： 1、业务检核规则业务检核规则是检核数据的业务逻辑中内在联系满足度的一类规则。业务检核规则需要在产品设计、研发、系统需求分析等过程中由业务专家提出，将数据间内在的必然联系作为业务检核规则。通常情况业务检核规则需要业务专家不断支持，在规则管理中不断完善。2、技术检核规则技术检核规则是技术专家、系统设计人员、系统测试人员、系统运维人员等在技术实现和运行维护过程中总结和发现的质量检查规则。这些检核规则主要偏向于技术实现层面的规则。数据质量管理实施原则数据质量管理实施原则包含数据质量管理的具体工作项与工作流程，通过这些

51、工作项和工作流程形成数据质量治理的闭环，不断提升数据质量。从改进的问题领域选择开始，到最终的质量问题监控，这些改进过程形成一个闭环流程，通过监控如果发现质量不能满足要求， 则需要重新开始新的改进流程。与银监 EAST 系统接口 与银监 EAST 系统接口信雅达公司审计系统数据集市是基于中国银监会监管数据标准化规范和中小银行及农村金融机构监管采集数据标准化接口规范基础上搭建。与银监 EAST 系统数据接口平台保持高度一致，完全符合银监 EAST 系统所需要采集的数据。系统提供方便快捷的数据卸载功能， 可每天或定期从数据集市中导出全量或每天增量数据提供给监管部门或相关使用部门。网络架构总 总 总

52、总 总 总 总 总 总总 总 总 总总 总 总 总总 总 总 总 总 总总 总 总 总 总总 总总 总VPN总 总 总 总 总总 总 总 总 总 总 Oracleinformatica总 总 总 总 总 总总 总 总 总总 总 总 总总 总 总 总 总 总WebLogic/websphere总 总 总 Greenplum总 总 总 总 总总 总 总 总总 总 总 总总 总 总 总 总总 总总系统以总行集中部署，数据库服务器和 WEB 服务器部署在审计数据信息中心，总行风险监管中心和分行、支行、网点、业务管理部门通过内部网络连接 WEB 服务器，实现系统管理与非现场审计、现场审计、内控评价、风险

53、预警监控等工作的各类操作，系统与行内或有的影像档案平台和数码监控录像平台相连接，实现风险监控工作中的业务数据与影像档案、数据录像的一体化应用。审计数据信息中心审计数据信息中心部署数据库服务器和存储设备，数据库服务器可采用双机备份，系统所有数据存放在高可用性存储设备上；审计数据信息中心部署 WEB 服务器，可采用双机备份。总行风险监管中心总行风险监管中心系统管理人员和内审部门作业人员通过行内局域网络连接 WEB 逻辑应用服务器进行系统管理、预警监测、查询查证、内控评价、项目评价、审计计划、审计项目信息管理等作业和管理。各业务部门、分支行机构业务管理部门、分支行机构风险监管作业通过行内局域网连接

54、WEB 逻辑应用服务器进行风险线索确认、问题整改、信息查询等作业操作。灾备中心为了保证系统 7X24 小时连续不断运行，系统可部署远程灾备中心。远程灾备中心部署数据库服务器和存储设备、WEB 服务器，采用数据拷贝方式实现风险监管中心到远程灾备中心的数据备份。在审计信息数据中心遭受灾难无法恢复时系统切换到远程灾备中心运行。运行环境配置服务器硬件环境硬件环境硬件类别硬件机型配置要求数量生产环境数据库服务器小 型 机 或 PC Server4CPU、32G 内存300G*2 硬盘标配 1 台。可考虑双机备份或集群配置WEB 服务器PC Server4CPU、16G 内存146G*2 硬盘标配 1 台

55、。可考虑集群配置及F5 负载均衡数据存储高速磁盘阵列至少4TB 可用空间满足 3 年以上扩展需要服务器端软件环境类别类型版本数量备注操作系统Aix/Linux/WindowsAix6/RedHat/20032系统支持主流的操作系统数据库软件Db2/Oracle/GreenPl um9.0/10g/4.01支持其他主流数据库系统，如：Sybase、SQLServer 等应用中间件WebLogic8.0 以上1支持其他主流产品， 如 ： Websphere 、Tomcat、Jboss 等ETL 工具信雅达公司提供的自主开发的ETL 工具1可选用其他商业 ETL工具【informatica】报表工具

56、信雅达公司提供的自主开发的报表工具1可选用其他商业产品图形工具信雅达公司提供的自主封装的图形工具1可选用其他商业产品计算引擎信雅达公司提供的自主封装的计算引擎1规则引擎信雅达公司提供的自主封装的规则引擎1工作流引擎信雅达公司提供的自主研发的工作流产品1搜索引擎信雅达公司提供的自主封装的搜索引擎1WebOffice 插件信雅达公司提供的自主研发的插件1客户端环境类别标准配置备注硬件PC 机主流PC 机操作系统Windows Xp 以上办公软件Office 2000 以上/WPS浏览器IE6.0 以上浏览器插件支持ActiveX 控件安全和访问控制序号功能内容1鉴别机制采用用户名和口令机制：（1）

57、用户的口令在存储、传输过程中必须是以密文方式存在。（2）输入口令字时不许明文回显。（3）用户认证通过后，如果在 15 分钟时间内无操作，用户需要进行确认性重认证。2鉴别失败处理用户登录失败,需要返回有限的失败信息【用户名或密码错误、用户不存在、用户没有权限】当用户连续鉴别错误次数超过限制条件 8 次时，将该用户锁定，12 小时后自动恢复，或通过管理员重新设定后恢复.3控制机制系统限制口令长度至少 6 位。口令必须加密存储和传输。对于系统预置的口令，提供强制初次登录系统时修改口令的能力。系统限制更换后的口令必须与前90 天或者前2 次不同。提供特权用户以设置普通用户对系统功能和数据访问的权限。失

58、败信息提示：要求对未授权或者在授权时间范围之外使用系统的用户显示警告信息。4存储数据的保密性应用系统采取访问控制机制，确保系统内的重要数据不被授权以外的任何用户或授权用户以任何未经授权的方式访问。5通信保密性在通信双方建立连接之前利用密码技术进行会话初始化验证，包括用户口令加密传输。在通信过程中，对口令等敏感信息字段进行加密。6安全审计机制日志记录要素包括日期和时间、类型、动作发起者用户名称（主体标识）、操作对象（客体标识）、操作对象主要特证（客体敏感标记）、事件的结果等。7安全监控系统提供查看在线人员的用户名、登录时间、IP 地址等信息的功能。8SCAM 数字认证平台用于系统登录身份验证和数

59、据加密系统性能方案系统在性能方面处理方案：1、在审计数据平台中，增加业务中间表层数据处理把大数据量、复杂逻辑的处理放在中间表层，优化系统业务处理的性能；2、在数据平台规划、表空间、表索引、存储规划以及数据库的设置方面有资深的 DBA 提供技术支持，在项目实施和运行过程中提供持续的数据库层优化支持；3、首席审计咨询顾问通过对模型思路梳理，提供最优化的计算逻辑；4、资深的业务模型专家在模型开发过程中，根据经验和实施在开发过程中提供适合的 SQL优化逻辑。系统性能指标我司对招标书提出的各项系统性能指标的达标情况，做出如下保障承诺：系统稳定要求：系统必须具备稳定性、可靠性和可扩展性；用户要求：系统支持

60、的并发用户数不低于 150 人；数据吞吐量：系统支持 200G/天的数据加载处理；系统备份要求：系统应提供对应用系统数据表的保留、备份、检索的有效策略；系统平台要求：系统必须提供平台级的负载均衡和容错能力；系统运行要求：系统将提供（7 天24 小时）不间断连续性服务，无需人工干预；页面响应速度：常规页面 3 秒内响应，复杂页面 10 秒内响应；平均页面响应时间：页面响应时间完全支持平均页面响应时间不超过 5 秒的要求；系统资源占有率：为了保证系统能够正常、稳定运行，推荐配置的服务器的 CPU 占用率和内存完全保障使用率均不应超过 60%的要求；数据实效：T1，即在数据源可以正常提供数据的前提下