基于DataWorks构建数据中台

DataWorks实战3-业务流程开发之约定配置

2020-11-23  本文已影响0人  子沐然

使用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


喜欢的朋友请帮忙点赞,谢谢大家!

上一篇 下一篇

猜你喜欢

热点阅读