数据平台系统项目-技术方案.doc

数据平台项目数据平台系统投标书技术投标书目 录第1章 方案总述11.1 前言11.2 项目背景11.3 项目目标21.4 项目建设原则2第2章 系统建设规划32.1 项目建设目标的理解32.1.1 项目建设范围32.1.2 项目建设内容32.2 分行数据平台的建设目标42.2.1 分行数据平台一期建设目标52.2.2 分行数据平台二期建设目标5第3章 整体设计方案53.1 系统设计方法论53.1.1 方法论53.1.2 设计原则63.2 数据平台技术体系113.2.1 数据平台逻辑架构113.2.2 数据采集设计143.3 数据平台数据体系193.3.1 数据架构设计193.3.2 数据模型设计213.3.3 灵活查询功能架构293.3.4 数据备份与恢复293.4 数据平台应用体系323.4.1 统一报表平台323.4.2 数据图表化展示823.5 数据平台设计关键点903.5.1 数据平台性能保障903.5.2 时间窗口983.5.3 备份策略993.5.4 数据模型的历史数据存储993.5.5 源系统变更影响分析101第4章 软件及推荐硬件设备配置方案1024.1 系统软件方案1024.1.1 统一报表平台103北京宇信易诚科技有限公司 II数据平台系统投标书技术部分第1章 方案总述1.1 前言我们衷心感谢贵行给予我们这样一个很好的机会，可以为贵行的数据平台建设提供技术解决方案和项目实施方案的建议书，并通过我们的方案建议书为及其应用系统的建设提供帮助。我们期盼与贵行共同努力，以我们在兄弟分行和其他银行实施同类项目的经验以及我们使您的愿景变成现实的能力，为贵行IT建设增添一个新的里程碑，也为我们与贵行的真诚合作启动一个良好的开端。该项目除了可以用宇信易诚所具有的经验和技术为贵行提供帮助外，我们认为这也是一个与贵行建立长期战略合作关系的宝贵机会。我们为这个目标所做出的努力正反映了这一点，我们愿意建立一个灵活的商务策略，和服务质量有竞争力的专家团队来满足贵行的需要。1.2 项目背景随着贵行业务的快速发展，信息系统不断增多，业务数据量的规模也在急速膨胀。分行数据整合平台作为贵行的数据整合中心，需紧密衔接总行ODS、数据仓库及分行特色系统、并且需考虑到贵行未来将要建设的系统的接入问题。根据贵行业务的拓展和条线管理的需要，各业务部门对决策信息依赖程度不断提高，经常会有一些高灵活性、多变性、高及时性的信息需求。贵行目前需要能够满足业务需求快速响应的统一数据平台，仅依靠传统的数据加工模式对源数据进行抽取加工操作，由于业务口径的不一致性、数据质量低下、以及缺乏良好的数据统计分析手段等问题导致分行范围的决策分析成为难题，不能充分发挥业务积累的相关数据的作用数据的及时性和准确性难以保证，给管理和营销增加了难度。本次数据报表平台项目承担了分行主要业务数据的集中和整合及报表应用展示的功能。通过数据平台的建设，将为零售、公司、同业、绩效、人力资源、运营等业务提供统一准确的数据支持，是贵行业务精细化管理能力的重要基础类系统。 数据平台从中远期角度来看，将成为贵行管理层/经营层洞察经营全貌、优化经营管控水平、推进战略决策效能、支撑综合运营分析的数据分析平台。通过数据的集中化、标准化管理，实现分行数据的信息共享，构建实现企业数据平台及相关的管理决策分析应用。1.3 项目目标贵行数据平台建设项目是搭建一个对接总行ODS、数据仓库、衔接分行特色业务的数据平台。从底层的数据平台、DW到上层的BI（商业智能）展现，数据平台在各交易系统之间、交易系统和报表分析系统之间实现数据交换，通过数据的加工、整合实现报表统计和分析。建立基础数据模型、ETL 平台、ETL 管理调度平台、确保数据采集完整、保证ETL数据质量、形成统一的数据展现。具体目标为：1、构建统一的、层次合理的、灵活的企业级数据模型，整合各业务系统数据，形成分行统一的数据视图，建设成为贵行系统应用的基础数据平台。2、建设统一数据应用平台，在实现基础数据平台的基础上实现统一报表平台，为贵行业务分析和经验决策提供全面的支持。1.4 项目建设原则本次项目建设遵循的技术原则如下：数据平台的正确建立和合理利用将直接影响到贵行的未来信息化发展，贵行数据平台建设应参考以下架构原则，指导和规范未来的数据平台信息化建设和管理，在项目方案中应该能够体现以下原则：1.数据集中原则：将总行ODS、数据仓库数据、分行特色数据和应用统一进行管理和运维，保证资源的高度利用以及通过相关的技术保证数据和应用的绝对安全和稳定。 2.数据标准分行统一原则：依据总行的数据字典，减少数据定义的二义性。未来分行特色应用系统的数据结构是分行数据结构模型的子集。对分行级数据实行单点维护，确保分行级数据的可靠性和一致性。3.数据管理分行统一原则 ：统一的存储管理，统一规划使用存储资源，提高存储资源使用效率。统一的性能管理，根据实际业务需求，合理分配资源，确保对数据的访问性能能够满足业务的需要。统一标准的安全管理，提高数据访问控制能力，降低关键业务数据的安全隐患。4.降低数据冗余和数据复制原则 ：减低分行级数据的冗余度，降低数据对存储资源的需求。各业务系统根据自身业务处理实际需求，确定对属于其它系统数据的同步需求，制订出相应的数据复制同步策略并统一进行实施。第2章 系统建设规划2.1 项目建设目标的理解数据平台的建设对于贵行是一个非常重要的系统工程，承担着贵行企业数据整合、数据交换以及数据服务的重任，通过数据平台的建设使得贵行将自身信息资产切实、有效的管理起来，形成企业统一信息视图，搭建企业数据治理的框架，并为统一报表系统提供有效的数据支撑。2.1.1 项目建设范围贵行数据平台本期项目建设范围，可以从涉及到的业务范围、涵盖到的组织范围以及数据平台需要接入的源系统范围三个角度来分析。 业务范围本项目的业务范围以贵行零售、公司业务条线为主，计财、绩效、运营等为辅。 组织范围本项目业务涵盖的组织范围为贵行及辖内二级分行、支行。 数据范围本项目的源系统范围包括目前贵行的主要业务系统，并需要满足本期数据平台主题应用的数据需求。2.1.2 项目建设内容 基础数据平台基础数据平台技术架构搭建从总体上规划企业级的基础数据平台，平台将包含历史数据存储、基础数据平台、统一报表平台、自动调度监控等内容组成，数据平台要采用统一的数据标准规范；基础数据平台ETL监控、调度功能，完成从原数据仓库数据移植到新数据平台的工作。ETL子系统实现将各业务系统的数据抽取至数据平台，并进行数据的清洗、转化、加载等操作，形成数据分析、决策所需的各种汇总数据模型、分析模型，最终形成各种报表、查询以及KPI指标。ETL子系统实现自动化的数据抽取、数据加载、数据转化、数据卸载、自动化数据重新加载、加载错误自动处理、脏数据识别等功能。基础数据平台数据补录功能 提供数据补录平台功能，包括补录流程管理、补录模版管理、单笔补录、批量补录等。通过补录平台实现数据平台无法自动获取的具备分析价值的数据。本期基础数据平台数据标准涵盖以下工作内容：接口标准：规范数据平台加载数据接口、卸出数据格式及校验标准公共代码标准：参考总行ODS与数据仓库标准与分行特色数据标准；数据质量管控数据质量管控是一个长期的过程，依托于数据管控组织机构、流程的建立和完善。数据平台一期进行数据质量管控体系的初步探索，主要完成如下目标：（1）、建立初步的数据质量管理检查规则，包括功能性和非功能性规则。功能性规则主要包括：完整性、唯一性、合法性、准确性等；非功能性主要包括信息的完整性、一致性、业务稽核等；（2）、根据建立的初步检查规则，进行数据质量的监测，出具初步的数据质量检查报告；（3）、根据数据质量检查报告，提出数据质量提升的解决方案。 分行级指标体系借鉴与参考总行统一报表指标体系成果，在此基础上建立满足分行口径指标体系，扩展分行指标；满足业务日常固定报表使用的同时提供多样化的报表展现界面，包括表格展现，各类图形展现；要求界面友好，易用性强，并能够提供具性化应用风格支持。 统一报表平台构建统一报表平台，实现分行业务应用报表的集中化管理、一体化服务；具有报表定制、管理、维护功能；构建分行用户及权限管理体系，支撑分行业务用户报表应用需求。能够快速响应各级业务应用人员的报表需求，满足报表批量分类存档的需要。2.2 分行数据平台的建设目标2.2.1 分行数据平台一期建设目标基于对贵行系统现状的了解，贵行数据平台一期的建设目标是：1、构建统一的、层次合理的、灵活的企业级数据模型，整合各业务系统数据，形成分行统一的数据视图，建设成为贵行数据集中管理和应用的基础数据平台。2、建设统一数据应用平台，在实现基础数据平台的基础上实现统一报表平台 ，为贵行业务分析和经验决策提供全面的支持。3、集成现有对公、零售主要系统业务固定报表，支撑业务数据使用需求。4、指标数据按照图表样式进行区间查询展示数据趋向，波动。5、将分行原指标体系按照新指标体系进行平移；2.2.2 分行数据平台二期建设目标鉴于一期建设主要是搭建主体平台，二期的信息化建设目标是继续完善平台，丰富平台应用效果，全面覆盖现有旧综合平台，将重要数据迁移。具体目标如下：二期项目中可以集成计财、运营、人力资源等系统报表;支持数据图表展示、SQL查询等个性化查询需求；将更多的管理应用系统的数据源迁移至数据平台；建立并推广一套完整的需求与技术落地标准与体系。可以预见，随着数据平台的不断成熟，业务部门对数据平台的认知不断提高，会有源源不断的需求基于数据平台提出，这种变化将使得数据平台由前期技术部门“推”转变为业务部门的“拉”，让业务需求作为数据平台持续良好发展的源动力。第3章 整体设计方案3.1 系统设计方法论3.1.1 方法论数据平台的项目是一个长期的循序渐进的过程，也是一个不断创新、修复、完善的过程，其伴随着应用系统的发展而发展。根据贵行的业务特点以及企业系统建设的现状和未来发展蓝图，致力打造一个可扩展的、高可用性的、安全的、高效的、跨部门的可以快速处理海量数据的数据平台。在贵行数据平台建设方面依据可重用性、安全性、高可用性、可管理性、可扩展性、高性能的设计原则采取总体规划，分层实现的方式。纵向层面自上而下看，贵行数据平台的架构由逻辑（应用）架构、数据架构、技术架构和物理架构四个层次组成，每个层次内部又根据设计需要进行抽象分层，从而形成立体的贵行数据平台项目架构方法。逻辑（应用）架构是贵行数据平台项目承载的应用体系，它描述了贵行数据平台项目所要实现的应用需求，以及支撑这些应用需求所必须的公共模块，如调度、监控和元数据管理等工具组件。数据架构承载了支撑应用架构所必须的业务实体关系的分布，它通过数据模型的方式进行组织，主要分为缓冲数据层(ODS)、基础数据层（FDM）、加工汇总层(ADM)和数据集市层(MDM)等四个层次。技术架构是用于支撑贵行数据平台的数据分布和流动的技术框架，用到的技术有数据库技术、数据平台技术、ETL技术、多维计算技术、数据展现技术等。作为最底层的物理架构，是对贵行数据平台物理设备和网络的合理规划部署，它通过有效地利用硬件和网络，并能够添加硬件设备进行扩展为上层架构（技术架构、数据架构、逻辑架构）提供支撑能力。贵行数据平台架构方法立体视图3.1.2 设计原则根据贵行数据平台提出的系统建议的总体原则，总结我们在多家金融机构建设数据平台经验，贵行数据平台的设计原则体现如下原则：标准规范，可扩展，开放，前瞻，高性能，稳定，安全，易维护，实用，可管理，高可用，可重用。系统设计原则 标准规范建立标准的ETL开发流程，制定符合贵行数据平台的代码标准化统一规范，设计应对有高效数据处理要求及日常低能耗操作的兼容性数据模型，建设符合贵行数据平台远景目标利益的技术管理体系。1. 数据模型：制定表名、字段名命名规范标准。设计基础标准模型及基于基础数据模型之上的未来建设的应用系统的模型标准。建立数据质量管理机制，提高贵行数据平台的数据质量，也是数据平台迈向标准化规范化管理的重要环节。2. ETL处理：将ETL处理程序分类化，整理规范出各种ETL处理策略。确保ETL开发人员所开发的ETL程序遵循中信总行的规范。3. ETL管理：建设ETL管理平台，将其纳入贵行的ETL管理体系，形成有贵行特色的ETL管理制度。 开放性系统建设遵循开放原则，适应未来业务和技术发展，与现有系统进行有序的数据交互。1. 数据模型：数据模型的设计尽量接口化，关系与抽象并存。应对新出现的业务种类，同时能够兼容与现有系统进行数据交互，完成输入与输出系统的角色。2. ETL处理：ETL程序处理逻辑规则模块化，应对日益更新的技术发展及业务变更。3. 相关产品：项目开发过程中使用的宇信易诚工具类产品可以提供客户相关开发源码进行二次开发。4. 后续开发：项目组再实施过程中，会对客户方科技人员进行相关的技术培训，使科技人员能够独立的进行ETL程序的开发、报表开发、数据分发的设置、数据源配置等等 可扩展性可扩展性是指数据平台能够支持贵行业务系统和应用系统发展的需要。在本项目中，具体要从以下几个方面考虑系统的可扩展性：1. 数据模型：设计基础数据层和数据预处理层模型时应充分考虑，除了能够容纳现有源系统的结构设计，还应该尽可能满足即将要上线的业务系统数据模型，同时还需要制定一套合理的模型设计规范，使得新上线的业务系统数据模型能很方便地扩展到数据平台。2. ETL处理：需要考虑两个方面的扩展性，增加新的ETL任务处理以及原有任务所处理的数据规模加大，ETL处理架构必须能适应新的变化，需要考虑通过集群的方式来扩展。3. 数据交换平台：在设计时应考虑，随着分发数据规模的扩大和推送节点的增多，对交换处理和传输处理的性能要求会越来越高，必须支持集群的方式进行扩展。此外，数据交换平台还必须提供二次开发接口，支持SOA服务模式，可以进行应用级的扩展。4. 服务器：平台中的每一种服务器都使用集群扩展模式，可以通过对服务器数量的增加获得更好的数据处理和查询能力。 高性能高性能是指在硬件资源有限的情况下，数据平台应尽可能的支持尽量多的数据服务需求，还能承受用户峰值时间段压力，使得数据平台能够满足分行范围内的使用者。在本项目中，高性能的设计主要体现在以下几个方面：1. ETL处理：在进行ETL设计时，需要考虑大数据量条件下的处理效率，确保在规定的时间窗口内完成ETL处理，特别是一些特殊日期的ETL处理，例如结息日、月底等。2. 数据交换平台：需要考虑在大数据量条件下的文件传输效率，主要也是体现在一些特殊日期条件下的文件传输，以及特殊情况下的全量文件传输。3. 数据库设计：对一些海量数据表或频繁访问的数据表，在数据库设计的时候需要从数据库设计的角度考虑性能优化机制。 可管理性这里所说的可管理性主要是指系统运维的可管理性。比如：在实际运行过程中，系统能很方便地对系统的运行状态进行监控，查看数据质量情况；出现系统异常时，能及时收到消息通知，并有一套完善的流程来处理数据或系统方面的异常等等。在本项目中，可管理性的设计具体表现在以下几个方面：1. ETL处理：在ETL的总体设计时，确保系统可以监控全过程的运行状态，并能对异常情况及时提醒，保存完整的处理日志信息，并设计相应的错误处理流程。另外，还需要考虑ETL任务配置的直观图形化。2. 数据管控：在总体设计时，应充分考虑数据的复杂性，必须能做到多而不乱，能够清楚了解系统每一个应用的转换逻辑和数据含义，在任何环节有变动时，能迅速的反馈变动产生的影响。3. 数据交换平台：在总体设计时，需要充分考虑数据交换任务易于配置，传输结果易于监控。 高可用性高可用性是指系统在一些特殊情况发生时，依靠架构的有效设计，仍然能保证正常运行。在本项目中，高可用性的设计主要体现在以下几个方面：1. 数据模型的可用性：模型的设计应能屏蔽证券业务源系统结构的变化对数据平台集成平台和将在其上建设的分析应用系统带来影响。局部数据模型的扩展不会对其它数据模型产生大的影响。2. ETL处理的可用性：应充分考虑各源系统的时间窗口可能存在不一致的情况，避免出现一个系统的数据时间窗口没有满足条件，影响到其它所有系统的ETL处理。3. 系统备份：当正在运行的系统出现异常时，系统应具备相应的备份恢复机制，确保系统能及时恢复处理。4. 各个功能模块设计时应考虑自己的运行管理流程。 安全性在本项目中，安全性主要包括两个层面的含义：一是防止数据服务体系的数据资源被恶意修改和盗取；二是防止数据在传输过程中被截留和篡改。在本项目中，安全性的设计具体体现在以下方面：1. 对于第一个层面的安全性，主要依赖于各应用系统对用户角色和功能权限的控制。因此，在编写基于数据服务体系的应用系统设计开发规范时，应明确要求应用系统必须充分考虑安全性的设计。若贵行建设有面向管理系统的统一用户认证平台（UA），可以考虑通过UA来管理用户权限。对于数据范围方面的安全控制要求，在梳理出贵行数据平台应用需求与目标用户权限关系之后，通过在程序中对数据进行过滤，用户无法涉及其权限范围以外的数据，以确保数据范围的安全。数据过滤程序可抽象为一个准确、高效、易管理维护的过滤器。2. 对于第二个层面的安全性，主要依赖于文件传输过程中的加解密处理。因此，数据交换平台在进行总体设计的时候需要充分考虑数据传输过程中的安全性。3. 此外，系统在进行网络规划时，对系统的安全级别也需要进行分析，必要时需要提高网络的安全级别，从物理设计层面提高系统的安全性。 可重用性可重用性是指尽可能避免贵行数据服务体系建设的重复投入，应尽可能考虑包括物理设备、系统软件、框架组件、规范方法以及业务应用等多个层面上的复用。在本项目中，可重用性的设计具体表现在以下几个方面：1. ETL功能组件：在设计ETL任务处理流程时，要分析ETL任务的各个环节，尽可能找出一些公用的ETL组件，进行必要的封装，便于在模块内复用，进而推广到项目内进行复用。2. 数据预处理层的数据模型：在设计数据预处理层的数据模型时，应充分考虑应用系统的数据加工需求，尽可能将一些共性的加工需求在该层实现；并通过这种机制，不断扩充和完善改成的数据模型，实现加工数据的复用。3. 知识库的复用：在ETL管理平台中，应充分考虑知识库的管理和使用流程，以便运维人员和业务人员复用知识库的经验，来解决和处理一些日常的问题。4. 组件复用：各模块在开发的过程中，注意提炼出一些可用共用的公共组件，在模块内实现复用，甚至在模块间实现复用。5. 硬件部署：在进行硬件部署的规划时，应充分对系统的处理规模进行分析。如果性能允许的话，尽可能集中部署，使用现有设备，在硬件方面实现复用。3.2 数据平台技术体系3.2.1 数据平台逻辑架构贵行数据平台逻辑架构图上图为宇信易诚对贵行数据平台的逻辑架构建议设计图。从逻辑架构上看，数据平台主要分为下面几个部分： 数据集成区数据集成区为总行区域，分行只需要提出对应接口需求，由数据集成区下发至分行，目前的范围包含了总行ODS、数据仓库。 分行分析型数据区分行分析型数据区包含报表数据区、应用服务区及访问层区；报表数据区将总行数仓、ODS数据经分发平台下发至分行数据进行整合，选用宇信易诚的YC.LDM作为参考模型，建立数据缓冲层、基础整合层、共性加工层、应用集市层。其中基础整合层模型是用来统一存储整合企业所有源系统的业务数据；共性加工层数据模型主要是用来存储一些共性数据指标，为各应用系统提供共同的基础数据预处理，提高数据共享程度和数据使用效率。应用服务区按照报表类别及指标作用划分为固定报表、即席报表、OLAP、仪表盘等，满足业务报表需求。访问层主要对用户角色、操作权限进行管理； 管理平台区管理平台区包括任务调度、元数据、数据质量三大模块。分行需要建设自身的调度平台。可以采用总行统一调度平台ETLPLUS或宇信公司USE调度产产品，实现对作业调度、监控和配制管理，支持各类ETL JOB的调度，能够与主流ETL工具集成，支持对调度策略、执行过程、错误日志的实时监控。此外ETL管理平台支持文件到达监控，ETL集群部署与集群调度以及针对各个服务器资源的运行情况监控。元数据及数据质量使用总行元数据及数据质量标准，本期暂不考虑分行自建。 统一报表展现平台统一报表展现平台（报表平台）是本期基于数据平台之上建立的一个报表系统，实现对报表的统一管理以及统一展现服务，向用户展现数据平台数据整合的成果。报表平台在功能上需要具备系统管理、报表管理、报表展现（业务报表需求）、BI工具集成，报表目录与分类，灵活查询以及报表统计等功能。通过BI工具开发的报表能够被报表展现平台无缝集成并且以最方便、最直观的方式提供给报表的使用者。在本次贵行数据平台建设中，图表展示、SQL灵活查询均将作为一类特殊的报表系统的应用。由统一报表展现平台完成功能集成与发布，向用户提供统一的访问入口以及应用体验。 ETL设计关键技术点说明.1.1 ETL处理策略原则上因机构撤并造成的新增账户仍以新增帐户处理，账户间的关系通过机构拆并表进行对应。如果有脏数据，依据数据情况另行处理。账户主档表的处理：新增账户直接插入拉链表的处理：关闭老账户，以销户方式处理；新增账户直接插入。.1.2 ETL处理流程机构撤并ETL处理流程.2 质量检核.2.1 ETL处理原则质量检核是数据准确性的外部保证，应尽量提供检核处理检核处理不能对ETL处理有较大性能上的影响检核处理不能对时间窗口压力过大.2.2 ETL处理方法检核作业与该表的数据处理作业封装在同一个作业组中3.2.2 数据采集设计在数据平台架构中，数据采集平台的设计主要体现在T+1数据采集区技术架构、数据补录、数据处理平台三个方面的设计。数据采集模式 T+1数据采集T+1数据采集的主要功能需要从源系统中采集数据到数据集成平台的源系统数据文件落地区。通用的数据采集方法如下：1. 自行开发通用的数据下载平台，将源系统生产数据同步到数据采集区。这种模式常用于核心系统增量数据采集。通过该模式基本上能按需要来定制开发数据采集程序，灵活性大，效率也较高，同时还可以集成增量比对、乱码校验及修正、压缩打包、拆分并发处理、传输处理等功能，是一个务实的做法。但该模式也存在一个致命的问题，那就是如何确定增量数据的问题？如果通过数据库日志来获取，难度很大，而且也并不一定可行；如果通过数据库结构的某个字段来识别，这完全取决于源系统最初设计时是否考虑了增量备份的需求；不幸的是，大多数情况下，并没有考虑。于是，不得不采用先全量下载的方式，然后传送到数据采集区，再通过数据采集区来实现增量对比。在这种模式下，全量数据的传输无疑又是一个新的问题。事实上，这也正是大部分数据平台目前面临的实际问题。2. 由源系统本身开发数据下载脚本，在本地生成数据，然后通过文件传输工具发送到数据采集区。这种模式常用于核心系统以外的其他源系统数据采集，这主要是考虑其他源系统的数据采集量不大，而且各源系统架构多样化，不适宜采用通用的数据下载工具。这种模式是一种主动采集模式。上述两种数据采集模式，均各有特点，鉴于总行下发数据都是采集过的，分行只需要将特色系统数据定时FTP下发即可。T+1数据采集除了考虑上述采集技术外，还应该设计T+1数据采集区的存储方式。分行数据平台仅需按一定的规则存储不同来源基础数据。通常的做法是，数据采集区的数据以文件的方式保存，不用加载到数据库。这些数据文件的保存周期大约为7天左右，最长不应超过一个数据纠错周期。 数据补录数据补录是为了弥补数据源缺失或者业务系统建设不完善的情况而设置特殊采集模式。在本方案中数据补录功能采用宇信易诚开发的产品（YC.RIDP）来实现。数据补录模块的提供是针对不同业务数据库的通用数据录入工具，包括页面录入和模板录入以及数据入库的审批流程。支持对录入数据的事件处理（如新增前进行有效性数据检查、新增后进行数据平衡校验等，使用检核规则来实现）。数据补录工具服务于各部门、各机构的数据录入人员。该模块使用到“数据集管理”功能。.1 检核规则管理检核规则有两种类型：存储过程、正则表达式，是用于对录入数据进行合法性检核而定义的规则。存储过程类型的检核规则必须要有输入参数和输出字段，其中输入参数得到需要检核的数据的值，输出参数返回检核结果的标志位。管理员建立录入任务的时候，可以在检核规则设置界面设置录入的数据所对应的检核规则，可以设置数据入库前、入库后、修改前、修改后等各种检核规则。检核规则管理.2 录入任务管理录入任务是对一项录入工作的总体安排，包括录入的目标表、操作控制信息、使用的检核规则、批量录入模板的管理和权限控制等一系列内容。1. 目标表：录入的数据将被保存到这个表中，目标表也是一个数据集。2. 操作控制信息：控制录入任务是否可以被新增、修改、删除。3. 检核规则：用于对录入数据进行检核，可设置在入库前、入库后、修改前、修改后、任务分发前、任务分发后等时间点触发检核过程。4. 批量录入模板：用于批量导入数据。5. 权限管理：设置录入任务的可见机构，用于控制权限。录入任务建立并且分发完毕后，管理员可通过“权限管理”菜单下的“权限对照设置”子菜单，来修改录入任务的操作权限。录入任务管理.3 数据录入录入任务定义好之后，用户可以在此界面进行具体数据的录入。数据录入用户也可以下载批量录入模板，按模板样式填好数据之后，可以将批量录入文件上传至服务器并导入文件中的数据。批量录入模板如果管理员将录入任务定义成不需要审批的状态，那么录入员将数据写入临时数据后，就可以直接将它们提交入库。.4 查询操作用户可查询录入任务的正式数据和临时数据。可对录入任务的各个查询字段输入条件来筛选数据。录入查询查询临时数据时，还可以对“未提交”或者“不通过”的数据进行审批操作。.5 录入任务审批用于对用户录入的临时表数据进行审核及入库操作。用户录入的数据存放在临时表中，需要对临时表数据审核之后，才可以正式入库。录入审批3.3 数据平台数据体系3.3.1 数据架构设计数据平台数据架构数据平台数据架构上可分为以下层次：u 源系统数据落区 u 缓冲数据层(数据平台-ODM)u 基础整合层(FDM)u 共性加工层(ADM)u 数据集市层(MDM) 源系统数据落地区贵行数据平台的数据来源将囊括总行下发数据、贵行主要系统模块，包括公司、零售、同业、绩效、运营、人力资源多个子模块等。数据平台每日将总行的增量数据将首先以文件形式落地在源系统数据洛地区内，每日的数据文件以系统+日期的形式存储在特定的文件目录内，之后由数据平台的数据加载程序完成从文件向数据库贴源区装载的过程。源系统数据落地区的文件需要保留一定的纠错周期，一般保留周期为1周1个月。 缓冲数据层(ODM)该层本质上是业务系统、总行下发数据与数据平台之间的中间缓存层次，有以下特点：u 对接总行ODS、仓库下发的主题及汇总数据u 基于分行特色业务系统的整理和分析，按照业务流程进行梳理，对关键业务及相关信息进行抽取整合；u 可按照需要进行必要的裁剪，但不作转换和聚合处理；u 不保留历史信息，每日增量、全量业务信息；u 缓冲数据层的数据是经过标准化的，在该入库过程进行数据转换处理动作。缓冲层的存储周期一般仅作为缓冲处理，保留周期为1天。 基础整合层（FDM）基础整合层（FDM）基于缓冲层主题或非主题数据，进行处理和转化。总行下发的ODS、仓库是经过了标准化处理后的，可以直接进行主题存储。针对缓冲层非主题书，按照总行主题进行存放，可以结合分行特色，抽象符合分行特色的主题域。主题域是对银行业务的抽象。它着眼于银行经营活动中的要素：团体、协议、事件、产品等以及这些要素间的关系。 基础数据层还存储通过分行平台应用补录的汇总及明细数据。该区域存储需要考虑存储规划，一般建议至少保留1年以上，通过合理的数据库规划可以保留35年。 共性加工层（ADM）共性加工层（ADM）。该数据层主要存放总行下发共性明细、汇总数据、以及分行自建的统计指标数据。该层数据必须要设计相应的数据模型。该数据层部数据是在FDM层的基础上，经过运算加工得到的。根据我们对应用需求的理解和提炼，暂规划为机构、客户、产品、渠道、财务等汇总模型等几个关键主题，完成多维汇总模型与指标体系的规划和建设。共性加工层的数据因为已经按照一定粒度进行汇总加工，数据量能够得到控制，因此数据存储周期一般可以保留5年以上。建议再存储充足的情况下一直保留。 数据集市层（MDM）数据集市层保存各管理信息应用系统所对应的数据集市。数据集市建设面向具体的业务应用，数据集市的数据是在逻辑模型层数据的基础上按需生成，允许一定的数据冗余，以提高管理信息系统的数据访问效率。结合行内使用，可以建立面向零售应用、对公应用、计财、运营、考核相关集市数据，后续可以根据业务发展的需要逐步进行扩充。数据集市的数据量较小，建议永久保留。 各层次数据特点对比下表对贴源数据、基础数据层、共性汇总层、数据集市层次之间数据特点和差异作说明：源系统数据落地区贴源数据层基础数据层共性汇总层数据集市层数据用途面向特定业务用途面向特定业务用途面向抽象主题的模型化存储面向应用统计、分析面向信息查询/多维分析数据组织不同业务之间分散不同业务之间分散按主题集成的按业务集成的按应用集成的数据结构业务数据结构业务数据结构关系数据结构星型数据结构星型结构数据稳定性可变的可变的相对稳定的，保留历史轨迹不变的不变的数据粒度明细的明细的明细的经过一次数据集合经过一次数据集合数据能见度反映当前业务信息的反映当前业务信息的历史的，反映长期的信息历史的，反映长期的信息历史的, 反映长期的信息数据标准化未标准化的标准化的标准化的标准化的标准化的数据时效性高，实时、T+1高，实时、T+1和历史的低、T+1和历史数据低、T+1和历史数据低、T+1和历史数据3.3.2 数据模型设计 基础整合层主题模型区按照总行ODS/数仓主题进行存储，结合分行特色抽象提取特色主题。数据补录区提供数据的补充和录入功能，是数据完整性、一致性、有效性的有力保证。提供对录入数据的组织权限、业务权限和数据权限的全面控制。使用检核规则实现对录入数据的事件处理，可对数据新增前、新增后、修改前、修改后等事件关联检核规则，以便对数据进行有效性数据检查、数据平衡校验等操作。 共性加工层.1 共性层模型设计思路根据在数据集市应用的经验和对贵行各类业务需求的理解，我们可以将此类业务需求分为如下三类： 基础数据类需求：此类需求主要为明细业务查询，业务部门卸数需求，外部监管、外部数据交换和对账等，或者其他数据深加工等方面的基础数据准备需求。 加工指标类需求：主要是汇总类的指标数据。这些指标主要是为各业务部门的报表里面的指标项，包括上报外部监管部门报表等，例如内部管理报表“经营分析报告”中的各个指标项。 报表/图形展现类需求：贴近最终用户的形成报表/图的展现需求来进行设计，多数情况下都是基于对基础数据、指标数据的基础上通过展现工具将数据变为信息的过程。图表 1 业务需求类型根据这三类不同应用需求特点，和不同数据层次数据粒度要求，可以对应到数据平台模型设计对应的数据层次来： 基础数据类需求对应数据平台中的基础数据层； 加工指标类需求对应于数据平台中的共性加工数据层数据（当然，加工指标类数据还有为某应用系统所独有的指标数据，为了数据平台模型整体架构的层次更加鲜明和清晰，我们把它归入下一层的数据集市模型）； 而报表/图形类需求，则更接近于数据集市模型；注：在本项目的共性加工层数据模型建设中，将重点从目前需建设的应用系统需求中的提炼共性需求，建议ADM数据层设计不宜过“厚”，以免统计口径不一致或粒度不符合业务需求而重复开发。.2 共性加工层模型建设方法在共性加工数据层设计时，要充分理解其共性（即多应用系统共用的数据）和加工（数据汇总、加工）的两个特点，才能在其数据模型设计中做出最好的成果。因此，共性加工层数据模型的建设也就是回答好以下几个问题： 模型存储什么数据？ 数据如何获取？ 数据如何存储？ 模型中数据如何组织？ 模型中数据如何被使用？ 模型如何满足多应用系统共性数据存储的需求? 模型如何适应指标频繁变化的要求？.2.1 存储什么数据：存储具有一定程度汇总的指标共性加工数据层存放的是经过一定程度加工汇总的指标数据。这些指标拥有其独有的业务口径，和相应的统计规则，同时，指标也是具有一定粒度的。典型如我们大家都了解的“储蓄余额”指标，其业务口径和统计规则可理解如下： 业务口径：对私定活期科目的存款余额的汇总； 统计规则：可汇总相加的，不像百分比指一样不能汇总相加。 粒度：可以有不同类别的币种、日期和机构部门。.2.2 数据如何获取：指标分类和指标ID共性加工数据层的数据不能简单的堆砌在一起，首先需要对指标进行分类和整合，方便实现复用。不同类别的指标，存放到不同的模型中。另外，为便于用户或应用系统快速对指标进行定位，以方便获取。可以对每个指标编制唯一的ID，并有专门的指标定义表，描述指标的名称、含义、业务口径等。这样，指标就能够通过分类，或指标ID快速获得。.2.3 数据如何存储：星型模型基于上面所描述的指标特点，我们可以看出，指标是能够采用标准结构定义和约束的。符合这种特点的数据模型，例如星型模型、或基于星型模型扩展的雪花模型，就可存储指标。同样，对于上面的“储蓄余额”指标，结合对星型模型的理解和多年的数据平台实施经验，我们可以将该指标分解如下： 维度：日期、机构、币种 指标：储蓄存款的时点余额根据星型模型的特点，该指标存储数据模型分解为： 维表：日期维表、机构维表、币种维表、科目维表 事实表：总帐科目事实表其简化模型如下（在本模型中，指标ID就是三级科目编码）： 图表 2 业务需求类型.2.4 如何适应多应用系统共性数据存储的需求：与业务需求轻耦合贵行众多的应用管理系统要求指标的存储模型要求具有一定的稳定性，与业务需求轻耦合。因此，在设计数据模型时，对指标进行技术分析，了解指标的维度和指标，并依据维度来对指标进行分类，将拥有类似维度的指标存放在统一模型中，从而使数据模型具有高度的稳定性。后面有类似维度的指标添加进来时，就可在不改变现有模型的情况下扩充该指标。.2.5 如何适应指标频繁变化的要求：具有高度的扩展性在国内外大环境的影响下，银行业竞争激烈，对银行客户分析和银行的经营管理信息支持的需求也不断变化，获取信息的迫切程度也不断提高。这要求共性加工层存储的指标能根据业务需求快速扩展、或调整，满足业务要求。在共性加工层数据模型设计时，需要对模型本身及将来可能发生的变化充分考虑，确保模型具有高度的可扩展性和灵活性。例如，针对上面“储蓄余额”的模型设计例子，在业务发展和业务管理发展过程中，业务部门可能会需要获取储蓄存款的年日均余额、季度日均余额、当月日均余额等，因此可以对模型进行优化，添加上述要素，适应后面可能发生的变化。因此，我们可以对该模型进行优化，满足其扩展性和灵活性的要求，如下图所示简图： 图表 3 业务需求类型注：新扩展的指标属性维度包括有： 时点余额 旬累计值 旬日均值 月累计值 月日均值 季累计值 季日均值 年累计值 年日均值.3 共性加工层当前目标基于上述对共性加工层的认识与理解，结合贵行目前的需求状况，规划一个能完全满足未来应用的汇总模型不太现实，因此现阶段共性加工层本着“共性、实用”的目的来设计，通过借助零售客户管理、公司客户管理、绩效考核等系统的共性提炼，并最终将共性加工模型回归到各应用系统中，保证共性加工层的使用性、可操作性。因此，共性加工层当前目标主要是： 分行统一指标服务。建立初步可派生多维度的账务指标体系，对核心总账数据的ETL加工，建立一套在配置上，可通过基础科目灵活定义公式进行派生，日期、币种、机构、日期度量等多维度的指标服务体系；在应用上，分析报表、监管报表、数据集市均能够使用的公共指标数据；在发布上，建立起可通过报表、卸数、短信平台向业务人员发送等诸多数据发布渠道。各级用户都可以自己定义报表指标内容来达到自己的目的。 各个业务条线产品指标分析。贵行按业务产品品种来分有存款储蓄业务、贷款信贷业务、中间业务。按经营客户来分又可以分为对公存款、对公贷款、同业存款、同业贷款、对私储蓄、对私贷款。按服务渠道来分可以分为柜面业务、网银业务、电话银行业务、ATM业务等品种。对业务条线产品的分析要既能满足当前业务规模的需要，同时借鉴其他行的应用集市模型保证一段时期内贵行业务发展的数据分析需要。 提炼ECIF、绩效考核等系统的共性指标，并针对共性指标逐一讨论、论证，形成共性加工层数据模型； 通过各应用系统的验证、迭代，保持共性加工数据模型的实用性、可验证性与可操作性； 共性加工层的数据不应过于高度汇总，这样不利于未来业务扩展，比如只针对于某张报表而设计的汇总指标； 根据目前的业务需求范围、内容，所提取的共性指标可能不多，因此在此次共性加工层中不建议做主题划分。.4 共性加工层远景目标.4.1 完善贵行数据平台及之上的应用系统数据架构在贵行后续应用系统建设和投产，深入理解共性加工层的建设思路和建设方法，梳理其中的共性加工数据，完善贵行数据平台及之上的应用系统数据架构。例如，后期分析业务需求整理其所需使用的指标数据，对于在原有的共性加工数据中已有指标数据，直接获取并采用该部分指标数据；对于新的指标数据，依照共性加工层的建设思路和建设方法，采集基础数据生成。一方面，避免重复加工该类指标数据，造成指标数据口径不一致、指标质量问题及数据冗余，另一方面，可以保证所建设的应用系统数据架构清晰，确保贵行数据平台及其数据加工建设思想的可持续发展。.4.2 扩展共性加工层指标数据在不同的应用建设过程中，根据业务部门对各类指标的业务需求，逐步丰富、完善共性加工层的指标数据，形成完善的共性加工层指标，可以为总分行各业务部门，各应用系统提供更多的指标数据，加快应用系统开发的周期，满足业务应用的要求。.4.3 关于共性加工层主题划分随着未来业务发展，共性加工层是不断丰富、不断深化的过程，未来需要对共性加工层定义分类，如按传统的账户、客户、机构等主题划分。 集市数据层为面向应用所建立的数据集市模型，主要是从时效性和高效性两方面进行平衡而设立的贴近展现形式的数据存储结构。这里重点指综合经营分析子系统的集市模型建设。我们规划了七个模型。1、 平台查询：基础数据查询分存款、贷款、资产负债查询三类，都是从基础数据层直接查询而得。2、对公业务：整合了对公、同业客户信息、存贷款信息。3、对私业务：整合了对私客户信息、存贷款信息，其中还包括补录的计划指标。4、银行卡：主要是以卡为中心分析模型，包括各种卡类在不同机构的关键指标。如发卡量、帐户活动率、存款余额、透支余额、消费额、累计消费额、卡日均存款等等信息。5、中间业务：整合了中间业务和理财产品在渠道上的交易信息以及关联账户信息。6、渠道业务：整合了各个渠道的全部业务量，包括其中办理柜员、自助渠道、电子银行的相关信息。7、指标体系：包括对总账科目数据机构汇总，日期维度历史快照、币种维度的并帐折算、派生指标公式计算的等账务数据模型以及各类工作量等的非账务数据模型。3.3.3 灵活查询功能架构分行数据分析人员、业务人员在数据平台构建的应用集市层、指标库基础上，可通过Cognos或MUSP指标灵活查询对业务数据进行灵活查询。按照语义层整合的逻辑视图，使用Cognos自定义报表，对业务数据进行查询。在MUSP指标灵活查询功能中可对单一指标、指标口径、指标自定义报表进行查询。及时响应业务灵活性高的查询场景。3.3.4 数据备份与恢复 数据备份与恢复实施思路备份技术（Point-in-time Copy）是对业务运行过程中某一时刻的生产数据的保护。该保护在业务正常运行时生成，主要预防因生产数据的逻辑故障而造成的停顿；当生产数据因人为误操作或病毒破坏而损坏时，可以利用该定点拷贝将业务状态恢复到损坏发生时刻的正常业务状态。在