Datastage 作业开发规范说明

前言:

以下是工作中关于Datastage 开发过程中必须以及应该注意的规范事项。

1.关于直接路径加载

规范说明:

针对使用数据库Oracle链接类Stage (Connector ,Enterprise)进行Append 数据加载模式时,要求设置Stage的Index Mode 选项为:

1)对于存在唯一索引的,要求必须重建Index;

2)对于非唯一索引类型,不重建索引。

2.制定此规范的原因:

          使用Append Load数据时,针对唯一索引的表,必须重建索引,如果不设置Index Mode选项Job 运行时会报“索引失效”错误而失败。

案例:Datastage Oracle Connector 控件批量加载数据 

2.与数据库保持一致

规范说明:

在数据库类Stage中,除引用源系统的表或对表进行Truncate操作时,其他任何对表的引用应该使用同义词。

2.制定此规范的原因:

根据数据库对象管理规范要求,Datastage也要统一,确保一致执行。

3.样例:无

3.日志尽量不要有Warning出现

规范说明:

Job开发调试或调度运行过程中,Job日志信息不允许有Warning告警信息出现。

2.定制此规范的原因:

 a>Warning信息的出现,实际上是提醒或提示Job中可能存在一定的风险或缺陷,可能会在特殊场景下风险就变为问题缺陷。

 b>养成合理的开发习惯,不仅有利于提升代码质量和程序的健壮性,警告信息会造成日志写入Log的I/O消耗,消耗系统资源。

 c>为了保证开发代码质量,针对开发过程中的日志警告信息,要求开发人员认真调试及处理,确保不出现Warning告警信息。

4.一般不要轻易打开Unicode扩展

规范说明:

通常情况下,Job来源和目标数据源字符集类型是一致的,将Column的数据类型定义为Char 或Varchar 类型时,规定不允许打开Unicode扩展;但当Job来源和目标数据的字符集类型不一致时,要勾选Unicode属性。

 备注:Stage选择加载表的元数据结构时,不勾选“所有字段使用”Unicode”选项,即可确保加载Columns就不会打开Unicode属性。

2.制定此规则的原因:

Unicode属性会对数据做严格校验,当来源和目标端字符集类型一致情况下,校验就会影响Job性能,特明确作为规范要求定制。

案例:Datastage 记一次编码转换问题

5.作业里面控件不要太多

规范说明:

每个Job使用的Stage数量要求不超过30,超过此上限,应该拆分为多个Job实现。

2.制定此规范的原因:

 一个Job Stage 数量太多,会产生大量进程导致系统资源繁忙,不利于系统并发应用及性能优化;合理的落地次数,可以保证Job逻辑层次清晰,有利于平稳运行和应用维护。

6.使用调度工具来进行统一调度

规范说明:

对于自动调度的ETL Job ,不能将Job 使用SEQUENCE来建立Job运行前后关系,建议直接在任务调度器中设置。

2.制定此规范原因:通过参考业界经验和测试,Sequence在被调度时稳定性不好,容易导致调度异常,同时Sequence使用通常情况下是封装多个Job来一起而非单个Job,若一个Job报错,就要整个Sequence失败重做,不利于Job单元的维护。

7.对于复杂作业写明描述

规范说明:

新增或修改Job,应该使用Description Annotation Stage 填写Job的简要描述信息。包含创建/修改开发人员,创建/修改日期,创建/修改简要功能等项信息,其中描述信息格式如下:

开发人员信息:姓名首字母+8位工号。

创建/修改日期:以YYYY-MM-DD格式书写。

创建/修改简要功能;使用核心精简文字描述。 

Job开发过程中,针对逻辑比较复杂的Stage处理,应该使用Annotation Stage 增加模块信息注释。

2.制定此规范的原因:

增加描述说明信息有利于代码维护和技术支持。

8.对目标表入库方式

规范说明

数据装载时,要求操作方式如下:

1.对于全量加载,应该采用 Tuncate Load 方式;

2.对于增量数据仅进行插入操作时,应该使用Insert 方式,禁止使用Update方式;

3.对于增量数据同时进行插入及更新操作时,应该使用Update then Insert 的方式,禁止使用Insert then Update。

2.制定此规范的原因:

老版本规范是根据实际数据比例(Update 的比例大于30%以上时,使用Update then Insert 方式,Update的比例小于30%时,采用Insert then Update)

灵活运用加载方式,但TS运维部门提出生产环境Job运行使用Insert then Update 经常 倒挂住 或者性能较慢等异常情况,再更改为Update then Insert 后重跑运行正常,为了保持调度的稳定性,对增量数据既有插入又有更新操作时调整为Update then Insert 的方式

9.对于环境变量要应用,不要写死

规范说明:

Job开发过程中,对于可引用工程环境变量参数的必须使用参数,不容许自定义配置写死,目标表数据库连接配置(Source,user_name ,user_passowrd),调度(start_date,end_date)和临时文件路径(file_path)等。

2.制定此规范的原因:

统一管理Job参数,便于环境迁移及同步管理。

10.Aggregator Stage 的优化

规范说明:

使用Aggregator Stage 进行分组时,建议选择项中的Mode属性设置如下:当 group by 分组数小于1000,建议使用Hash 方法以获得较好的性能;当分组数大于1000,建议使用Sort 方法。

2.制定此规范的原因:

    为了获得更好的性能,建议结合应用情况灵活设置,具体原因如下:

    当Group key 值数量很大时,将Method 该为Sort,default 值为Hash ,Hash方法需要为每一组Key值分配一个内存,当Key值很多时,日志会有警告,最终会引起资源不足导致Job失败。由于Aggregator Stage 需要Input Link 的数据事先排序,可以在Aggregator Stage的Partition 页中选用Hash 方式对Group Key 值排序

—-未完待更新

打赏

觉得本站还不错就打赏一下吧!

支付宝扫一扫打赏

微信扫一扫打赏

本站所有内容均来自于互联网自动采集,如无意侵犯了您的权利,请您发送邮件到admin@chinaetl.com.cn联系管理员删除。
ChinaETL » Datastage 作业开发规范说明