数据工场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} 即可，系统在调度运行时将自动把这两个参数替换成相应的时间。
很多用户的周期任务都是和日期/时间有关的，比如某用户的一个周期任务，每天都要处理昨天产生的业务数据，用户需要先按照昨天的日期创建一个分区，然后再把昨天的相关数据写入到该分区下。这里以每天周期运行，生成一个新的分区为例，为大家演示如何灵活利用好这两个系统参数。
如上图所示，首先新建一个分区表tbltest1，分区字段有3个，分别是sale_biz_date ,sale_curtime 和 region，其中sale_biz_date代表业务日期，sale_curtime代表运行时间，region代表区域。
上图中，sql任务的目的是，为表tbltest1增加一个分区，分区中使用了2个系统参数，每次运行该任务时，这两个系统参数${bdp.system.bizdate} 和 ${bdp.system.cyctime}都会被分别替换成具体日期和时间。
如上图所示，在这个sql周期任务的“调度配置”处，设置成小时周期任务，并且从0点开始，每小时执行一次，这样1天理论上每个小时就会产生一个实例。
通过上图的设置，每个小时都会运行一次这个sql任务。在DataWorks的“运维中心”——“任务运维”——“周期实例”下可以看到每个小时都会产生一个任务实例，如下图所示。
点击进到某个任务实例，比如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。这正是符合我们的预期的。
上图是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。同样，这正是符合我们的预期的。
二、自定义参数
当使用自定义参数时：
非 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;
配置为每小时一次的调度，如下图：
自定义参数配置为：thishour=$[yyyy-mm-dd/hh24:mi:ss]，
即当前的运行时间；lasthour =$[yyyy-mm-dd/hh24:mi:ss-1/24]，即当前运行时间的上一个小时的时间。
在周期性任务提交后的第二天，在运维中心可以看到系统自动按时间周期生成的运行实例。例如在 2017 年 07 月 16 日这一天，系统为该任务每小时生成一个实例。运行日期为 2017 年 07 月 16 日，因此 ${bdp.system.cyctime} 的日期部分应当是 20170716。
先看下20170716生成的第一个实例，即0点的实例，看下日志中，如下图：
第一个实例定时时间为 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。如下图所示。
上面介绍了DataWorks参数调度中系统参数和自定义参数的使用方法，请大家注意到：运行时间=（业务日期+1）+定时时间，即运行时间和业务日期之间的关系。后续，笔者还会更新大家在使用参数调度中遇到的一些问题，敬请关注，谢谢。
