EDW/数据仓库项目方案
第一章 系统总体架构
一.1 总体架构设计概述
一.1.1 总体架构的设计框架
XX银行EDW项目的总体架构分为基础技术架构、应用架构和数据架构三个核心部分。这三个部分共同组成了XX银行EDW系统。
在基础技术架构中，包括执行架构、逻辑架构、功能组件架构和运维架构四个部分。
⏹执行架构描述系统大的框架和模块区域，以及之间的逻辑关系；是确定生产环境的建设要求及指导原则。
⏹逻辑架构描述EDW各个模块之间的数据的接口、数据流向、工具使用和采用具体的技术实现手段或方式情况，用于规范本项目最终生产环境的建立。逻辑架构是建立应用架构、执行架构、运维架构的基础，也是建立执行架构、应用架构以及运维架构的原型系统。
⏹功能组件架构描述确定系统各个大的组件组件区域的功能模块框架，以及提供的某种服务类型。
⏹运维架构是描述EDW项目的运维架构标准，包括运维架构设计的内容、设计原则、各构成组件的设计考虑因素、约束、要求等。运维架构通过相应的流程和工具实现对逻辑架构、功能组件架构、执行架构、数据架构以及应用架构的运维和管理。
而数据架构和应用架构的主要描述：
⏹应用架构是EDW为满足业务需求所提供的系统应用功能及其蓝图设计，其中业务需求是应用架构设计的基础，最终的应用架构将以应用系统的形式体现在执行架构中，主要包括：应用服务和数据服务。
⏹数据架构描述于EDW系统相关的数据流动策略，即数据在EDW系统的执行架构下的抽取、转换、储存策略以及应采用的流程，包括数据层次和总分行之间的数据分部情况等。数据架构是建立执行架构标准的需求定义。
下图是EDW项目总体架构的框架：
一.1.2 总体架构的设计原则
⏹总体架构在着重考虑实施要求的同时，需要为后续阶段进行规划，以保证项目最终能够达到目标架构的设计；
⏹总体架构的设计要基于包括XX银行数据现状分析、实施阶段数据源情况分析、第一阶段实施EDW设计建议做为参考；
⏹总体架构设计架构时充分考虑与现有系统兼容，充分利用已有成果，避免重复开发和建设。
⏹总体架构设计过程中应遵守XX银行的IT管理规程，保证最终的系统可以顺利的部署并移交给XX银行的运行维护部门。
一.1.3 总体架构的设计特点
⏹ 权衡功能、性能、可扩展性、易用性、可管理性和性价比。
⏹根据XX银行的数据情况和分析需求，采用多层次的企业EDW系统架构来保证在存在复杂的数据种类和关系的海量数据上进行业务分析和查询在业务支持能力和性能等方面的要求。
⏹多级／自动的增量ETL加载机制，有效提高ETL并发度、加载效率，降低错误处理的复杂性。
⏹通过用户入口支持用户采用Web浏览器使用查询和分析工具，统一的信息服务界面，提高系统易用性，减少技术支持工作量。
⏹利用企业信息集成和Web数据服务，提高系统的数据支持能力和接口的一致性。统一的数据增强平台也减少数据增强的复杂度。
一.2 EDW执行架构
执行架构的主要内容是描述EDW项目执行架构的建设要求及指导原则，用于规范本项目最终生产环境的建设。EDW项目的生产环境的建立需要参考并遵循执行架构部分提出的要求。
一.2.1 执行架构概述
执行架构是EDW的概念环境，主要包含：源数据、数据落地区、ETL、数据准备区、数据存储区EDW、业务应用、用户环境、数据管控、系统安全性以及EDW基础设施平台（包括：服务器、存储、网络）等功能组件。从技术层面上来说，EDW系统的执行架构应实现多种技术平台及应用之间的无缝集成。
一.2.2 执行架构设计原则
在EDW项目实施的过程中，系统执行架构的建设应遵循以下技术原则：
开放性原则：EDW项目的生产环境的建设应基于业界开放标准，对系统中使用的网络协议、硬件接口、数据接口等应进行统一规划，EDW系统应支持主流的应用软件包及其部署的各种硬件平台。
灵活性与可扩展性：EDW系统的基础设施平台应能够根据未来系统的发展需要以及应用需求，方便的扩展设备容量和提升设备性能；具备支持多种组件模块、多种物理接口的能力；具备技术升级、设备更新的灵活性；具备支持业务功能的扩展与重构的灵活性。如：系统容量可以随着ETL系统数据量的扩展以及应用系统的不断扩展、用户量不断扩展而进行平滑的扩展。
高性能原则：系统应达到数据处理时间窗口的要求，用户定义的查询效率、响应时间的要求，满足业务系统的要求；对现有业务系统影响小。
自动化原则：EDW项目建设的核心任务之一是数据抽取、转换、清洗和加载（ETL），在这个过程中应采用自动化的设计原则，避免手工操作。同时对于元数据管理过程应采用元数据管理平台来实现对元数据集中、自动化的管理。
安全性原则：EDW项目建设中的数据迁移过程都必须保证数据的安全性，例如：在系统建设过程中应对数据中敏感字段进行安全处理、同时整个系统还应采用网络隔离、用户身份认证及访问控制、数据库安全、操作系统安全以及完善的安全审计机制。
一.2.3 执行架构框架
上图是EDW系统执行架构，其中包含EDW系统中涵盖的功能框架以及框架之间的逻辑关系。在以下的内容中将对执行架构中的功能框架以及框架之间的关系进行详细描述，具体内容包括：
数据源：包括XX银行的多个业务系统，主要有核心系统、个贷系统、信贷系统、国际业务系统、财务系统和各类渠道系统等。
数据落地区：此部分内容说明数据落地的用途，同时对数据落地区应具备的功能进行了标准定义以及数据落地区与其他功能组件之间的关联关系；
ETL：此部分内容描述ETL系统中数据抽取、转换、加载等功能的需求，同时定义了ETL系统建设的标准以及ETL与系统中其他功能组件之间的关系；
数据准备区：此部分描述数据准备区应具备的功能，以及数据准备区在建设过程中的标准需求。
操作型存储区：此部分内容描述EDW系统在建设的过程中操作型存储区应遵循的标准以及系统建设过程中应满足的需求；
数据仓库存储区：此部分内容描述EDW系统的数据仓库存储区应遵循的标准以及系统建设过程中应满足的需求；
业务应用：此部分内容描述BI应用系统建设的系统需求，包含对应用环境、分析环境、静态报表环境；
用户环境：此部分的内容描述用户在EDW系统中应具备运用的能力，包括：利用通用展现平台进行信息展现、驾驶舱应用、报表应用等；
时间窗口和性能的定义：此部分描述整个EDW项目中关于时间窗口的定义以及相关系统的性能指标要求；
元数据管理：此部分描述在系统执行架构中元数据管理的内容以及元数据管理系统的建设的标准定义；
系统安全性：此部分内容主要描述EDW系统中的安全性管理内容，包括应用安全、网络安全、数据安全、系统安全等，同时描述系统安全在建立过程中遵循的原则；
基础设施平台（服务器 、网络、存储）：此部分内容主要描述生产系统中的硬件资源，包括：服务器，网络以及存储的资源需求，容量规划应满足的系统指标等内容；
一.2.3.1 数据源
源数据系统是报表、关键指标、灵活查询、主题分析等应用系统的基础数据来源。在系统建设初期，源数据系统应提供能满足初始业务需要的数据以及业务系统需要提供完整数据的时间窗口，在EDW系统扩展的过程中，各个源数据系统中的数据将逐渐的加载到EDW系统当中。源数据无法满足应用需求时，系统应提供手工方式通过手工数据补入平台将需要的数据补入到EDW系统中。
目前数据源包括XX银行的多个业务系统，主要有核心系统、个贷系统、对公信贷系统、国际业务系统、财务系统和各类渠道系统等。
一.2.3.2 数据落地区
数据落地区是为了保证多系统对源系统数据抽取的需求，在数据从源数据系统抽取后在统一的数据集成环境中整合。数据落地区应建立与各相关源数据系统的接口，将这些系统定期卸载的数据以固定的格式接收、存放到落地区，考虑数据传输和加载的速度，源数据系统应以文本文件格式将数据定期传输给数据落地区进行处理。
数据落地区的数据存储格式原则上是与数据源的存储格式保持一致
一.2.3.3 数据ETL架构
ETL是数据的抽取、转换、加载的全部过程，它是数据从数据落地区到ETL服务器以及从ETL服务器到EDW的数据迁移过程以及数据从EDW向数据集市的数据迁移过程中必须使用的过程和方法， ETL系统应包括以下三个主要功能：
⏹数据抽取：从数据落地区系统抽取EDW中需要的数据；
⏹数据转换：将从源数据系统获取的数据转换成EDW要求的形式，同时按照业务需求对数据进行转换；
⏹数据加载：将助转换后的数据装载到EDW的物理模型中；
一.2.3.4 数据准备区
数据准备区是数据存储的临时存储区域，数据在其中只作暂时性保存，数据经转换后导入到EDW的物理模型中。
数据准备区的功能包括：格式转换、排序去重/筛选、通用基础清洗、连接/合并/分割、业务转换等
一.2.3.5 操作型存储区
操作型存储区是数据仓库系统一个重要的环节。该区有着承上启下的作用，从数据形态来看，该区的数据定义贴近业务源系统;从数据标准来看，该区的数据标准是遵循数据仓库系统的标准。所以该区一般分为两个层次，第一个层次称之为良好质量的、统一格式的数据贴源层，第二个层次为统一的、规范的、遵循数据仓库系统标准的数据标准层。
数据贴源层可以继续为行内现有的一些报表系统或者分析系统提供数据，而数据标准层为数据仓库中的企业数据模型的落地扫清了道路。
所以该存储区在整个EDW系统起到了一个承上启下的关键作用。
一.2.3.6 EDW存储区
EDW存储区是面向主题的、集成的、面向企业的、最明细的数据存储，其内容是依据最终用户应用和分析需求来进行组织。数据存储区中的数据模型对标准层数据、基础整合数据、汇总数据和面向应用的集市数据按数据层次进行管理，每个数据层有自己的数据管理重点。对于每个数据层次，再按主题进行分类组织。这样就可以有效的将银行企业的操作型数据、汇总型数据和分析型数据以清晰的架构组织、管理起来，并相辅相成。数据层的内容相互促进发展，组成银行完善的数据集合，为各种主题管理应用的构建提供良好的数据架构基础。
一.2.3.7 业务应用
业务应用是EDW系统向业务用户提供应用功能支持，根据应用服务提供的形式和所采用的应用系统的不同，业务应用主要定义在以下几个技术环境。
数据集市：在业务应用层中包含了应用系统中需要的应用集市、OLAP、静态报表等数据集市。数据集市是一组特定的、针对某个主题域、部门或用户分类的数据集合。这些数据需要针对用户的快速访问和数据输出进行优化，优化的方式可以通过对数据结构进行汇总和索引。通过数据集市可以保障EDW的高可用性、可扩展性和高性能。
应用环境：应用环境是为满足业务需要在数据EDW环境中配置的应用软件包。
分析环境：数据分析环境为EDW的高端用户提供即时的数据分析功能等。
报表环境：报表环境是于来产生和发布静态报表的环境，包括：产生的静态报表、OLAP产生的报表、KPI指标展现以及其他系统产生的报表。
一.2.3.8 用户环境
用户环境是EDW系统最终向用户提供的某种应用服务的集合，主要有三种应用服务的表现形式：
通用展现平台：通过此平台将报表、KPI展现、灵活查询、分析等多个应用集成到一个平台中，进行统一的展现和信息的管理，包括如：报表生命周期的管理等。
数据分发环境：在数据分发的过程中应提供大容量数据批量分发的能力。给其他需要某个系统的数据提供数据交换功能。
报表分发环境：报表的分发应可以满足系统定义的安全性，如按照不同的用户类型、不同的组织进行分发，不同的用户和组织只能看到属于自己的报表的数据，数据的分发将通过数据传输平台进行。
一.2.3.9 元数据管理
元数据管理是对数据信息的收集和发布的集成管理，数据信息包括：数据的业务含义和技术特性。数据仓库系统架构中的各个部分中都含有元数据信息，应对其进行主动式管理，以保证它正确的定义、收集和使用。元数据是“关于数据的数据”。应包括文件结构定义，数据库字段名称，数据模型中的长度和标准，以及在域-域或域-报表对应关系中的计算和公式等内容。
元数据管理的架构如下图所示，系统的最终架构应实现对元数据的集中的管理方式：
一.2.3.10 系统安全性
EDW系统中的数据和报表信息均为敏感信息。因此必须采用适当的安全策略以保证其系统和数据的安全性。数据仓库系统的安全性应涵盖如下四个方面：
⏹验证：系统应对用户进行访问控制，保证只有合法的用户才能进入到系统中；
⏹授权：系统应根据用户角色对其进行授权，包括对数据的访问权限，对功能的使用权限等。
⏹机密性：所有的敏感数据必须被严格控制，禁止未授权访问，并保障其安全性。
⏹一致性：数据和程序只能在授权模式下进行修改。
针对上述6个方面，数据仓库分系统应按照以下的6个方面的标准进行建设：
应用层
EDW应用系统是建立在OLAP软件平台的基础上，应用层应实现用户访问控制的功能，针对不同的用户访问不同的系统资源来保证整个应用系统的安全性控制。对于未来的数据仓库系统来说，应与统一门户平台整合，实现整体安全性管理的策略；
数据库层
只有被授权用户才能访问和修改数据库中的信息并且数据在传输过程中应对敏感信息进行加密处理来保证数据的安全。
数据库管理员应按照角色对数据库用户进行划分，并且通过赋予角色权限的方式实现对用户安全性访问控制的管理，如：针对用户组或耽搁用户分配特定数据表访问权限。
系统层
系统应防止未授权访问和系统调用，及时进行系统安全补丁的更新。对于系统主机应采用服务器加固的方法，来保证整个系统的安全性。
网络层
网络层安全是保证网络节点之间数据传递的安全性，以及网络环境不受恶意攻击。
XX银行数据仓库环境建立在企业内部网络中，不同功能的服务器应部署在不同网段中，网段之间相互隔离，对网段之间的访问应通过防火墙并定义严格的访问控制策略。整个系统的网络环境应得到实时监控，对入侵进行检测和处理，并在发生入侵时通知系统管理员。
物理层
物理层安全保障物理设备（主机、路由器等）不受非法用户攻击。目前物理设备的安全性由运行中心负责。
管理
管理部分与上述的所有安全问题相关，对安全问题的管理必须由多个部门共同协作完成。管理层面包括：
⏹安全资源：实现各种安全使用的资源，如：防火墙，入侵检测和处理设备，反病毒软件等；
⏹安全策略和规划：各种安全规则，组织和责任人；
⏹突发事件处理：在发生安全威胁时的应急处理流程，包括：事件记录、时间报告制度等流程；
⏹安全审计：对安全策略的审核和检查；
⏹灾难恢复计划：发生问题后的系统和数据恢复；
一.3 EDW逻辑架构
一.3.1 逻辑架构框架
如上图所示的XX银行EDW的逻辑体系架构，这一架构是在联科可扩展的EDW系统框架的基础上，结合XX银行信息系统建设的实际情况而设计出来的多层、可扩展框架结构。架构的核心上包括源数据层、ETL流程调度、数据平台层、数据集市层、应用服务层、访问控制层、用户层和数据消费传输通道七个大部分，另外，元数据管理和安全管理也是系统必不可少的部分，这2部分会涉及到所有核心层次。
在明确定义各层之间的接口后，多层框架结构具有高度的扩展能力和方便的系统开发和维护性能，符合目前流行的多层应用结构，适合EDW系统多阶段、多层次的应用特点。
一.3.1.1 源数据层
【功能与作用】
总行的各个业务系统为整个EDW系统提供原始数据支持，首先作为ETL层的数据抽取源。
【组成部分】
目前总行的数据源包括XX银行的多个业务系统，主要有核心系统、个贷系统、对公信贷系统、国际业务系统、财务系统和各类渠道系统等。
一.3.1.2 ETL流程调度层
【功能与作用】
该层为EDW数据流向的主要环节，EDW系统数据流动的流程调度核心层，流程调度主要针对下面几个方面：
⏹EDW系统将数据源的数据抽取到数据落地区
⏹EDW系统对数据执行格式转换、排序去重、通用数据清洗、业务转换后等操作，最终完成数据准备区加载。
⏹EDW系统再将数据准备区的数据按照EDW数据模型的方式加载到数据存储区中。
⏹在数据存储区中进行基础数据层、加工汇总层和应用集市层的数据加载。
⏹EDW中的数据准备区和数据存储区可以为为其它系统提供数据服务。
⏹总行EDW可以为分行EDW提供数据服务。
【组成部分】
上面的逻辑架构图淡绿色色矩形部分为ETL 调度管理技术架构图，其作用是让许多的任务在作业的执行条件满足时自动地执行。ETL 调度管里最基本的可执行元素是单元，每个单元是完成某一特定功能的程序，相关单元组合在一起构成了可以调度的最小组件——任务。由上面的技术架构图可知，ETL 调度管里包含下列组件：
⏹知识库
建立在DB中的一个数据库，包含了与流程调度相关的一组表，保存ETL流程调度服务器、任务、任务之间的依赖触发关系、任务组、调度计划等多种类型的信息。
⏹侦测器
驻留在后台的服务，基于定义的触发规则和调度计划监测是否触发任务的执行。
⏹任务调度引擎
接受侦测器的信息调度任务执行（可以使本服务器任务也可以是其它服务器的任务）。
⏹任务执行代理
调用任务包含的每个单元执行的服务，同一服务器上可以有多个任务执行代理同时运行。
⏹任务
封装在Perl程序中，执行数据加载、整合、立方体生成等工作的一组程序。
⏹日志管理引擎
记录ETL调度管理各个服务器组件以及每个任务的执行日志，日志按天保存，可以定期清理。
⏹管理监控器
Java应用程序，用于定义任务、任务组合触发关系等信息，同时可以实时监控任务执行情况查看日志。
作为专门为数据仓库系统设计的流程调度管理具有如下特点：
⏹任务执行代理可分布在多台服务器上。
⏹结构简单、伸缩性强。
⏹支持多种执行任务。
1)加载数据
2)整合数据
3)数据质量检查和清洗
4)数据转换
5)OLAP数据生成
6)数据挖掘模型的执行
7)定制报表的产生
8)定制页面的产生
9)数据库备份、告警等系统作业
10)调用其他ETL/ELT工具产生的任务
11)数据导出到指定的渠道系统
⏹执行的任务可以是另一个任务调度引擎触发（如：EDW）。
⏹可以启动其它的ETL引擎的任务。
一.3.1.3 数据平台层
【功能与作用】
作为本系统的数据核心部分，它负责存储和管理来自各种源数据系统的数据，并为访问用户提供数据服务。
这些数据是按照在逻辑数据模型分主题存放的。
【组成部分】
本层由操作型存储区、仓库存储区和集市应用层四个部分组成。详细内容参见“EDW数据架构”
一.3.1.4 数据集市层
【功能与作用】
数据集市是一组特定的、针对某个主题域、部门或用户分类的数据集合。这些数据需要针对用户的快速访问和数据输出进行优化，优化的方式可以通过对数据结构进行汇总和索引。通过数据集市可以保障EDW的高可用性、可扩展性和高性能。
【组成部分】
包括：驾驶舱报表系统和灵活查询以及其他应用集市系统。
一.3.1.5 应用服务层
【功能与作用】
通过对数据平台层中的数据进行适当的提炼、汇总，利用通用展现平台向用户提供包括报表服务、查询服务、决策仪表盘等相关服务。该层为用户对数据的访问提供各种方式的服务（C/S、B/S），从而实现访问方式的多样化和信息存取的透明化。
【组成部分】
通用展现平台主要包括的功能模块有：
第一个层次是核心模块包括：框架、引擎，核心模块作为报表集成开发环境的基础、核心和框架存在。报表集成开发环境核心功能和模块组装由核心模块统一提供，只暴露给开发人员；
第二个层次是管理模块包括：报表信息、基本管理、代理、信息推送、连接信息，管理模块为报表集成开发环境提供管理服务，它提供报表集成开发环境的用户、权限等的统一管理，管理模块也是报表集成开发环境必选模块，它的很多功能调用由核心模块提供，管理模块包括5个子模块；
第三个层次是应用模块包括：仪表盘、灵活查询、数据录入、报表、复杂报表，应用模块提供报表集成开发环境最终用户（非管理人员）的用户体验，可以和管理模块相结合有选择地灵活部署。
一.3.1.6 访问控制层
【功能与作用】
访问控制层主要包括WEB、认证、安全、门户四方面的服务。该层位于用户层和中间服务层之间，为用户层成提供HTTP服务、门户的单点登录、用户统一认证、提交用户层请求到中间服务层，对用户实施安全策略，为用户管理报表、查询文档，提供个性化定制等。
一.3.1.7 用户层
由上面的逻辑架构图可知用户层包括各种最终用户。按照用户使用EDW系统的方式和特点，可以划分为业务分析人员、高级分析人员和管理决策人员。所有用户统一通过用户门户访问EDW系统各类应用，从而实现了EDW系统的应用界面、安全管理统一，同时用户可以对门户进行个性化定制以方便自己使用。
实际上，EDW系统还包括进行系统建设的开发人员、系统运行人员和系统管理人员，这里所指的用户层主要针对业务用户进行描述。
⏹业务分析人员
主要指总行各业务部门、各分行的业务用户，如：客户经理。该类人员直接使用模块化的应用界面访问EDW系统，生成或预览预定义报表，进行相对固定的查询以及分析。这类用户会使用B/S和C/S两种客户端访问EDW系统。
⏹高级分析人员
是指总行各业务部门、各分行的较为高级的用户。除能够执行一般业务分析人员进行的操作外，可以对指定的主题、指标进行自定义的灵活分析和比较。分析的方式包括自定义查询、自定义报表、旋转和穿透钻取等等。这类用户会使用B/S和C/S两种客户端访问EDW系统。
⏹管理决策人员
主要包括各部门的领导、分行领导和总行领导。EDW系统为管理决策人员分配专门的系统资源，建立最为直观和方便的存取界面，为决策人员赋予最大的信息访问权限，实现决策人员对信息的自由访问。同时，EDW系统将决策人员最为关心的信息主动发布到决策人员的访问界面上，简化信息访问的方式，使得决策人员在第一时间获得经营管理的各种重要信息和指标。这类用户只会使用B/S客户端访问EDW系统。
一.3.1.8 消费数据传输通道
在数据仓库系统建立以后，会有很长一段时间旧有的报表系统和分析系统需要逐步迁移，在此期间，需要有一个消费数据传输通道来支持旧有系统的良好运转。
一.3.1.9 安全管理体系
安全管理体系主要包括以下四个方面：
⏹网络安全
主要包括在不同网络层次设置不同级别的防火墙及IDS系统，同时在每一个安全层次下通过部署不同的安全原则，这完全符合XX银行的安全级别规定。
⏹操作系统安全
系统所有应用或数据库服务器均采用Unix操作系统，操作系统本身有着严密的系统安全认证与用户权限管理体系，并具备登录、审核以及资源访问的审计与跟踪。
⏹数据安全
提供各种基于数据库的安全保护机制。
⏹应用安全
应用是直接面对用户的，虽然应用系统能够持续提供服务是涉及到系统安全的问题，但是因为这些问题更多的是由系统的安全问题来保证的。所以就应用级的安全策略更多的是保证对数据访问的合法性。
一.3.1.10 元数据管理体系
在机构内关于数据的信息称为“元数据(Metadata)”。清楚地区分数据库中的数据和元数据是很重要的，所谓元数据，是指关于数据的数据，即用来描述数据的类型、来源、定义、存储位置，使得可以正确地使用数据仓库。
元数据仓库(Meta Data Repository)对业务人员来说是很重要的，是业务人员与数据仓库的数据交流的传达手段。IT人员可能已经拥有许多有效的工具进行数据存取。但对业务人员，他们需要一种手段和工具来理解他们存取的数据。
在本期EDW系统的建设中，包括技术元数据和业务元数据两类，其数据源涵盖了EDW系统的各个环节，包括：数据源系统、EDW数据库、EDW逻辑数据模型、ETL系统、业务应用系统等，同时，还将涉及数据的业务含义和业务规则等相关业务文档。在架构上，元数据系统包括：元数据应用、元数据报表、元数据分析、元数据集成系统、元数据展现系统、元数据管理系统、元数据维护系统。
一.3.2 数据处理流程
各业务数据源系统通过多种方式(如：ETL工具直接从源系统获取、源系统数据批量导出)将数据获取过来,由数据落地区区进行集中管理。
后续的数据加工、转换通过ETL Server来完成,中间采取不落地的方式,将加工完毕后的数据放在数据准备区域。ETL Server 可通过 ds job,FTP,NFS 等方式从数据落地区获取数据，将处理后的结果放在数据准备区域。再将数据准备区的数据加载到数据存储区中。
根据目标系统的不同,采用灵活的方式向外提供数据,可使用ETL 工具直接向目标系统加载或者通过 FTP方式向其他目标传输。为支持其他的业务需求,将近期(30-60天)的明细数据、流水数据集中存放在数据库系统中,日常增量数据刷新数据库系统。
整个过程通过调度工具进行统一调度,集中管理,确保各项任务有序完成。
一.4 EDW运维架构
一.4.1 运维架构概述
下图中给出了EDW的运维架构，是在EDW系统上线后，为了保持系统良好的稳定性而定义的相关的管理需求。运维架构主要是针对执行架构的数据导入层、数据服务层、中间服务层和访问控制层服务器进行管理，面向的最终用户是IT人员。
图1 运维逻辑体系架构
运维架构中包含了如下组件：系统监控管理组件、系统维护管理组件、备份恢复管理组件、故障切换管理组件、性能容量规划组件和运维安全管理组件。各个组件的主要功能如下：
系统监控管理组件：监控网络/系统性能、运行，以及诊断和报告故障。管理的硬件和软件包括所有开发、测试和生产环境中的硬件和软件。
系统维护管理组件：系统维护是指系统在运行过程中，为了系统的正常服务而进行的配置、参数管理，以及启/停机、清理过期数据等日常操作，以及数据、系统发生变更的维护等。
备份恢复管理组件：备份/恢复管理组件处理系统中所有必须的备份和恢复操作。这个组件根据备份策略，通过对数据的冗余存储来保证系统可以从各种服务中断中恢复。
故障切换管理组件：故障切换管理提供了管理和控制应用切换的机制。故障切换组件使用冗余系统和数据来保证关键任务数据流不间断。当发生故障或失败时，该切换发生在主系统和备份系统之间。
性能容量规划组件：性能及容量规划从环境中的不同元素收集利用数据，并规划硬件和软件能力需求。
运维安全管理组件：运维安全管理组件通过制定和管理运维安全策略，并利用安全工具，维护信息系统资产（包括硬件、软件、用户数据、信息/数据）的机密性、一致性和可用性。
运维环境管理组件：运维环境管理用于确保物理环境和系统环境的妥善管理和保护，不受故障和灾难的侵害，以及不受人为因素的干扰和破坏。
整个运维架构通过一些标准的流程实现生产环境运行管理，包括的流程主要是日常操作流程和特殊操作流程。日常操作流程是指IT用户在日常为维护生产环境正常运转需要做的工作，如：数据仓库管理、系统监控、备份恢复、容量规划。特殊操作流程不会每天发生，这一流程的启动通常是由于系统软硬件升级、数据变更、新增应用等需求引起的。
一.4.2 运维架构的逻辑框架
一.4.2.1 系统监控管理
在EDW系统中，需要监控管理的系统元素可以分为如下五类：
网络/主机管理：用于监控、控制和报告网络及主机状态。
数据库/数据仓库管理：提供相关监控信息源,控制各个的服务器或数据库/数据仓库。应监控所有的关键数据库/数据仓库性能比例，以保证高可用性和性能。
应用管理：处理客户应用中发生的事件。应用本身包括了衡量内部应用响应时间和性能的工具，应搜集这些工具产生的信息（如日志、运行报告等）用于监控。
生产调度：生产调度组件包括了一套应用，用于调度和自动化网络、系统和应用管理（如ETL）特有的任务。
安全管理：运维架构中涉及的安全管理内容主要包括身份管理、系统级密钥和证书管理、安全策略管理。
系统监控管理的主要任务及工具支持如下图所示：
一.4.2.2 系统维护管理
系统维护是指系统在运行过程中，为了系统的正常服务而进行的配置、参数管理，以及启/停机、清理过期数据等日常操作，以及数据、系统发生变更的维护等。
系统维护管理包括两方面的管理内容：系统维护和变更管理。
系统维护是指系统在运行过程中，为了系统的正常服务而进行的配置、参数管理，以及启/停机、清理过期数据等日常操作。
变更管理允许对技术架构组件进行变更的控制管理。在EDW系统运行过程中，有两种典型的变更需要进行管理：数据变更和系统升级。变更控制组件可以协助运维团队、开发团队和业务部门之间的沟通，保障系统的变更平滑进行。
系统维护管理的主要任务及工具支持如下图所示：
一.4.2.3 备份恢复管理
备份与恢复的目标在于：
保证在任何时点对数据的完全恢复。
最低程度地降低数据丢失。
尽量提高数据备份过程的效率。
备份恢复管理的主要任务及工具支持如下图所示：
一.4.2.4 故障切换管理
故障切换管理组件提供了管理和控制应用切换的机制，提供系统的高可用性。故障切换组件使用冗余系统和数据来保证关键任务数据流不间断。当发生故障或失败时，该切换发生在主系统和备份系统之间。在故障或失败事件中，故障切换管理组件将系统资源重路由到稳定配置的备份系统中，直到主系统被恢复或替代。
一.4.2.5 性能和容量规划
性能和容量规划组件代表了从环境中的不同系统元素收集利用数据，并规划硬件和软件能力需求的工具。数据通过放置在环境中系统元素一端的代理进行的收集，并由容量规划组件进行分析，包括磁盘容量、内存使用、处理器使用、数据库、和网络等。
性能容量规划包括如下组件：
信息收集：收集性能容量相关的重要分析数据；
性能管理：对系统系统性能进行监控、管理、分析和调优；
性能容量规划：基于历史趋势和未来性能容量需求进行规划；
性能容量规划的主要任务及工具支持如下图所示：
一.4.2.6 运维安全管理
安全管理组件通过制定和管理安全策略，并利用安全工具，维护信息系统资产（包括硬件、软件、固件、用户数据、信息/数据）的机密性、一致性和可用性。
安全管理是贯穿EDW总体架构的。例如，在运维架构中可能需要使用安全控制工具对系统管理工具的访问进行管理，在开发架构中则可能使用安全控制工具对代码存储的访问进行管理。为防止安全内容的重复，所有安全组件都应统一被考虑，它是跨开发、执行、运维架构的。
一.5 EDW数据架构
一.5.1 数据架构设计原则
⏹统一规范
对各源系统数据按主题进行统一整合；分行特色也按统一规范进行补充建设。
⏹灵活性原则
数据模型要为数据应用提供有效的信息支持，这些信息需求会随着银行需求的变化而不断增加，进而会引起需求的不可预料性。特别是加工汇总层的数据架构必须符合“汇总指标可灵活增加”的技术要求，不会随着指标的增加而变更数据模型。
⏹可扩展性原则
随着源系统和数据集市应用系统的不断增加，数据模型应提供一个规范化的设计思路，以便业务系统的扩展。
⏹高效原则
数据模型面临海量数据的加工和存储，随着时间的推移，数据将不断累积，因此效率问题是直接影响系统可用性的关键因素。数据模型的效率包括ETL的加工效率和数据展现的查询效率，因此数据模型的数据组织和存储，必须是高效可用的。
⏹实用性原则
处理大量的源系统数据，将会占用大量的系统资源，因此必须仔细分析数据的实用性、指标的使用频率，以业务需求驱动为原则，对业务提出的基础数据和指标需求进行优先级划分，正确制定指标的汇总粒度。
加工汇总层要重点解决共性指标的加工。
⏹存储空间合理性原则
数据模型需要处理海量数据。随时间的增加，存储数据越来越多。因此在设计时必须考虑如何合理组织数据，以减小数据冗余。
一.5.2 数据架构分层设计
数据库统一存储管理所辖数据，由于数据类型比较多，数据库表也比较多，如何有效的组织管理好全行多种业务的数据和信息，对下一步清晰的信息应用、方便地使用数据是很关键的。因此数据和信息不能随意堆积存放到数据库中，需要对全行的数据和信息进行分层、分类存放，并制定相应的数据分层、分类的规范，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）根据业务要求形成的分析加工数据－如理财卡帐务数据、客户大额存取款等
⏹集市数据层数据模型
集市数据层用于建立面向各个应用主题的数据集市，不同的主题应用在集市数据区下建立不同的数据集市，数据集市的数据模型根据应用模型的需要进行设计。数据集市中可存在操作型数据、汇总型数据和分析数据，根据应用的需要分别进行建立。
一.6 EDW应用架构
一.6.1 应用架构设计原则
EDW系统的应用架构应考虑开放性、完整性、合理性。
开放性：EDW系统的应用架构设计必须考虑平台、系统、功能的开放性，与XX银行的科技规划相适应，能够与周边各系统进行良好的信息传递。
完整性：EDW系统的应用架构设计应具备完整性，涵盖目前的应用需求，并以框架形式界定EDW项目的应用需求范围。EDW系统的应用架构应该能够作为需求检查列表，检验当前用户需求是否被涵盖，而不会发生遗漏。
合理性：应用架构的设计应是对用户需求的全面反映。应用架构应采用先进的理念和技术，并结合XX银行科技规划与现有的技术平台。
一.6.2 数据服务
EDW将提供全行各个系统的批量数据服务，如应用架构图所示EDW即可以为核心系统、财务系统、个贷系统、信贷系统等业务系统提供数据，也可以为资产负债系统、内部评级系统、战略客户管理信息系统等管理内的系统提供数据服务；同时也可以为未来实现的EDW系统提供数据，从而实现全行范围内系统间的批量数据采集、加工和发布，原则上各系统不能再建设其他渠道实现批量数据采集、加工、发布。
EDW数据采集、加工、发布的范围包括：
⏹总行各应用系统之间
⏹总行与分行应用系统之间
⏹同一分行应用系统间
⏹不同分行应用系统间
⏹分布部署的同一应用系统间
EDW数据服务具备的能力有：
⏹EDW快速提供批量数据，可以满足应用系统准实时的数据要求。
⏹EDW能够提供的数据会覆盖全行所有系统，可以满足全行所有的数据加工对数据的需求。
⏹EDW模型化各系统数据，可以满足各应用系统对全量数据、增量数据的需求，减少对重要交易系统的干扰。
⏹EDW能够根据应用系统的需要，对源系统数据进行必要的加工处理，按照全行数据架构原则，合理地在数据线上分配数据加工功能，保证数据处理的高效、准确。
一.6.3 应用服务
基于数据分析功能和交易功能分离原则，为保证交易系统运行效率和数据分析功能日益增加的需求，新系统设计时，应该将数据分析功能和交易功能分离到不同系统中，或者至少为将来分离做好技术准备。
在这个原则下，EDW可以对外提供应用服务，如：驾驶舱报表系统中的报表功能；某些时效性要求较高的即时OLAP分析；经营关键指标KPI展示等。
第二章 ETL体系建设
二.1 ETL架构概述
在商业银行的EDW系统中，数据由数据源系统加载到EDW的各个数据层中，并通过供数接口提供给相关使用者系统。其实现的困难在于ETL系统将面临复杂的数据环境，包括巨大的加载数据量、错综复杂的数据关系和参差不齐的数据质量，这些都使ETL的架构和应用设计面临相当的挑战。
通过高效的ETL系统结构、层次化的应用功能划分和标准的程序模板，EDW系统能够达到以下目标：
✓支持在此框架下实现EDW项目所需要的ETL功能；
✓支持在规定的批处理时间窗口（Batch Window）内能够完成数据加载工作，即需要满足日常数据加载的性能需求；
✓能够支持有效的应用程序开发模式，提高开发效率，尽量减少应用开发成本；
✓减少系统维护的复杂性，支持后续增加新数据或功能的开发工作。
✓和上下游系统接口的松耦合设计，避免上下游系统的变更导致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允许的相应时间段的历史数据支持。
二.2 ETL设计方案
二.3 ETL关键设计环节
二.3.1 接口层设计策略
将数据源环境下的数据装载进入EDW环境，需要在两个不同环境的记录系统之间建立一个接口。建立和设计这个接口，似乎只要编制一个抽取程序就可以了，事实上，在这一阶段的工作中，的确对数据进行了抽取，但抽取并不是全部的工作，这一接口还应具有以下的功能：
●从面向应用和操作的环境生成完整的数据；
●数据的基于时间的转换；
●数据的聚合 ；
●对现有记录系统的有效扫描，以便以后进行追加。
从业务系统抽取数据，采用ETL平台直接从业务系统抽取数据，也可以先把业务系统的数据导出为文本文件再加载到临时存储区。
二.3.2 Staging Area设计策略
Staging Area Storage由一些ETL处理过程的辅助表组成，辅助ETL工具完成复杂的转换和计算，Staging Area通常是一些临时表。
Staging Area的作用与实现：
1.减少对数据源的查询压力，有助于数据整合。
将数据源的数据统一抽取到Staging Area ，协调获取不同数据源的调度。
2.应用于增量处理
可以减少处理的记录数量，使增量处理更加容易，例如应用于SCD Type 2。Staging Area的另一个应用是仅存储被更改的记录。
3.对数据的格式进行转换
在Staging Area完成数据格式的转换，例如日期格式、字符串右边的空格、NULL值的替换、数据类型转换等。
4.时间调度上的灵活性
通过建立Staging Area，把数据存储在临时空间，使ETL调度更灵活。
5.作为ETL后续处理的统一接口
建立Staging Area作为ETL每个处理阶段的接口，对系统的灵活性和可扩展性非常有帮助。
二.3.3 数据加载策略
数据加载分为历史数据加载（Initial Load）和日常数据加载（Incremental Load）。历史数据加载指在第一次加载数据到数据仓库中，此时数据仓库中不存在历史数据。日常数据加载是指在历史数据加载完成后，将变化了的增量数据加载到数据仓库中。
我们认为只需要建立一套增量加载的ETL 同样处理历史数据加载和日常数据加载，而不再开发另一套全量加载ETL 程序处理历史数据加载。 这样只需要开发一套ETL 程序作业，减少了开发工作量，并且避免了两套程序可能出现的数据算法不一致造成的数据不一致的错误。
对于历史数据加载的策略，我们可以采用时间窗口的分段的方法来处理历史数据量大的表的装载，即我们可以一个一个时间段来加载历史数据。
二.3.4 增量ETL设计策略
确定增量数据测量和故障恢复策略。增量策略是正常的日常增量处理的策略，故障恢复策略是在日常增量处理出错时的处理策略。
如果判断增量数据，方法有：
1.时间戳
对于交易流水、帐户数据等，可以采用判断时间戳的方法获取增量数据。
2.自增长的序列号
源系统设置了自增长的序列号作为唯一主键。
3.更改标志
源系统定义了一个字段作为数据被更改的标识。
4.整表比较
对于没有时间戳的增量数据，数据量不大时，例如编码表，可以采用使用数据库的SQL操作语句（NOT IN，NOT Exists）的方法。
5.日志
对于经常对历史数据进行修改、删除的业务系统，并且修改没有设置登记簿，可以通过读取数据库的日志来实现增量。
一般数据库均包括日志，通过分析数据库的日志来判断增量数据。此方法需要有专门的工具读取数据库日志。
6.循环校验码
对于没有时间戳的数据进行修改，还可以考虑采用循环校验码。
7.通过TRIGGER实现增量识别
在数据表上建立TRIGGER，一般数据项发生变化，将记录到增量表中。缺点是必须对业务数据库进行改动，客户不一定能接受。
联科增量数据抽取的设计，符合以下要求：
⏹增量抽取策略必须支持要很方便跟踪进程运行状态
⏹增量抽取支持抽取类型为增量或全量，抽取方式为日、月、季度等多种方式
⏹通过设定简单的参数，如：table_name, first day of run, load_type, load_methEDW等，就可以设置一个抽取的过程
错误处理和恢复策略
在复杂的ETL 过程中，难免会产生错误。ETL管理调度利用作业调度控制可以处理各种异常错误情况。
在作业流程中可以设置异常的条件，如当错误记录超过一定的条数或者错误级别达到一定的级别时，作业掉转到异常处理流程，进行自动处理，系统设计的原则是尽量不中断ETL 作业流程，当然如果错误特别严重，也可以转到手工处理。
错误的恢复策略：
⏹每条记录中有数据ETL的时间戳，对小数据量的数据表，可以通过该时间戳清除掉本次加载的数据。
⏹对于大数据量的表，可以利用时间窗口功能， 如果大表某一天的数据出现错误后，可以直接进行一天数据的恢复。
二.3.5 异常处理
ETL处理的异常主要包括：
1)硬件、操作系统、网络导致异常；
2)数据源数据传输、质量导致异常；
3)ETL过程处理导致异常；
4)目标数据模型导致异常；
5)人工干预导致异常等；
建议处理的方法包括：
1)手工干预，重新调整ETL过程；
2)终止流程,通知管理员；
3)拒绝数据，记录原因；
4)清洗数据，部分入库；
5)监控资源，反复尝试
ETL恢复策略包括有：
1)每条记录中有数据ETL的时间戳，对小数据量的数据表，可以通过该时间戳清除掉本次加载的数据。
2)对于大数据量的表，可以利用时间窗口功能， 如果大表某一天的数据出现错误后，可以直接进行一天数据的恢复。
二.3.6 作业调度和监控
根据作业依赖关系的元数据进行ETL作业的调度，并对执行过程进行监控。作业调度需要包括以下功能：灵活启停作业；根据日期规则设置作业执行计划；支持作业的并发执行；允许作业网络的嵌套；方便新增ETL作业。
作业的监控需要包括以下功能：监控作业的当前执行情况；查询作业历史执行情况。
二.3.7 元数据管理
ETL过程需要通过元数据的管理来实现数据流程的监控以及作业的灵活调度。需要定义：源数据结构、目标数据结构、源和目标的映射(包括定制映射的方案、定制映射调用的函数、定制清洗的方案)、作业处理日志以及作业依赖关系。
二.3.8 ETL模块设计
XX银行的ETL采用数据库的存储过程及Shell脚本等技术支持，可以按照如下模块设计：
⏹调度模块：负责任务的管理、调度和分发，作业依赖关系的管理；
⏹作业控制：负责计算资源的分配、作业的执行，控制作业执行的流程、跟踪作业执行的结果、记录作业的日志。
⏹数据库模块：管理类数据库：用于调度和作业主控，保存任务和作业的相关配置信息和运行信息。应用类数据库：用于具体应用的业务数据库。
⏹ETL域：ETL架构中基本的计算资源组合，是一个计算机群，由JCI统一管理和控制，一个ETL域由一个ETL Server和多个ETL Client组成。
⏹ETL应用：应用部署和配置管理的基本单位，一个ETL应用包含一组相关的作业单元、作业配置参数和应用环境参数。
⏹物理作业：具体负责数据加工的程序执行单元，各类存储过程或者作业脚本(SHELL脚本、用C/C++/PROC等开发的可执行程序）。
ETL模块可以划分为任务调度、任务控制、任务执行。任务调度模块
在EDWH+EDWB统一模块中，调度是由部署在总行的调度SERVER统一完成调度工作,或者由部署在分行的调度Server完成本分行作业的调度。调度SERVER根据各个JOB的运行时间和依赖关系，按照一定的调度策略对总分行的JOB进行统一调度。在实际部署中，调度模块可以仅部署在总行，实施统一调度，也可能部署在分行，实施分布调度；而在每个ETL域的ETL Server上部署调度的Agent模块，调度Server负责任务的检索、调度和分发，调度Agent接收到调度Server的调度指令，调用作业主控模块(JCI)执行具体的作业，并根据JCI的退出码将作业的执行情况反馈给调度Server。
⏹任务控制模块
统一架构中的处理模块是由一个或多个ETL域组成的。总行有一个或多个总行的ETL域，分行有本分行的ETL域。域与域在物理上是分开，但是在逻辑上是联系在一起的。对于不同的域，它们的处理任务也是不一样的。
每个处理域由一个或多个ETL SERVER 和若干个ETL CLIENT 组成。
ETL SERVER主要负责ETL JOB的具体执行。首先，ETL SERVER接收调度Agent发过来的要执行的作业的作业ID，根据该作业ID到管理库中获取该作业的运行参数并解释所有参数。其次根据作业运行资源需求，获取所属ETL CLIENT的资源情况，选择最优的若干台ETL CLIENT，分配作业给这些ETL CLIENT运行。最后收集并记录作业运行日志信息，释放ETL CLIENT的资源，更新作业运行状态，返回作业运行结果信息给调度Agent。
ETL CLIENT 主要负责ETL SERVER 分配的作业模块的具体执行，是作业的具体执行者。
ETL统一架构中的ETL域并不是一成不变的，理论上具有无限的横向扩展能力。它可以根据本域上的作业情况增减ETL CLIENT。
如果作业的数目太多，ETL SERVER承担的任务过重，则可以增加ETL SERVER来降低原有的ETL SERVER任务的压力。
如果实际运行JOB的ETL CLIENT资源不足，经常处于高负荷状态，则可以通过增加ETL CLIENT来提高运行效率。
ETL Server访问管理库，ETL Client只访问应用库，不允许访问管理库。
⏹数据库模块
统一架构中的数据库模块分为两个部分：管理类数据库和业务类数据库。业务类数据库存放的是ETL作业处理的业务数据。管理类数据库存放的是作业运行控制相关的数据信息，如系统配置参数或作业配置信息、状态信息和运行日志信息等。
在统一架构中，数据库模块分为两层，一层是总行层，另外一层是分行层。无论是总行还是分行，数据库都是由管理类数据库和业务类数据库组成。
在管理库的具体部署时，可能只部署在总行，所有ETL Server都访问这个管理库，分行的ETL Server通过跨越广域网的数据库连接访问管理库。管理库的信息分为三类：
⏹系统参数和作业配置信息：静态参数；
⏹状态信息： 属于控制类的动态信息；
⏹日志信息；
二.3.9 ETL流程设计
系统ETL设计流程如下图：
本系统ETL处理流程顺序概要描述如下：
1.调度程序在总行的调度服务器上面运行，当调度程序发现某个作业符合调度条件，就对其进行调度，将该JOB的ID发给该JOB所在域的ETL SERVER。
2.ETL SERVER 得到调度的调度指令后，根据JOB ID，先到所在域中的管理类数据库中JOB实例表中查找该JOB，判断该JOB的状态是否正确，查找该JOB的前序JOB是否完成，然后在JOB参数表中查找该JOB对应的各种参数，为作业的运行解析和准备参数，同时到所在域的业务类数据库中查找各种输入文件是否存在，如果条件都满足，则JOB可以运行。
3.3．ETL SERVER对JOB的类型进行判断，如果是普通的SHELL JOB或者EXEC JOB，则根据JOB实例表中的NODES_LIST(该作业可使用的节点列表)，计划在本域中分配一个ETL CLIENT给JOB运行，如果是DS JOB，则根据JOB实例表中的NODES_NEED(运行该作业所需节点数)和NODES_LIST(该作业可使用的节点列表)得到该JOB运行所需的结点个数以及所能够运行该JOB的结点列表。
4.在每个ETL CLIENT上都安装着用于获取结点资源情况的RESOURCE AGENT，这些AGENT每隔一定的时间间隔，就会将本台CLIENT上的系统资源使用情况，如：CPU使用率，MEMORY使用率，I/O等待情况等写入所属域的管理类数据库中的结点使用情况表中。
5.ETL SERVER 在得到JOB运行的结点个数和能够运行该JOB的结点列表后，根据本域的管理类数据库中结点的使用情况表，按照一定的策略对能够运行该JOB的结点列表进行排序，选出最优的若干个ETL CLIENT。然后根据结点情况，动态生成JOB运行配置文件。然后根据运行配置文件，将JOB分配给各个ETL CLIENT执行。
6.ETL CLIENT开始执行JOB，无论JOB运行成功还是失败，都将各种运行信息反馈给所属域的ETL SERVER。
7.ETL SERVER 得到ETL CLIENT的反馈信息后，将其写入日志，并设置JOB的状态，同时释放结点的资源。
8.ETL SERVER将作业运行的情况通过退出码的方式反馈给调度程序。
二.3.10 动态资源分配
上图为本系统的动态资源采集模块的逻辑结构图，其目的是实时采集整个ETL域中各节点的系统资源使用情况，以及检测节点运行状态是否正常，以作为动态资源分配的主要依据。
Resource Agent：运行于域中所有节点(包括主节点)之上的一个守护进程，负责按照一定的时间间隔采集当前节点的各种系统资源(CPU使用情况，内存使用情况)使用情况，磁盘I/O使用情况，是否存在故障），并通过TCP/IP和运行于主节点上的Resource Broker进程进行通信，将当前节点的系统资源使用情况汇报给ETL Server；
Resource Broker：运行于域中ETL Server之上的一个守护进程，负责j接收来自域内节点的连接请求，记录请求节点的系统资源使用情况；如果域中某个节点超过指定的时间间隔没有发送资源报告，则将该节点置为故障，该节点将不会被分配来运行任务，如果此后收到该节点的资源报告请求，则将该节点状态置为活动。
客户端与服务端采用C/S通信模式，通过TCP协议传送信息，这样做的好处是：
◆避免工作节点直接访问管理库，访问管理库的工作统一ETL Server来完成，从而提高了应用部署的适应能力；
◆ETL Server可以据此检测所有工作节点是否存在故障；
客户端负责采集信息发送到服务端，服务端接收信息，并写到数据库。对于每个客户端的连接，服务端fork出一个子进程处理。服务端与客户端作为daemon进程，要求能够长时间运行。应该能接受收 SIGQUIT, SIGTERM, SIGHUP 信号，完成退出并清理进程资源;
在EDW中，将由成千上万的作业来完成数据整和的功能，这些作业由于复杂度不同，运行频度不同，甚至是同一个作业，由于数据来源不同(例如不同的分行)，数据规模也是相差甚远的，因此如果对所有的作业使用相同的配置文件，将对系统资源造成极大的浪费，例如一个非常简单的作业，事实只需要几秒钟的时间，却将其部署到多个节点上运行，不仅没必要，而且造成额外的网络开销和调度开销。
因此为了提高作业运行的性能，充分使用计算机群中所有节点的资源，必须采用一种合理的作业运行资源配置方案，在这种方案中，将根据作业的复杂度，数据规模，运行频度、约束条件等因素，动态地生成运行资源配置配置文件，从而使系统中的每个作业能以最优的方案运行，从而使整个系统获得最优的性能。
二.3.11 数据接口设计
数据仓库平台系统需要建立一个集成的ETL接口平台，该平台需要同时支持：打包数据文件和数据库直连两种ETL方式。各种ETL方式的通过ETL工具进行统一配置和管理，不同的接口方式由相应的接口适配器（Input Adapter）来处理，接口适配器仅处理数据/文件物理格式的转换，并不负责业务要素层面的转换，接口适配器一旦调试通过后，将不随业务元素变化（例如表字段改变）而变化。
数据接口规范用来规范本系统和各源业务系统以及本系统内部之间数据交换，使数据交换遵循一个统一的标准。由于各业务系统之间的数据标准不尽一致，因此在制订与不同业务系统的数据接口规范时，必须要涵盖如下内容：
数据内容
分析确定需要的数据表，以及表中的每个数据项，包括数据项的长度、类型等，明确数据表项之间相互的关系。
数据格式
根据接口文件类型指定文件格式，如文本文件，需描述字段变长分隔符分隔，字符数据项、日期数据项格式等。
编码格式
文件内容的编码格式，如ASCII码、EBCDIC码等，确定数据交换文件的解析规范或语义。
编码规范
说明业务系统相关的业务编码，和本系统保持统一的标准。如业务种类、网点机构的机构代码等，必须遵守统一的命名规范。
数据来源
数据表项来自的业务系统。数据表项和业务系统数据表项的对应关系。
数据统计算法
对于各业务指标的计算方法必须有统一的公式，并且其组成要素的业务涵义必须统一。
外部数据接口标准
对于来自外部的数据，须经过系统预处理转换成符合标准接口的文件。
数据接口规范主要用来明确源业务系统与本系统之间以及本系统内部数据文件交换的控制和要求。规范要涵盖的内容及对数据文件交换的要求如下：
命名规范
数据接口文件的命名、数据文件交换存放的路径名、文件流水格式的约定等。包括了所有在数据交换过程中涉及到命名规则、以及各种格式的约定。
抽取周期
明确本系统和各个源业务系统之间数据抽取的频次，如每日、每周、每月、不定期等。对本系统和所有源业务系统之间的数据交换做统一安排，避免不同业务系统之间出现冲突。
过程监控
对数据文件的交换情况进行记录，监控和每个源业务系统数据文件的交换情况。下载本文
