使用DataWorks开发过程中会存在各类配置，面对如此多的配置，如果不进行规范化的约定，后期业务过程将面临难以维护，参数定义冗乱等问题，在这里我将自己的参数定义、约定呈现给大家。

流程节点约定配置：

1、SQ节点名称与节点输出表名称一定保持一致。（数据全量、增量同步业务流程可以不遵从这条，他们分别DI、RI节点）

2、一张数仓表的一定最终是某一个节点输出的，如果存在多个节点输入到同一张表的情况，请修改模型。（ODS层可不遵循，因为存在全量一次性同步到全量表、增量+全量合并到全量表2种情况，后面再介绍数据集成时候会详细说明）。

调度配置约定配置：

1、业务流程在定时调度时，会根据定时任务时间或业务时间过滤表分区中的数据。实践中，我发现使用定时任务时间更符合使用习惯，建议大家使用定时任务时间，即使用$[]方式，不使用${}方式。

2、为规范命名标准，可以按如下约定配置：

昨天日期约定使用ds、year、month、day表示

ds=$[yyyymmdd-1]  表示昨天对应的年月日

year=$[yyyy-1] 表示昨天对应的年

month=$[mm-1]  表示昨天对应的月

day=$[dd-1] 表示昨天对应的日

上一个小时约定使用ds_1h、year_1h、month_1h、day_1h、hour_1h

ds_1h=$[yyyymmdd-1/24]  表示上一个小时对应的年月日

year_1h=$[yyyy-1/24] 表示上一个小时对应的年

month_1h=$[mm-1/24] 表示上一个小时对应的月

day_1h=$[dd-1/24] 表示上一个小时对应的日

hour_1h=$[hh24-1/24] 表示上一个小时对应的小时

3、为节约开发时间，可以在调度配置-参数配置里 直接拷贝如下一段代码，可以满足大部分按分区时间过滤场景。

ds=$[yyyymmdd-1] year=$[yyyy-1] month=$[mm-1] day=$[dd-1] year_2d=$[yyyy-2] month_2d=$[mm-2] day_2d=$[dd-2] ds_1h=$[yyyymmdd-1/24] year_1h=$[yyyy-1/24] month_1h=$[mm-1/24] day_1h=$[dd-1/24] hour_1h=$[hh24-1/24] ds_2h=$[yyyymmdd-1/24] year_2h=$[yyyy-2/24] month_2h=$[mm-2/24] day_2h=$[dd-2/24] hour_2h=$[hh24-2/24]

可能会有实际开发人员疑惑，为什么分区会定义成year、month、day这样，而不是定义成一个ds，其实这是由于dataworks实时同步mysql-binlog日志时会自动生成maxcompute表，该maxcompute表即是这样定义分区的。最佳实践是只有ods层会如此定义分区字段(严格来说ods不属于数仓)，cdm层依然按照ds字段作为分区的日时间字段。

4、ods层数据合并业务流程是定时将（一天或一小时）全量表与增量表数据合并后重写回全量表。在实践中发现，不论是使用DTS还是Dataworks的实时同步功能，将binlog日志同步到增量表时都会存在延迟的情况。如23:59:45秒的日志在第二天00:00:52秒才会入到增量表的昨日分区里。所以进行约定：数据合并业务流程建议在每天/每小时00:05分执行。

5、尽量使用自动解析的依赖配置，且节点的输出名称、节点输出的表名、节点名是一致的。

6、小时任务的业务流程，请配置成"依赖上一周期"，依赖项配置成"本节点"，可以解决大部分天任务依赖小时任务，小时任务依赖天任务问题。

7、调度资源组请务必选择独享调度资源组。平时可以在运维中心-周期任务运维-周期任务页面按"调度资源组"过滤搜索出找出，并修改重新发布。

数据源约定配置：

配置约定：{数据源类型}_{源系统名}_[只读/读写]

譬如：某个pms系统的数据源mysql-rds则配置为:  rds_pms_ro（只读库）、rds_pms_rw(读写库)

          某个los系统的数据源datahub则配置为：datahub_los

喜欢的朋友请帮忙点赞，谢谢大家！