-
未登录
热门文章
ETL设计说明书
目录
1. 概述
2. ETL开发策略
3. ETL系统架构设计
3.1 ETL整体框架
3.2 ETL系统逻辑架构
3.2.1 ETL系统的备份和恢复
4. ETL应用框架设计
4.1 ETL应用架构逻辑图
4.2 ETL模式
4.3 数据抽取(Extract)和数据变换(Convert)
4.3.1 数据抽取（Extract）
4.3.2 数据变换（Convert）
4.3.3 数据分割（Split）
4.4 数据转换(Transform)
4.4.1 字段合并与拆分
4.4.2 赋缺省值
4.4.3 数据排序（Sort）
4.4.4 数据翻译(Lookup)
4.4.5 数据合并(Merge)
4.4.6 数据聚合(Aggregate)
4.4.7 文件比较(File Compare)
4.4.8 其他复杂计算
4.5 数据加载(Load)
4.5.1 Pre-Load
4.5.2 Load
4.5.3 Post-Load
4.6 ETL进程和进程调度
4.7 管理功能（Management Interface）
4.8 初始数据、历史数据和日常数据ETL
5. 开发规范
5.1 中间文件
5.2 临时文件
5.3 BAPI参数文件
5.4 ETL程序
5.4.1 DataStage Project命名
5.4.2 DataStage中Job命名
5.4.3 DataStage中Stage命名
5.4.4 DataStage中Link命名
5.4.5 DataStage中Routine命名
5.4.6 DataStage产生的Abap程序命名
5.4.7 DataStage中Table Definition命名
5.4.8 Store procedure程序命名
5.5 Reject文件
5.6 系统日志
5.7 ODBC
5.8 版本控制
5.8.1 ABAP程序及BAPI程序
5.8.2 DataStage Job及Routine
5.8.3 Store Procedure程序
5.8.4 文档
5.9 ETL Job开发方法规范
5.9.1 TableDefinition的使用原则
5.9.2 Extract Job的开发原则
5.9.3 CS Job的开发原则
5.9.4 Load Job的开发原则
5.9.5 Gc和Ge Job的开发原则
5.9.6 关于存储过程及BAPI
6. 系统环境
6.1 开发、测试和运行环境规划
6.2 文件目录
6.3 DataStage Manager目录层级规划
7. ETL应用设计
7.1 应用模块架构
7.1.1 DataStage Server
7.1.2 DataBase Server
7.2 ETL Job设计
7.2.1 Schedule Job
7.2.2 Dependence Job
7.2.3 Maintance Job
7.2.4 Group Job
7.2.5 Component Job
7.3 ETL环境参数
7.3.1 JobParams.cfg文件格式
7.3.2 参数说明
7.4 公共Routine设计
7.4.1 Transform Routine
7.4.2 Before/After SubRoutine
7.5 初始ETL程序
8. ETL开发流程及管理
8.1 开发环境准备
8.2 开发步骤
8.2.1 日常数据加载：
8.2.2 初始数据加载：
8.2.3 历史数据加载：
8.3 角色及责任
9. ETL质量控制及错误处理
9.1 ETL质量控制主要实现手段
9.2 拒绝文件及拒绝处理策略
9.3 已入库源数据发生错误的应对策略
附录 I. ETL Mapping文件文档模板
附录 II. ETL Data Flow文档模板
附录 III. ETL Job Dependency文档模板
ETL系统的核心功能就是按照本设计说明书的架构，将数据由数据源系统加载到数据仓库中。其实现的困难在于ETL系统将面临复杂的源数据环境，包括多种多样的数据源平台、繁多的数据种类、巨大的加载数据量、错综复杂的数据关系和参差不齐的数据质量，这些都使ETL的架构和应用设计面临相当的挑战。
通过高效的ETL系统结构、层次化的应用功能划分和标准的程序模板，ETL系统和应用架构设计需要能够达到以下目标：
Ø 支持在此框架下实现中心数据库所需要的ETL功能；
Ø 支持在规定的批处理时间窗口（Batch Window）内能够完成数据加载工作，即需要满足日常数据加载的性能需求；
Ø 能够支持有效的应用程序开发模式，提高开发效率，尽量减少应用开发成本；
Ø 减少系统维护的复杂性，支持后续增加新数据或功能的开发工作。
ETL设计说明书为ETL开发提供指导，着重叙述数据仓库系统ETL系统的架构、功能和实施模板，但未包含针对数据仓库中每个具体数据表的ETL详细设计，由开发人员根据《ETL数据对照》中所规定的ETL规则，按照ETL设计的应用开发流程和规范，参照模板程序，实现每一个ETL应用程序。再通过DataStage的作业调度功能依据《JOB依赖关系说明书》将所有ETL应用程序有机地联系起来，完成复杂的数据ETL过程。
ETL过程依赖于源数据的准备就绪，本设计说明书并未详细设计具体源数据准备的控制流程，根据项目的实际情况，对于源数据准备就绪的接口设计将体现在单独的文档《ETL源数据就绪接口设计说明书》中。
同时，本设计说明书不包括有关ETL投产运行过程的环境说明、管理方法、流程的说明，这部分的内容将包括在投产准备阶段相应的规范和文档中。
由于ETL的复杂性，本设计尝试从多个层面进行说明，希望能够尽可能回答开发过程中所面临的问题达到指导开发的目的，但实际开发过程中，开发人员仍然可能遇到设计说明书没有涉及的问题，因此，遵循设计的基本思想，通过开发人员的反馈，在开发的过程中不断地完善和修正设计，对于ETL的开发是非常重要的。对于任何ETL开发过程中遇到的技术问题，开发人员需要与设计人员协商讨论，以迅速解决问题，保证开发顺利进行。
而同时，为保证ETL系统架构的完整、统一、程序的可维护性以及开发的可管理性，对设计的修改必须得到控制，重要的变动必须通过版本管理流程来协调进行。
本设计说明书将包括以下部分：
1． 设计策略：简要叙述本项目ETL开发中包括实现方法、技术选择、工具和平台选择等方面策略性的思路。
2． 架构设计：设计ETL整个应用的架构。包括逻辑架构和物理架构。
3． 应用框架：按照架构设计，确定ETL应用的基本架构，以及每个步骤的高层设计思想，提出程序开发的模式，作为应用程序设计的指导。
4． 开发规范：定义开发过程中需要遵循的开发标准，如程序和文件的命名规范、文件结构、版本控制等等。
5． 系统环境：规范ETL开发、测试及生产环境
6． 应用设计：参照流程设计和数据对照表，设计每个任务的具体实现，作为开发的基础。在程序设计中包括任务中每个步骤的命名、功能、输入和输出数据、运行条件和参数、需要使用的中间数据的数据结构、存储格式和存储位置。
7． ETL开发流程及管理：规范ETL开发的步骤及管理方法
8． ETL质量控制及错误处理：具体说明如何保证入库数据质量的主要方法及手段
9． 附录提供了ETL开发过程中需要产生的相关文档的模板，通过ETL的实施，这些模板需要根据项目的实际状况同步完成
本设计方案基于以下前提：
1． 预计每日数据处理量不超过1G，运行效率的要求不高，因此本项目完全采用ETL工具DataStage开发实现ETL过程，本设计完全基于DataStage进行ETL设计
2． 由于源系统为同步发开的新系统，新系统并不提供历史数据，对于历史数据的加载将先将数据导入源系统，再从源系统进行ETL加载，以保证ETL接口的统一
Ø 由于Data Warehouse 中存储基础数据，需要采用的数据转换比较简单，ETL程序开发效率是开发中需要解决的主要矛盾，因此，为提高开发效率，将完全采用工具来开发ETL程序。
Ø 在ETL过程中中间数据文件采用文本文件，为提高运行速度，可以先临时转换成HASH文件再进行Refrence的处理。
Ø 对所有数据仓库表，在ETL过程中暂不建立索引，未来是否需要对实际数据仓库建立索引，将根据ETL Batch Windows和ETL系统性能，再行决定。
Ø 因为初始数据和历史数据加载是一次性执行，所以初始数据和历史数据的加载主要采用手工方式进行，暂时不需要复杂的工作调度程序。不实现全自动的初始数据ETL。
Ø 对不同的数据表的每个ETL步骤都有一个独立的任务。不同任务可以是使用不同参数的同一个程序，如数据加载程序。同一类型的程序，如抽取，转换，加载，等等，尽量采用相同的程序结构，减少设计复杂度。
Ø 数据仓库的加载和数据集市的加载将采用相同的ETL架构实现。差别在于数据集市的数据源就是数据仓库本身。加载数据仓库的中间文件(CIF)同时也可作为计算相应数据集市的事实表的基础，以提高数据共享，加快处理速度。
Ø 所有ETL程序的实现结构上力求单纯统一，例如，所有Load Job在处理数据入库的时候采用统一的Stage加载。
本章从宏观体系结构的高度，概要叙述ETL系统的基本架构和设计思想，着重于描述架构的特点、系统主要组成、ETL各个部分的基本功能和它们之间的关系以及方案选择的出发点。
ETL系统需要能够在限定的时间内完成对日常数据的周期性的自动加载流程，支持对初始数据及历史数据的加载，并满足未来扩充的要求。数据仓库系统的数十个目标数据表和相应数量的数据源意味着ETL程序的复杂性，庞大的数据量则需要充分考虑系统运行的效率，为开发复杂的程序，就要求灵活而简单明了的程序结构，而程序的效率要求的优化又往往需要针对不同数据的个性化设计，因此，ETL的设计必须在开发的可管理性和程序性能之间平衡，有些实现复杂、个性化突出的做法就要让位于要求一致的程序结构。这样的平衡是本设计中很重要的一个考虑因素。
在基于此设计思路的ETL架构下，每个数据表的ETL过程按照ETL的特性统一为3个标准步骤，即数据抽取/变换 (Extract/Convert)、数据转换(Transform)和数据加载（Load），所有数据的ETL都被纳入到这个标准框架中，因此，所有需开发的ETL程序的流程也就被对应分为3个主要的步骤, 每个步骤需要记录完整的处理中间状态及完善的日志信息，对于程序员来说明，遵循统一的架构开发可以保证所有开发的程序的结构一致性，便于程序的管理，同时对于开发和测试人员来说，根据不同步骤的中间状态记录及日志信息很容易定位及修正程序的bug。
上图是ETL系统逻辑架构。从宏观设计上，历史数据、初始数据加载和日常数据加载的ETL都将按照此架构设计。该架构将ETL作为一个整体来设计。
对于数据仓库的加载，ETL分为数据抽取（Extract）、数据变换（Convert）、数据转换（Transform）以及数据加载（Load）4个阶段。每个阶段之间以文本文件作为接口，即数据抽取（Extract）阶段读取数据源产生EXF文件，CSS（Converting/Sort/Split）阶段读取EXF文件产生CIF文件，数据转换（Transform）阶段读取CIF文件产生PLF文件，数据加载（Load）阶段读取PLF文件加载到数据仓库。
此架构将数据抽取、转换和加载分隔开，以CIF（Common Interface Format）作为数据仓库表和数据源之间的桥梁，从而使每个功能相对独立，减少各功能相互间的耦合度，同时，每个模块的功能被细分后，逻辑更加简单，更容易控制开发错误，提高开发效率。另外，也便于系统运行过程中的错误追综和异常恢复。
对于数据集市的加载，由于数据质量已经得到保证，ETL过程不再分割，一个目标集市表直接对应一个ETL Job完成从数据仓库表通过Aggregation加载到数据集市，由于从数据仓库到数据集市的加载相对简单，因此本设计说明书着重于从数据源到数据仓库的加载过程。
ETL系统的备份包括两个部分，即ETL运行环境备份及数据库的备份。
运行备份是指为保证如果运行的ETL系统崩溃时可以通过备份的ETL系统继续完成ETL的工作，为达到这个目的，应安装两台DataStage环境，并建立相同的配置，其中一台处于运行状态，而另一台为待机状态。每日在日常ETL完成后对运行环境的各文件进行备份，即将ETL的运行目录(本项目中为E:\***ETL)转储到外挂磁盘或外部存储介质。
而数据库的数据备份对于ETL非常重要，建议系统管理员每日做数据的完全备份，即采用Oracle的Export命令对数据仓库的Schema做完全的备份，每天保留一个备份文件，建议至少保留7天。
ETL系统的恢复相应也包括两个部分，即运行恢复及数据恢复
运行恢复是指当运行系统遇到严重故障如硬件故障、操作系统崩溃等无法及时修复时，启用备份的运行系统继续，通过将上一日备份的ETL环境恢复到待机系统，然后启动待机系统运行日常ETL。
数据库恢复通常两种情况下会用到，一种是数据库系统本身出了故障需要重新安装，这时需要将上一日备份的数据恢复到新的数据库环境中。还有一种是数据加载过程中发现几天以前加载了某些有问题的数据，需要从之前某一天开始重新加载修正后的数据，这时需要将指定日的备份重新恢复到数据仓库中，然后顺序运行每日的日常ETL
上图是ETL应用程序的架构图，ETL架构从功能上被划分为三个层次：
Ø ETL作业及作业调度
通过作业调度功能，管理员根据目标数据表的更新周期和源数据就绪时间，制定日常数据的ETL的时刻表。管理员通过DataStage的作业调度功能进行运行时刻设置，自动在规定条件满足时启动相应的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步骤的程序，即上面所述的Extract、CSS、TR和LOAD程序(LOAD又分为PreLoad、LOAD、PostLoad)。每个模块实现一个特定的功能。各模块之间无任何调用关系，它们之间可能的关系仅仅是一个模块的输出文件是另一个模块需要读取和加工的文件。一个ETL功能模块就是一个DataStage Job，每个功能模块的逻辑都只是ETL过程中一个相对独立的部分。
Ø ETL控制环境
ETL功能模块的运行需要由相应的参数进行控制，同时在各模块之间也存在很多控制文件及调用一些公共的功能，功能模块在运行过程中可能产生拒绝文件，针对功能模块的运行状况会有产生一些监控信息等等，这些对于ETL功能模块的运行起到控制与支撑的环境以及相应的维护管理程序构成ETL架构环境。
上两层构成ETL应用，而ETL控制环境则为以上层次的每个应用程序提供支持，应用层次上独立的功能模块都通过更上一个层次的逻辑关系联系起来，使每个模块的功能更加清晰、明确。
根据模型的设计和源数据的情况，有四种数据ETL模式：
Ø 完全刷新（Refresh，Type 1）：数据仓库数据表中只包括最新的数据，每次加载均删除原有数据，然后完全加载最新的源数据。如大多数参数表的加载都采用这种模式。这种模式下，数据抽取程序抽取源数据中的所有记录，在加载前，将目标数据表清空，然后加载所有记录。为提高删除数据的速度，一般是采用Truncate清空数据表而不采用SQL Delete进行删除。本项目中由于主要目标是实现Daily报表，因此大部分的表均为此种类型。如CO_DATE_MF表就是这种类型。
Ø 镜像增量（Snapshot Append，Type 2）：源数据中的记录定期更新，但记录中包括记录时间字段，源数据中保存了数据历史的记录，ETL可以通过记录时间将增量数据从源数据抽取出来以附加的方式加载到数据仓库中，数据的历史记录也会被保留在数据仓库中。目前项目中没有这种类型的数据。
Ø 事件增量（Event Append，Type 3）：每一个记录是一个新的事件，相互之间没有必然的联系，新记录不是对原有记录数值的变更，记录包括时间字段，可以通过时间字段将新增数据抽取出来加载到数据库中。如CO_PO_HIST表就是这种类型
Ø 镜像比较（Snapshot Delta，Type 4）：数据仓库数据具有生效日期字段以保存数据的历史信息，而源数据不保留历史并且每天都可能被更新。因此，只能将新的镜像数据与上次加载的数据的镜像进行比较，找出变更部分（即Delta），更新历史数据被更新记录的生效终止日期，并添加变更后的数据。大多数源数据中需保存历史信息的维表。如CO_Plant_MF表就是这种类型。
数据抽取是从数据源获取所需数据的过程。数据抽取过程会过滤掉数据仓库中不需要的源数据字段或数据记录。
数据抽取可以采用PULL和PUSH两种方式。PUSH就是指由源系统按照双方定义的数据格式，主动将符合要求的数据抽取出来，形成接口数据表或数据视图供ETL系统使用。PULL则是由ETL程序直接访问数据源来获取数据的方式。
为提高ETL效率，数据在进入ETL系统后，EXF文件都将转换为Flat Text文件格式。整个ETL过程中，除数据抽取外，都不使用效率较差的SQL方式进行数据处理。
由于本项目ETL系统可以访问所有源系统，而日数据量不大，综合上面的分析，从ETL程序设计的灵活性、可控性和整体结构的一致性考虑，尽量采用Pull的方式，减少对源系统的影响和对其他开发队伍的依赖，并减少网络压力。
Convert的任务是逐条记录的检查数据，将每个字段转换为遵循数据仓库标准的数据格式，即对数据类型和数据格式进行转换，并对空字段赋予适当的缺省值，形成规整的数据结构，对于不符合要求的数据，写入拒绝文件（Reject文件）中。
数据变换主要的工作有：
Ø 格式变换，如所有日期格式统一为yyyy-mm-dd；
Ø 赋缺省值，在数据仓库中定义取值不为空的字段在源数据对应的字段可能存在没有取值的记录，这时根据业务需要，可能有两种处理办法，一是将该记录写入到Reject文件中，由业务部门根据Reject文件检查并修补源数据，另一种是在Convert阶段直接赋一个缺省值；
Ø 类型变换, 如将源系统的Number类型转为vahar2类型等
Ø 长度变换, 如将源系统中定义的vahar2(10)转为vahar2(20)等
Ø 代码转换，如源系统的某些字段经过代码升级以后，将老的代码转为新的代码等。
Ø 数值转换，如数值单位由万元转为元等。
同一个数据源表的数据可能被多个数据仓库表使用，这就需要将一个数据源按不同的条件通过Extract和Convert过程分成多个CIF文件以对应于不同的目标表的转换加载。
正如前面所讨论的，由于系统的数据量并不大，性能并不是第一考虑的指标，而本设计更着重于系统架构的统一性及完整性，因此为了使架构更加单一，对于按条件分割的情况将在Extract的步骤完成，即按不同的条件分别抽取为不同的EXF，然后再由不同的Convert程序变换为各自对应的CIF，而对于需要排序分割的情况，则在Transform时处理，在真正开始Transform之前先将CIF排序为新的临时的CIF文件。
数据转换（Transform）是按照目标表的数据结构，对一个或多个源数据的字段进行翻译、匹配、聚合等操作得到目标数据的字段。
数据转换主要包括格式和字段合并与拆分、数据翻译、数据匹配、数据聚合以及其他复杂计算等。
字段合并是指源数据的多个字段合并为目标数据的一个字段。
字段拆分是指将源数据中一个表的一个字段拆分为目标数据的多个字段。
对于数据仓库中有的字段，在源系统中并没有相对应的源字段，这时根据模型的设计，可能需要缺省赋一个值
TR程序有时需要对于两个或多个CIF文件merge，在merge之前需要将CIF文件按所要求的key排好序，这样可以加快merge的速度，排序的过程在Transform之前进行。
在DataStage中提供了排序的Stage功能，一般在CS JOB的最后调用该Stage，但Stage的性能并不特别高，如果对于性能有进一步的要求，可以采用第三方如CoSort等工具软件。
将源系统中一些表示状态、类型等的代码直接翻译为其所表达的意思，或反之。数据翻译需要用到参考表（Reference Table），数据参考表一般是字典表或根据源数据与目标数据的定义手工产生，如果数据翻译时在参考表中找不到对应的对照，根据业务规则，需要将对应的记录Reject出来或赋缺省值。
按一定条件（一般是key值相等）对数据进行合并，找出描述同一对象的分布在不同数据表中的记录，并把这些记录联系起来。数据合并其实是数据翻译的一种特殊情况，主要用于数据量特别大的情况，数据合并在实现方式上一般先对要合并的两个表分别排序(Sort)，然后顺序对两个表的记录进行匹配合并，这样可以大大加快处理的速度。
对数据按照不同分组进行汇总等统计计算，一般是用于汇总表的计算，主要的聚合种类有：
Ø 求和
Ø 求平均值
Ø 求记录数
Ø 求最小值
Ø 求最大值
Ø 取第一行
Ø 取最后一行
原则上，ETL只处理规律而重复性大的数据聚合，如汇总、取平均值、找最大最小值等，而不用于复杂计算，以减少开发成本和系统负载。对于不规律而且复杂的计算，应该由源系统端将数据计算好。
对应于四种ETL模式，数据转换为PLF文件后需要进行不同的处理，在Type1、Type2和Type3模式下，PLF可以直接由数据加载过程加载到数据仓库中，而Type4则由于存在有效日期，需要将当日的snapshot数据与历史数据镜像进行比较，找出需要添加和需要更新的记录，然后产生真正可以向数据库加载的PLF文件，再由数据加载过程将PLF文件加载到数据仓库中。
在数据仓库中定义的某些字段需要按照业务规则进行复杂计算才能得到，主要有两类：
Ø 主要针对一些在数据源中找不到直接对应的字段，需要在ETL过程中通过相关字段计算才能得出的字段。
Ø 原则上复杂的计算并不在ETL中完成，对于一定需要由ETL来完成的复杂计算字段，采取在ETL加载时该字段先留空，在加载完成以后调用的存储过程来计算，但为了管理与调度的统一，可以在DataStage中调用存储过程以统一调度。
经过数据转换生成的PLF文件的结构与数据仓库数据表的结构完全一致，可以直接通过数据加载工具，以Bulk Load的方式加载到数据仓库中。数据加载工作将分为3步进行。
在真正进行数据加载之前还可能需要完成以下准备工作：
Ø 删除数据仓库中数据表的索引，提高加载效率。主要是针对detail及fact大表，可以直接调用DBA所创建的索引维护脚本。DBA调试过数据仓库后，必须更新相应的索引维护脚本，以保证ETL能够正确删除和建立索引。
Load主要完成将PLF文件的数据加载到数据仓库的表中，需要用到的加载方式有三种：
Ø Insert：只需要将PLF文件所有数据完全Insert到目标表中。
Ø UpdAdd：需要对目标表同时做Update及Insert操作，根据primary key，对于已有的记录进行Update操作，对于不存在的记录做Insert的操作，对于数据量大的表，由于此操作的效率非常低，可以采用先将PLF文件分割为Delet文件及Insert文件，然后先将Delete文件中的记录根据primay key对应从数据仓库中删除，然后再从Insert文件中将所有记录全部Insert到目标表中。
Ø Refresh：即将目标表的数据完全更新，一般的做法是先Truncate目标表的数据，然后再完全Insert要加载的记录
加载过程中，数据仓库关闭数据RI（Referential Integrity）管理功能，数据库的RI检查由ETL应用程序完成。
Ø 重新生成索引：在pre-load阶段删除的索引需在此重建，该过程也是调用DBA维护的索引维护脚本。
Ø 文件清理：删除不需要的临时文件及临时表。
进程调度的功能比较单纯，就是在规定的时刻启动程序，并记录系统运行情况和运行结果。
不同数据表的更新周期不同，因此，进程调度需要能够支持日周月等多种不同的启动周期，并通过设定启动时间来确定每个任务在何时启动运行。
只有日常数据加载才需要考虑进程调度的问题。而对于初始数据及历史数据的加载，由于是一次性的工作，将采取手工启动加载的方式，所以无需制定对初始数据及历史数据加载制度化的进程调度。
在ETL程序的抽取过程运行之前一定要保证其抽取的源数据已经准备就绪，本项目关于源数据准备就绪的接口采用数据就绪标识及时间约定相结合的方式，即源系统部门在源数据准备就绪以后向就绪接口表中写入就绪标识，而ETL Job从约定的时间开始不断检查该该标识，直到判断该标识已经就绪，将启动正常的ETL Job开始运行。
本系统使用DataStage作为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的运行选项，如自动删除过时的Job日志的选项、运行人员授权等
但依然有部分管理功能无法由DataStage直接提供，需要通过开发来完成，但所有的开发都使用DataStage Job的形式，这样有利于在DataStage中统一进行管理，主要开发的管理功能应包括：
Ø 参数设置，通过参数设置Job SetParam设置ETL运行的参数，实际上也就是通过界面实现对于参数文件JobParams.cfg的维护；
Ø Job运行情况的Email通知，主要用于每日指定的时间检查当日的Job运行状况并通过Email的形式将检查结果发送给运行维护人员
初始数据加载(Initial Load)是指在系统正式运行之前，需要将当前完整企业数据视图一次性地加载到数据仓库中，作为数据仓库的基础数据。
历史数据加载(History Load)是指将历史一定时间段的数据(主要是细节数据)加载到数据仓库，对于ETL的历史加载，需要SAP系统将原有历史数据导入SAP以后，ETL再统一从SAP的接口中加载历史数据。
日常数据加载(Incremental Load)是指周期性地将该周期内的增量数据加载到数据仓库数据库中。
针对初始数据加载、历史数据加载（Initial Load）和日常数据加载（Incremental Load）的数据量、数据源和工作流程的不同，设计将采用不同的ETL策略。
对于日常数据加载，由于需要定期自动运行相关的程序，因此需要有支持scheduler的工具支持以满足自动运行的需要，数据源主要是业务系统针对数据仓库系统提供的接口表，程序逻辑的处理要求非常严格。
对于初始数据加载，由于需要在上线日之前一次性完成，因此在上线日之前业务部门必须完成相关的数据清洗，从而保证初始数据加载的顺利完成，否则，将造成上线后数据仓库的数据质量不高。
因为初始数据加载和历史数据加载都是一次性执行，所以主要采用手工和程序控制相结合的方式进行，不需要复杂的工作调度程序。程序逻辑的处理也不需要非常严格，如果其中涉及的逻辑非常复杂，也可以将源数据直接导出成数据文件，经业务部门对数据进行确认或修正签字生效以后，将数据文件直接加载到数据仓库中，从而降低ETL开发的难度。
与日常数据加载不同，历史数据加载可能按不同的时段需要从分散在不同的数据表中加载数据，并可能需要不同的数据转换逻辑，因此针对不历史数据时段需要单独开发不同的ETL程序。
ETL应用涉及大量的中间文件、程序和任务，因此需要制定相应的命名规范，以提高应用的可管理性和可读性。
在本章中将采用如下方式表示命名规范：
Ø 加黑正体字母：在命名中直接采用该字母；
Ø 加黑斜体字母：表示固定采用所指定的名称列表中的。如souesystemname表示固定采用112、10000、bill、97、ecrm、eip中的一个。
Ø 斜体字母：可以用任意字符串代替的部分。如souetablename表示在实际开发中根据实际采用与源系统的数据表名称一致的命名。
Ø []：里面的字符串为可选需要，即依赖于之前的字符串不同可能需要，也可能不需要。如
Ø 下划线：表示直接使用下划线符；
格式：systemname_tablename[sequence].extname
说明：systemname为源系统类型，其取值为
| Systemname | 说明 |
| AUTO | SAP R/3源系统 |
| APO | SAP APO源系统 |
| DOL | DOL系统(DMS系统一期) |
| DW | 数据仓库系统 |
| DMdatamartname | 数据集市系统，datamartname为具体数据集市的名称 |
| HW | 手工数据 |
Tablename为表名（源表或目标表）
Sequence为文件顺序号，从1开始编号，只有当extname为EXF或CIF且需要对源数据表进行分割时才使用。
extname为中间文件的类型，其取值为
| Extname | 说明 |
| EXF | EXF文件 |
| CIF | CIF文件 |
| PLF | PLF文件 |
| REF | 参考文件 |
中间文件的字段之间采用”|”分隔，文件名全命采用大写字母，中间文件的第一行为列名
格式：souefile.[Filetype][sequence]
说明：souefile为源文件，产生本文件的源文件
filetype为临时文件的类型，只有与中间文件的类型不同时使用，其取值为：
| Filetype | 说明 |
| HSF | Hash文件 |
| SRF | SORT文件 |
Sequence为文件顺序号，从1开始编号，只有当对同一文件产生的临时文件超过1个才使用，。
格式：method.PARAM
说明：method为BAPI程序的method
ETL开发、测试、生产统一采用***
格式：EtltypeJobtypeSystemnameDescription [sequence]
说明：etltype用于标识ETL程序的分类，其取值为：
| Etltype | 说明 |
| I | 日常数据加载程序(incremental) |
| N | 初始加载程序(Initial) |
| H | 历史加载程序(History) |
Jobtype用于标识Job的任务类型，其取值为：
| Jobtype | 说明 |
| Ex | 抽取程序(Extract) |
| Cs | 变换程序(Convert) |
| Tr | 转换程序(Transform) |
| Ld | 加载程序(Load) |
| Ma | 维护程序(Maintance) |
| Gc | 结果为CIF的JobGroup，一个Gc Job调用Ex及Cs Job对应生成一个CIF文件 |
| Ge | 结果为数据库表的JobGroup，一个Ge Job调用Tr及Ld Job对应完成转换加载一个数据库表 |
| Sh | 用于定义Schedule的Control Job，Sh Job不允许Abort |
| Se | 用于定义作业执行顺序的作业，通过Se Job设置Gc及Ge Job的运行依赖关系 |
systemname为源系统类型，其取值为
| Systemname | 说明 |
| AUTO | SAP R/3源系统 |
| APO | SAP APO源系统 |
| DOL | DOL系统(DMS系统一期) |
| DW | 数据仓库系统 |
| DMdatamartname | 数据集市系统，datamartname为具体数据集市的名称 |
| HW | 手工数据 |
Description为源或目标描述信息，分为以下几种情况
Ø 对于Ex、Cs、Gc Job而言为数据源描述信息，如果是直接抽取一个源表(包括从数据仓库中反抽表)，则使用Tablename（如果源表中含有“_”则忽略之），如果抽取的是调用BAPI程序返回一个数据结果集，则使用BAPI+BAPI程序的method代替，如BAPIZGEwoDate，如果抽取的是Join几个源表返回一个数据结果集，则使用MIX+描述信息，其中描述信息根据抽取结果的业务含义自定
Ø 对于Tr、Ld、Ge Job而言为目标数据库描述信息，直接使用TableName
Ø 对于Sh、Se、Ma而言由程序员根据Job的功能自定义描述信息
Sequence为Job顺序号，从1开始编号，主要针对Ex、Cs、Tr和Ld等Component Job使用，用于在一个Job中很难实现所有逻辑时进行分拆时使用。
| Stage | 命名 | DataStage Stages | 说明 |
| 抽取 | EX_souetablename | Abap_Ext_for_R3BAPI_PACK_for_R3Oraoci9i | souetablename为抽取的源表名 |
| 转换 | TR_plfname | Transformer | plfname为转换的目标plf文件名，其中小数点以”_”代替 |
| 排序 | SR_filename_n | Sort | Filename为要排序的源文件名，n表示一位的序号，其中小数点以”_”代替 |
| 合并 | MG_targetfilename | Merge | Targetfilename为合并的目标文件名，其中小数点以”_”代替 |
| 加载 | LD_targetgtablename | Oraoci9i | Targettablename为要加载的目标表名 |
| 文本文件 | SQ_filename | Sequencial file | Filename为要产生的文本文件名，其中小数点以”_”代替 |
| Hash文件 | HS_filename | Hash | Filename为hash文件的文件名，其中小数点以”_”代替 |
| 文件合并 | CP_filename | Link Collector | Filename为合并后文件名，其中小数点以”_”代替 |
| 行列变换 | PV_souetablename | Pivot | Souetablename为要变换的源表名 |
| 文件夹 | FD_foldername | Folder | foldername为目录名 |
| Stage | 命名 | DataStage Stages | 说明 |
| 顺序序列 | Senn | Sequencer | nn为两位数字，从01开始 |
| 作业 | JB_jobname | JobActivity | Jobname为job的名称 |
| 文件等待 | WF_filename | WaitingForFile | filename为文件的名称 |
| DOS命令 | CMD_description | ExecuteCommand | description为命令说明 |
格式：LKnn
说明：nn为两位序号，不代表含义，但在用于Lookup时，如果针对同一Transform Stage中需要用到多个Link，为了在Transform Stage的开发不至于混淆，可以用有含义的名字来代替
格式：RTfunctionname。
说明：functionname为Routine的功能描述
格式：ZG<programtype><module><ModifyFlag>nnn
说明：ZG两位为遵循ABAP程序开发规范而使用的
programtype为程序的种类，其取值为：
| Programtype | 说明 |
| R | 日常加载程序 |
| N | 初始加载程序 |
moudle为模块名：
| Module | 说明 |
| C | CO |
| F | FI |
| I | IPPE |
| P | PPDS |
| M | MM |
| D | DMS |
modify为修改标识，其取值为
| Type | 说明 |
| A | 完全由DataStage自动生成的程序 |
| M | 需要修改或单独编写的ABAP程序 |
nnn为三位的顺序号，从001开始编号，为了避免引起开发的混乱，编号统一由一位开发人员管理分配，当需要生成一个新的ABAP程序时，开发人员应先向编号管理员申请一个新的编号。
DataStage中的TableDefinition共有以下几类：
EXF
格式：systemname_tablename.EXF
说明：
systemname为源系统类型，其取值为
| Systemname | 说明 |
| AUTO | SAP R/3源系统 |
| APO | SAP APO源系统 |
| DOL | DOL系统(DMS系统一期) |
Tablename为源表名或BAPI Method名
CIF
格式：systemname_tablename.CIF
说明：
systemname为源系统类型，其取值为
| Systemname | 说明 |
| AUTO | SAP R/3源系统 |
| APO | SAP APO源系统 |
| DOL | DOL系统(DMS系统一期) |
Tablename为源表名或BAPI Method名
DW
格式：tablename
说明：与数据库表名完全致
PARA
格式：systemname_tablename.PARA
说明：
systemname为源系统类型，其取值为
| Systemname | 说明 |
| AUTO | SAP R/3源系统 |
| APO | SAP APO源系统 |
| DOL | DOL系统(DMS系统一期) |
Tablename为源表名或BAPI Method名
TMP
不设定统一的格式，根据Job开发的需要自定义临时需要用到的结构
Store procedure主要会应用于ETL目标表中部分需要计算的字段，这些字段通过store procedure在已加载的表中直接计算，同时由ETL程序统一调用
格式：sp_etl_functiondescription
说明：tablename为需要计算的表名，functiondescription为存储过程的功能说明，如果该存储过程只是为计算某一特定字段，则可用该字段名表示，如果是同时计算多个字段，则独立命名
格式：yyyymmdd_souefilename.RJ
说明：yyyymmdd为系统的rundate
souefilename为拒绝的源文件名。
在DataStage上将采用软件所提供的日志功能，可以直接使用DataStage Director查看每个Job的运行日志。
在开发系统、测试系统、生产系统上需要配置数据库的ODBC连接。为保证程序移植的简单，同一ODBC连接采用相同的命名，所以在开发系统上，连接数据仓库的ODBC是指向开发机数据库，而在测试系统中同一名称的ODBC连接指向测试机数据库，生产系统中同一名称的ODBC连接指向生产机数据库。
格式：systemname
说明：systemname为源系统类型，其取值为
| Systemname | 说明 |
| AUTO | SAP R/3源系统 |
| APO | SAP APO源系统 |
| DOL | DOL系统(DMS系统一期) |
| DW | 数据仓库系统 |
| Dmdatamartname | 数据集市系统，datamartname为具体数据集市的名称 |
开发过程中需要对所有ETL程序及文档进行相应的版本控制，跟踪开发过程中的修改，以保证开发版本的一致性及保持开发的连续性，本项目主要使用的版本管理工具为Ascential的Version Control软件及Microsoft的Visual SoueSafe软件。
实际运行的ABAP程序及BAPI程序保存在SAP系统中，但开发的源代码文件则存放于VSS的03Construct\02ETL Soue Code\01ABAP Programs目录下
DataStage Job及Routine的版本通过Version Control工具来控制，首先在开发机DataStage Server上创建一个名为Version的Project，在开发机上每次将开发及修改后的稳定Job通过Version Control工具传到Version Project中，然后根据需要将要发布的Job发布到QA机及生产机上。具体Version Control工具的用法请参考DataStage软件包随附的文档
实际运行Store Procedure程序保存在DW的数据库中，但开发的源代码文件则存放于VSS的\03Construct\02ETL Soue Code\02Store Procedures目录下
ETL相关的文档主要包括本设计文档、ETL Job Dependency文档、ETL Mapping文档均存放于VSS的02Design\03ETL Design目录下
为了保证ETL开发过程的规范，本节对ETL的开发过程进行一些原则上的规范，ETL开发人员在开发的过程中必须统一采用这些开发的方法，这样，才能保证开发完成的ETL程序具有可管理性
在开发的过程所有的Stage中使用的数据结构必须在TableDefinition中有定义，有以下原则需遵循：
Ø 在抽取Job的开发过程中，应将Job的输出结构保存到***\EXF目录
Ø 在CSJob的开发过程中，应将Job的输出结构保存到***\CIF目录
Ø 在开发TR和LDJob之前，应先import数据库的相应表的结构到***\DW目录
Ø 由于PLF的结构与数据库table完全一致，因此不再单独定义PLF的数据结构，需要用到PLF的地方直接使用***\DW中对应数据库表的结构
Ø 在TRJob中如果用到Hash文件，需要将Hash文件的输出结构保存到***\TMP目录
Ø 对于ABAP抽取程序，源表的所有主键都必须抽取以保证数据的完整性，而无论该字段是否需要
Ø 对于ABAP抽取程序，一个ABAP程序对应一个源表，原则上应尽量避免通过表之间的Join得到抽取结果的开发方法
Ø 对于ABAP抽取程序，在以下两处地方同步加上程序的描述信息，描述信息的格式参照以下Sample
Ø 在Cs Job中应将所有的char及vahar类型的字段进行Trim操作以去除字符串的前后空格，如果该字段特别要求保留空格的情况除外
Ø 标准的Load Job的样式应该如下面的例子所示，LK02完成数据库表的加载，LK03应输出加载失败的记录：
Ø 对于Oraoci9i Stage，建议缺省设置如下两个选项：
Ø Gc和Ge Job在调用Component Job(Ex、Cs、Tr、Ld)时，应先判断该Job的状态，如果不是可运行状态时则先Reset该Job的状态，然后再运行该Job，一段典型的代码如下所示：
存储过程及BAPI均是将逻辑封装于DataStage之外的一种开发方法，原则上应尽量尽量避免使用，只有在下列情况下才使用：
Ø 无法直接从源表中得到所需的数据，也无法通过抽取多个源表通过表之间的关联得到所需的数据，只有通过调用SAP的function Module才能得到所需数据的情况可以采用BAPI
Ø 在需要增量抽取的情况下，如果无法直接从SAP的Table获得增量抽取的条件而必须全部抽取SAP的Table并经过表关联才能得到增量数据，但抽取的数据量很大并严重影响ETL的性能时可以通过BAPI取增量数据
Ø 如果目标表需要通过数据仓库中已加载的表通过逻辑运算得出，而运算的逻辑通过DataStage工具很难实现，可以通过采用Store Procedure来实现
Ø 如果目标表需要通过数据仓库中已加载的表通过逻辑运算得出，并且也可以将数据仓库相关的表反抽出来然后通过DataStage Job来实现运算的逻辑，但抽取的数据量很大并严重影响ETL性能时可以通过采用Store Procedure来实现
| 机器 | 一级目录 | 二级目录 | 三级目录 | 说明 |
| 开发机/测试机/生产机 | E:\***ETL\ | YYYYMMDD\ | EXF\ | 存放EXF文件 |
| CIF\ | 存放CIF文件 | |||
| PLF\ | 存放PLF文件 | |||
| TMP\ | 存放临时文件，如Hash文件等 | |||
| PARA\ | 存放BAPI参数文件 | |||
| LOG\ | ETL程序运行的日志文件 | |||
| REJ\ | ETL程序运行的拒绝文件 | |||
| REF\ | 手工参考文件 | |||
| JOB\ | ***\ | DataStage的JOB存放目录 | ||
| FTP\ | BAK\COR01 | COR01输出文件备份目录 | ||
| BAK\IPPE13 | IPPE13输出文件备份目录 | |||
| BAK\IPPE15 | IPPE15输出文件备份目录 | |||
| BAK\PPDS01 | PPDS01输出文件备份目录 | |||
| BAK\PPDS12 | PPDS12输出文件备份目录 | |||
| FTP\ | OUT\COR01 | COR01输出文件存放目录 | ||
| OUT\IPPE13 | IPPE13输出文件存放目录 | |||
| OUT\IPPE15 | IPPE15输出文件存放目录 | |||
| OUT\PPDS01 | PPDS01输出文件存放目录 | |||
| OUT\PPDS12 | PPDS12输出文件存放目录 | |||
| FTP\ | IN\IPPE13 | IPPE13输入条件目录 | ||
| IN\IPPE15 | IPPE15输入条件目录 | |||
| IN\MM14 | MM14用户上传文件目录 |
DataStage Manager中与开发有关的目录层级
| JOB目录 | Jobs\***\Incremental\FICO\EX \FICO\CS \FICO\TR \FICO\LD \FICO\SH\GC \FICO\SH\GE \COPLUS\EX \COPLUS\CS \COPLUS\TR \COPLUS\LD \COPLUS\SH\GC \COPLUS\SH\GE \IPPE\EX \IPPE\CS \IPPE\TR \IPPE\LD \IPPE\SH\GC \IPPE\SH\GE \MM\EX \MM\CS \MM\TR \MM\LD \MM\SH\GC \MM\SH\GE \PPDS\EX \PPDS\CS \PPDS\TR \PPDS\LD \PPDS\SH\GC \PPDS\SH\GE \SCHEDULE \SCHEDULE\MA \SCHEDULE\OUTPUT \SCHEDULE\SEQ \Initial\FICO\EX \FICO\SH\GC \PPDS\EX \PPDS\SH\GC \SEQ |
| Routines目录 | Routines\*** |
| Share Containers目录 | Share Containers\*** |
| Table Definitions目录 | Table Definitions\***\EXF \CIF \PARA \TMP \DW \DM |
本章从应用开发的层次更详细的描述在本项目的ETL系统实现中应用或模块的功能及其关系，本项目中ETL的开发实际上包括日常ETL程序的开发和初始ETL程序的开发两部分，由于ETL运行的重心在于日常ETL程序，为了使本章的内容更加突出重点，将文档结构组织为前4节的内容主要指导日常ETL程序的应用开发而不单独说明其用途，因此读者在阅读的过程中应该清楚前4节是针对日常ETL应用设计的。而初始ETL的开发将采用与日常ETL基本一致的开发方法甚至于直接使用一部分完成日常ETL任务的Job，本章的最后一节则主要针对初始ETL开发将其与日常ETL不同的部分予以专门的说明。
上图反映了ETL应用模块的架构体系，从图中可以盾出，整个ETL过程所需要模块存在于三类不同的系统中：
在DataStage Server中包含了所有DataStage的Job及相应的公共环境，其中Job又分为以下几类：
Ø Schedule Job
用于供DataStage的定时调度，以ISh开头，不允许Abort
Ø Dependence Job
用于建立ETL Job的Dependence关系，以ISe开头
Ø Maintance Job
用于系统维护及管理方面功能的任务，以IMa开头
Ø Group Job
以IGc或IGe开头，IGc用于将抽取作业(IEx)和变换作业(ICs)Group起来完成生成CIF的任务，IGe用于将转换作业(ITr)和加载作业(ILd)Group起来或直接调用Store Procedure完成加载数据表的任务
Ø Component Job
ETL最底层的Job，用于完成一项特定的功能，IEx完成抽取功能、ICs完成变换功能、ITr完成转换功能、ILd完成装载功能
公共环境包括共用的参数文件JobParams.cfg及公用的Routine函数，JobParams.cfg配置了ETL Job运行的全局变量，是保证各个步骤的ETL Job运行协调一致的纽带，而Routine函数是一些供ETL Job调用的公共函数
DB Server中包含了供ETL加载作业调用的存储过程，这些存储过程主要用于DW中某些表或表的字段的计算，其数据来源是ETL已经加载完成的表
所有的Job及程序均通过DataStage的作业调度功能统一由ISh的Job发起嵌套调用，也即是说，在DataStage的运行环境中只会针对ISh的Job设定Schedule。
JOB名：IShDayOpen
功能：该JOB调用IMaDayOpen完成日初始化工作
运行参数：无
启动时间：设为每日3:00
JOB名：IShDayOff
功能：该JOB调用IMaDayOff完成日结工作
运行参数：无
启动时间：设为每日23:00
JOB名：IShDailyRunCheck
功能：该Job遍历当前Project中所有的Job，查找每个Job当日的运行日志，分为Attach Fail、Warning、Fatal、Reject四种情况形成四份运行Report，并通过Email将Report发送给管理员，其中Attach Fail Report列出所有不可运行的Job列表，Warning Report列出运行过程中含有Warning信息的Job列表，Fatal Report列出所有运行失败的Job列表，同时将错误日志附在Report中便于管理员及早分析问题，Reject Report列出所有产生了Reject记录的Job列表，同时将拒绝日志附在Report中以便管理员可以看到拒绝的记录数
运行参数：
| 参数名称 | 参数类型 | 说明 |
| Mailserver | String | smtp邮件服务器IP地址，注意不能开启身份验证功能，目前设置为210.75.71.180 |
| Senduser | String | 发送用户的email地址 |
| receiveuser | String | 接收用户的email地址，如果需要同时发送给多个地址，地址间用”;”分隔 |
流程说明：
启动时间：设为每日8:00
JOB名：IShPreAUTO
功能：该JOB调用IMaPreAUTOSub Job完成检查当日AUTO系统的后台作业是否成功运行完毕，如果成功检测到AUTO后台作业已运行结束，则生成一个标识文件
运行参数：
| 参数名称 | 参数类型 | 说明 |
| Interval | Integer | 如果AUTO后台作业未运行结束，下一次检测的间隔时间（以分钟为单位，缺省设为5） |
| Retrytimes | Integer | 如果AUTO后台作业未运行结束，重试的次数，缺省设为60 |
流程说明：
启动时间：设为每日4:30
JOB名：IShPreAPO
功能：该JOB调用IMaPreAPOSub Job完成检查当日APO系统的后台作业是否成功运行完毕，如果成功检测到APO后台作业已运行结束，则生成一个标识文件
运行参数：
| 参数名称 | 参数类型 | 说明 |
| Interval | Integer | 如果APO后台作业未运行结束，下一次检测的间隔时间（以分钟为单位，缺省设为5） |
| Retrytimes | Integer | 如果APO后台作业未运行结束，重试的次数，缺省设为60 |
流程说明：
启动时间：设为每日4:30
JOB名：ISh******
功能：该JOB调用同名的ISe****** Job完成数据的ETL过程
运行参数：无
启动时间：根据实际运行情况确定
JOB名：ISe******
功能：该JOB设置Gc和Ge的Job运行的Dependence关系，用于被ISh的Job调用每天定时运行
运行参数：无
JOB名：IMaDayOpen
功能：该脚本完成每日的ETL初始化工作。此脚本由IShDayOpen调用，具体完成以下工作：
1 设置工作日
2 初始化当日工作目录：yyyymmdd/EXF，yyyymmdd/CIF，yyyymmdd/PLF，yyyymmdd/TMP，yyyymmdd/PARA)
3 生成初始化完成标识文件DayOpenyyyymmdd.ok
输入参数：
| 参数名称 | 参数类型 | 说明 |
| Rundate | String | 数据日期，格式yyyymmdd，如果不设则缺省设为当前日历日期减1 |
| Jobdate | String | Job运行日期，格式yyyymmdd，主要用于检查SAP后台作业是否完成，如果不设则缺省设为当前日历日期 |
JOB名：IMaDayOff
功能：该脚本完成每日的ETL日结工作。该脚本删除ETL运行过程中的接口标识文件及超过保存期限的中间文件。此脚本在当日所有ETL Job完成以后才能运行，由IShDayOff调用，具体完成以下工作：
1 清除接口标识文件，包括DayOpenyyyymmdd.ok，PreAUTOyyyymmdd.ok, PreAPOyyyymmdd.ok, IGcDWCOPlantMf.ok, IGcDWCOProductPartMf.ok等
2 清除超过参数FileKeepCycle设定保存周期的中间目录yyyymmdd
输入参数：
| 参数名称 | 参数类型 | 说明 |
| rundate | String | 数据日期，格式yyyymmdd |
JOB名：IMaSetParam
功能：该脚本将用户设置的参数及其值写入JobParam.cfg配置文件中，供操作员手工调用修改或添加配置参数
输入参数：
| 参数名称 | 参数类型 | 说明 |
| rootpath | String | 参数文件JobParam.cfg存放的根路径 |
| ParamName | String | 参数名称 |
| ParamValue | String | 参数值 |
| EncryptFlag | String | 是否加密存放：Y—加密写入N—不加密写入 |
JOB名：IMaPreAUTOSub
功能：该脚本检查当日SAP AUTO后台作业是否已经完成，如果完成则创建一个标识文件PreAUTOyyyymmdd.ok，用于供IShPreAUTO调用。
输入参数：
| 参数名称 | 参数类型 | 说明 |
| rundate | String | 数据日期，格式yyyymmdd |
| rootpath | String | ETL根目录 |
处理流程说明：
1 连接SAP AUTO系统
2 调用ABAP程序ZGRIA294，查看表TBTCO，取出符合以下条件的记录：
a) JOBNAME = ’DY10_D_MM05 PUS ISSUE TO E-SCH’
b) ENDDATE = Backgroud JOB运行日期
c) STATUS = ‘F’
3 将取出的记录写入文件PreAUTO.tmp
JOB名：IMaPreAPOSub
功能：该脚本完成每日的ETL日结工作。该脚本调用系统的备份功能备份当日的入库数据和中间文件并删除超过保存期限的中间文件。此脚本在所有ETL执行完成后运行一次。可由操作员启动或由作业调度程序自动调用。
输入参数：
| 参数名称 | 参数类型 | 说明 |
| rundate | String | 数据日期，格式yyyymmdd |
| rootpath | String | ETL根目录 |
处理流程说明：
1 连接SAP APO系统
2 调用ABAP程序ZGRIA295，查看表TBTCO，取出符合以下条件的记录：
a) JOBNAME = ’DY10_D_PPDS07 SL_REL_R1’
b) ENDDATE = Backgroud JOB运行日期
c) STATUS = ‘F’
3 将取出的记录写入文件PreAPO.tmp
JOB名：IGc******
功能： 该Job是为Control Job,该Job调用Ex及Cs的Job组合起来形成一个组合的任务，目的是最终生成一个CIF文件，如果抽取及变换的逻辑无法通过一个Ex及一个Cs程序来完成，也可以分拆多个Ex或Cs Job，但一个CIF文件只能对应一个Gc Job，同样一个Gc Job也只能产生一个CIF文件
输入参数：无
基本流程：
JOB名：IGe******
功能：该Job是为Control Job,主要有两种类型，一类调用Tr及Ld Job组合起来形成一个组合的任务，另一类直接调用存储过程，最终都是以向DW数据库加载完成一个Table为目的，如果转换和装载的逻辑无法通过一个Tr及一个Ld程序来完成，也可以分拆多个Tr或Ld Job，但一个数据库表只能对应一个Ge Job，同样一个Ge Job也只能加载一个数据库表
输入参数：无
基本流程：
Ø 调用Tr和Ld Job的基本流程
Ø 调用存储过程的基本流程：
JOB名：IEx******
功能： 该Job调用SAP的ABAP程序或BAPI程序抽取SAP源系统的Table或结果集，将抽取的结果写入EXF文件，IExAUTO******抽取AUTO系统的数据源，IExAPO******抽取APO系统的数据源。用于被IGc的Job调用。
输入参数：
对于IExAUTO******的Job，其输入参数
| 参数名称 | 参数类型 | 说明 |
| rundate | String | 数据日期，格式yyyymmdd |
| rootpath | String | ETL根目录 |
| autouserid | String | 连接AUTO系统的用户名 |
| autouserpwd | String | 用户密码 |
| a | String | AUTO系统的client Number号 |
对于IExAPO******的Job，其输入参数
| 参数名称 | 参数类型 | 说明 |
| rundate | String | 数据日期，格式yyyymmdd |
| rootpath | String | ETL根目录 |
| apouserid | String | 连接APO系统的用户名 |
| apouserpwd | String | 用户密码 |
| p | String | APO系统的client Number号 |
基本流程(Sample)：
ABAP抽取Sample
BAPI抽取Sample
JOB名：ICs******
功能： 该Job读取EXF文件，完成类型转换、数据变换、Trim空格等任务并将结果写入CIF文件。用于被IGc的Job调用。
输入参数：
| 参数名称 | 参数类型 | 说明 |
| rundate | String | 数据日期，格式yyyymmdd |
| rootpath | String | ETL根目录 |
基本流程(Sample)：
JOB名：ITr******
功能： 该Job读取CIF文件，完成业务逻辑转换(如Lookup、Merge、Aggregation等)任务并将结果写入PLF文件。用于被IGe的Job调用。
输入参数：
| 参数名称 | 参数类型 | 说明 |
| rundate | String | 数据日期，格式yyyymmdd |
| rootpath | String | ETL根目录 |
流程说明：Tr过程比较复杂，根据实际的业务逻辑没有统一的处理流程，但结果都是要生成一个用于预加载的PLF文件，如果业务逻辑非常复杂，很难在同一个Job中完成全部的业务逻辑转换，可以分拆成多个子Tr程序，在程序最后一位用一位数字标识区分不同的Job
JOB名：ITr******
功能： 该Job读取PLF文件，将PLF文件的数据加载到对应的数据库热物理表中，同时将拒绝的记录写入到拒绝文件中。用于被IGe的Job调用。
输入参数：
| 参数名称 | 参数类型 | 说明 |
| rundate | String | 数据日期，格式yyyymmdd |
| rootpath | String | ETL根目录 |
| dwuserid | String | 数据库登录用户名 |
| dwuserpwd | String | 用户密码 |
| servicename | String | 数据库服务名 |
基本流程(Sample)：
为了提高ETL JOB的灵活性，需要设置一些公共的环境参数供JOB在运行过程中动态使用，这些参数在运行过程中可以由运行人员根据实际的运行情况进行调整，这些参数设置在JobParams.cfg文件中。
JobParams.cfg文件是一个文本文件，每一行代表一个参数，每一行由三个Field组成，格式如下：
EncryptFlag:ParamName=ParamValue
其中EncryptFlag为参数加密标识，”N”表示非加密存放，即参数值(ParamValue)为明文，”E”表示加密存放，即参数值(ParamValue)为密文
ParamName为参数名称
ParamValue为参数取值，根据EncryptFlag加密或明文存放
本部分内容在开发过程中根据实际开发的需要不断补充修改。以下是JobParams.cfg文件中的参数定义列表
| 参数名称 | 取值说明 | 备注 |
| Runday | 格式yyyymmdd | 当前ETL数据日期 |
| Rootpath | E:\***ETL | ETL JOB在ETL Server上使用的根路径 |
| servicename | 数据仓库服务名 | |
| Dwuserid | 数据仓库用户ID | |
| dwuserpwd | 数据仓库用户密码 | |
| autouserid | SAP R/3 AUTO系统用户ID | |
| autouserpwd | SAP R/3 AUTO系统用户密码 | |
| A | SAP R/3 AUTO系统用户Client Number | |
| apouserid | SAP APO系统用户ID | |
| apouserpwd | SAP APO系统用户密码 | |
| P | SAP APO系统用户Client Number | |
| dsnname | 数据仓库数据库配置的ODBC的DSN名。 | |
| keepfilecycle | 中间文件在系统上的保存天数。 | |
| jobdate | 针对Job设置的运行日期，用于根据此值判断在SAP系统的前置JOB的运行状态，本项目中一般设为RunDate+1。 |
在DataStage Job开发过程中，将公共功能做成routine可供多个Job使用，以RT开头
功能：取指定日期上一日的日期
输入参数：
| 参数名称 | 参数类型 | 说明 |
| currentdate | Char(8) | 格式yyyymmdd |
输出结果：
| 参数名称 | 参数类型 | 说明 |
| outputdate | Char(10) | 上一日日期,格式yyyy-mm-dd |
调用示例：
RTGetYesterday(“20031122”)返回2003-11-21
功能：将yyyymmdd格式的日期转换为yyyy-mm-dd格式
输入参数：
| 参数名称 | 参数类型 | 说明 |
| currentdate | Char(8) | 格式yyyymmdd |
输出结果：
| 参数名称 | 参数类型 | 说明 |
| outputdate | Char(10) | 转换后日期,格式yyyy-mm-dd |
调用示例：
RTFormatDate(“20031122”)返回2003-11-22
功能：将指定日期增加指定的偏移值
输入参数：
| 参数名称 | 参数类型 | 说明 |
| curtime | Vahar2(20) | 指定日期，格式YYYY-MM-DD HH:MI24:SS |
| Flag | char(1) | 偏移数的单位(时、分、秒)，目前只能取值为”H”或”h”，表示小时 |
| num | Integer | 偏移数，取值只能是正数 |
输出结果：
| 参数名称 | 参数类型 | 说明 |
| outputdate | Vahar2(20) | 转换后日期,格式YYYY-MM-DD HH:MI24:SS |
调用示例：
RTDateAdd(“2003-11-22 17:02:02”,”H”,8)返回”2003-11-23 01:02:02”
功能：删除指定的目录或文件
输入参数：
| 参数名称 | 参数类型 | 说明 |
| Type | char(1) | 删除类型，取值为：D—目录F—文件 |
| path | Vahar2(200) | 目录或文件路径 |
输出结果：
| 参数名称 | 参数类型 | 说明 |
| retflag | char(1) | 执行结果标识，取值为：0—执行成功其它—执行失败 |
调用示例：
RTDel(“D”,“E:\***etl\20031122”)返回0，表示删除目录E:\***etl\20031122成功
功能：加密指定的字符串
输入参数：
| 参数名称 | 参数类型 | 说明 |
| strText | Vahar2(200) | 需要加密的字符串 |
输出结果：
| 参数名称 | 参数类型 | 说明 |
| retStr | Vahar2(200) | 返回加密后的字符串 |
调用示例：
RTEncryptStr(“abcd”)返回加密后的字符串
功能：解密指定的字符串
输入参数：
| 参数名称 | 参数类型 | 说明 |
| strText | Vahar2(200) | 需要解密的字符串 |
输出结果：
| 参数名称 | 参数类型 | 说明 |
| retStr | Vahar2(200) | 返回解密后的字符串 |
调用示例：
RTDecryptStr(“abcd”)返回解密后的字符串
功能：执行指定的存储过程
输入参数：
| 参数名称 | 参数类型 | 说明 |
| dsnname | Vahar2(200) | ODBC的DSN Name |
| dwuserid | Vahar2(200) | 登录数据库的用户名 |
| dwuserpwd | Vahar2(200) | 用户密码 |
| spname | Vahar2(200) | 要执行的存储过程 |
输出结果：
| 参数名称 | 参数类型 | 说明 |
| retcode | intger | 返回代码，取值为：0—执行成功其它—执行失败 |
调用示例：
RTexecsp(“sp_etl_ippe_ewo_hist()”)返回0表示执行存储过程sp_etl_ippe_ewo_hist成功
功能：执行指定的SQL语句
输入参数：
| 参数名称 | 参数类型 | 说明 |
| dsnname | Vahar2(200) | ODBC的DSN Name |
| dwuserid | Vahar2(200) | 登录数据库的用户名 |
| dwuserpwd | Vahar2(200) | 用户密码 |
| stmt | Vahar2(200) | 要执行的SQL语句 |
输出结果：
| 参数名称 | 参数类型 | 说明 |
| retcode | intger | 返回代码，取值为：0—执行成功其它—执行失败 |
调用示例：
RTexecstmt(“select * from ippe_ewo_hist”)返回0表示执行成功
功能：从参数配置文件中读取指定参数的取值
输入参数：
| 参数名称 | 参数类型 | 说明 |
| rootpath | Vahar2(200) | ETL根目录 |
| ParamName | Vahar2(200) | 参数名 |
输出结果：
| 参数名称 | 参数类型 | 说明 |
| ParamValue | Vahar2(200) | 参数值 |
调用示例：
RTGetParamValue(“E:\***ETL”,“rundate”)返回”20040209”
功能：将指定的参数写入参数配置文件中
输入参数：
| 参数名称 | 参数类型 | 说明 |
| rootpath | Vahar2(200) | ETL根目录 |
| ParamName | Vahar2(200) | 参数名 |
| ParamValue | Vahar2(200) | 参数值 |
| EncryptFlag | char(1) | 加密存放标识，取值为：Y—加密存放N—明码存放 |
输出结果：
| 参数名称 | 参数类型 | 说明 |
| retcode | Integer | 返回值，取值如下：0--写入成功其他—失败 |
调用示例：
RTWriteParamValue(“E:\***ETL”,“rundate”,”20040209”,”N”)返回0表示写入成功
功能：取当前系统时间，格式YYYY-MM-DD HH:MI24:SS
输入参数：无
输出结果：
| 参数名称 | 参数类型 | 说明 |
| curtime | Vahar2(20) | 当前时间字符串，格式YYYY-MM-DD HH:MI24:SS |
调用示例：
RTGetCurTimeStamp()返回”2004-02-09 16:00:00”
功能：删除空的Reject文件，主要用于删除由DataStage产生的实际不包含拒绝记录的拒绝文件
输入参数：
| 参数名称 | 参数类型 | 说明 |
| FileName | Vahar2(200) | 包含完整路径的文件名 |
输出结果：
| 参数名称 | 参数类型 | 说明 |
| Erroode | Vahar2(200) | 由Del命令返回的错误码,0表示执行成功 |
调用示例：
RTDelNullRejFile(“E:\***ETL\REJ\abc.rej”)返回0表示删除文件成功
初始ETL程序的架构与日常ETL基本一致，以下主要针对其不同点专门予以说明
从上图可以看出，初始ETL与日常ETL主要的的不同有以下几个方面：
Ø 初始ETL不再设计Schedule Job，这是因为初始加载只需要在系统上线之前一次性完成，而这个加载过程是通过手工完成
Ø 初始ETL需要开发部分的Sequencer Job(NSe开头)、针对CIF的Group Job(NGc开头)、抽取Job(NEx)、ABAP及BAPI程序，主要是针对日常ETL中做增量抽取的Job在这里需要改写为完全抽取，实际上这些Job或程序的开发可以通过将对应的日常ETL Job复制一份然后修改其中的抽取条件即可
另外需要注意的是，由于没有单独针对初始ETL设计Load程序，因此在使用初始ETL加载数据之前应先手工删除需要加载的数据库表的数据
开发需check以下环境是否ready:
1 SAP开发用测试数据源准备就绪
2 数据仓库的Oracle数据库准备就绪，ETL要加载的表已创建
3 ETL Server的相关软件(DataStager Server及MetaStage)已安装就绪
4 ETL Server与SAP数据源及目标Oracle数据库的连接已通过测试
5 在ETL Server上创建与Oracle连接的ODBC已创建
6 在ETL Server上创建开发人员的用户
7 在ETL Server上设置共享使开发人员可以访问的中间文件目录
1 开发ETL mapping文档确定每个源表的数据抽取规则(确定增量还是完全抽取)
2 开发ETL mapping文档完成源-EXF-CIF对照关系及CIF-PLF-目标的对照关系
3 开发Component JOB完成ETL每个子任务
4 开发Group Job完成对Component Job的封装
5 开发Job Dependence文档定义Group Job之间的依赖关系
6 根据Job Dependence文档开发Sequencer Job
7 根据Sequencer Job开发对应的Schedule Job
8 根据业务状况设定合适的Schedule自动完成批量数据表的加载
1 确定需要开发初始抽取的数据源范围，即列出需要开发初始加载程序的数据源列表
2 开发相应的ETL抽取JOB
3 开发相应的Group Job完成ETL抽取及变换任务的封装
4 根据Job Dependence文档开发Sequencer Job
5 手动运行Sequencer Job完成批量数据表加载
只有细节表才可能要求有历史数据加载
1 确定需要历史加载的数据表范围，即列出需要开发历史加载程序的数据表列表
2 开发ETL mapping文档确定每个源表的数据抽取规则
3 开发ETL mapping文档完成源-EXF-CIF-PLF-目标的对照关系
4 开发ETL JOB完成ETL加载任务
ETL的实施是一项繁杂而艰巨的任务，必须有很好的内部组织及管理方法才能够保证顺利地实施，ETL Team的各成员通过有效地分工合作来保证各项任务的顺利进行， ETL Team的角色组成如下：
| 角色 | 人数 | 职责 | Own的程序及文档 |
| Team Leader | 1人 | 1 Team内部及与其他Team的问题协调与处理2 分配开发任务3 跟踪及控制开发进度 | 文档：<ETL工作周报><ETL任务分配及跟踪表> |
| 架构设计人员 | 1人 | 1 设计ETL系统架构2 制定开发的策略、规范、原则3 为开发人员提供指导及根据开发反馈修改完善系统设计4 review ETL程序 | 文档：<ETL Design> |
| Mapping开发人员 | 1-2人 | 1 与Model组及源系统相关人员交流完成ETL Mapping设计2 指导ETL Job开发人员理解Mapping并根据开发人员的反馈完善Mapping设计 | 文档：<EXF2CIF Mapping><CIF2PLF Mapping> |
| EX/CS/LD/GC/GE Job开发人员 | 1人 | 1 根据ETL Mapping遵循开发规范开发EX/CS/LD/GC Job2 与TR开发人员交流开发对应的GE Job3 如果开发过程中遇到开发规范无法支持的问题及时向架构设计人员反馈 | 程序：ES JobCS JobLD JobGC JobGE Job |
| TR Job开发人员 | 多人（根据实际开发任务及Schedule确定） | 1 根据ETL Mapping遵循开发规范开发开发TR Job2 如果开发过程中遇到开发规范无法支持的问题及时向架构设计人员反馈 | 程序：TR Job |
| Routine及公共Job开发人员 | 1人 | 1 开发公共Routine并为使用人员提供使用指导2 与其他ETL Job开发人员交流维护<Job Dependence>文档并开发相应的Dependence Job3 开发Schedule Job、Maintance Job | <Job Dependence>Schedule JobDependence JobMaintance JobRoutine |
| SAP BAPI开发人员 | 1人 | 1 BAPI程序开发2 程序文档维护 | 程序：BAPI程序文档：<BAPI程序说明> |
| Store Procedure开发人员 | 1人 | 1 Store Procedure开发2 程序文档维护 | 程序：Store Procedure文档：<存储过程说明> |
结合项目的实际情况，以上角色可以被兼任。
本章详细描述如何通过ETL如何控制数据的质量及因为数据质量问题的相关处理措施
在ETL过程中需要做下列3种类型数据质量检测方式：
² 格式（Formatting）及对照（Mapping）检查：确保ETL过程中的格式变换的正确，并且各字段的转换和计算正确。
² 记录数平衡检查（Count Balance）：验证ETL各步骤中输入和输出的记录数没有变化，记录数平衡检查可以确认ETL程序运行中没有丢失或重复记录。
² 参照完整性（Referential Integrity）检查：检查数据是否遵照数据模型定义的数据实体的参照关系，即Identify关系中，是否每个子实体中的记录都能够对应相应的父实体中的记录，RI检查保证数据仓库中实体间逻辑关系的正确。
格式及对照检查和记录数平衡检查相辅相成，前者确保入库记录中的每个字段符合要求，后者保证源数据中所有记录都被处理到，没有遗漏或重复。
参照完整性检查通过Lookup等手段，确认入库的数据是否符合业务逻辑关系，前面2种检查强调的是每个数据实体的正确性，而参照完整性检查则强调于数据实体之间关系的正确性。通过参照完整性检查，也可以发现源数据中的质量问题，例如，在把数据中的地区名称转换为地区代码时，可以部分地检查到源数据中的地区名称是否是规范或准确。
在实现上，格式及对照检查在测试阶段完成，它是系统测试阶段的重要工作，根据测试案例，以人工或测试程序来检测数据的每个字段是否都准确按照数据对照的要求进行转换。
记录数平衡检查需要在每一次ETL运行时进行，以确认当次运行过程的正常，没有出现程序错误、系统错误或其他运行过程的错误，通过记录数平衡检查，对程序进行长期跟踪，对ETL程序的维护提供重要的线索。记录平衡检查由DataStage工具在运行过程中自动完成的，运行人员可以通过查看运行的日志，获得ETL每个步骤的输入输出记录数据，如果检查到某个ETL步骤的记录数不平衡，则应检查ETL程序是否存在异常。
多数参照完整性的检查过程也是包含在程序中，在每次ETL运行过程中被执行。很大一部分参照完整性检查是在数据翻译（lookup）和数据合并（Merge）的过程中实现，如果数据翻译时找不到对应的数据，则表明存在参照完整性问题或是源数据存在错误。根据需要，也可以在Mapping程序中编写专门的参照完整性检查的逻辑，对必要的参照完整性进行检查。并非所有数据模型中的参照（外键）关系都需要进行检查，因为源数据质量原因，可能存在部分数据的父数据已经无法得到，但该数据仍然需要入库，则不应该对其进行参照完整性检查。
ETL在加载步骤中可能产生Reject文件，拒绝文件中记录加载过程中被拒绝数据，数据的格式与PLF文件一致。
对于在ETL过程中Reject的数据，由技术部门根据Job运行的Reject日志，完成拒绝文件分析报告，业务部门该分析报告及Reject数据文件查看源数据，并将源数据修复，等业务部门将源数据修复以后，重新加载相关的数据。
如果数据在入库一段时期后才发现源数据存在错误，就需要对入库数据进行相应修改，修改过程需要手工完成，不同数据的错误的涉及面也不相同，处理也不会相同，针对不同的错误相应采取不同的应对策略。
u 如果是定期更新的不含历史的数据的表，如字典表等只需等源数据修改以后重新运行ETL进程即可。
u 如果是包含短期历史数据的细节表，根据源数据的修改经由数据管理人员签字认可后可直接修改数据仓库的相应数据
u 如果是包含历史的维度表，则要视错误发生的字段不同而相应处理也不同
² 如果只是维表本身使用的属性字段发生错误，则直接修改该数据本身即可
² 如果是用来给其他表做参照的关键字段发生错误，则需要分析其影响，除了修改维表本身的数据以外，还要将其影响到的数据表中相应的使用到该参照数据的地方做对应修改，如果数据量较小，通过手工比对进行修改，如果数据量较大，则可能需要写专门的程序分析并修改相应的数据
关键源数据质量问题所引起的维护成本相当昂贵，对业务不稳定，而且数据源质量较差的数据入库，将导致很多维护工作。由于数据仓库在运行的初期一般数据质量都不是特别可靠，因此数据仓库设计的初始阶段应尽量避免设计汇总表，而将一部分力量投入到数据源的规范和管理上，减少错误频度。对ETL过程发现的源数据质量后应及时修正，并积极制定相应策略，对源数据进行管理规范化。
对错误数据的更正也不单单是数据库开发和维护人员的事，源数据的维护人员，特别是产生业务数据的业务部门的参与和协调非常重要。这项工作的具体实施策略需要权衡考虑业务部门的源数据质量情况、业务上对数据准确性的要求、IT人员的工作量和项目的进度以及数据仓库系统的状况等各个方面，才能得到各方都比较满意的效果。
附录 I. ETL Mapping文件文档模板
包括EXF2CIF的Mapping和CIF2PLF的Mapping，分别参见EXF2CIF Template.xls及CIF2PLF Template.xls文档
附录 II. ETL Data Flow文档模板
参见ETL Data Flow Template.xls
附录 III. ETL Job Dependency文档模板
参见job dependency Template.xls文档
