EDW数据仓库项目方案

年5月29日EDW数据仓库项目方案文档仅供参考XX银行EDW/数据仓库项目方案

目录TOC\o"1-3"\h\z第一章系统总体架构 ３1.1总体架构设计概述 ３1.1.1总体架构的设计框架 ３1.1.2总体架构的设计原则 ４1.1.3总体架构的设计特点 ４1.2EDW执行架构 ５1.2.1执行架构概述 ５1.2.2执行架构设计原则 ５1.2.3执行架构框架 ６1.3EDW逻辑架构 １３1.3.1逻辑架构框架 １３1.3.2数据处理流程 １９1.4EDW运维架构 ２０1.4.1运维架构概述 ２０1.4.2运维架构的逻辑框架 ２１1.5EDW数据架构 ２６1.5.1数据架构设计原则 ２６1.5.2数据架构分层设计 ２８1.6EDW应用架构 ３０1.6.1应用架构设计原则 ３０1.6.2数据服务 ３１1.6.3应用服务 ３２第二章ETL体系建设 ３３2.1ETL架构概述 ３３2.2ETL设计方案 ３５2.3ETL关键设计环节 ３５2.3.1接口层设计策略 ３５2.3.2StagingArea设计策略 ３５2.3.3数据加载策略 ３６2.3.4增量ETL设计策略 ３６2.3.5异常处理 ３８2.3.6作业调度和监控 ３９2.3.7元数据管理 ３９2.3.8ETL模块设计 ３９2.3.9ETL流程设计 ４２2.3.10动态资源分配 ４４2.3.11数据接口设计 ４５系统总体架构总体架构设计概述总体架构的设计框架XX银行EDW项目的总体架构分为基础技术架构、应用架构和数据架构三个核心部分。这三个部分共同组成了XX银行EDW系统。在基础技术架构中,包括执行架构、逻辑架构、功能组件架构和运维架构四个部分。执行架构描述系统大的框架和模块区域,以及之间的逻辑关系;是确定生产环境的建设要求及指导原则。逻辑架构描述EDW各个模块之间的数据的接口、数据流向、工具使用和采用具体的技术实现手段或方式情况,用于规范本项目最终生产环境的建立。逻辑架构是建立应用架构、执行架构、运维架构的基础,也是建立执行架构、应用架构以及运维架构的原型系统。功能组件架构描述确定系统各个大的组件组件区域的功能模块框架,以及提供的某种服务类型。运维架构是描述EDW项目的运维架构标准,包括运维架构设计的内容、设计原则、各构成组件的设计考虑因素、约束、要求等。运维架构经过相应的流程和工具实现对逻辑架构、功能组件架构、执行架构、数据架构以及应用架构的运维和管理。而数据架构和应用架构的主要描述:应用架构是EDW为满足业务需求所提供的系统应用功能及其蓝图设计,其中业务需求是应用架构设计的基础,最终的应用架构将以应用系统的形式体现在执行架构中,主要包括:应用服务和数据服务。数据架构描述于EDW系统相关的数据流动策略,即数据在EDW系统的执行架构下的抽取、转换、储存策略以及应采用的流程,包括数据层次和总分行之间的数据分部情况等。数据架构是建立执行架构标准的需求定义。下图是EDW项目总体架构的框架:总体架构的设计原则总体架构在着重考虑实施要求的同时,需要为后续阶段进行规划,以保证项目最终能够达到目标架构的设计;总体架构的设计要基于包括XX银行数据现状分析、实施阶段数据源情况分析、第一阶段实施EDW设计建议做为参考;总体架构设计架构时充分考虑与现有系统兼容,充分利用已有成果,避免重复开发和建设。总体架构设计过程中应遵守XX银行的IT管理规程,保证最终的系统能够顺利的部署并移交给XX银行的运行维护部门。总体架构的设计特点 权衡功能、性能、可扩展性、易用性、可管理性和性价比。根据XX银行的数据情况和分析需求,采用多层次的企业EDW系统架构来保证在存在复杂的数据种类和关系的海量数据上进行业务分析和查询在业务支持能力和性能等方面的要求。多级／自动的增量ETL加载机制,有效提高ETL并发度、加载效率,降低错误处理的复杂性。经过用户入口支持用户采用Web浏览器使用查询和分析工具,统一的信息服务界面,提高系统易用性,减少技术支持工作量。利用企业信息集成和Web数据服务,提高系统的数据支持能力和接口的一致性。统一的数据增强平台也减少数据增强的复杂度。EDW执行架构执行架构的主要内容是描述EDW项目执行架构的建设要求及指导原则,用于规范本项目最终生产环境的建设。EDW项目的生产环境的建立需要参考并遵循执行架构部分提出的要求。执行架构概述执行架构是EDW的概念环境,主要包含:源数据、数据落地区、ETL、数据准备区、数据存储区EDW、业务应用、用户环境、数据管控、系统安全性以及EDW基础设施平台(包括:服务器、存储、网络)等功能组件。从技术层面上来说,EDW系统的执行架构应实现多种技术平台及应用之间的无缝集成。执行架构设计原则在EDW项目实施的过程中,系统执行架构的建设应遵循以下技术原则:开放性原则:EDW项目的生产环境的建设应基于业界开放标准,对系统中使用的网络协议、硬件接口、数据接口等应进行统一规划,EDW系统应支持主流的应用软件包及其部署的各种硬件平台。灵活性与可扩展性:EDW系统的基础设施平台应能够根据未来系统的发展需要以及应用需求,方便的扩展设备容量和提升设备性能;具备支持多种组件模块、多种物理接口的能力;具备技术升级、设备更新的灵活性;具备支持业务功能的扩展与重构的灵活性。如:系统容量能够随着ETL系统数据量的扩展以及应用系统的不断扩展、用户量不断扩展而进行平滑的扩展。高性能原则:系统应达到数据处理时间窗口的要求,用户定义的查询效率、响应时间的要求,满足业务系统的要求;对现有业务系统影响小。自动化原则:EDW项目建设的核心任务之一是数据抽取、转换、清洗和加载(ETL),在这个过程中应采用自动化的设计原则,避免手工操作。同时对于元数据管理过程应采用元数据管理平台来实现对元数据集中、自动化的管理。安全性原则:EDW项目建设中的数据迁移过程都必须保证数据的安全性,例如:在系统建设过程中应对数据中敏感字段进行安全处理、同时整个系统还应采用网络隔离、用户身份认证及访问控制、数据库安全、操作系统安全以及完善的安全审计机制。执行架构框架上图是EDW系统执行架构,其中包含EDW系统中涵盖的功能框架以及框架之间的逻辑关系。在以下的内容中将对执行架构中的功能框架以及框架之间的关系进行详细描述,具体内容包括:数据源:包括XX银行的多个业务系统,主要有核心系统、个贷系统、信贷系统、国际业务系统、财务系统和各类渠道系统等。数据落地区:此部分内容说明数据落地的用途,同时对数据落地区应具备的功能进行了标准定义以及数据落地区与其它功能组件之间的关联关系;ETL:此部分内容描述ETL系统中数据抽取、转换、加载等功能的需求,同时定义了ETL系统建设的标准以及ETL与系统中其它功能组件之间的关系;数据准备区:此部分描述数据准备区应具备的功能,以及数据准备区在建设过程中的标准需求。操作型存储区:此部分内容描述EDW系统在建设的过程中操作型存储区应遵循的标准以及系统建设过程中应满足的需求;数据仓库存储区:此部分内容描述EDW系统的数据仓库存储区应遵循的标准以及系统建设过程中应满足的需求;业务应用:此部分内容描述BI应用系统建设的系统需求,包含对应用环境、分析环境、静态报表环境;用户环境:此部分的内容描述用户在EDW系统中应具备运用的能力,包括:利用通用展现平台进行信息展现、驾驶舱应用、报表应用等;时间窗口和性能的定义:此部分描述整个EDW项目中关于时间窗口的定义以及相关系统的性能指标要求;元数据管理:此部分描述在系统执行架构中元数据管理的内容以及元数据管理系统的建设的标准定义;系统安全性:此部分内容主要描述EDW系统中的安全性管理内容,包括应用安全、网络安全、数据安全、系统安全等,同时描述系统安全在建立过程中遵循的原则;基础设施平台(服务器、网络、存储):此部分内容主要描述生产系统中的硬件资源,包括:服务器,网络以及存储的资源需求,容量规划应满足的系统指标等内容;数据源源数据系统是报表、关键指标、灵活查询、主题分析等应用系统的基础数据来源。在系统建设初期,源数据系统应提供能满足初始业务需要的数据以及业务系统需要提供完整数据的时间窗口,在EDW系统扩展的过程中,各个源数据系统中的数据将逐渐的加载到EDW系统当中。源数据无法满足应用需求时,系统应提供手工方式经过手工数据补入平台将需要的数据补入到EDW系统中。当前数据源包括XX银行的多个业务系统,主要有核心系统、个贷系统、对公信贷系统、国际业务系统、财务系统和各类渠道系统等。数据落地区数据落地区是为了保证多系统对源系统数据抽取的需求,在数据从源数据系统抽取后在统一的数据集成环境中整合。数据落地区应建立与各相关源数据系统的接口,将这些系统定期卸载的数据以固定的格式接收、存放到落地区,考虑数据传输和加载的速度,源数据系统应以文本文件格式将数据定期传输给数据落地区进行处理。数据落地区的数据存储格式原则上是与数据源的存储格式保持一致数据ETL架构ETL是数据的抽取、转换、加载的全部过程,它是数据从数据落地区到ETL服务器以及从ETL服务器到EDW的数据迁移过程以及数据从EDW向数据集市的数据迁移过程中必须使用的过程和方法,ETL系统应包括以下三个主要功能:数据抽取:从数据落地区系统抽取EDW中需要的数据;数据转换:将从源数据系统获取的数据转换成EDW要求的形式,同时按照业务需求对数据进行转换;数据加载:将助转换后的数据装载到EDW的物理模型中;数据准备区数据准备区是数据存储的临时存储区域,数据在其中只作暂时性保存,数据经转换后导入到EDW的物理模型中。数据准备区的功能包括:格式转换、排序去重/筛选、通用基础清洗、连接/合并/分割、业务转换等操作型存储区操作型存储区是数据仓库系统一个重要的环节。该区有着承上启下的作用,从数据形态来看,该区的数据定义贴近业务源系统;从数据标准来看,该区的数据标准是遵循数据仓库系统的标准。因此该区一般分为两个层次,第一个层次称之为良好质量的、统一格式的数据贴源层,第二个层次为统一的、规范的、遵循数据仓库系统标准的数据标准层。数据贴源层能够继续为行内现有的一些报表系统或者分析系统提供数据,而数据标准层为数据仓库中的企业数据模型的落地扫清了道路。因此该存储区在整个EDW系统起到了一个承上启下的关键作用。EDW存储区EDW存储区是面向主题的、集成的、面向企业的、最明细的数据存储,其内容是依据最终用户应用和分析需求来进行组织。数据存储区中的数据模型对标准层数据、基础整合数据、汇总数据和面向应用的集市数据按数据层次进行管理,每个数据层有自己的数据管理重点。对于每个数据层次,再按主题进行分类组织。这样就能够有效的将银行企业的操作型数据、汇总型数据和分析型数据以清晰的架构组织、管理起来,并相辅相成。数据层的内容相互促进发展,组成银行完善的数据集合,为各种主题管理应用的构建提供良好的数据架构基础。业务应用业务应用是EDW系统向业务用户提供应用功能支持,根据应用服务提供的形式和所采用的应用系统的不同,业务应用主要定义在以下几个技术环境。数据集市:在业务应用层中包含了应用系统中需要的应用集市、OLAP、静态报表等数据集市。数据集市是一组特定的、针对某个主题域、部门或用户分类的数据集合。这些数据需要针对用户的快速访问和数据输出进行优化,优化的方式能够经过对数据结构进行汇总和索引。经过数据集市能够保障EDW的高可用性、可扩展性和高性能。应用环境:应用环境是为满足业务需要在数据EDW环境中配置的应用软件包。分析环境:数据分析环境为EDW的高端用户提供即时的数据分析功能等。报表环境:报表环境是于来产生和发布静态报表的环境,包括:产生的静态报表、OLAP产生的报表、KPI指标展现以及其它系统产生的报表。用户环境用户环境是EDW系统最终向用户提供的某种应用服务的集合,主要有三种应用服务的表现形式:通用展现平台:经过此平台将报表、KPI展现、灵活查询、分析等多个应用集成到一个平台中,进行统一的展现和信息的管理,包括如:报表生命周期的管理等。数据分发环境:在数据分发的过程中应提供大容量数据批量分发的能力。给其它需要某个系统的数据提供数据交换功能。报表分发环境:报表的分发应能够满足系统定义的安全性,如按照不同的用户类型、不同的组织进行分发,不同的用户和组织只能看到属于自己的报表的数据,数据的分发将经过数据传输平台进行。元数据管理元数据管理是对数据信息的收集和发布的集成管理,数据信息包括:数据的业务含义和技术特性。数据仓库系统架构中的各个部分中都含有元数据信息,应对其进行主动式管理,以保证它正确的定义、收集和使用。元数据是”关于数据的数据”。应包括文件结构定义,数据库字段名称,数据模型中的长度和标准,以及在域-域或域-报表对应关系中的计算和公式等内容。元数据管理的架构如下图所示,系统的最终架构应实现对元数据的集中的管理方式:系统安全性EDW系统中的数据和报表信息均为敏感信息。因此必须采用适当的安全策略以保证其系统和数据的安全性。数据仓库系统的安全性应涵盖如下四个方面:验证:系统应对用户进行访问控制,保证只有合法的用户才能进入到系统中;授权:系统应根据用户角色对其进行授权,包括对数据的访问权限,对功能的使用权限等。机密性:所有的敏感数据必须被严格控制,禁止未授权访问,并保障其安全性。一致性:数据和程序只能在授权模式下进行修改。针对上述6个方面,数据仓库分系统应按照以下的6个方面的标准进行建设:应用层EDW应用系统是建立在OLAP软件平台的基础上,应用层应实现用户访问控制的功能,针对不同的用户访问不同的系统资源来保证整个应用系统的安全性控制。对于未来的数据仓库系统来说,应与统一门户平台整合,实现整体安全性管理的策略;数据库层只有被授权用户才能访问和修改数据库中的信息而且数据在传输过程中应对敏感信息进行加密处理来保证数据的安全。数据库管理员应按照角色对数据库用户进行划分,而且经过赋予角色权限的方式实现对用户安全性访问控制的管理,如:针对用户组或耽搁用户分配特定数据表访问权限。系统层系统应防止未授权访问和系统调用,及时进行系统安全补丁的更新。对于系统主机应采用服务器加固的方法,来保证整个系统的安全性。网络层网络层安全是保证网络节点之间数据传递的安全性,以及网络环境不受恶意攻击。XX银行数据仓库环境建立在企业内部网络中,不同功能的服务器应部署在不同网段中,网段之间相互隔离,对网段之间的访问应经过防火墙并定义严格的访问控制策略。整个系统的网络环境应得到实时监控,对入侵进行检测和处理,并在发生入侵时通知系统管理员。物理层物理层安全保障物理设备(主机、路由器等)不受非法用户攻击。当前物理设备的安全性由运行中心负责。管理管理部分与上述的所有安全问题相关,对安全问题的管理必须由多个部门共同协作完成。管理层面包括:安全资源:实现各种安全使用的资源,如:防火墙,入侵检测和处理设备,反病毒软件等;安全策略和规划:各种安全规则,组织和责任人;突发事件处理:在发生安全威胁时的应急处理流程,包括:事件记录、时间报告制度等流程;安全审计:对安全策略的审核和检查;灾难恢复计划:发生问题后的系统和数据恢复;EDW逻辑架构逻辑架构框架如上图所示的XX银行EDW的逻辑体系架构,这一架构是在联科可扩展的EDW系统框架的基础上,结合XX银行信息系统建设的实际情况而设计出来的多层、可扩展框架结构。架构的核心上包括源数据层、ETL流程调度、数据平台层、数据集市层、应用服务层、访问控制层、用户层和数据消费传输通道七个大部分,另外,元数据管理和安全管理也是系统必不可少的部分,这2部分会涉及到所有核心层次。在明确定义各层之间的接口后,多层框架结构具有高度的扩展能力和方便的系统开发和维护性能,符合当前流行的多层应用结构,适合EDW系统多阶段、多层次的应用特点。源数据层【功能与作用】总行的各个业务系统为整个EDW系统提供原始数据支持,首先作为ETL层的数据抽取源。【组成部分】当前总行的数据源包括XX银行的多个业务系统,主要有核心系统、个贷系统、对公信贷系统、国际业务系统、财务系统和各类渠道系统等。ETL流程调度层【功能与作用】该层为EDW数据流向的主要环节,EDW系统数据流动的流程调度核心层,流程调度主要针对下面几个方面:EDW系统将数据源的数据抽取到数据落地区EDW系统对数据执行格式转换、排序去重、通用数据清洗、业务转换后等操作,最终完成数据准备区加载。EDW系统再将数据准备区的数据按照EDW数据模型的方式加载到数据存储区中。在数据存储区中进行基础数据层、加工汇总层和应用集市层的数据加载。EDW中的数据准备区和数据存储区能够为为其它系统提供数据服务。总行EDW能够为分行EDW提供数据服务。【组成部分】上面的逻辑架构图淡绿色色矩形部分为ETL调度管理技术架构图,其作用是让许多的任务在作业的执行条件满足时自动地执行。ETL调度管里最基本的可执行元素是单元,每个单元是完成某一特定功能的程序,相关单元组合在一起构成了能够调度的最小组件——任务。由上面的技术架构图可知,ETL调度管里包含下列组件:知识库建立在DB中的一个数据库,包含了与流程调度相关的一组表,保存ETL流程调度服务器、任务、任务之间的依赖触发关系、任务组、调度计划等多种类型的信息。侦测器驻留在后台的服务,基于定义的触发规则和调度计划监测是否触发任务的执行。任务调度引擎接受侦测器的信息调度任务执行(能够使本服务器任务也能够是其它服务器的任务)。任务执行代理调用任务包含的每个单元执行的服务,同一服务器上能够有多个任务执行代理同时运行。任务封装在Perl程序中,执行数据加载、整合、立方体生成等工作的一组程序。日志管理引擎记录ETL调度管理各个服务器组件以及每个任务的执行日志,日志按天保存,能够定期清理。管理监控器Java应用程序,用于定义任务、任务组合触发关系等信息,同时能够实时监控任务执行情况查看日志。作为专门为数据仓库系统设计的流程调度管理具有如下特点:任务执行代理可分布在多台服务器上。结构简单、伸缩性强。支持多种执行任务。加载数据整合数据数据质量检查和清洗数据转换OLAP数据生成数据挖掘模型的执行定制报表的产生定制页面的产生数据库备份、告警等系统作业调用其它ETL/ELT工具产生的任务数据导出到指定的渠道系统执行的任务能够是另一个任务调度引擎触发(如:EDW)。能够启动其它的ETL引擎的任务。数据平台层【功能与作用】作为本系统的数据核心部分,它负责存储和管理来自各种源数据系统的数据,并为访问用户提供数据服务。这些数据是按照在逻辑数据模型分主题存放的。【组成部分】本层由操作型存储区、仓库存储区和集市应用层四个部分组成。详细内容参见”EDW数据架构”数据集市层【功能与作用】数据集市是一组特定的、针对某个主题域、部门或用户分类的数据集合。这些数据需要针对用户的快速访问和数据输出进行优化,优化的方式能够经过对数据结构进行汇总和索引。经过数据集市能够保障EDW的高可用性、可扩展性和高性能。【组成部分】包括:驾驶舱报表系统和灵活查询以及其它应用集市系统。应用服务层【功能与作用】经过对数据平台层中的数据进行适当的提炼、汇总,利用通用展现平台向用户提供包括报表服务、查询服务、决策仪表盘等相关服务。该层为用户对中央数据的访问提供各种方式的服务(C/S、B/S),从而实现访问方式的多样化和信息存取的透明化。【组成部分】通用展现平台主要包括的功能模块有:第一个层次是核心模块包括:框架、引擎,核心模块作为报表集成开发环境的基础、核心和框架存在。报表集成开发环境核心功能和模块组装由核心模块统一提供,只暴露给开发人员;第二个层次是管理模块包括:报表信息、基本管理、代理、信息推送、连接信息,管理模块为报表集成开发环境提供管理服务,它提供报表集成开发环境的用户、权限等的统一管理,管理模块也是报表集成开发环境必选模块,它的很多功能调用由核心模块提供,管理模块包括5个子模块;第三个层次是应用模块包括:仪表盘、灵活查询、数据录入、报表、复杂报表,应用模块提供报表集成开发环境最终用户(非管理人员)的用户体验,能够和管理模块相结合有选择地灵活部署。访问控制层【功能与作用】访问控制层主要包括WEB、认证、安全、门户四方面的服务。该层位于用户层和中间服务层之间,为用户层成提供HTTP服务、门户的单点登录、用户统一认证、提交用户层请求到中间服务层,对用户实施安全策略,为用户管理报表、查询文档,提供个性化定制等。用户层由上面的逻辑架构图可知用户层包括各种最终用户。按照用户使用EDW系统的方式和特点,能够划分为业务分析人员、高级分析人员和管理决策人员。所有用户统一经过用户门户访问EDW系统各类应用,从而实现了EDW系统的应用界面、安全管理统一,同时用户能够对门户进行个性化定制以方便自己使用。实际上,EDW系统还包括进行系统建设的开发人员、系统运行人员和系统管理人员,这里所指的用户层主要针对业务用户进行描述。业务分析人员主要指总行各业务部门、各分行的业务用户,如:客户经理。该类人员直接使用模块化的应用界面访问EDW系统,生成或预览预定义报表,进行相对固定的查询以及多维分析。这类用户会使用B/S和C/S两种客户端访问EDW系统。高级分析人员是指总行各业务部门、各分行的较为高级的用户。除能够执行一般业务分析人员进行的操作外,能够对指定的主题、指标进行自定义的灵活分析和比较。分析的方式包括自定义查询、自定义报表、多维旋转和穿透钻取等等。这类用户会使用B/S和C/S两种客户端访问EDW系统。管理决策人员主要包括各部门的领导、分行领导和总行领导。EDW系统为管理决策人员分配专门的系统资源,建立最为直观和方便的存取界面,为决策人员赋予最大的信息访问权限,实现决策人员对信息的自由访问。同时,EDW系统将决策人员最为关心的信息主动发布到决策人员的访问界面上,简化信息访问的方式,使得决策人员在第一时间获得经营管理的各种重要信息和指标。这类用户只会使用B/S客户端访问EDW系统。消费数据传输通道在数据仓库系统建立以后,会有很长一段时间旧有的报表系统和分析系统需要逐步迁移,在此期间,需要有一个消费数据传输通道来支持旧有系统的良好运转。安全管理体系安全管理体系主要包括以下四个方面:网络安全主要包括在不同网络层次设置不同级别的防火墙及IDS系统,同时在每一个安全层次下经过部署不同的安全原则,这完全符合XX银行的安全级别规定。操作系统安全系统所有应用或数据库服务器均采用Unix操作系统,操作系统本身有着严密的系统安全认证与用户权限管理体系,并具备登录、审核以及资源访问的审计与跟踪。数据安全提供各种基于数据库的安全保护机制。应用安全应用是直接面对用户的,虽然应用系统能够持续提供服务是涉及到系统安全的问题,可是因为这些问题更多的是由系统的安全问题来保证的。因此就应用级的安全策略更多的是保证对数据访问的合法性。元数据管理体系在机构内关于数据的信息称为”元数据(Metadata)”。清楚地区分数据库中的数据和元数据是很重要的,所谓元数据,是指关于数据的数据,即用来描述数据的类型、来源、定义、存储位置,使得能够正确地使用数据仓库。元数据仓库(MetaDataRepository)对业务人员来说是很重要的,是业务人员与数据仓库的数据交流的传达手段。IT人员可能已经拥有许多有效的工具进行数据存取。但对业务人员,她们需要一种手段和工具来理解她们存取的数据。在本期EDW系统的建设中,包括技术元数据和业务元数据两类,其数据源涵盖了EDW系统的各个环节,包括:数据源系统、EDW数据库、EDW逻辑数据模型、ETL系统、业务应用系统等,同时,还将涉及数据的业务含义和业务规则等相关业务文档。在架构上,元数据系统包括:元数据应用、元数据报表、元数据分析、元数据集成系统、元数据展现系统、元数据管理系统、元数据维护系统。数据处理流程各业务数据源系统经过多种方式(如:ETL工具直接从源系统获取、源系统数据批量导出)将数据获取过来,由数据落地区区进行集中管理。后续的数据加工、转换经过ETLServer来完成,中间采取不落地的方式,将加工完毕后的数据放在数据准备区域。ETLServer可经过dsjob,FTP,NFS等方式从数据落地区获取数据,将处理后的结果放在数据准备区域。再将数据准备区的数据加载到数据存储区中。根据目标系统的不同,采用灵活的方式向外提供数据,可使用ETL工具直接向目标系统加载或者经过FTP方式向其它目标传输。为支持其它的业务需求,将近期(30-60天)的明细数据、流水数据集中存放在数据库系统中,日常增量数据刷新数据库系统。整个过程经过调度工具进行统一调度,集中管理,确保各项任务有序完成。EDW运维架构运维架构概述下图中给出了EDW的运维架构,是在EDW系统上线后,为了保持系统良好的稳定性而定义的相关的管理需求。运维架构主要是针对执行架构的数据导入层、数据服务层、中间服务层和访问控制层服务器进行管理,面向的最终用户是IT人员。图1运维逻辑体系架构运维架构中包含了如下组件:系统监控管理组件、系统维护管理组件、备份恢复管理组件、故障切换管理组件、性能容量规划组件和运维安全管理组件。各个组件的主要功能如下:系统监控管理组件:监控网络/系统性能、运行,以及诊断和报告故障。管理的硬件和软件包括所有开发、测试和生产环境中的硬件和软件。系统维护管理组件:系统维护是指系统在运行过程中,为了系统的正常服务而进行的配置、参数管理,以及启/停机、清理过期数据等日常操作,以及数据、系统发生变更的维护等。备份恢复管理组件:备份/恢复管理组件处理系统中所有必须的备份和恢复操作。这个组件根据备份策略,经过对数据的冗余存储来保证系统能够从各种服务中断中恢复。故障切换管理组件:故障切换管理提供了管理和控制应用切换的机制。故障切换组件使用冗余系统和数据来保证关键任务数据流不间断。当发生故障或失败时,该切换发生在主系统和备份系统之间。性能容量规划组件:性能及容量规划从环境中的不同元素收集利用数据,并规划硬件和软件能力需求。运维安全管理组件:运维安全管理组件经过制定和管理运维安全策略,并利用安全工具,维护信息系统资产(包括硬件、软件、用户数据、信息/数据)的机密性、一致性和可用性。运维环境管理组件:运维环境管理用于确保物理环境和系统环境的妥善管理和保护,不受故障和灾难的侵害,以及不受人为因素的干扰和破坏。整个运维架构经过一些标准的流程实现生产环境运行管理,包括的流程主要是日常操作流程和特殊操作流程。日常操作流程是指IT用户在日常为维护生产环境正常运转需要做的工作,如:数据仓库管理、系统监控、备份恢复、容量规划。特殊操作流程不会每天发生,这一流程的启动一般是由于系统软硬件升级、数据变更、新增应用等需求引起的。运维架构的逻辑框架系统监控管理在EDW系统中,需要监控管理的系统元素能够分为如下五类:网络/主机管理:用于监控、控制和报告网络及主机状态。数据库/数据仓库管理:提供相关监控信息源,控制各个独立的服务器或数据库/数据仓库。应监控所有的关键数据库/数据仓库性能比例,以保证高可用性和性能。应用管理:处理客户应用中发生的事件。应用本身包括了衡量内部应用响应时间和性能的工具,应搜集这些工具产生的信息(如日志、运行报告等)用于监控。生产调度:生产调度组件包括了一套应用,用于调度和自动化网络、系统和应用管理(如ETL)特有的任务。安全管理:运维架构中涉及的安全管理内容主要包括身份管理、系统级密钥和证书管理、安全策略管理。系统监控管理的主要任务及工具支持如下图所示:系统维护管理系统维护是指系统在运行过程中,为了系统的正常服务而进行的配置、参数管理,以及启/停机、清理过期数据等日常操作,以及数据、系统发生变更的维护等。系统维护管理包括两方面的管理内容:系统维护和变更管理。系统维护是指系统在运行过程中,为了系统的正常服务而进行的配置、参数管理,以及启/停机、清理过期数据等日常操作。变更管理允许对技术架构组件进行变更的控制管理。在EDW系统运行过程中,有两种典型的变更需要进行管理:数据变更和系统升级。变更控制组件能够协助运维团队、开发团队和业务部门之间的沟通,保障系统的变更平滑进行。系统维护管理的主要任务及工具支持如下图所示:备份恢复管理备份与恢复的目标在于:保证在任何时点对数据的完全恢复。最低程度地降低数据丢失。尽量提高数据备份过程的效率。备份恢复管理的主要任务及工具支持如下图所示:故障切换管理故障切换管理组件提供了管理和控制应用切换的机制,提供系统的高可用性。故障切换组件使用冗余系统和数据来保证关键任务数据流不间断。当发生故障或失败时,该切换发生在主系统和备份系统之间。在故障或失败事件中,故障切换管理组件将系统资源重路由到稳定配置的备份系统中,直到主系统被恢复或替代。性能和容量规划性能和容量规划组件代表了从环境中的不同系统元素收集利用数据,并规划硬件和软件能力需求的工具。数据经过放置在环境中系统元素一端的代理进行的收集,并由容量规划组件进行分析,包括磁盘容量、内存使用、处理器使用、数据库、和网络等。性能容量规划包括如下组件:信息收集:收集性能容量相关的重要分析数据;性能管理:对系统系统性能进行监控、管理、分析和调优;性能容量规划:基于历史趋势和未来性能容量需求进行规划;性能容量规划的主要任务及工具支持如下图所示:运维安全管理安全管理组件经过制定和管理安全策略,并利用安全工具,维护信息系统资产(包括硬件、软件、固件、用户数据、信息/数据)的机密性、一致性和可用性。安全管理是贯穿EDW总体架构的。例如,在运维架构中可能需要使用安全控制工具对系统管理工具的访问进行管理,在开发架构中则可能使用安全控制工具对代码存储的访问进行管理。为防止安全内容的重复,所有安全组件都应统一被考虑,它是跨开发、执行、运维架构的。EDW数据架构数据架构设计原则统一规范对各源系统数据按主题进行统一整合;分行特色也按统一规范进行补充建设。灵活性原则数据模型要为数据应用提供有效的信息支持,这些信息需求会随着银行需求的变化而不断增加,进而会引起需求的不可预料性。特别是加工汇总层的数据架构必须符合”汇总指标可灵活增加”的技术要求,不会随着指标的增加而变更数据模型。可扩展性原则随着源系统和数据集市应用系统的不断增加,数据模型应提供一个规范化的设计思路,以便业务系统的扩展。高效原则数据模型面临海量数据的加工和存储,随着时间的推移,数据将不断累积,因此效率问题是直接影响系统可用性的关键因素。数据模型的效率包括ETL的加工效率和数据展现的查询效率,因此数据模型的数据组织和存储,必须是高效可用的。实用性原则处理大量的源系统数据,将会占用大量的系统资源,因此必须仔细分析数据的实用性、指标的使用频率,以业务需求驱动为原则,对业务提出的基础数据和指标需求进行优先级划分,正确制定指标的汇总粒度。加工汇总层要重点解决共性指标的加工。存储空间合理性原则数据模型需要处理海量数据。随时间的增加,存储数据越来越多。因此在设计时必须考虑如何合理组织数据,以减小数据冗余。数据架构分层设计数据库统一存储管理所辖数据,由于数据类型比较多,数据库表也比较多,如何有效的组织管理好全行多种业务的数据和信息,对下一步清晰的信息应用、方便地使用数据是很关键的。因此数据和信息不能随意堆积存放到数据库中,需要对全行的数据和信息进行分层、分类存放,并制定相应的数据分层、分类的规范,EDW系统上所有数据和应用的建设都应遵从统一的数据管理规范。存放到EDW数据库中的数据有以下几类:1、从原业务系统直接采集过来的经标准化处理的标准数据,由标准数据按主题整合形成的基础业务数据;2、经过中间加工汇总形成的汇总数据;3、管理应用所专用的操作型数据;4、为满足应用分析需要而加工形成的多维分析数据。为了更好的管理这些数据,EDW数据按层次进行划分存放及管理,从逻辑模型上划分为以下几个数据层次:源数据缓冲层:数据层与业务源的数据结构一一对应,是数据存储的临时存储区域,数据在其中只作暂时性保存,当新的数据到达缓储区时,现有数据被删除或覆盖。标准化数据层:对数据做标准化处理,主要有公共代码标准化、数据类型标准化和数据格式标准化,未来能够做客户信息标准化。标准化全量层基础数据层数据模型基础数据模型用于整合、存储全行各业务系统的基础业务数据。原则上该区域的数据不作复杂加工,直接存储业务系统中原始数据记录的关键数据(主数据),尽量保持贴近源系统的数据结构。为应用方便、查询高效考虑,能够对源系统进行适当的整合、拆分,也能够裁减掉源系统中没有必要整合的数据。同时需要对各系统冗余及标准不一致的数据进行规范和整合。在基础据模型中按照八大主题对银行全行数据进行整合、分类组织和存储,这八大主题包括总帐(GL)、客户(CI)、存款(DEP)、贷款(LN)、银行卡(CRD)、中间业务(NIN)、渠道(CHN)、公用(CM);每个主题下设计相应的数据模型,最后构成全行统一的基础数据模型。EDW对各源系统机构编码进行统一,提供统一的基线机构。EDW对源系统客户号进行统一,提供统一的客户号(ECIF客户编号)。加工汇总数据层数据模型;加工汇总数据层的主题划分为八大主题:总帐(GL)、客户(CI)、存款(DEP)、贷款(LN)、银行卡(CRD)、中间业务(NIN)、渠道(CHN)、公用(CM)。加工汇总数据层下的汇总需求由”应用需要”来确定。多个应用相同的汇总要求,或者多个应用在汇总计算的基础部分有重复汇总的部分能够纳入该区域进行汇总,形成应用共享的中间汇总结果,如按客户、机构、产品、渠道等主题的一些公共汇总数据(包括每天或每个阶段的业务量、业务额、平均额等数据的汇总)。加工汇总数据层的数据模型设计在有相应的汇总需求情况下才针对汇总需求进行数据表和数据汇总任务的扩展设计,逐步积累公共汇总指标,最后形成全行可共享的面向各个主题的中间汇总指标。加工汇总数据层分为两种不同数据形态:1)汇总指标－如平均余额等2)根据业务要求形成的分析加工数据－如理财卡帐务数据、客户大额存取款等集市数据层数据模型集市数据层用于建立面向各个应用主题的数据集市,不同的主题应用在集市数据区下建立不同的数据集市,数据集市的数据模型根据应用模型的需要进行设计。数据集市中可存在操作型数据、汇总型数据和多维分析数据,根据应用的需要分别进行建立。EDW应用架构应用架构设计原则EDW系统的应用架构应考虑开放性、完整性、合理性。开放性:EDW系统的应用架构设计必须考虑平台、系统、功能的开放性,与XX银行的科技规划相适应,能够与周边各系统进行良好的信息传递。完整性:EDW系统的应用架构设计应具备完整性,涵盖当前的应用需求,并以框架形式界定EDW项目的应用需求范围。EDW系统的应用架构应该能够作为需求检查列表,检验当前用户需求是否被涵盖,而不会发生遗漏。合理性:应用架构的设计应是对用户需求的全面反映。应用架构应采用先进的理念和技术,并结合XX银行科技规划与现有的技术平台。数据服务EDW将提供全行各个系统的批量数据服务,如应用架构图所示EDW即能够为核心系统、财务系统、个贷系统、信贷系统等业务系统提供数据,也能够为资产负债系统、内部评级系统、战略客户管理信息系统等管理内的系统提供数据服务;同时也能够为未来实现的EDW系统提供数据,从而实现全行范围内系统间的批量数据采集、加工和发布,原则上各系统不能再建设其它渠道实现批量数据采集、加工、发布。EDW数据采集、加工、发布的范围包括:总行各应用系统之间总行与分行应用系统之间同一分行应用系统间不同分行应用系统间分布部署的同一应用系统间EDW数据服务具备的能力有:EDW快速提供批量数据,能够满足应用系统准实时的数据要求。EDW能够提供的数据会覆盖全行所有系统,能够满足全行所有的数据加工对数据的需求。EDW模型化各系统数据,能够满足各应用系统对全量数据、增量数据的需求,减少对重要交易系统的干扰。EDW能够根据应用系统的需要,对源系统数据进行必要的加工处理,按照全行数据架构原则,合理地在数据线上分配数据加工功能,保证数据处理的高效、准确。应用服务基于数据分析功能和交易功能分离原则,为保证交易系统运行效率和数据分析功能日益增加的需求,新系统设计时,应该将数据分析功能和交易功能分离到不同系统中,或者至少为将来分离做好技术准备。在这个原则下,EDW能够对外提供应用服务,如:驾驶舱报表系统中的报表功能;某些时效性要求较高的即时OLAP分析;经营关键指标KPI展示等。ETL体系建设ETL架构概述在商业银行的EDW系统中,数据由数据源系统加载到EDW的各个数据层中,并经过供数接口提供给相关使用者系统。其实现的困难在于ETL系统将面临复杂的数据环境,包括巨大的加载数据量、错综复杂的数据关系和参差不齐的数据质量,这些都使ETL的架构和应用设计面临相当的挑战。经过高效的ETL系统结构、层次化的应用功能划分和标准的程序模板,EDW系统能够达到以下目标:支持在此框架下实现EDW项目所需要的ETL功能;支持在规定的批处理时间窗口(BatchWindow)内能够完成数据加载工作,即需要满足日常数据加载的性能需求;能够支持有效的应用程序开发模式,提高开发效率,尽量减少应用开发成本;减少系统维护的复杂性,支持后续增加新数据或功能的开发工作。和上下游系统接口的松耦合设计,避免上下游系统的变更导致ETL程序本身频繁变更。XX银行总行的EDW系统数据源环境复杂,应用系统数据需求旺盛,数据质量参差不齐,结合以上系统目标及设计原则,建议采用如下体系架构建设:ETL逻辑结构按照处理过程可划分为ETL预处理、ETL转换清洗、ETL目标数据装载。对于数据提供者,包括业务系统(核心业务系统、个贷系统、信贷系统、国际业务系统、财务系统、渠道系统)以及管理系统(数据仓库EDW系统、客户关系管理CRM系统、绩效考核系统、稽核管理系统、报表中心),经过ETL预处理,数据装载入数据缓冲区。ETL转换清洗经过连接、合并、分割,按照清洗规则对数据缓冲区、数据存储区的数据进行加工、汇总,最终装载入数据存储区。ETL目标数据装载按照EDW的数据接口要求,给目标系统提供数据。ETL1:属于ETL预处理。加载源系统数据,增加时间拉链,数据装载入数据缓冲区。对源数据做数据平衡检查、稽核数据有效性,报告数据质量问题。ETL2:属于ETL清洗。对数据缓冲区数据标准化,统一数据表示格式,排序数据,筛选重复数据,合并或分割数据项,装载入数据存储区的基础数据层。报告数据转换清洗异常。ETL3:属于ETL转换。对操作型存储区的贴源标准化数据,按照业务转换规则、通用数据清洗规则,加工数据,装载入数据仓库区的FDM基础层。ETL3处理是耗时最长,逻辑处理最复杂的阶段,需要非常重视。ETL4:属于ETL转换。从数据仓库FDM层进行适量的维度、指标建模。一些低粒度数据逐步向高粒度数据归并和汇总。ETL5:属于ETL目标数据装载。提供数据存储区的FDM层数据、ADM层数据。本模式提供EDW允许的相应时间段的历史数据支持。ETL6:属于ETL目标数据装载。提供数据存储区的FDM层数据、ADM层数据。本模式提供EDW允许的相应时间段的历史数据支持。ETL设计方案ETL关键设计环节接口层设计策略将数据源环境下的数据装载进入EDW环境,需要在两个不同环境的记录系统之间建立一个接口。建立和设计这个接口,似乎只要编制一个抽取程序就能够了,事实上,在这一阶段的工作中,的确对数据进行了抽取,但抽取并不是全部的工作,这一接口还应具有以下的功能:从面向应用和操作的环境生成完整的数据;数据的基于时间的转换;数据的聚合;对现有记录系统的有效扫描,以便以后进行追加。从业务系统抽取数据,采用ETL平台直接从业务系统抽取数据,也能够先把业务系统的数据导出为文本文件再加载到临时存储区。StagingArea设计策略StagingAreaStorage由一些ETL处理过程的辅助表组成,辅助ETL工具完成复杂的转换和计算,StagingArea一般是一些临时表。StagingArea的作用与实现:减少对数据源的查询压力,有助于数据整合。将数据源的数据统一抽取到StagingArea,协调获取不同数据源的调度。应用于增量处理能够减少处理的记录数量,使增量处理更加容易,例如应用于SCDType2。StagingArea的另一个应用是仅存储被更改的记录。对数据的格式进行转换在StagingArea完成数据格式的转换,例如日期格式、字符串右边的空格、NULL值的替换、数据类型转换等。时间调度上的灵活性经过建立StagingArea,把数据存储在临时空间,使ETL调度更灵活。作为ETL后续处理的统一接口建立StagingArea作为ETL每个处理阶段的接口,对系统的灵活性和可扩展性非常有帮助。数据加载策略数据加载分为历史数据加载(InitialLoad)和日常数据加载(IncrementalLoad)。历史数据加载指在第一次加载数据到数据仓库中,此时数据仓库中不存在历史数据。日常数据加载是指在历史数据加载完成后,将变化了的增量数据加载到数据仓库中。我们认为只需要建立一套增量加载的ETL同样处理历史数据加载和日常数据加载,而不再开发另一套全量加载ETL程序处理历史数据加载。这样只需要开发一套ETL程序作业,减少了开发工作量,而且避免了两套程序可能出现的数据算法不一致造成的数据不一致的错误。对于历史数据加载的策略,我们能够采用时间窗口的分段的方法来处理历史数据量大的表的装载,即我们能够一个一个时间段来加载历史数据。增量ETL设计策略确定增量数据测量和故障恢复策略。增量策略是正常的日常增量处理的策略,故障恢复策略是在日常增量处理出错时的处理策略。如果判断增量数据,方法有:时间戳对于交易流水、帐户数据等,能够采用判断时间戳的方法获取增量数据。自增长的序列号源系统设置了自增长的序列号作为唯一主键。更改标志源系统定义了一个字段作为数据被更改的标识。整表比较对于没有时间戳的增量数据,数据量不大时,例如编码表,能够采用使用数据库的SQL操作语句(NOTIN,NOTExists)的方法。日志对于经常对历史数据进行修改、删除的业务系统,而且修改没有设置登记簿,能够经过读取数据库的日志来实现增量。一般数据库均包括日志,经过分析数据库的日志来判断增量数据。此方法需要有专门的工具读取数据库日志。循环校验码对于没有时间戳的数据进行修改,还能够考虑采用循环校验码。经过TRIGGER实现增量识别在数据表上建立TRIGGER,一般数据项发生变化,将记录到增量表中。缺点是必须对业务数据库进行改动,客户不一定能接受。联科增量数据抽取的设计,符合以下要求:增量抽取策略必须支持要很方便跟踪进程运行状态增量抽取支持抽取类型为增量或全量,抽取方式为日、月、季度等多种方式经过设定简单的参数,如:table_name,firstdayofrun,load_type,load_methEDW等,就能够设置一个抽取的过程错误处理和恢复策略在复杂的ETL过程中,难免会产生错误。ETL管理调度利用作业调度控制能够处理各种异常错误情况。在作业流程中能够设置异常的条件,如当错误记录超过一定的条数或者错误级别达到一定的级别时,作业掉转到异常处理流程,进行自动处理,系统设计的原则是尽量不中断ETL作业流程,当然如果错误特别严重,也能够转到手工处理。错误的恢复策略:每条记录中有数据ETL的时间戳,对小数据量的数据表,能够经过该时间戳清除掉本次加载的数据。对于大数据量的表,能够利用时间窗口功能,如果大表某一天的数据出现错误后,能够直接进行一天数据的恢复。异常处理ETL处理的异常主要包括:硬件、操作系统、网络导致异常;数据源数据传输、质量导致异常;ETL过程处理导致异常;目标数据模型导致异常;人工干预导致异常等;建议处理的方法包括:手工干预,重新调整ETL过程;终止流程,通知管理员;拒绝数据,记录原因;清洗数据,部分入库;监控资源,重复尝试ETL恢复策略包括有:每条记录中有数据ETL的时间戳,对小数据量的数据表,能够经过该时间戳清除掉本次加载的数据。对于大数据量的表,能够利用时间窗口功能,如果大表某一天的数据出现错误后,能够直接进行一天数据的恢复。作业调度和监控根据作业依赖关系的元数据进行ETL作业的调度,并对执行过程进行监控。作业调度需要包括以下功能:灵活启停作业;根据日期规则设置作业执行计划;支持作业的并发执行;允许作业网络的嵌套;方便新增ETL作业。作业的监控需要包括以下功能:监控作业的当前执行情况;查询作业历史执行情况。元数据管理ETL过程需要经过元数据的管理来实现数据流程的监控以及作业的灵活调度。需要定义:源数据结构、目标数据结构、源和目标的映射(包括定制映射的方案、定制映射调用的函数、定制清洗的方案)、作业处理日志以及作业依赖关系。ETL模块设计XX银行的ETL采用数据库的存储过程及Shell脚本等技术支持,能够按照如下模块设计:调度模块:负责任务的管理、调度和分发,作业依赖关系的管理;作业控制:负责计算资源的分配、作业的执行,控制作业执行的流程、跟踪作业执行的结果、记录作业的日志。数据库模块:管理类数据库:用于调度和作业主控,保存任务和作业的相关配置信息和运行信息。应用类数据库:用于具体应用的业务数据库。ETL域:ETL架构中基本的计算资源组合,是一个计算机群,由JCI统一管理和控制,一个ETL域由一个ETLServer和多个ETLClient组成。ETL应用:应用部署和配置管理的基本单位,一个ETL应用包含一组相关的作业单元、作业配置参数和应用环境参数。物理作业:具体负责数据加工的程序执行单元,各类存储过程或者作业脚本(SHELL脚本、用C/C++/PROC等开发的可执行程序)。ETL模块能够划分为任务调度、任务控制、任务执行。任务调度模块在EDWH+EDWB统一模块中,调度是由部署在总行的调度SERVER统一完成调度工作,或者由部署在分行的调度Server完成本分行作业的调度。调度SERVER根据各个JOB的运行时间和依赖关系,按照一定的调度策略对总分行的JOB进行统一调度。在实际部署中,调度模块能够仅部署在总行,实施统一调度,也可能部署在分行,实施分布调度;而在每个ETL域的ETLServer上部署调度的Agent模块,调度Server负责任务的检索、调度和分发,调度Agent接收到调度Server的调度指令,调用作业主控模块(JCI)执行具体的作业,并根据JCI的退出码将作业的执行情况反馈给调度Server。任务控制模块统一架构中的处理模块是由一个或多个ETL域组成的。总行有一个或多个总行的ETL域,分行有本分行的ETL域。域与域在物理上是分开,可是在逻辑上是联系在一起的。对于不同的域,它们的处理任务也是不一样的。每个处理域由一个或多个ETLSERVER和若干个ETLCLIENT组成。ETLSERVER主要负责ETLJOB的具体执行。首先,ETLSERVER接收调度Agent发过来的要执行的作业的作业ID,根据该作业ID到管理库中获取该作业的运行参数并解释所有参数。其次根据作业运行资源需求,获取所属ETLCLIENT的资源情况,选择最优的若干台ETLCLIENT,分配作业给这些ETLCLIENT运行。最后收集并记录作业运行日志信息,释放ETLCLIENT的资源,更新作业运行状态,返回作业运行结果信息给调度Agent。ETLCLIENT主要负责ETLSERVER分配的作业模块的具体执行,是作业的具体执行者。ETL统一架构中的ETL域并不是一成不变的,理论上具有无限的横向扩展能力。它能够根据本域上的作业情况增减ETLCLIENT。如果作业的数目太多,ETLSERVER承担的任务过重,则能够增加ETLSERVER来降低原有的ETLSERVER调控任务的压力。如果实际运行JOB的ETLCLIENT资源不足,经常处于高负荷状态,则能够经过增加ETLCLIENT来提高运行效率。ETLServer访问管理库,ETLClient只访问应用库,不允许访问管理库。数据库模块统一架构中的数据库模块分为两个部分:管理类数据库和业务类数据库。业务类数据库存放的是ETL作业处理的业务数据。管理类数据库存放的是作业运行控制相关的数据信息,如系统配置参数或作业配置信息、状态信息和运行日志信息等。在统一架构中,数据库模块分为两层,一层是总行层,另外一层是分行层。无论是总行还是分行,数据库都是由管理类数据库和业务类数据库组成。在管理库的具体部署时,可能只部署在总行,所有ETLServer都访问这个管理库,分行的ETLServer经过跨越广域网的数据库连接访问管理库。管理库的信息分为三类:系统参数和作业配置信息:静态参数;状态信息:属于控制类的动态信息;日志信息;ETL流程设计系统ETL设计流程如下图:本系统ETL处理流程顺序概要描述如下:调度程序在总行的调度服务器上面运行,当调度程序发现某个作业符合调度条件,就对其进行调度,将该JOB的ID发给该JOB所在域的ETLSERVER。ETLSERVER得到调度的调度指令后,根据JOBID,先到所在域中的管理类数据库中JOB实例表中查找该JOB,判断该JOB的状态是否正确,查找该JOB的前序JOB是否完成,然后在JOB参数表中查找该JOB对应的各种参数,为作业的运行解析和准备参数,同时到所在域的业务类数据库中查找各种输入文件是否存在,如果条件都满足,则JOB能够运行。3．ETLSERVER对JOB的类型进行判断,如果是普通的SHELLJOB或者EXECJOB,则根据JOB实例表中的NODES_LIST(该作业可使用的节点列表),计划在本域中分配一个ETLCLIENT给JOB运行,如果是DSJOB,则根据JOB实例表中的NODES_NEED(运行该作业所需节点数)和NODES_LIST(该作业可使用的节点列表)得到该JOB运行所需的结点个数