An auto triggered node is a node that the scheduling system runs periodically based on its scheduling configuration. You can go to the page to view the auto triggered nodes in a specific workspace and perform O&M operations on them. These operations include running nodes automatically or manually, viewing run details, freezing nodes, and undeploying nodes. This topic details these operations.
Usage notes
-
Only the Operation Center in the production environment supports automatic scheduling to generate auto triggered node instances; the development environment does not.
-
Use the commit and deploy process to add, modify, or undeploy node code, scheduling configuration, resources, and functions in the production environment.
-
All changes to a node must be deployed to take effect in the production environment. A deployment may fail, be blocked, or result in an unexpected version. Therefore, check the node on the page after deployment. For more information, see Manage auto triggered nodes.
O&M operations
This topic describes how to perform O&M operations on auto triggered nodes.
|
O&M operation |
Description |
|
On the Cycle Task page, you can view detailed information about nodes and perform operations from the list view or the DAG. |
|
|
|
|
|
|
You can view the operation logs, node versions, and operation history for nodes and instances. |
Viewing auto-triggered nodes
The auto triggered node list displays all nodes scheduled to run automatically in the production environment. You can verify that the node code, scheduling parameters, dependencies, and data lineage are correct. You can also view detailed information and perform operations from the list view or the DAG. For more information, see Manage auto triggered nodes.
-
Only nodes deployed to the production environment appear in the auto triggered node list in Operation Center.
-
A node is also not scheduled if it depends on one of its own descendant nodes, as this creates a dependency loop.
Running auto-triggered nodes
This section describes DataWorks node run modes and how to diagnose issues based on execution status.
Running modes
Every night, DataWorks automatically generates the next day's auto triggered node instances from the current auto triggered nodes. You can also manually trigger an auto triggered node to generate data backfill instances and test instances.
|
Instance type |
Use case |
Generation method
|
Trigger method
|
|
Run periodic, automated ETL operations. |
DataWorks automatically generates the next day's instances based on a nightly snapshot of the auto triggered node. Note
The Operation Center in the development environment does not automatically schedule or generate auto triggered node instances. |
DataWorks automatically runs the instance. |
|
|
Run ETL operations to backfill data for a past or future period for the current node and its descendant nodes. |
A data backfill instance is generated when you manually trigger a data backfill for an auto triggered node. |
The data backfill instance runs immediately after it is generated. |
|
|
Test an auto triggered node to verify that its execution result is correct. Note
A test instance runs the actual code logic. |
A test instance is generated when you manually trigger a test run for an auto triggered node. |
The test instance runs immediately after it is generated. |
Node run conditions
A scheduled node runs only when all of its ancestor nodes have completed successfully, its scheduled time has arrived, sufficient scheduling resources are available, and the node is not frozen. For more information, see Prerequisites for a scheduled node to run.
Troubleshooting node run issues
Symptom: The node does not run even after its scheduled time has arrived. Possible causes include its ancestor nodes not running successfully, insufficient scheduling resources, or the node being frozen.
Troubleshooting: First, use the upstream analysis feature in the DAG panel to identify the blocking ancestor nodes. Then, use the intelligent diagnosis feature to diagnose why the key instance has not run or to identify other issues. For nodes with complex dependencies, this feature helps you locate the problem and improves O&M efficiency. For more information, see Why has my node not run after its scheduled time?, Waiting for resources, and Freeze and unfreeze a node.
Emergency operations
-
If an ancestor node has not run and is blocking the current node, you can right-click the instance that has not run and select to run the current node immediately.
NoteBefore you perform this operation, check the node's code and data lineage to confirm that it will not adversely affect your data.
-
If a widespread data quality issue occurs, you can right-click an instance and select . For more information, see Appendix: Force rerun descendant nodes.
-
In some extreme cases, such as a server power outage or a primary/secondary switchover, DataWorks may not be able to completely terminate related MaxCompute tasks. In this situation, go to the corresponding MaxCompute project to terminate the job.
Managing auto-triggered nodes
Deploying auto-triggered nodes
A node must be deployed to the production scheduling system before it appears in the auto triggered node list in Operation Center. For more information, see Deploy nodes (old-version DataStudio) and Deploy nodes or workflows (new-version DataStudio).
Undeploying auto-triggered nodes
If a node or a business process is no longer needed, you can undeploy it. After a node is undeployed, it no longer appears on the Cycle Task page. For more information, see Undeploy nodes (old-version DataStudio) and Undeploy nodes (new-version DataStudio).
Pausing scheduled runs
Do not modify the projectname_root node. This node is the root node of the workspace. Auto triggered node instances depend on this node. If you freeze this node, auto triggered node instances cannot run.
|
Operation |
Use case |
Description |
|
Freeze an auto triggered node |
If a node and its descendant nodes do not need to be automatically scheduled for a period, you can freeze the node. |
|
|
Freeze an instance |
If a specific instance does not need to run, you can freeze it. |
The freeze operation affects only the selected instance. It does not affect other instances from the same day or any subsequent instances generated by the auto triggered node. |
|
Set an auto triggered node to dry run |
If a node does not need to run for a period but should not block its descendant nodes, you can set its scheduling type to Empty Run Scheduling. |
An auto triggered node set to dry run generates dry run instances. These instances have empty run logs, no execution duration, and do not process any data. Note
Setting the scheduling type to Paused in DataStudio has the same effect as freezing an auto triggered node in Operation Center. However, changes made in DataStudio take effect only in the development environment. To apply them to the production environment, you must deploy the node. For more information, see Deploy nodes (old-version DataStudio) and Deploy nodes or workflows (new-version DataStudio). |
For more information about the effects of freezing and unfreezing auto triggered nodes and their instances, see Freeze and unfreeze a node.
Managing node priority
You can use the baseline management feature to manage the priority of a node. The scheduler allocates resources to high-priority nodes first. For more information, see Manage baselines.
Node monitoring and alerting
You can configure monitoring rules for a node from the auto triggered node list:
-
Monitor the status of auto triggered node instances during scheduled runs. For more information, see Create and manage custom alert rules.
-
Monitor the quality of table data generated by auto triggered node instances, data backfill instances, and test instances. For more information, see Data Quality overview.
-
Monitor the resource group used by the node by setting alerts for metrics such as instance count and resource utilization. For more information, see Create and manage custom alert rules.
Modifying a node's resource group
You can modify the resource groups used by a node, including the scheduling resource group and the resource group for Data Integration. For more information, see Reference: Switch resource groups.
To redefine other properties of an auto triggered node, go to DataStudio, find the node, and open its configuration panel. For more information, see Configure basic properties. To modify multiple nodes at once, go to the Batch Operations page.
Modifying the node owner
You must first enable Allow Sub-accounts to Change Node Owner. Once enabled, the workspace administrator can change owners in the following ways:
-
In DataStudio, you can change the owner for a single node or for multiple nodes in a batch:
-
Single node: Open the panel.
-
Multiple nodes: Use the Batch Operations page. For more information, see Batch Operations.
Changes to the owner in the development environment must be deployed to the production environment to take effect.
-
-
In the production environment:
-
Single node: In the Actions column for the node, click .
-
Multiple nodes: Select the nodes whose owner you want to change, and then click Change Owner at the bottom of the page.
NoteChanges to the owner in the production environment are synchronized to the development environment.
-
Viewing O&M records
|
Entry point |
Description |
|
Operation Log for a node or instance |
Click a node or instance and go to the Operation Log tab to view its change history. |
|
Node Version |
If the deployment process lacks detailed records, go to DataStudio and compare the node version with the one in the production environment to see detailed changes. For more information, see Deploy nodes (old-version DataStudio) and Deploy nodes or workflows (new-version DataStudio). |
|
Operation History |
You can view the operation records for nodes, instances, and baselines on the Operation History page. For more information, see View O&M records in Operation Center. |
FAQ
For frequently asked questions about O&M for auto triggered nodes, see FAQ about auto triggered nodes.