1、银行卡统计分析系统概要设计说明书文档信息 Document Information项目名称（中文）Project Name：银行卡统计分析系统项目名称（英文）Project Name：文档名称 Document Title：概要设计说明书文档密级 Document Security Level：内部阅读版本号 Version Number：V1.0负责人 Administrator：编写人 Issued by：创建日期 Create Time：最后修改日期Last Saved Time：修改人 Last Saved by：状态 Status：目 录1引言11.1编写目的11.2术语11.3参考
2、资料21.4适用范围21.5背景21.6目标21.7实施原则31.7.1可用性和易操作性31.7.2易维护性31.7.3先进性和可扩展性31.7.4保护现有资源42总体设计42.1逻辑架构42.2网络拓扑架构62.3业务管理组织架构72.4安全管理架构92.4.1网络的安全管理92.4.2数据的安全管理92.4.3应用程序的安全管理102.5应用系统架构122.6系统处理流程142.7系统架构特点152.7.1系统框架特点：152.7.2数据处理的特点162.7.3调度管理的特点162.7.4应用系统特点162.7.5运行策略特点163系统用户及管理范围173.1系统用户权限管理183.1.1
3、用户权限管理原则183.1.2用户组的作用183.1.3功能权限管理183.1.4机构权限和报表权限管理193.2用户管理193.2.1用户级别193.2.2用户密码管理193.2.3系统管理员权限193.3系统初始化用户设置194功能模块194.1调度管理模块204.1.1调度管理模块框架204.1.2调度管理模块功能及其处理流程214.1.3调度管理各子模块功能及其处理流程224.2ETL模块274.2.1基础数据284.2.2源数据抽取294.2.3数据获取策略304.2.4数据加载策略304.2.5基础数据生成304.2.6数据集市的生成324.3报表处理模块344.3.1报表的生成3
4、54.3.2多维立方体的生成354.4系统和环境管理模块354.4.1系统管理模块354.4.2环境管理模块374.5门户管理模块384.5.1门户功能384.5.2门户界面384.5.3实现思路394.6辅助采集模块404.6.1商户基本数据项414.6.2设备基本数据项424.6.3国际卡收单基本数据项424.6.4网上银行数据424.7报表展现模块424.8总分行数据交换模块445系统关键技术455.1数据处理455.1.1数据压缩和解压455.1.2数据抽取455.1.3数据传输465.1.4数据加载465.1.5数据清洗和转换465.1.6脚本自动生成465.2调度管理465.3数据
5、存储475.4门户管理475.5前端展现475.6系统管理475.6.1组织机构的设计485.6.2应用系统和Congnos系统用户、权限的同步技术485.6.3用户权限分配策略486系统设备及软件要求486.1数据量的估算486.2生产环境硬件配置486.3开发环境硬件配置496.4软件配置491 引言1.1 编写目的概要设计说明书的编制目的是说明一个软件系统各个层次中的每个模块的设计考虑，如果一个软件系统比较简单，层次很少，本文件可以不单独编写，有关内容合并入概要(系统)设计说明书。对概要设计说明书的内容要求如下。1.2 术语n 数据源：指系统涉及到的原始数据来源，本系统包括：ABIS(综
6、合业务系统)、ABIS 中间层、BCSC(银行卡交换中心系统)、AIPS(综合应用前置系统)、国际卡系统和辅助采集部分。n 卡基础数据：包括日源数据加载区，临时过渡区和基础数据区三个部分。n 日源数据加载区：数据源经过初清洗、加工形成每天的源数据，日源数据加载区只保留每天的增量数据（月底全量）。n 临时过渡区：数据加工过程中需要利用的临时缓冲区，主要使用在数据日源数据加载区到基础数据区；基础数据区到应用数据区、多维分析数据区；应用数据区到多维分析数据区几个阶段。n 基础数据区：日源数据加载区的数据经过加工形成基础数据区，基础数据区的数据包括类源数据基础档案，静态数据档案和辅助采集数据档案三个部
7、分。n 类源数据基础档案：n 卡应用集市：卡应用集市是对卡基础数据平台的数据进行深加工、统计生成的，主要包括应用数据区、多维数据区和多维立方体。n 应用数据区：基础数据区的数据经过深加工、统计生成应用数据区的数据，应用数据区主要用来生成电子报表和生成多维分析区的数据。n 多维分析区：基础数据区和应用数据区的数据经过加工形成多维分析区。n 多维立方体：多维立方体用来提供多维分析、多维查询、多维报表，多维立方体的数据是对多维分析区的数据加工后生成的，包含银行卡统计分析系统中的所有基本数据项。n 电子报表：根据银行卡统计分析最终所需的报表格式制定，根据应用数据区的数据生成报表格式文件（XML格式），
8、再根据XML格式文件生成的。1.3 参考资料银行卡统计分析系统需求书银行卡统计分析系统需求分析说明书数据源与基本数据项的映射关系1104工程监管报表系统系统设计之总体框架v2.11104报表设计文档1.4 适用范围1.5 背景随着银行卡业务的快速发展，产品品种和业务功能日益增多，业务处理系统的不断升级，银行卡产品的系统也正处于由分散到集中的进程中。而现有的报表系统是基于我行系统分散在地市行的模式下开发的，独立于我行业务系统之外。报表的生成以手工为主，是由发卡行按照卡部要求，从银行卡业务系统中抽取要求上报的数据，辅助采集到报表系统中，再生成上报数据文件传送到省行，汇总生成省报表，并通过我行办公系
9、统发送数省级报表文件到总行，总行统计人员再将分行的报表文件导入到报表系统中，生成全国的统计分析报表。该报表系统虽然为银行卡业务经营分析起到了重要的作用，但已不能满足经营管理的需要，主要有以下几个方面的问题：一是数据辅助采集，不能完全保证准确；二是报表生成环节多，汇总时间长，任何一个环节产生问题，都会影响报表生成的及时性；三是报表系统缺乏灵活性，不能根据业务发展需要进行调整；四是现有系统的容量有限，不能进行复杂分析。我行银行卡业务增长方式正由粗放逐渐走向集约，由数量型向质量型转变。由于目前我行银行卡业务缺乏真正面向市场、面向客户的分析系统，在客户服务和管理上带来了一定的难度。随着中国全面开放金融
10、业务的时间临近，如何提高银行卡综合竞争能力已摆到重要议事日程上，为了更好地提高银行卡综合竞争力，更好地分析产品、细分市场，提高业务管理水平，特开发银行卡统计分析系统。1.6 目标根据银行卡统计分析的整体规划，本项目分为近期目标和远期目标。近期目标是实现银行卡相关信息的统计，生成卡部所需要的报表，同时为实现远期目标打下基础。远期目标是建立完备的银行卡管理分析系统，提供经营决策信息支持。通过信息采集、存储，实现银行卡业务的全面信息化管理，并通过功能强大的信息管理分析工具，对银行卡业务进行全方位的立体信息挖掘，产生出各种经营决策支持分析结果，提高银行卡运营机构的高效性、实时性、分析的准确性和科学性。
11、为了实现以上这些目标，本系统采用“统一规划、全面考虑、分步实施”的策略，具体分为两期建设：一期主要功能为：1、 完成对基本数据项的统计2、 实现业务部门提出的固定报表3、 完成相关数据的处理和积累4、 实现数据处理流程的自动化5、 在条件许可的情况下，实现一些简单的分析。二期主要功能为：结合卡部需求，对一期的功能进行补充，并实现我行卡业务的分析与挖掘。1.7 实施原则银行卡统计分析系统一期主要实现卡部的报表统计，二期要对我行卡业务进行分析和挖掘，一期要为二期的实施奠定基础。因此在制定实施原则时，既应充分考虑到当前卡部生成统计报表的需求，更应该统筹考虑日后二期建设的扩展和相关系统的改造。总的实施
12、原则主要包含以下几点：1.7.1 可用性和易操作性1.7.2 易维护性1.7.3 先进性和可扩展性银行卡统计分析系统的建设既要考虑我行数据源多、需求差异大、地域分布广的特点，又要兼顾全行各业务应用系统、各主机平台、全国网络的现状，充分考虑如何利用我行已经买断、技术先进、有实用价值的软硬件。既要防止因技术落后、体系陈旧使得系统没有实用性，又要引进技术先进、成熟的技术实现手段，以加快系统建设步伐，保证系统的先进性。同时，总体考虑系统物理平台、软件平台选择、数据库结构设计、数据采集以及系统运行效率等各方面，确保系统的可扩展性，为未来发展保留足够的空间。1.7.4 保护现有资源充分借鉴1104、FAR
13、S，DAS和基础数据平台等系统的建设经验，合理利用ABIS、AIPS等系统的资源合理规划系统。2 总体设计2.1 逻辑架构系统逻辑架构如图1所示：图1 系统逻辑架构图系统的总体逻辑架构分为：数据源层、卡基础数据层、卡应用集市层和前台展现层。数据源层主要包括从ABIS、AIPS、交换中心、国际卡系统、辅助采集系统等各数据源系统获取的数据文件。卡基础数据层包括日源数据加载区，临时过渡区和基础数据区几个部分；日源数据加载区中的数据是数据源经过初清洗、加工形成的，日源数据加载区只保留每天的增量数据（月底全量）；临时过渡区：存放加工过程中的临时数据；基础数据区：日源数据加载区的数据经过加工形成基础数据区
14、，基础数据区的数据包括类源数据基础档案，静态数据档案和辅助采集数据档案三个部分。卡应用集市主要是对卡基础数据的数据进行深加工、统计生成的，主要包括应用数据区、多维数据区和多维立方体；应用数据区的数据是由基础数据区的数据经过深加工、统计生成的，应用数据区主要用来生成电子报表和生成多维分析区的数据；多维分析区的数据是由基础数据区和应用数据区的数据经过加工形成的；多维立方体用来提供多维分析、多维查询、多维报表，多维立方体的数据是对多维分析区的数据加工后生成的，包含银行卡统计分析系统中的所有基本数据项。前台展现包括电子报表、定式查询、随意查询、多维报表、多维查询、多维分析和智能分析几个部分；随意查询和
15、智能分析在本期不实现。2.2 网络拓扑架构系统网络结构如图2所示：图2 网络拓扑架构图银行卡统计分析系统在设计时充分考虑到银行的实际情况，既可以采用集中部署，也可以采用分布部署，同时也可以根据实际情况采用集中-分布部署。对任何一种部署方式系统用户都可以到网点，但在实际部署时可以根据系统的性能只开放到一级分行、二级分行、支行中的任何一个级别。系统在设计时，做到了非常灵活的部署，满足了银行卡部目前和将来发展的需要。整个系统架构在总行现有的OA网上，符合OA的各种规范，不需要在OA网上增加任何设备，充分利用了我行现有的资源。2.3 业务管理组织架构由于银行卡统计分析系统管理组织和交易有些不同，同时管
16、理和业务又有很多特殊之处，本系统为适应这些需要建立了业务管理组织架构，银行卡统计分析系统业务管理组织架构如图3所示：图3 业务管理组织架构图机构关系设计思路是按照银行卡业务数据归属关系和交易关系设置的，数据归属关系按照网点、支行、二级分行、一级分行、总行进行报表数据汇总，按照事先设置好的交易关系识别交易的跨省、省内异地及同城。（一） 数据归属关系是按照网点、支行、二级分行、一级分行、总行机构上下级关系进行向上报表汇总。这种报表数据汇总关系与业务部门要求的报表汇总关系一致。 （二）交易关系与数据归属关系基本一致，但存在以下特殊的关系，具体为：u 一级分行之间的同城交易：北京分行和总行营业部之间可
17、以看作是两个平行的一级分行，但由于是同城，所有的交易都应该属于同城；u 计划单列市分行与当地省分行之间：计划单列市分行与当地省分行都是一级分行，如：广东分行和深圳分行，这两个分行之间的交易属于省内异地；u 一个城市内存在几个二级分行，且二级分行属于不同的一级分行：新疆分行与新疆建设兵团在同一个城市都有自己的二级分行，二级分行属于不同的一级分行，但这些同一个城市内的二级分行之间的银行卡交易为同城交易；u 一个城市内存在几个二级分行，且二级分行属于相同的一级分行：广东分行下属的佛山分行、南海支行（省行直属支行）和顺德支行（省行直属支行）之间的交易属于同城。在设计的时候，项目组充分利用ABIS现有资
18、源，在实现数据归属关系的前提下，通过设置“等效收费城市代码”和“等效省内交易省份代码”来识别是否属于同城或省内异地交易。 (三) 对于机构数据遵循只增不减的原则：系统保留机构数据的历史记录，发生网点机构撤并时，银行卡统计分析系统可以生成撤并机构网点的历史统计报表。机构和网点的逻辑模型如图4所示：图4 机构和网点逻辑模型2.4 安全管理架构2.4.1 网络的安全管理网络的安全管理对WEB应用程序的安全，防止服务器被来自网络层的攻击所破坏是非常重要的。本系统对网络的安全管理基本要求是：1、 系统架构在总行的OA网上，所有的安全要求与总行的OA网保持一致2、 确保只是总行网内的用户才能访问本系统的W
19、EB服务器。任何其它网络的用户都不允许访问。2.4.2 数据的安全管理1、 数据的存放：所有核心数据存放在数据库中，绝大多数系统的配置数据也存放在数据库中。2、 数据的修改：对数据的修改必须在完整的事务中进行，确保数据的一致性。对于敏感数据的修改必须留有完整的流水（日志）记录。3、 数据的查询：数据的查询必须和应用系统的用户权限结合起来，保证操作者只能查询到自己权限内的用户数据。4、 数据的备份和恢复：数据必须能进行方便的备份和恢复，在灾难情况下必须能进行方便的恢复。2.4.3 应用程序的安全管理由于本系统是建立在WEB应用基础上，对于其安全性的考虑是多方面的，如图5所示：图5 应用安全管理图
20、对于WEB应用的安全设计必须考虑输入验证、身份验证、授权、配置管理、敏感数据保护、会话管理、密码系统、参数处理、异常管理和审核与日志记录等。4.4.1.1 安全要求1 认证：只有经过认证的用户才能访问系统的资源；2 授权：已认证的用户必须经过授权才能对系统指定的资源进行访问和操作。限制用户访问系统级资源；3 加密：用户密码必须经过加密存储。加密算法要采取国际上流行的不可逆算法，如MD5等；4 访问控制：能对Web资源和POJO进行保护，能实现Http资源访问控制，Method 调用访问控制等；5 输入检验：检验用户输入的数据是否正确，包括数据的类型、长度、格式和范围等，对不符合要求的输入进行限
21、制、拒绝和清理；6 配置管理：对管理界面使用强身份验证和授权，避免在 Web 空间中存储敏感数据；7 会话管理：限制会话的生命周期，加密身份验证 Cookie 的内容，保护会话状态不被未经授权访问；8 异常管理：使用结构化的异常处理，不要暴露敏感的应用程序实现细节，不要记录私密数据（如密码），考虑采用集中的异常管理框架；9 审核和日志记录：识别恶意的行为，审核和记录所有应用程序层的活动，保护对日志文件的访问，备份和定期分析日志文件。4.4.1.2 安全框架 安全管理是涉及的技术是多方面的，但是最关键是要解决用户的认证和授权。因此需要部署一个方便管理用户的认证和授权的安全管理框架。在本系统中我们
22、采用了Acegi作为我们的WEB应用安全管理框架。这是因为Acegi是Spring框架下最成熟的安全系统，能够和目前流行的Web容器无缝集成。它使用了Spring的方式提供了安全和认证安全服务，包括使用Bean Context，拦截器和面向接口的编程方式。因此，Acegi安全系统能够轻松地适用于复杂的安全需求。它有以下特点：一、多方面的安全控制粒度1.URL 资源访问控制 http:/apps:8080/index.htm - 公共用户 http:/apps:8080/user.htm -所有认证用户2.方法调用访问控制public void getData() - 所有认证用户public
23、void modifyData() - 只有系统管理员 3. 对象实例保护order.getValue() 所有认证用户order.getValue() $100 - 只有系统管理员二、非入侵式安全架构1.基于Servlet Filter和Spring aop, 使商业逻辑和安全逻辑分开，结构更清晰。2.使用Spring 来代理对象，能方便地保护方法调用。三、安全逻辑模型 为了实现用户的认证和授权，安全逻辑模型如图6所示。图6 安全逻辑模型图安全逻辑模型中包括用户组、用户和资源。用户组使USER(用户)和RESOURCE(资源)分离,一个用户可以属于多个用户组,一个用户组拥有多个相应的资源,从
24、而减少了权限管理的复杂度,可更灵活地支持复杂的安全策略。一个RESOURCE(资源)资源可以是一个菜单或者是一个功能项，一个资源的权限分为ACL,URL,和FUNTION三种类型。为了实现对特殊用户的权限控制，加入USER_RES表。可以灵活地对单一用户的功能进行授权。利用这个逻辑模型可以非常灵活地对用户的权限进行控制，满足系统对用户安全管理的需求。2.5 应用系统架构应用系统采用浏览器/服务器(B/S)模式开发，按照MVC架构进行设计，整个架构分为三层：l 第一层是界面表示和控制层（View层）；l 第二层是业务逻辑层，完成业务逻辑管理界面与实现（Control层）；l 第三层为数据存取、业
25、务对象缓存和ORM实现层（Model层）。应用系统架构如图7所示。业务数据访问服 务 提 供界 面 表 现用 户 视 图 层业 务 控 制 层模 型 管 理 层服 务 管 理图7 MVC架构图三层的主要功能是：1、视图层（View）：由jsp,html组成。它把action传递过来的数据模型，形成展示界面。数据模型都是可序列化对象及关系构成，并根据对象生命周期，保存于param、header、cookie、page、request session、application、Sevrlet Context上下文环境中。该层使用的核心技术有：Jsp2.0、Jstl1.1、struts tags、ta
26、glib、javascript（ajax）、Xml等。2、控制层（Control）：接受客户端提交的数据，表单生成、完成输入验证、管理Web上下文、实现业务逻辑的访问、组装View层需要的数据模型、选择合适的用户视图。该层使用的核心技术有：struts3、模型层（Model）：处理业务逻辑，主要有ERD（实体关系对象图）、数据访问组件（Dao）、业务管理组件构成。Ibatis实现了对象关系处理，数据访问组件实现了对象的访问方法，业务组件通过数据访问组件实现统一的业务界面。该层使用的核心技术有：Ibatis三层之间的数据交换以POJO共享为基础。层次结构简单，相互独立，减少了程序的复杂度，具有良
27、好的灵活性和可扩展性。2.6 系统处理流程系统处理流程主要分为总行处理流程和分行处理流程两大类别。分行处理流程如下：ETL分行卡基础数据平台1应用数据2多维分析数据33辅助采集生成电子报表文件多维立方体上报总行44多维查询和分析5生成电子报表5图8 银行卡统计分析系统分行处理流程体现出基本数据项下载，一般查询分行业务处理主要有以下几个步骤：步骤1：对数据源经过ETL处理，辅助采集系统采集商户、POS等汇总信息生成分行卡基础数据平台；步骤2：对基础数据平台中的数据进行深加工、计算生成应用数据；步骤3：根据应用数据和分行卡基础数据平台数据进行加工生成多维分析数据，同时对应用数据进行加工生成电子报表
28、；步骤4：根据多维分析数据生成多维立方体，同时把多维数据和应用数据上报总行；步骤5：根据多维立方体进行多维分析和查询，根据电子报表文件生成电子报表，供最终用户进行查询、下载。总行系统处理流程如下：分行1应用数据多维分析数据全行汇总，生成全行应用数据多维查询和分析全行汇总，生成全行多维分析数据生成全行报表文件2233生成全行报表4图9 银行卡统计分析系统总行处理流程总行业务处理主要有以下几个步骤：步骤1：接收分行上报的应用数据和多维分析数据；步骤2：对分行上报的应用数据进行汇总，生成全行应用数据，对分行上报的多维分析数据进行汇总，生成全行多维分析数据；步骤3：生成全行报表文件，同时提供全行的多维
29、查询和分析；步骤4：根据全行报表文件生成全行报表。2.7 系统架构特点2.7.1 系统框架特点： 1、系统部署灵活，可全国集中部署、区域部署、分行单独部署三种模式，能方便解决总行业务经营的复杂性； 2、系统能纵深使用，用户可部署在总行、省分行、二级分行、支行和网点等5级组织架构上； 3、业务管理组织架构模型覆盖范围广，基本涵盖了卡应用环境的业务模式，无须对特殊业务进行特殊设计指定； 4、基本业务元素丰富，能方便地给1104工程提供所需要的数据要素； 5、简化了数据仓库的元数据管理模式，能方便了用户灵活运用数据，而不影响系统效率和正常运行。2.7.2 数据处理的特点1、在卡基础数据、卡应用数据集
30、市处理阶段，支持重复加载、还原数据、会计日期不敏感性处理思路，而不影响数据准确性；2、系统吸收了月终全量法、31天关键主档全量轮换法、主键-自由字基础数据构建法等三种ETL处理方法；3、系统作业处理采用大模块法，清晰了设计思路和系统架构，分类比较明确；4、作业模块部署比较灵活，同性质的作业模块可分别部署在不同物理机上，充分利用现有资源，进行分布式处理；5、作业模块可部署在广域网上，满足总分一体性。2.7.3 调度管理的特点1、自动调度数据处理流程； 2、自动组装复杂的数据逻辑功能；3、构建企业级5维空间智能作业调度系统,自动实现负载均衡、跨系统和跨平台管理；2.7.4 应用系统特点1、采用基于
31、MVC(模型视图控制)三层开发部署框架。为Web开发提供了具有高可配置性的开发模式和应用模式。2、合理地将用户表示逻辑、业务逻辑和控制逻辑分离。使得开发过程变得简洁清晰，能缩短开发时间。3、具有组件模块化、灵活性和重用性的优点，可以提高软件的可维护性和可重用性。4、前台展现采用了电子报表、多维报表、多维分析和数据项应用等4位一体的卡分析应用平台。2.7.5 运行策略特点 1、ETL处理策略 系统统一采用两套运行逻辑，系统级处理错误采用技术人员干预，应用级处理错误采用系统封闭重复运行策略； 2、总行数据文件的存放各分行把每天总行下发的文件存于备份区中，在需要做数据抽取或清洗时把相关文件copy到
32、临时区中处理，尽量保证总行下发的数据不被修改。3、数据库数据的备份当数据库空间达到一定负荷或在规定时期定期备份和清理数据，对有用数据应该刻录在磁带，在处理数据同时要确保不影响报表数据的正确性。4、基数数据和数据集市的数据内容存储数据的存储要考虑到一定的策略，用最优的策略保证需求的需要和数据库的承受能力。具体策略有：1）过滤垃圾字段，用简练的模型保存数据。如不必保存一些表的校验码或是备注信息等等；2）数据表中对数据历史时间较长的数据，采用按月存储，不再保留每天的具体数据。3）对帐户信息等类似的数据发生记录改变时要记录历史数据，而且要保持数据的完好衔接。 5、应用访问策略 用户访问应用系统，处理结
33、果采用三套策略展现。成功访问利用MVC的DO技术，引向成功视图界面，访问出现系统错误引向系统错误堆栈视图界面，访问出现应用错误引向正确操作指引视图界面。3 系统用户及管理范围用户管理内容主要包含了功能权限管理、机构权限管理、报表权限管理和用户管理几个部分。设计的主要思路是引入用户组的概念，使USER(用户)和RESOURCE(资源)分离, 一个菜单或者是一个功能项或者一个报表URL都可以定义为一个资源项,一个用户属于一个或多个用户组,一个用户组拥有多个相应的资源,通过用户组的设立来管理用户对系统资源的使用权限。通过用户的机构级别和报表级别的匹配来实现报表的级别管理。用户权限管理业务关系如图10
34、所示：图10 用户权限管理业务关系修改图例，增加功能，与大图保持一致3.1 系统用户权限管理3.1.1 用户权限管理原则系统权限管理的原则是上级用户可以访问下级报表，下辖一级的机构可查看部分上级行开放的全辖数据报表，同级不能互访统计报表。具体为总行负责总行系统的管理和维护，总行用户有权查看各个层次的统计数据；一级分行管理员负责一级分行系统的管理和维护，一级分行用户有权查看和应用所属发卡行的统计数据，可以查询其他省份的部分开放报表；二级分行卡部可以查看本发卡行辖内的支行及网点的统计数据，可以查询本省其他发卡行的部分开放报表。 3.1.2 用户组的作用系统的功能权限和报表权限管理是系统控制用户能操
35、作哪些功能菜单能查看哪种报表的机制，如系统管理员组能够维护普通用户和设置系统参数等操作，录入员组可以录入需要辅助采集的商户、设备资料等数据，银行卡业务管理员组可以查询打印机构权限内的银行卡统计报表等。为了实现对特殊用户的权限控制，系统可以对单一用户的功能进行授权。3.1.3 功能权限管理功能权限是系统控制用户能操作哪些功能菜单的机制，系统通过用户、用户组、功能菜单的对照关系来控制用户的功能权限。3.1.4 机构权限和报表权限管理机构权限和报表权限是为每个用户指定相应的机构权限范围和报表权限范围的控制机制，机构权限和报表权限控制是通过用户、用户组、报表类别、报表级别的控制关系来实现的。3.2 用
36、户管理系统所建立的每个用户都分属于一个或多个用户组，每个用户都归属于一个机构，系统通过用户组管理用户的功能权限和报表类别权限，通过用户的机构级别和报表级别的匹配来实现报表的级别管理。3.2.1 用户级别 用户的级别是由该用户所属的机构级别决定的。3.2.2 用户密码管理登陆统计分析系统必须通过用户号和密码的验证，密码需要加密验证, 加密算法采取国际上流行的不可逆算法。密码统一设置为6位，可用数字与字母混合方式。3.2.3 系统管理员权限总行管理员负责设置总行的用户，分行管理员设置分行的用户。总行管理员可查询和下载到全国各一级分行、市行的数据。一级分行管理员可查询和下载所辖地市行、支行、网点的数
37、据，并上报需要辅助采集的数据。二级分行管理员可查询和下载所辖地支行、网点的数据，并上报需要辅助采集的数据。3.3 系统初始化用户设置系统初始化时，各二级分行以上机构设一名具有中心管理、权限管理和用户管理的系统管理员用户，由该用户在机构内建立用户组、分配用户组权限并管理用户。4 功能模块系统功能ETL报表处理辅助采集报表展现多维分析源数据加载基础数据生成应用表生成多维分析表生成报表文件生成中心维护机构维护用户维护权限维护日志查询通讯维护维表维护汇率维护报表查询报表下载作业调度与监控调度管理系统和管理管理多维立方体生成多维查询、分析作业调度管理图11 系统功能模块4.1 调度管理模块4.1.1 调
38、度管理模块框架调度管理模块由作业指令发送系统（控制台），作业调度与监控系统，作业系统等三部分组成。其框架结构图如图12所示： 作业监控作业初始化作业日终处理作业指令发送系统维护作业状态监控作业调度系统作业选择器作业调度信号接收器作业状态更新器消息接收器消息通知器作业系统作业处理器消息响应器消息接收器 作 业 容 器图12 调度管理模块框架后台任务调度如图13所示：数据抽取任务调度环境生产源数据加载构建卡基础数据构建卡应用数据构建卡多维分析数据构建卡CUBE构建卡应用电子报表数据图13 任务调度4.1.2 调度管理模块功能及其处理流程调度管理系统主要处理三方面的功能，包括启动作业调度、终止作业调
39、度、查询作业调度情况等。4.4.1.3 启动作业调度的流程 1）、作业指令发送系统发送启动作业调度的指令；2）、启动和终止作业调度信号接收器接收到指令，判断该指令是启动作业调度指令，把指令发送给作业选择器；3）、作业选择器接收到指令，解析该指令，选择本次调度的作业，加载作业服务组件，发送作业服务的消息给消息通知器；4）、消息通知器接收消息，建立与作业系统的连接，发送该消息给作业系统的消息接收器；5）、消息接收器接收到消息，判断该消息是作业服务消息，发送给作业处理器；6）、作业处理器接收到消息，处理作业容器中相关作业，发送作业服务结果给消息响应器；7）、消息响应器接收到作业服务结果，建立与作业调
40、度与控制系统的连接，发送作业服务结果给消息接收器；8）、消息接收器接收到作业服务结果，提交给作业状态更新器，并发送已接收到作业服务结果的反馈信息给消息响应器；9）、作业状态更新器接收到作业服务结果，更新作业状态及其作业依赖关系状态，并发送已成功更新的反馈信息给消息接收器。4.4.1.4 终止作业调度的流程1）、作业指令发送系统发送终止作业调度指令；2）、启动和终止作业调度信号接收器接收到指令，判断该指令是终止作业调度指令，分别发送该指令给作业选择器和作业状态更新器；3）、作业选择器和作业状态更新器接收到指令，停止相关工作。4.4.1.5 查询作业调度情况的流程 1）、作业指令发送系统发送查询作
41、业调度情况指令； 2）、启动和终止作业调度信号接收器接收到指令，判断该指令是查询作业调度情况指令，分别发送该指令给作业选择器和作业状态更新器； 3）、作业选择器和作业状态更新器接收到指令，提交作业状态信息。4.1.3 调度管理各子模块功能及其处理流程4.4.1.6 控制和监控子系统功能及其处理流程控制和监控台子系统主要完成作业初始化、作业日终处理、作业状态监控、作业指令发送、作业维护、节点维护等功能。1、作业初始化当开始运行整个银行卡统计分析系统ETL之前，对需运行的作业进行初始化，重建作业依赖关系，将其作业的运行状态变为未运行，等待作业调度控制子系统的作业选择器处理。当个别节点的作业出现异常
42、需要对其个别作业重新作业初始化，重新进入队列，进行作业选择。2、作业状态监控每隔约定的时间内，如15秒，检查作业处理状态。根据作业处理状态不同，按不同的颜色显示在监控台上。对出错的作业，根据可允许重初始化标志，重新作业初始化。3、作业指令发送对初始化的作业，发送作业调度指令，启动作业选择器，进行作业调度处理。系统运行异常时，发送终止作业调度指令，终止作业选择、作业状态更新等进程。4、作业日终处理备份当日作业处理状态，更新节点作业日期为下日。5、系统维护作业的增加、删除和修改；节点的增加、删除和修改；作业间依赖关系的增加、删除、修改、修复作业依赖关系链；操作员的增加、删除和修改。4.4.1.7
43、作业调度与监控子系统处理流程作业调度与监控子系统处理流程分两部份，包括作业选择和消息通知处理流程、作业响应消息获取和状态更新处理流程等。作业选择器处理流程消息通知器处理流程消息接收器处理流程消息接收器接收到作业系统作业处理信息通知，传送给作业状态更新器，把状态更新器的处理结果返回给对应的作业系统的消息响应通知器。作业状态更新器处理流程对返回作业成功处理的信息，更改作业状态信息为作业已完成；作业依赖关系中此作业的处理形态改为完成，作业作为父作业的处理形态为已完成，其子作业处理形态为可以执行。 对返回作业失败的处理信息，更改作业状态信息为作业已失败状态；作业依赖关系中此作业的处理形态改为可以执行。
44、作业依赖关系处理作业依赖关系处理，主要以下四个方面的问题：1、作业与父作业的关系为一对一的关系。2、作业与父作业的关系为一对多的关系。3、作业与父作业的关系是跨越节点的关系。4、作业的父作业在某日停止处理，作业需要追索父作业的父作业的处理问题。解决问题的基本原则： 1、父作业未处理，则作业不能处理； 2、父作业某日不做处理，则把父作业的父作业作为作业的父作业。要求在启动作业调度时，必须重建作业依赖关系，剔掉那些不做处理的父作业，使得父作业必须处理。4.4.1.8 作业系统处理流程作业系统处理流程由三大部分组成，包括交换器（消息接受器、作业处理器）、消息响应器和作业容器等。交换器处理流程交换器是
45、作业调度系统和作业系统的总控，是整个系统的核心。所起作用控制交易并发流量、接收发起的服务、调用服务、发送服务结果。交换器在作业调度系统和作业系统中是同一个。交换器处理流程如下：作业处理状态消息响应器处理流程作业处理器作业处理完后，把处理结果交给交换器，然后交换器提交服务结果给消息响应器，响应器把处理结果发送给作业调度控制系统的消息接收器。作业容器根据作业所扮演的角色不同，分别有不同的作业处理模块。每个作业模块的功能由具体应用开发设计组进行阐述，这里不再一一累述。作业处理消息响应通知补发器消息接收器未接收到作业处理信息，写入消息信息失败或作业处理消息响应通知未成功发送时，都需要补发作业处理消息响应通知。对消息响应通知失败
