灵活运用DataWorks参数配置-阿里云开发者社区

开发者社区> 阿里云支持与服务> 正文
登录阅读全文

灵活运用DataWorks参数配置

简介: 大家好,本文中笔者要跟大家探讨一下众多DataWorks用户经常遇到的一类问题,就是在DataWorks中如何灵活运用参数配置这个功能。很多用户的需求场景是和时间有关的。为使周期运行的任务能根据运行时间的变化而变化,DataWorks提供了系统参数和自定义参数等两种参数,供用户来使用。

数据工场DataWorks (原大数据开发套件Data IDE) 是基于MaxCompute作为计算和存储引擎的,并用于工作流可视化开发和托管调度运维的海量数据离线分析平台。DataWorks可以按照时间和依赖关系,实现任务的全面托管和调度。在这里,笔者跟大家探讨一下众多DataWorks用户经常遇到的一类问题,就是在DataWorks中如何灵活运用参数配置这个功能。

很多用户的需求场景是和时间有关的。为使周期运行的任务能根据运行时间的变化而变化,DataWorks提供了系统参数和自定义参数等两种参数,供用户来使用。下面来具体介绍下。

一、系统参数

DataWorks(数据工场)提供了 2 个系统参数,定义如下:
${bdp.system.cyctime}:定义为一个实例的定时运行时间,默认格式为: yyyymmddhh24miss。
${bdp.system.bizdate}:定义为一个实例运行时对应的业务日期,业务日期默认为运行日期的前一天,默认以 yyyymmdd 的格式显示。

从定义可知,运行时间和业务日期有如下计算公式:运行时间=(业务日期+1)+定时时间。
若使用系统参数,可以直接在代码中引用 ${bdp.system.bizdate}${bdp.system.cyctime} 即可,系统在调度运行时将自动把这两个参数替换成相应的时间。
很多用户的周期任务都是和日期/时间有关的,比如某用户的一个周期任务,每天都要处理昨天产生的业务数据,用户需要先按照昨天的日期创建一个分区,然后再把昨天的相关数据写入到该分区下。这里以每天周期运行,生成一个新的分区为例,为大家演示如何灵活利用好这两个系统参数。

image

如上图所示,首先新建一个分区表tbltest1,分区字段有3个,分别是sale_biz_date ,sale_curtime 和 region,其中sale_biz_date代表业务日期,sale_curtime代表运行时间,region代表区域。
上图中,sql任务的目的是,为表tbltest1增加一个分区,分区中使用了2个系统参数,每次运行该任务时,这两个系统参数${bdp.system.bizdate}${bdp.system.cyctime}都会被分别替换成具体日期和时间。

image

如上图所示,在这个sql周期任务的“调度配置”处,设置成小时周期任务,并且从0点开始,每小时执行一次,这样1天理论上每个小时就会产生一个实例。
通过上图的设置,每个小时都会运行一次这个sql任务。在DataWorks的“运维中心”——“任务运维”——“周期实例”下可以看到每个小时都会产生一个任务实例,如下图所示。

image

点击进到某个任务实例,比如0点这个实例,点击工作流中对应的sql任务节点,点击“运行日志”,能看到在日志中,sql语句alter table tbltest1 add partition(sale_biz_date='${bdp.system.bizdate}',sale_curtime='${bdp.system.cyctime}', region='china');中的系统参数${bdp.system.bizdate}已经被替换成了20180304,而${bdp.system.cyctime}已经被替换成了20180305000000。这正是符合我们的预期的。

image

上图是0点产生的实例,我们看下下面1点产生的实例进行验证。
我们可以通过下图看到,在凌晨1点时产生的实例,点击工作流中对应的sql任务节点,点击“运行日志”,能看到在日志中,sql语句alter table tbltest1 add partition(sale_biz_date='${bdp.system.bizdate}',sale_curtime='${bdp.system.cyctime}', region='china');中的系统参数${bdp.system.bizdate}已经被替换成了20180304,而${bdp.system.cyctime}已经被替换成了20180305010000。同样,这正是符合我们的预期的。

image

二、自定义参数

当使用自定义参数时:
非 Shell 类型的脚本或任务:需要先在代码中编辑 ${key1},${key2},然后在 参数 编辑框输入 “key1=value1 key2=value2” 方可生效。
Shell 类型的脚本或任务:需要先在代码中编辑 $1 $2 $3,然后在 参数 编辑框 “value1 value2 value3” 方可生效。
我们这里以非shell类型脚本为例,进行介绍。

很多客户有特殊的需求,系统参数已经不能满足其需求了。比如客户当时运行的任务,想取当前时间中的年或月,或者想取前N天或后N天的时间。这时,自定义参数便能满足客户的需求。
这里请注意,自定义参数是基于bdp.system.cyctime进行计算取值的,也就是基于运行时间进行取值的。例如“key1=$[yyyy]”表示按 bdp.system.cyctime 的值取年的部分作为结果替换该参数。

可供参考的自定义参数配置方式如下:

后N年:$[add_months(yyyymmdd,12*N)]
前N年:$[add_months(yyyymmdd,-12*N)]
后N月:$[add_months(yyyymmdd,N)]
前N月:$[add_months(yyyymmdd,-N)]
后N周:$[yyyymmdd+7*N]
前N周:$[yyyymmdd-7*N]
后N天:$[yyyymmdd+N]
前N天:$[yyyymmdd-N]
后N小时:$[hh24miss+N/24]
前N小时:$[hh24miss-N/24]
后N分钟:$[hh24miss+N/24/60]
前N分钟:$[hh24miss-N/24/60]

通过上述自定义参数配置方式,我们可以发现一个规律,前四个自定义参数配置方式中,add_months里面的数字的单位是月,所以后N年的配置中,N才会乘上12;其他的自定义参数配置中,中括号中的数字的单位是天,所以后N周的配置中,N才会乘上7。
比如,有某用户的需求是,其ODPS_SQL 任务为按小时调度,每隔 1 小时执行一次,代码中有两个自定义参数 thishour 和 lasthour,操作如下:
在DataWorks “数据开发”中,sql代码如下:

insert overwrite table tb1 partition(ds ='20150304') select
c1,c2,c3
from (
select * from tb2
where ds ='${thishour}') t
full outer join(
select * from tb3
where ds = '${lasthour}') y
on t.c1 = y.c1;

配置为每小时一次的调度,如下图:

image

自定义参数配置为:thishour=$[yyyy-mm-dd/hh24:mi:ss]
即当前的运行时间;lasthour =$[yyyy-mm-dd/hh24:mi:ss-1/24],即当前运行时间的上一个小时的时间。

image

在周期性任务提交后的第二天,在运维中心可以看到系统自动按时间周期生成的运行实例。例如在 2017 年 07 月 16 日这一天,系统为该任务每小时生成一个实例。运行日期为 2017 年 07 月 16 日,因此 ${bdp.system.cyctime} 的日期部分应当是 20170716。
先看下20170716生成的第一个实例,即0点的实例,看下日志中,如下图:

image

第一个实例定时时间为 2017-07-16 00:00:00,那么 thishour 替换的结果为 2017-07-16/00:00:00,lasthour 替换的结果为 2017-07-15/23:00:00。同理,第二个实例定时时间为 2017-07-16 01:00:00,那么 thishour 替换的结果为 2017-07-16/01:00:00,lasthour 替换的结果为 2017-07-16/00:00:00。如下图所示。

image

上面介绍了DataWorks参数调度中系统参数和自定义参数的使用方法,请大家注意到:运行时间=(业务日期+1)+定时时间,即运行时间和业务日期之间的关系。后续,笔者还会更新大家在使用参数调度中遇到的一些问题,敬请关注,谢谢。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

分享阿里云支持与服务团队最佳实践、经典案例与故障排查。

官方博客
最新文章
相关文章
文档