设计规范
抽取加载策略设计文档
- 节点名称，与目标表一致
- 负责人
- 源表、目标表
- 抽取方式、加载策略
- 增量新增数据的判断条件
- 是否支持重复执行
ETL 映射设计文档
- 节点名称，与目标表一致
- 所在层级、所属 Job
- Job 中的位置、上游节点名称
- 负责人
- 参数列表
- 源表、目标表
- 字段映射转换关系
- 是否支持重复执行
调度设计文档
- 顶层调度有几个
- 顶层 Job 调度时机
- 顶层调度参数列表
- 每个 Job 内的任务调度顺序编排
- 调度是否支持重复执行
- 调度是否支持并行
开发规范
命名规范
- Job 命名规范：J_层次名_内容描述
- 节点命名规范：跟目标表一致
- 参数命名规范：统一命名，禁止私自创造
代码编写原则
- 代码清晰、整齐，易读性高。
- 代码编写要充分考虑执行速度最优原则。
- 代码行整体层次分明、结构化强。
- 代码中应有必要的注释以增强代码的可读性。
- 规范要求非强制性地约束代码开发人员的代码编写行为。在实际应用中，只要不违反常规要求，允许存在可理解的偏差。
代码开发规范
- 脚本是否有备注、复杂计算逻辑是否有注释。
- 任务是否支持多次重跑而输出不变，不能有直接 insert into 语句。
- 分区表是否使用分区键过滤并且有有效裁剪。
- 外连接的过逑条件是否使用正确，例如在左连接的 where 语句存在右表的过滤条件。
- 关联小表，是否使用/*+ map join * /。
- 不允许引用别的计算任务临时表。
- 原则上不允许存在一个任务更新多个目标表。
- 是否存在笛卡尔积。
- 禁止在代码里面使用 drop、create、rename 等 DDL 语句。
- 使用动态分区时，有没有检查分区键值为 NULL 的情况。
- 对于重要的任务 DQC 质量监控规则是否配置，严禁裸奔。
- 代码中有没有进行适当的规避数据倾斜语句。
日志输出规范
- 每个任务节点，都需要输出成功/失败标志，如果失败最好输出错误信息。
- 每个 Job 也要输出成功/失败标志，如果失败必须输出失败任务节点名称。
部署规范
调度部署
- 需要定义清楚，每个工作流应该部署到哪台服务器的哪个目录下边；
- 需要定义清楚，ETL 服务器的目录结构；
- 调度其实不需要过多了解工作流的内部情况，只需根据工作流的使用说明书，做好如下二件事情即可：
- 在合适的时间调度执行；
- 监控工作流的执行情况，报错或超时的时候发出告警，开始或者结束的时候发出通知；
流程依赖
- 根据节点间的依赖关系、每个节点的资源消耗和每个节点的执行耗时，去合理编排流程；
- 有依赖的必须串行，无依赖可以并行用于降低总执行时长、
- 同时也要注意任务并行会增加瞬时资源消耗；
- 注意：流程依赖里配置的执行先后顺序，后执行的不一定就真的依赖于先执行的任务节点；
调度配置
- 具体到调度层面，需要把每个工作流都打上如下标签（使用说明书）：
- 允许的最早调度时间（需要考虑前置依赖或数据源就位时间）；
- 允许的最晚结束时间（如有）；
- 参数列表以及默认值；
- 告警通知人列表；
- 是否支持重复跑；
- 是否支持并行补多个日期数据；
经验之谈
- 注意保留执行过程中的日志记录；
- 补数、重跑情况下的参数传递问题；
- 内层工作流或底层节点绝对不能把参数（主要是日期）写死；
- 需要在调度工作流的时候，工作流内的所有节点都能接受到来自外层传入的参数；
- 尽量的将可以重复跑的、和不能重复跑的节点，放到不同的工作流；
- 尽量的将可并行补多个日期数据的节点、跟不能并行补数的节点放到不同的工作流；
