参数优先级

DolphinScheduler 中所涉及的参数值的定义可能来自三种类型：

  • 全局参数：在工作流保存页面定义时定义的变量
  • 上游任务传递的参数：上游任务传递过来的参数
  • 本地参数：节点的自有变量，用户在“自定义参数”定义的变量，并且用户可以在工作流定义时定义该部分变量的值

因为参数的值存在多个来源，当参数名相同时，就需要会存在参数优先级的问题。DolphinScheduler 参数的优先级从高到低为：本地参数 > 上游任务传递的参数 > 全局参数

在上游任务传递的参数中，由于上游可能存在多个任务向下游传递参数，当上游传递的参数名称相同时：

  • 下游节点会优先使用值为非空的参数
  • 如果存在多个值为非空的参数，则按照上游任务的完成时间排序，选择完成时间最早的上游任务对应的参数

例子

下面例子向你展示如何使用任务参数传递的优先级问题

1：先以 shell 节点解释第一种情况

priority-parameter01

节点 【useParam】可以使用到节点【createParam】中设置的变量。而节点 【useParam】与节点【noUseParam】中并没有依赖关系，所以并不会获取到节点【noUseParam】的变量。上图中只是以 shell 节点作为例子，其他类型节点具有相同的使用规则。

priority-parameter02

其中节点【createParam】在使用变量时直接使用即可。另外该节点设置了 “key” 和 “key1” 两个变量，这里用户用定义了一个与上游节点传递的变量名相同的变量 key1，并且赋值为 “12”，但是由于我们设置的优先级的关系，这里的值 “12” 会被使用，最终上游节点设置的变量值会被抛弃。

2：我们再以 sql 节点来解释另外一种情况

priority-parameter03

节点【use_create】的定义如下：

priority-parameter04

“status” 是当前节点设置的节点的自有变量。但是用户在保存工作流时也同样设置了 “status” 变量（全局参数），并且赋值为 -1。那在该 SQL 执行时，status 的值为优先级更高的 2。抛弃了全局变量中的值。

这里的 “id” 是上游节点设置的变量，用户在节点【createParam1】、节点【createParam2】中设置了相同参数名 “id” 的参数。而节点【use_create】中使用了最先结束的【createParam1】的值。