1、ETL设计说明书Error! Reference source not found.Author: Zhang JianCustomer: *目录1. 概述 52. ETL开发策略 73. ETL系统架构设计 .83.1 ETL整体框架 83.2 ETL系统逻辑架构 .83.2.1 ETL系统的备份和恢复 .94. ETL应用框架设计 .104.1 ETL应用架构逻辑图 104.2 ETL模式 114.3 数据抽取(Extract)和数据变换(Convert) 114.3.1 数据抽取（Extract） .114.3.2 数据变换（Convert） 114.3.3 数据分割（Split） 12
2、4.4 数据转换(Transform) 124.4.1 字段合并与拆分 .124.4.2 赋缺省值 124.4.3 数据排序（Sort） 124.4.4 数据翻译(Lookup) 124.4.5 数据合并(Merge) .134.4.6 数据聚合(Aggregate) .134.4.7 文件比较(File Compare)134.4.8 其他复杂计算 .134.5 数据加载(Load) .134.5.1 Pre-Load .134.5.2 Load 134.5.3 Post-Load144.6 ETL进程和进程调度 144.7 管理功能（Management Interface） 144.8
3、初始数据、历史数据和日常数据ETL 155. 开发规范 165.1 中间文件 .165.2 临时文件 .165.3 BAPI参数文件 .175.4 ETL程序 175.4.1 DataStage Project命名 175.4.2 DataStage中Job命名 .175.4.3 DataStage中Stage 命名 .185.4.4 DataStage中Link命名 195.4.5 DataStage中Routine命名 195.4.6 DataStage产生的Abap程序命名 195.4.7 DataStage中Table Definition命名 .205.4.8 Store proce
4、dure程序命名 215.5 Reject文件 215.6 系统日志 .215.7 ODBC .225.8 版本控制 .225.8.1 ABAP程序及BAPI程序 225.8.2 DataStage Job及Routine 225.8.3 Store Procedure程序 .225.8.4 文档 .225.9 ETL Job开发方法规范 235.9.1 TableDefinition的使用原则 235.9.2 Extract Job的开发原则 235.9.3 CS Job的开发原则 245.9.4 Load Job的开发原则 .245.9.5 Gc和Ge Job的开发原则 255.9.6 关
5、于存储过程及BAPI .266. 系统环境 276.1 开发、测试和运行环境规划 276.2 文件目录 .276.3 DataStage Manager目录层级规划 287. ETL应用设计 307.1 应用模块架构 307.1.1 DataStage Server307.1.2 DataBase Server.317.2 ETL Job设计 .317.2.1 Schedule Job 317.2.2 Dependence Job .367.2.3 Maintance Job.367.2.4 Group Job .387.2.5 Component Job.407.3 ETL环境参数 427.
6、3.1 JobParams.cfg文件格式 427.3.2 参数说明 427.4 公共Routine设计 .437.4.1 Transform Routine 437.4.2 Before/After SubRoutine .477.5 初始ETL程序 488. ETL开发流程及管理 .498.1 开发环境准备 498.2 开发步骤 .498.2.1 日常数据加载： .498.2.2 初始数据加载： .498.2.3 历史数据加载： .498.3 角色及责任 .509. ETL质量控制及错误处理 529.1 ETL质量控制主要实现手段 .529.2 拒绝文件及拒绝处理策略 529.3 已入库源
7、数据发生错误的应对策略 .52附录 I. ETL Mapping文件文档模板 54附录 II. ETL Data Flow文档模板 55附录 III. ETL Job Dependency文档模板 .561. 概述ETL系统的核心功能就是按照本设计说明书的架构，将数据由数据源系统加载到数据仓库中。其实现的困难在于ETL 系统将面临复杂的源数据环境，包括多种多样的数据源平台、繁多的数据种类、巨大的加载数据量、错综复杂的数据关系和参差不齐的数据质量，这些都使ETL的架构和应用设计面临相当的挑战。通过高效的ETL系统结构、层次化的应用功能划分和标准的程序模板，ETL系统和应用架构设计需要能够达到以下
8、目标： 支持在此框架下实现中心数据库所需要的 ETL 功能； 支持在规定的批处理时间窗口（Batch Window）内能够完成数据加载工作，即需要满足日常数据加载的性能需求； 能够支持有效的应用程序开发模式，提高开发效率，尽量减少应用开发成本； 减少系统维护的复杂性，支持后续增加新数据或功能的开发工作。ETL设计说明书为ETL 开发提供指导，着重叙述数据仓库系统ETL系统的架构、功能和实施模板，但未包含针对数据仓库中每个具体数据表的ETL详细设计，由开发人员根据ETL数据对照中所规定的ETL规则，按照ETL设计的应用开发流程和规范，参照模板程序，实现每一个ETL应用程序。再通过DataStag
9、e的作业调度功能依据JOB依赖关系说明书将所有ETL应用程序有机地联系起来，完成复杂的数据ETL过程。ETL过程依赖于源数据的准备就绪，本设计说明书并未详细设计具体源数据准备的控制流程，根据项目的实际情况，对于源数据准备就绪的接口设计将体现在单独的文档ETL源数据就绪接口设计说明书中。同时，本设计说明书不包括有关ETL投产运行过程的环境说明、管理方法、流程的说明，这部分的内容将包括在投产准备阶段相应的规范和文档中。由于ETL的复杂性，本设计尝试从多个层面进行说明，希望能够尽可能回答开发过程中所面临的问题达到指导开发的目的，但实际开发过程中，开发人员仍然可能遇到设计说明书没有涉及的问题，因此，遵
10、循设计的基本思想，通过开发人员的反馈，在开发的过程中不断地完善和修正设计，对于ETL的开发是非常重要的。对于任何ETL开发过程中遇到的技术问题，开发人员需要与设计人员协商讨论，以迅速解决问题，保证开发顺利进行。而同时，为保证ETL系统架构的完整、统一、程序的可维护性以及开发的可管理性，对设计的修改必须得到控制，重要的变动必须通过版本管理流程来协调进行。本设计说明书将包括以下部分：1 设计策略：简要叙述本项目 ETL 开发中包括实现方法、技术选择、工具和平台选择等方面策略性的思路。2 架构设计：设计 ETL 整个应用的架构。包括逻辑架构和物理架构。3 应用框架：按照架构设计，确定 ETL 应用的
11、基本架构，以及每个步骤的高层设计思想，提出程序开发的模式，作为应用程序设计的指导。4 开发规范：定义开发过程中需要遵循的开发标准，如程序和文件的命名规范、文件结构、版本控制等等。5 系统环境：规范 ETL 开发、测试及生产环境6 应用设计：参照流程设计和数据对照表，设计每个任务的具体实现，作为开发的基础。在程序设计中包括任务中每个步骤的命名、功能、输入和输出数据、运行条件和参数、需要使用的中间数据的数据结构、存储格式和存储位置。7 ETL 开发流程及管理：规范 ETL 开发的步骤及管理方法8 ETL 质量控制及错误处理：具体说明如何保证入库数据质量的主要方法及手段9 附录提供了 ETL 开发过
12、程中需要产生的相关文档的模板，通过 ETL 的实施，这些模板需要根据项目的实际状况同步完成本设计方案基于以下前提：1 预计每日数据处理量不超过1G，运行效率的要求不高，因此本项目完全采用ETL工具DataStage开发实现ETL过程，本设计完全基于DataStage进行ETL 设计2 由于源系统为同步发开的新系统，新系统并不提供历史数据，对于历史数据的加载将先将数据导入源系统，再从源系统进行ETL加载，以保证ETL接口的统一2. ETL开发策略 由于Data Warehouse 中存储基础数据，需要采用的数据转换比较简单，ETL程序开发效率是开发中需要解决的主要矛盾，因此，为提高开发效率，将完
13、全采用工具来开发ETL程序。 在ETL过程中中间数据文件采用文本文件，为提高运行速度，可以先临时转换成HASH文件再进行Refrence的处理。 对所有数据仓库表，在ETL过程中暂不建立索引，未来是否需要对实际数据仓库建立索引，将根据ETL Batch Windows和ETL 系统性能，再行决定。 因为初始数据和历史数据加载是一次性执行，所以初始数据和历史数据的加载主要采用手工方式进行，暂时不需要复杂的工作调度程序。不实现全自动的初始数据ETL。 对不同的数据表的每个ETL步骤都有一个独立的任务。不同任务可以是使用不同参数的同一个程序，如数据加载程序。同一类型的程序，如抽取，转换，加载，等等，
14、尽量采用相同的程序结构，减少设计复杂度。 数据仓库的加载和数据集市的加载将采用相同的ETL架构实现。差别在于数据集市的数据源就是数据仓库本身。加载数据仓库的中间文件(CIF)同时也可作为计算相应数据集市的事实表的基础，以提高数据共享，加快处理速度。 所有ETL程序的实现结构上力求单纯统一，例如，所有Load Job在处理数据入库的时候采用统一的Stage加载。3. ETL系统架构设计3.1 ETL整体框架本章从宏观体系结构的高度，概要叙述ETL系统的基本架构和设计思想，着重于描述架构的特点、系统主要组成、ETL 各个部分的基本功能和它们之间的关系以及方案选择的出发点。ETL系统需要能够在限定的
15、时间内完成对日常数据的周期性的自动加载流程，支持对初始数据及历史数据的加载，并满足未来扩充的要求。数据仓库系统的数十个目标数据表和相应数量的数据源意味着ETL程序的复杂性，庞大的数据量则需要充分考虑系统运行的效率，为开发复杂的程序，就要求灵活而简单明了的程序结构，而程序的效率要求的优化又往往需要针对不同数据的个性化设计，因此，ETL的设计必须在开发的可管理性和程序性能之间平衡，有些实现复杂、个性化突出的做法就要让位于要求一致的程序结构。这样的平衡是本设计中很重要的一个考虑因素。在基于此设计思路的ETL架构下，每个数据表的ETL过程按照ETL的特性统一为3个标准步骤，即数据抽取/ 变换 (Ext
16、ract/Convert)、数据转换(Transform)和数据加载（ Load），所有数据的ETL 都被纳入到这个标准框架中，因此，所有需开发的ETL程序的流程也就被对应分为3个主要的步骤, 每个步骤需要记录完整的处理中间状态及完善的日志信息，对于程序员来说明，遵循统一的架构开发可以保证所有开发的程序的结构一致性，便于程序的管理，同时对于开发和测试人员来说，根据不同步骤的中间状态记录及日志信息很容易定位及修正程序的bug。3.2 ETL系统逻辑架构E T LD A T A W A R E H O U S ES A P R / 3A B A PA B A PS A P A P OA B A P
17、A B A PD M SF l e xE xE xC VC VC VC VC VC VC VC VT RT RT RT RT RL O A DL O A DL O A DL O A DL O A DL O A DT RT RL O A DE xE xT R L O A DC o n v e r tT r a n s f o r mC I FE X F P L FS G M R e p o r t C e n t e r E T L L o g i c A r c h i t e c t u r eE xE xE xE xE xE xE x t r a c tC VC VD A T A M a
18、r tD A T A M a r tE T LA g g r e g a t i o nA g g r e g a t i o nA g g r e g a t i o nA g g r e g a t i o n上图是ETL系统逻辑架构。从宏观设计上，历史数据、初始数据加载和日常数据加载的ETL都将按照此架构设计。该架构将ETL作为一个整体来设计。对于数据仓库的加载，ETL分为数据抽取（Extract）、数据变换（Convert ）、数据转换（Transform）以及数据加载（Load）4个阶段。每个阶段之间以文本文件作为接口，即数据抽取（Extract）阶段读取数据源产生EXF文件，CSS
19、 （Converting/Sort/Split）阶段读取EXF文件产生CIF文件，数据转换（Transform）阶段读取CIF文件产生PLF文件，数据加载（Load）阶段读取PLF文件加载到数据仓库。此架构将数据抽取、转换和加载分隔开，以CIF（Common Interface Format）作为数据仓库表和数据源之间的桥梁，从而使每个功能相对独立，减少各功能相互间的耦合度，同时，每个模块的功能被细分后，逻辑更加简单，更容易控制开发错误，提高开发效率。另外，也便于系统运行过程中的错误追综和异常恢复。对于数据集市的加载，由于数据质量已经得到保证，ETL过程不再分割，一个目标集市表直接对应一个ET
20、L Job完成从数据仓库表通过Aggregation加载到数据集市，由于从数据仓库到数据集市的加载相对简单，因此本设计说明书着重于从数据源到数据仓库的加载过程。3.2.1 ETL系统的备份和恢复ETL系统的备份包括两个部分，即ETL运行环境备份及数据库的备份。运行备份是指为保证如果运行的ETL系统崩溃时可以通过备份的ETL系统继续完成ETL的工作，为达到这个目的，应安装两台DataStage环境，并建立相同的配置，其中一台处于运行状态，而另一台为待机状态。每日在日常ETL完成后对运行环境的各文件进行备份，即将ETL的运行目录( 本项目中为E:*ETL)转储到外挂磁盘或外部存储介质。而数据库的数
21、据备份对于ETL非常重要，建议系统管理员每日做数据的完全备份，即采用Oracle的Export命令对数据仓库的Schema做完全的备份，每天保留一个备份文件，建议至少保留7天。ETL系统的恢复相应也包括两个部分，即运行恢复及数据恢复运行恢复是指当运行系统遇到严重故障如硬件故障、操作系统崩溃等无法及时修复时，启用备份的运行系统继续，通过将上一日备份的ETL环境恢复到待机系统，然后启动待机系统运行日常ETL。数据库恢复通常两种情况下会用到，一种是数据库系统本身出了故障需要重新安装，这时需要将上一日备份的数据恢复到新的数据库环境中。还有一种是数据加载过程中发现几天以前加载了某些有问题的数据，需要从之
22、前某一天开始重新加载修正后的数据，这时需要将指定日的备份重新恢复到数据仓库中，然后顺序运行每日的日常ETL4. ETL应用框架设计4.1 ETL应用架构逻辑图E T L S e r v e rE T L A p p l i c a t i o n A r c h i t e c t u r eA r c h i t e c t u r e C o n t r o lE T L A r c h i t e c t u r e C o n t r o l F i l e s & T a b l eT r a n s f o r m S T A G EE X T R A C T S T A G EP
23、 L FC I FF i l e sE X Fe x tf i l e s变 换 、 排序 和 分 割C S S转 换T r a n s f o r m抽 取E x t r a c te x tf i l e se x tf i l e sE X Te x tf i l e se x tf i l e se x tf i l e sC I FW r i t eR e a dW r i t eR e a dW r i t ee x tf i l e se x tf i l e se x tf i l e sP L F- U P De x tf i l e se x tf i l e se x t
24、f i l e sP L F- I N SW r i t ee x tf i l e se x tf i l e se x tf i l e sm s gf i l e sL O A D S T A G EC D WD e t a i lF a c tD i m e n s i on加 载L o a d预 加载P r e -L o a d后 加 载P o s t -L o a de x tf i l e se x tf i l e se x tf i l e ss y s ou t f i l ese x tf i l e se x tf i l e se x tf i l e sl o a
25、dl o g se x tf i l e se x tf i l e se x tf i l e sR e j ec t f i l esA r c h i t e c t ur e T a b l e处 理 状 态 平 衡 控 制 错 误 处 理作 业 调 度E T L 作 业R e a dR e a d管理调度应用功能控制环境运 行界 面上图是ETL应用程序的架构图，ETL架构从功能上被划分为三个层次： ETL作业及作业调度通过作业调度功能，管理员根据目标数据表的更新周期和源数据就绪时间，制定日常数据的ETL的时刻表。管理员通过DataStage的作业调度功能进行运行时刻设置，自动在规定条
26、件满足时启动相应的 ETL作业。每个目标数据表ETL过程对应一组顺序执行的Entity 作业（包括Transform JOB和Load JOB）形成的一个Sequence，每个CIF文件的ETL过程则对应一组顺序执行CIF作业(包括Extract JOB和CSS JOB)形成的一个Sequence。这些ETL作业将其中的每个步骤，即抽取、CSS、转换、加载等ETL功能模块有机地联系起来。而作业调度是将CIF逻辑的作业和Entity逻辑的作业按照 CIF与Entity 的对应关系联系起来，从而控制该ETL过程的运作。 ETL功能模块ETL功能模块层次中包含实现每个ETL步骤的程序，即上面所述的E
27、xtract、CSS 、TR 和LOAD程序(LOAD又分为PreLoad 、LOAD 、PostLoad)。每个模块实现一个特定的功能。各模块之间无任何调用关系，它们之间可能的关系仅仅是一个模块的输出文件是另一个模块需要读取和加工的文件。一个ETL功能模块就是一个DataStage Job，每个功能模块的逻辑都只是 ETL过程中一个相对独立的部分。 ETL控制环境ETL功能模块的运行需要由相应的参数进行控制，同时在各模块之间也存在很多控制文件及调用一些公共的功能，功能模块在运行过程中可能产生拒绝文件，针对功能模块的运行状况会有产生一些监控信息等等，这些对于ETL功能模块的运行起到控制与支撑的
28、环境以及相应的维护管理程序构成ETL架构环境。上两层构成ETL应用，而ETL 控制环境则为以上层次的每个应用程序提供支持，应用层次上独立的功能模块都通过更上一个层次的逻辑关系联系起来，使每个模块的功能更加清晰、明确。4.2 ETL模式根据模型的设计和源数据的情况，有四种数据ETL模式： 完全刷新（Refresh，Type 1）：数据仓库数据表中只包括最新的数据，每次加载均删除原有数据，然后完全加载最新的源数据。如大多数参数表的加载都采用这种模式。这种模式下，数据抽取程序抽取源数据中的所有记录，在加载前，将目标数据表清空，然后加载所有记录。为提高删除数据的速度，一般是采用Truncate清空数据
29、表而不采用SQL Delete进行删除。本项目中由于主要目标是实现Daily报表，因此大部分的表均为此种类型。如CO_DATE_MF表就是这种类型。 镜像增量（Snapshot Append，Type 2）：源数据中的记录定期更新，但记录中包括记录时间字段，源数据中保存了数据历史的记录，ETL可以通过记录时间将增量数据从源数据抽取出来以附加的方式加载到数据仓库中，数据的历史记录也会被保留在数据仓库中。目前项目中没有这种类型的数据。 事件增量（Event Append，Type 3）：每一个记录是一个新的事件，相互之间没有必然的联系，新记录不是对原有记录数值的变更，记录包括时间字段，可以通过时间
30、字段将新增数据抽取出来加载到数据库中。如CO_PO_HIST表就是这种类型 镜像比较（Snapshot Delta，Type 4）：数据仓库数据具有生效日期字段以保存数据的历史信息，而源数据不保留历史并且每天都可能被更新。因此，只能将新的镜像数据与上次加载的数据的镜像进行比较，找出变更部分（即Delta），更新历史数据被更新记录的生效终止日期，并添加变更后的数据。大多数源数据中需保存历史信息的维表。如CO_Plant_MF表就是这种类型。4.3 数据抽取(Extract)和数据变换(Convert)4.3.1 数据抽取（ Extract）数据抽取是从数据源获取所需数据的过程。数据抽取过程会过滤
31、掉数据仓库中不需要的源数据字段或数据记录。数据抽取可以采用PULL和PUSH两种方式。PUSH 就是指由源系统按照双方定义的数据格式，主动将符合要求的数据抽取出来，形成接口数据表或数据视图供ETL系统使用。PULL 则是由ETL程序直接访问数据源来获取数据的方式。为提高ETL效率，数据在进入ETL系统后，EXF 文件都将转换为Flat Text文件格式。整个ETL 过程中，除数据抽取外，都不使用效率较差的SQL方式进行数据处理。由于本项目ETL系统可以访问所有源系统，而日数据量不大，综合上面的分析，从ETL程序设计的灵活性、可控性和整体结构的一致性考虑，尽量采用Pull的方式，减少对源系统的影
32、响和对其他开发队伍的依赖，并减少网络压力。4.3.2 数据变换（ Convert）Convert的任务是逐条记录的检查数据，将每个字段转换为遵循数据仓库标准的数据格式，即对数据类型和数据格式进行转换，并对空字段赋予适当的缺省值，形成规整的数据结构，对于不符合要求的数据，写入拒绝文件（Reject文件）中。数据变换主要的工作有： 格式变换，如所有日期格式统一为 yyyy-mm-dd； 赋缺省值，在数据仓库中定义取值不为空的字段在源数据对应的字段可能存在没有取值的记录，这时根据业务需要，可能有两种处理办法，一是将该记录写入到 Reject 文件中，由业务部门根据Reject 文件检查并修补源数据，
33、另一种是在 Convert 阶段直接赋一个缺省值； 类型变换, 如将源系统的 Number 类型转为 vahar2 类型等 长度变换, 如将源系统中定义的 vahar2(10)转为 vahar2(20)等 代码转换，如源系统的某些字段经过代码升级以后，将老的代码转为新的代码等。 数值转换，如数值单位由万元转为元等。4.3.3 数据分割（ Split）同一个数据源表的数据可能被多个数据仓库表使用，这就需要将一个数据源按不同的条件通过Extract和Convert过程分成多个CIF文件以对应于不同的目标表的转换加载。正如前面所讨论的，由于系统的数据量并不大，性能并不是第一考虑的指标，而本设计更着重
34、于系统架构的统一性及完整性，因此为了使架构更加单一，对于按条件分割的情况将在Extract的步骤完成，即按不同的条件分别抽取为不同的EXF，然后再由不同的Convert 程序变换为各自对应的CIF，而对于需要排序分割的情况，则在Transform时处理，在真正开始Transform之前先将CIF排序为新的临时的CIF文件。4.4 数据转换(Transform)数据转换（Transform）是按照目标表的数据结构，对一个或多个源数据的字段进行翻译、匹配、聚合等操作得到目标数据的字段。数据转换主要包括格式和字段合并与拆分、数据翻译、数据匹配、数据聚合以及其他复杂计算等。4.4.1 字段合并与拆分字
35、段合并是指源数据的多个字段合并为目标数据的一个字段。字段拆分是指将源数据中一个表的一个字段拆分为目标数据的多个字段。4.4.2 赋缺省值对于数据仓库中有的字段，在源系统中并没有相对应的源字段，这时根据模型的设计，可能需要缺省赋一个值4.4.3 数据排序（ Sort）TR程序有时需要对于两个或多个CIF文件merge，在merge之前需要将CIF文件按所要求的key排好序，这样可以加快merge的速度，排序的过程在Transform之前进行。在DataStage中提供了排序的Stage 功能，一般在CS JOB的最后调用该 Stage，但Stage的性能并不特别高，如果对于性能有进一步的要求，可
36、以采用第三方如CoSort等工具软件。4.4.4 数据翻译 (Lookup)将源系统中一些表示状态、类型等的代码直接翻译为其所表达的意思，或反之。数据翻译需要用到参考表（Reference Table），数据参考表一般是字典表或根据源数据与目标数据的定义手工产生，如果数据翻译时在参考表中找不到对应的对照，根据业务规则，需要将对应的记录Reject出来或赋缺省值。4.4.5 数据合并 (Merge)按一定条件（一般是key值相等）对数据进行合并，找出描述同一对象的分布在不同数据表中的记录，并把这些记录联系起来。数据合并其实是数据翻译的一种特殊情况，主要用于数据量特别大的情况，数据合并在实现方式上
37、一般先对要合并的两个表分别排序(Sort)，然后顺序对两个表的记录进行匹配合并，这样可以大大加快处理的速度。4.4.6 数据聚合 (Aggregate)对数据按照不同分组进行汇总等统计计算，一般是用于汇总表的计算，主要的聚合种类有： 求和 求平均值 求记录数 求最小值 求最大值 取第一行 取最后一行原则上，ETL只处理规律而重复性大的数据聚合，如汇总、取平均值、找最大最小值等，而不用于复杂计算，以减少开发成本和系统负载。对于不规律而且复杂的计算，应该由源系统端将数据计算好。4.4.7 文件比较 (File Compare)对应于四种ETL模式，数据转换为PLF文件后需要进行不同的处理，在Typ
38、e1、Type2和Type3模式下，PLF可以直接由数据加载过程加载到数据仓库中，而Type4则由于存在有效日期，需要将当日的snapshot数据与历史数据镜像进行比较，找出需要添加和需要更新的记录，然后产生真正可以向数据库加载的PLF文件，再由数据加载过程将PLF文件加载到数据仓库中。4.4.8 其他复杂计算在数据仓库中定义的某些字段需要按照业务规则进行复杂计算才能得到，主要有两类： 主要针对一些在数据源中找不到直接对应的字段，需要在ETL过程中通过相关字段计算才能得出的字段。 原则上复杂的计算并不在ETL中完成，对于一定需要由ETL来完成的复杂计算字段，采取在ETL加载时该字段先留空，在加
39、载完成以后调用的存储过程来计算，但为了管理与调度的统一，可以在DataStage中调用存储过程以统一调度。4.5 数据加载(Load) 经过数据转换生成的PLF文件的结构与数据仓库数据表的结构完全一致，可以直接通过数据加载工具，以Bulk Load的方式加载到数据仓库中。数据加载工作将分为3步进行。4.5.1 Pre-Load在真正进行数据加载之前还可能需要完成以下准备工作： 删除数据仓库中数据表的索引，提高加载效率。主要是针对detail及fact大表，可以直接调用DBA所创建的索引维护脚本。DBA调试过数据仓库后，必须更新相应的索引维护脚本，以保证ETL能够正确删除和建立索引。4.5.2
40、LoadLoad主要完成将PLF文件的数据加载到数据仓库的表中，需要用到的加载方式有三种： Insert：只需要将PLF文件所有数据完全Insert到目标表中。 UpdAdd：需要对目标表同时做Update及Insert操作，根据primary key，对于已有的记录进行Update操作，对于不存在的记录做Insert的操作，对于数据量大的表，由于此操作的效率非常低，可以采用先将PLF文件分割为Delet文件及Insert文件，然后先将Delete文件中的记录根据primay key对应从数据仓库中删除，然后再从Insert文件中将所有记录全部Insert到目标表中。 Refresh：即将目标
41、表的数据完全更新，一般的做法是先Truncate目标表的数据，然后再完全Insert要加载的记录加载过程中，数据仓库关闭数据RI（Referential Integrity）管理功能，数据库的RI检查由ETL应用程序完成。4.5.3 Post-Load 重新生成索引：在pre-load阶段删除的索引需在此重建，该过程也是调用DBA维护的索引维护脚本。 文件清理：删除不需要的临时文件及临时表。4.6 ETL进程和进程调度进程调度的功能比较单纯，就是在规定的时刻启动程序，并记录系统运行情况和运行结果。不同数据表的更新周期不同，因此，进程调度需要能够支持日周月等多种不同的启动周期，并通过设定启动时间
42、来确定每个任务在何时启动运行。只有日常数据加载才需要考虑进程调度的问题。而对于初始数据及历史数据的加载，由于是一次性的工作，将采取手工启动加载的方式，所以无需制定对初始数据及历史数据加载制度化的进程调度。在ETL程序的抽取过程运行之前一定要保证其抽取的源数据已经准备就绪，本项目关于源数据准备就绪的接口采用数据就绪标识及时间约定相结合的方式，即源系统部门在源数据准备就绪以后向就绪接口表中写入就绪标识，而ETL Job从约定的时间开始不断检查该该标识，直到判断该标识已经就绪，将启动正常的ETL Job开始运行。4.7 管理功能（Management Interface）本系统使用DataStage
43、作为ETL运行及管理工具，DataStage已经提供了比较友好的管理界面供用户可以用来监控系统的运行状况通过DataStage Director工具，可以完成以下管理及运行功能： 查看 ETL Job 运行结果，如 finished, finished with waring, abort 等； 控制 ETL Job 的运行，如启动或停止 Job 等； 查看 ETL Job 运行日志； 实时监控 ETL Job 的运行状态通过DataStage SAP Administrator，可以配置SAP 的连接参数通过DataStage Administrator，可以设置ETL Job的运行选项，如
44、自动删除过时的Job日志的选项、运行人员授权等但依然有部分管理功能无法由DataStage直接提供，需要通过开发来完成，但所有的开发都使用DataStage Job的形式，这样有利于在DataStage中统一进行管理，主要开发的管理功能应包括： 参数设置，通过参数设置 Job SetParam 设置 ETL 运行的参数，实际上也就是通过界面实现对于参数文件 JobParams.cfg 的维护； Job 运行情况的 Email 通知，主要用于每日指定的时间检查当日的 Job 运行状况并通过 Email 的形式将检查结果发送给运行维护人员4.8 初始数据、历史数据和日常数据ETL初始数据加载(In
45、itial Load)是指在系统正式运行之前，需要将当前完整企业数据视图一次性地加载到数据仓库中，作为数据仓库的基础数据。历史数据加载(History Load)是指将历史一定时间段的数据( 主要是细节数据)加载到数据仓库，对于ETL的历史加载，需要SAP系统将原有历史数据导入SAP以后，ETL 再统一从SAP 的接口中加载历史数据。日常数据加载(Incremental Load)是指周期性地将该周期内的增量数据加载到数据仓库数据库中。针对初始数据加载、历史数据加载（Initial Load）和日常数据加载（ Incremental Load）的数据量、数据源和工作流程的不同，设计将采用不同的
46、ETL策略。对于日常数据加载，由于需要定期自动运行相关的程序，因此需要有支持scheduler的工具支持以满足自动运行的需要，数据源主要是业务系统针对数据仓库系统提供的接口表，程序逻辑的处理要求非常严格。对于初始数据加载，由于需要在上线日之前一次性完成，因此在上线日之前业务部门必须完成相关的数据清洗，从而保证初始数据加载的顺利完成，否则，将造成上线后数据仓库的数据质量不高。因为初始数据加载和历史数据加载都是一次性执行，所以主要采用手工和程序控制相结合的方式进行，不需要复杂的工作调度程序。程序逻辑的处理也不需要非常严格，如果其中涉及的逻辑非常复杂，也可以将源数据直接导出成数据文件，经业务部门对数
47、据进行确认或修正签字生效以后，将数据文件直接加载到数据仓库中，从而降低ETL开发的难度。与日常数据加载不同，历史数据加载可能按不同的时段需要从分散在不同的数据表中加载数据，并可能需要不同的数据转换逻辑，因此针对不历史数据时段需要单独开发不同的ETL程序。5. 开发规范ETL应用涉及大量的中间文件、程序和任务，因此需要制定相应的命名规范，以提高应用的可管理性和可读性。在本章中将采用如下方式表示命名规范： 加黑正体字母：在命名中直接采用该字母； 加黑斜体字母：表示固定采用所指定的名称列表中的。如 souesystemname 表示固定采用112、10000、bill、97、ecrm、eip 中的一
48、个。 斜体字母：可以用任意字符串代替的部分。如 souetablename 表示在实际开发中根据实际采用与源系统的数据表名称一致的命名。 ：里面的字符串为可选需要，即依赖于之前的字符串不同可能需要，也可能不需要。如 下划线：表示直接使用下划线符；5.1 中间文件格式：systemname_tablenamesequence.extname说明：systemname为源系统类型，其取值为Systemname 说明AUTO SAP R/3源系统APO SAP APO源系统DOL DOL系统(DMS系统一期)DW 数据仓库系统DMdatamartname 数据集市系统，datamartname为具体
49、数据集市的名称HW 手工数据Tablename为表名（源表或目标表）Sequence为文件顺序号，从1开始编号，只有当extname为EXF 或CIF 且需要对源数据表进行分割时才使用。extname为中间文件的类型，其取值为Extname 说明EXF EXF文件CIF CIF文件PLF PLF文件REF 参考文件中间文件的字段之间采用”|”分隔，文件名全命采用大写字母，中间文件的第一行为列名5.2 临时文件格式：souefile.Filetype sequence说明：souefile为源文件，产生本文件的源文件filetype为临时文件的类型，只有与中间文件的类型不同时使用，其取值为：Filetype 说明HSF Hash文件SRF SORT文件Sequence为文件顺序号，从1开始编号，只有当对同一文件产生的临时文件超过1 个才使用，。5.3 BAPI参数文件格式：method.PARAM说明：method为 BAPI程序的method5.4 ETL程序5.4.1 DataStage Project命名ETL开发、测试、生产统一采用*5.4.2 DataStage中 Job命名格式：EtltypeJobtypeSy
