Configure same-cycle scheduling dependencies
A same-cycle dependency requires a node to wait for its upstream node instance in the current cycle to complete before it runs. This is suitable when a node consumes data produced by an upstream node on the same day. DataWorks provides multiple ways to configure and preview these dependencies so you can verify that tasks are scheduled as expected.
How it works
Scheduling dependencies are established by matching a node output with a node input: the upstream node's output name is added as the downstream node's input, so the downstream node runs only after the upstream node succeeds. Before you begin, identify the dependency targets and types based on your table lineage. For more information, see Scheduling dependency configuration guide.
Node output
A node output, also known as the output name of the current node, is a logical identifier that other nodes reference to establish a dependency. It does not represent the actual data the node produces.
DataWorks automatically generates two output names for each node:
-
projectName.randomNumber_out: This output is globally unique and cannot be modified or deleted.
-
projectName.nodeName: This output includes the node name and can be modified. This output name remains unchanged even if the node is renamed.
You can also add outputs manually or let DataWorks automatically parse inputs and outputs from your code. Support for automatic parsing varies by node type. For details, see Comparison of automatic parsing results.
Node input
A node input specifies the ancestor nodes that the current node depends on. You can specify a dependency by using the ancestor's output name (recommended), node name, or node ID.
A node ID is generated only after the ancestor node is submitted to the production environment.
Configuration guidelines
We recommend using automatic parsing to configure dependencies efficiently. When using automatic parsing, follow these guidelines:
-
Node creation: Name each node after its output table.
-
Code development: Avoid having multiple nodes write data to the same table.
-
Dependency configuration: Set the table that a node produces as that node's output.
Entry points and methods
Go to the edit page of the Data Studio node, click Schedule Settings in the right-side navigation pane, and configure the scheduling dependencies for the node in the Scheduling Dependency section.
-
Parent Nodes: Specifies the ancestor nodes that the current task depends on.
-
Output Name of Current Node: Defines the output names through which other tasks can establish dependencies on this node.
-
During code editing, dependencies are configured based on table lineage by default. DataWorks automatically checks whether the dependencies match the data lineage upon submission. You can choose whether to enable the automatic parsing before submission feature. For more information, see Configure automatic parsing before submission.
-
If the current node needs to depend on data produced by an upstream node yesterday, or if an hourly/minutely task needs to depend on its own instance from the previous cycle, configure cross-cycle dependencies.
-
If the current node and its upstream node have different scheduling frequencies, such as a daily task depending on an hourly task or depending on hourly tasks with different frequencies, see Configure dependencies between tasks with different scheduling frequencies.
You can configure dependencies in three ways. All three methods use the same underlying mechanism.
Configure node dependencies by parsing table lineage from code
Automatic parsing analyzes the table lineage in a node's code and configures the node's output names and upstream dependencies accordingly. Tables that the node writes to are added as node outputs in the projectname.tablename format, and tables that the node reads from are added as node inputs.
For example, when a node uses SELECT on a table, that table is automatically parsed as an upstream dependency of the node. When a node uses INSERT on a table, that table is automatically parsed as an output of the node. For the keywords supported by automatic parsing for each node type, see Keywords supported by automatic parsing for each node type.
-
Configure dependencies
Automatic parsing supports two methods: Parse Inputs and Outputs from Code and Automatic Parsing Before Committing. Both methods work on the same principle. Automatic parsing before committing automatically parses inputs and outputs when you submit the code and prompts you to configure dependencies.
For example, ODPS node mc2 depends on the output table
dws_user_info_all_diof node mc1. The code of node mc2 is as follows:INSERT OVERWRITE TABLE ads_user_info_1d PARTITION (dt='${workflow.var}') SELECT uid , MAX(region) , MAX(device) , COUNT(0) AS pv , MAX(gender) , MAX(age_range) , MAX(zodiac) FROM dws_user_info_all_di WHERE dt = '${workflow.var}' GROUP BY uid;After you click Parse Inputs and Outputs from Code, the input of this node is parsed as the
dws_user_info_all_ditable, and the output table name and name of the upstream node are automatically matched:Upstream node output name
Upstream node output table name
Upstream node name
Node ID
Workspace
Owner
Schedule
Method
Recent run status
Action
yunwan_lingyi.dws_user_info_all_di
mc1
-
Test workspace
lingyi01_testcloud_com
Day
Code parsing
No data
Delete
At the same time, the output of this node is parsed as the
ads_user_info_1dtable. The parsing results are as follows:Output name
Output table name
Downstream node name
Owner
Method
Downstream node affected baselines
Action
old_ide.505487297_out
-
-
-
Added by system
-
Delete
old_ide.mc2
-
-
-
Manually added
-
Delete
yunwan_lingyi.ads_user_info_1d
yunwan_lingyi.ads_user_info_1d
-
-
Code parsing
-
Delete
Node mc2 is now configured with a dependency on node mc1.
-
Modify dependencies from code parsing
If the parsed dependencies do not match your expectations, or if unsupported scenarios (tables whose data is not produced by periodic scheduling) require manual adjustments, modify the parsed dependencies as follows.
Action
Description
Manually delete parsing results
Delete the unexpected input from the upstream node dependency list, perform the delete operation, and re-parse. After deletion, a corresponding comment is automatically added to the code to prevent the dependency from being re-added during the next parsing:
--@exclude_input=Remove input --@exclude_output=Remove outputManually add inputs and outputs
Right-click a table name in the code editor and select Add Input or Add Output. After the input or output is added, a corresponding comment is automatically added to the code.
--@extra_output=Add output --@extra_input=Add inputAlternatively, you can add dependencies by using the methods described in Manually add upstream node dependencies from the schedule settings panel or Set node dependencies by dragging connections in the workflow panel.
ImportantDataWorks does not allow you to directly delete a node output that has existing downstream dependencies. Doing so causes downstream task execution or data retrieval errors. First adjust the downstream business logic and remove the upstream dependency from the downstream node, then delete the node output from the upstream node.
-
Scenarios excluded from automatic parsing
Temporary tables defined in workspace table management with a fixed naming format (for example, tables prefixed with
t_) in DataWorks are not automatically parsed as node outputs or upstream dependencies. -
Considerations for automatic parsing
When using automatic parsing, ensure that node outputs are unique within the current region. Keep the following in mind:
-
Node creation: Each node has a default output with the same name as the node. If nodes with the same name exist in the same workspace, you must manually modify the node output of one of them.
-
Code development: Automatic parsing uses the output table of a node as the node output. If two scheduled nodes in the same workspace insert data into the same table, automatic parsing will cause an error for one of the nodes. For more information, see Multiple nodes write data to the same table, and automatic parsing reports duplicate node output names.
-
Dependency configuration: When you use SQL tasks to process the output tables of batch synchronization tasks, to enable SQL tasks to quickly depend on batch synchronization tasks through lineage-based automatic parsing, you must manually configure the output table of the batch synchronization node as a node output, or name the batch synchronization task node after its output table (the platform automatically creates a node output with the same name as the node). Otherwise, when submitting the downstream SQL node, you may encounter the error The parent node output name ${projectname.tablename} that the current node depends on does not exist. The current node cannot be submitted. Make sure that the parent node with this output name has been submitted.
-
Manually add upstream node dependencies from the schedule settings panel
In the Schedule Settings > Scheduling Dependency > Parent Nodes section, add upstream node dependencies by entering the node output, node name, or node ID of the target node. Because node names can be duplicated, using node outputs is recommended.
Set node dependencies by dragging connections in the workflow panel
When you set dependencies by dragging connections in the DAG panel of a workflow, DataWorks automatically adds the upstream node's _out output to the downstream node, creating a node dependency.
When a dependency connection is deleted from the workflow panel, the corresponding dependency is also removed from the node's schedule settings.
Impact of deleting or changing node outputs
If you change the data a node produces or manually modify a node output, be aware of the following impacts:
-
Deleting a node output does not directly affect the data produced by the node.
-
If a node output already has downstream dependencies, changing or deleting it may severely impact downstream tasks.
-
Output table deletion: When a node output configured through automatic parsing changes because the output table changes, downstream nodes may become orphan nodes that are not scheduled, or downstream data may be corrupted because of missing data dependencies.
-
Output table change: If the table produced by the current node needs to be transferred to another node, see Transfer a node output table to another node.
Before deleting a node output that has downstream dependencies, notify the downstream task owners so they can adjust their dependencies and prevent their tasks from becoming orphan tasks.
-
Next steps: Verify that dependencies are as expected
After you configure dependencies, verify that they are correct to ensure tasks run as expected:
-
Preview dependencies: Verify that the dependencies are correct to prevent task scheduling delays caused by unexpected dependencies.
-
Submission check: Confirm that dependency changes are as expected when you submit a node.
-
Scheduled task dependency verification: After you deploy a node, verify that the dependencies of the production scheduled task in Operation Center are as expected. A scheduled task represents the latest state of the task in the production environment. The instance dependencies of scheduled instances are related to the instance generation method.
For more information, see Verify scheduling dependencies.
FAQ
For more FAQ, see Scheduling dependencies.
Best practices
To configure node dependencies across workspaces or across workflows within the same workspace, see Configure node dependencies across workspaces or workflows.