前言：
以下是工作中关于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 值排序。
----未完待更新
