TL规范概述

1.1 ETL含义:ETL是数据抽取(Extract)、转换(Transform)、装载(Loading)的缩写。

           数据抽取:从数据源获取所需数据的过程。数据抽取过程会过滤掉目标数据集中不需要的源数据字段或数据记录。

           数据转换:按照目标表的数据结构,对一个或多个源数据的字段进行翻译、匹配、聚合等操作得到目标数据的字段。

           数据转换主要包括:格式转换、字段合并与拆分、数据翻译、数据匹配、数据聚合其他复杂计算。

           数据装载:将数据加载到目标数据库中。

1.2 ETL应用:完整的ETL应用过程包含三个阶段:

           设计阶段:分析源和目标数据集的数据结构,定义合理的数据转换逻辑。

           实施阶段:按照设计阶段制定的逻辑规则进行编码,实现数据的E、T、L过程。

           维护阶段:对于非一次性数据整合项目,ETL过程需要重复执行,同时也需要不间断的维护和完善。

1.3 规范制定目的:ETL规范是为保证ETL正确设计、实施和维护所定义的一些规则和方法,具体包括ETL设计规范、开发规范以及维护规范。

1.4 设计规范

   设计规范主要应用于ETL编码的前期工作。本阶段要形成多个关于数据流的在不同层次的映射(Mapping)文档。

1.4.1 Mapping应该包含以下几个部分:

         数据源的相关属性,包括:实体名称—含DSN、所有者等信息;字段名—英文名称;字段简述—中文名称,如为参数信息应该有相关取值解释,如性别字段(1:男;2:女;0:不详);类型—字段类型,含长度和精度信息;非空属性—字段是否可以为空;

         目标数据集的相关属性,包括:实体名称—含DSN、所有者等信息;字段名—英文名称,建议根据字段含义来命名,而不是简单用拼音来定义字段(此部分由负责设计数据集的人员控制);字段简述—中文名称,对于保留字段应该给出默认值;类型—字段类型,含长度和精度信息;非空属性—字段是否可以为空;

          规则,主要描述ETL各个环节的转换规则,包括:数据源过滤规则—描述从源数据集获取数据过程中过滤掉记录的规则;关联规则—当源数据集为多个时,描述相互之间的关联关系;列转换规则—描述源数据集到目标数据集的字段间的转换规则(业务逻辑相关);目标数据集更新规则—描述目标数据集的更新策略,包括更新机制和更新频度,如每日全量更新、每周增量更新;

1.4.2 ETL作业列表—ETL所开发的作业之间包含一定的业务逻辑和编码逻辑,所以调度过程中应遵循一定的逻辑顺序,包括:

         作业名称—实现Mapping的作业名称,包括该作业功能描述;

         调度顺序—用序号或者是流程图模式描述作业的调度顺序,需要综合考虑业务逻辑、编码逻辑以及系统资源等多方面情况,在保证业务逻辑和编码逻辑的基础上,通过控制调度,最大限度地合理利用系统资源;

         参数列表—列举每个作业中所使用的参数,不同作业中的相同参数最好使用相同的名称,便于调度时进行控制;

1.4.3 版本管理

        ETL设计会随着对业务、系统理解的深入以及结构框架的变化而发生变化,所以Mapping设计也应该同步更新。在开发过程中,要严格遵守一个规则:当规则发生变更时,要先变更Mappig,然后才变更相应的作业设计。在Mapping变更管理方面,应该有详细的版本变更记录,以便追踪到ETL开发的变动情况。变更记录包括如下内容:

        版本—每次变更应给出一个新的版本号;作者—变更人;更新时间—变更时间;更新内容—简要说明变更内容;备注—可用于记录变更的原因等相关信息;

1.5 开发规范

    为保证项目开发各个时期的平稳过度及顺利交接,在开发过程中,应该遵循一定的开发规范。主要包括:命名规范、功能定义规范、结构规范

1.5.1 命名规范,规则如下

1.5.1.1 JOB命名规范    

       逻辑层_业务领域_目标表[_ALL][_序号]

       CASE1:如果一个job只涉及到一个目标表,则该job命名为:逻辑层_业务领域_目标表[_序号]。

       CASE2:如果一个job涉及到两个目标表,两张目标表为主从表关系,则该job命名为:逻辑层_业务领域_目标主表名_ALL。

       CASE3:如果满足1和2定义的规则出现两个job重名的情况,通过序号区分(序号定义:01,02,…)。

1.5.1.2 JOB中link命名规范

       对于作业内部的Stage与Link的命名,每个stage都赋予标示功能的名称,此外在作业设计界面内适当加上注释信息,主要包括作业功能说明、所属模块、开发时间、开发人员等信息。

Elements

Description

Example

Stages

Name_Desc

DB2_Product、Lkp_Product

Links

StageToSatge

LkpToAgg、SortToDb2

Connection Type

Native

Stage_Databse

DB2_DC

ODBC

ODBC_DBType_ODBCName

ODBC_IQ_TDC

1.5.1.3 文件定义:

      作业设计过程中不可避免要使用文件作为中间存储或者最终结果输出,在DataStage里,使用Sequential File Stage来定义顺序文件。对于Sequential File Stage,通常遵循以下规则进行定义:

      文件名:逻辑层_业务领域_功能_FILENAME,其中:

      功能:根据文件的目的进行存放,例如EXF(抽取),LD(装载),REJ(拒绝)

1.5.1.4 ETL参数规范

      参数与变量的命名统一为大写,单词或者简拼间用下划线(“_”)连接。其中各个字后不要有空格,遵循参数名=参数值的写法,一行一个参数。参数文件如下图所示

      参数的设置:

      CASE1:创建参数集Parameter Set:在参数集中添加该Project需要的参数,供各个Job调用。

      CASE2: 在job运行时,通过在Sequence Job里将具体的参数文件名传给参数集。

      一般项目中参数会分为以下几种情况:

      CASE1:参数值缓慢变化或者基本不变的参数。这类参数主要分为以下三种:

      CASE1.1:用来标识记录来源的APP_CODE字段以及数据库访问的模式名。

      CASE1.2:数据库连接相关参数。

      CASE1.3:临时输出的一些文本文件路径信息。

      CASE2:参数值经常变化的参数。这类参数主要分为以下两种

      CASE2.1:控制抽取数据的起始截止时间

      CASE2.2:以具体项目中业务为依据

      对于第一类参数的处理方式:

      DEAL_CASE1.1:定义参数集PARA_SET_APPCODE和PARA_SET_SCHEMA。PARA_SET_APPCODE定义所有用来标识源系统的参数名和参数值。PARA_SET_SCHEMA定义所有用来访问数据库的模式名称。PARA_SET_APPCODE对应的值文件为PARA_SET_APPCODE.txt,值文件PARA_SET_APPCODE.txt存储路径在IIS安装目录下:$PROJECT_NAME\ParameterSets\PARA_SET_APPCODE\PARA_SET_APPCODE.txt。PARA_SET_SCHEMA中对应的参数指定访问各个数据源数据库的模式名,PARA_SET_SCHEMA对应的值文件为PARA_SET_SCHEMA.txt,值文件PARA_SET_SCHEMA.txt存储路径在IIS安装目录下:$PROJECT_NAME\ParameterSets\PARA_SET_APPCODE\PARA_SET_APPCODE.txt。

      DEAL_CASE1.2:连接数据库的处理方式:在DataStage中定义数据连接对象,数据连接对象中参数我们在定义的时候赋参数值,在job中装载对应的连接对象。因为数据连接对象比较少,所以我们不采用传递参数值的方式去维护数据连接对象中需要的用户名、密码等相关参数。

      DEAL_CASE1.3:临时输出的一些文本的路径信息处理方式:我们将路径信息定义到环境变量中。定义Ds_File_Temp_Dir和Ds_File_Error_Dir两个环境变量。变量Ds_File_Temp_Dir的值是IIS安装目录下路径:$PROJECT\ds_file_temp,其中存放的job在运行过程中生成的临时中间文件。需要先在对应目录下创建文件夹ds_file_temp。变量Ds_File_Temp_Dir的是IIS安装目录下的路径:$PROJECT\sdetl\ds_file_Error,其中存放的是job运行过程中的一些关于数据质量的出错信息。关于数据质量的错误信息是在设计job的时候指定输出到文本的。需要先在对应目录下创建文件夹ds_file_Error。

      对于第二类参数的处理方式:

      DEAL_CASE2.1:定义参数集PARA_SET_业务领域_DATA。PARA_SET_业务领域_DATA中定义了所有的与日期相关的参数,参数的值是通过参数集值文件的方式提供的。每个业务领域都对应一个参数值文件用来分别控制本业务领域时间参数的设定。每个业务领域对应的参数集值文件是通过ETLjob自动生成。

      DEAL_CASE2.2:根据具体项目业务决定。

1.6 维护规范

     通常在ETL运行结束后,获取相关日志信息并记载到数据库中是一个较好的处理方法。对基于DataStage的开发,可以提供一套完整的日志处理方案,获取日志信息)由代码开发,将日志写回数据库,可以进行简单修改将日志导入数据库等容器中生成维护报告。

1.6.1日志文件报告

     汇总报告:SEQ作业,包含JOB数量,WARNING作业数,成功作业数,失败作业数,开始时间,结束时间….

     详细报告:SEQ作业名称,JOB名称,开始时间,结束时间,运行状态….

1.6.2 JOB维护文档

     点击文档中JOB的名称,可以提供JOB MAPPING设计。

1.6.2 备份、恢复与版本控制

     ETL系统的备份主要是对ETL运行环境备份。

     运行备份是指为保证如果运行的ETL系统崩溃时可以通过备份的ETL系统继续完成ETL的工作,为达到这个目的,应安装两台DataStage环境,并建立相同的配置,其中一台处于运行状态,而另一台为待机状态。每日在日常ETL完成后对运行环境的各文件进行备份,即将ETL的运行目录转储到外挂磁盘或外部存储介质。

ETL系统的恢复主要是运行恢复。

     运行恢复是指当运行系统遇到严重故障如硬件故障、操作系统崩溃等无法及时修复时,启用备份的运行系统继续,通过将上一日备份的ETL环境恢复到待机系统,然后启动待机系统运行日常ETL。