Advanced resource group elastic plans-DataWorks(DataWorks)-阿里云帮助中心

Lifecycle states

After you create a Configuration Plan and a Time Plan, an elastic plan can enter seven lifecycle states. The normal path is: Initializing > Scaling Out > Scale-out Succeeded > Scaling In > Scale-in Succeeded. Scale-out Timeout and Scale-in Timeout are two exception states.

Scale-out Timeout, Scale-in Timeout, and Scale-in Succeeded are terminal states. Once a plan enters any of these states, its execution for the day ends, and no further transitions occur.

State	Description
Initializing	The system enters initialization 30 minutes before the Plan Start Time. During this period, modifications (such as elastic CU amount or time range) do not take effect until the next cycle.
Scaling Out	From the configured Plan Start Time, the system allocates elastic CUs until it reaches the configured amount or the Plan End Time is exceeded. If scale-out completes within the time window, the plan enters the Scale-out Succeeded state; otherwise, it enters the Scale-out Timeout state.
Scale-out Succeeded	All configured elastic CUs are allocated, and the resource group has the additional computing capacity. Important Elastic scale-out resources can only be used for Data Computing and Synchronization Tasks in Data Integration quotas. They cannot be used for scenarios such as DataService Studio, Individual Development Environment, or Model Service.
Scale-out Timeout	Scale-out Timeout means the plan failed to allocate all elastic CUs within the time window. Two scenarios can trigger this state: General scenario: Elastic resource allocation did not complete by the plan end time. Important Best practice: Submit the plan at least 3 hours before the start time to allow for scheduling and resource initialization. Special scenario: If plan A is still scaling in when plan B starts, and resource group usage > resource group Reserved Specification + plan B's Elastic Specification, plan B cannot take over the resources. If resource group usage still exceeds its total specification after scale-out (resource group Reserved Specification + plan B's Elastic Specification) after plan B's Plan End Time, plan B is marked as Scale-out Timeout. Note More Scale-out Timeout examples are in Special scenario description.
Scaling In	At the Plan End Time, the system begins scale-in. The resource group stops allocating CUs to new tasks (they enter pending state) and waits for running tasks to complete naturally. When total CU usage ≤ Reserved Specification (CU), the system releases all elastic CUs as a block.
Scale-in Succeeded	Total resource group usage is back within the Reserved Specification (CU), and all elastic CUs are released. The resource group resumes serving with reserved CUs and starts allocating tasks.
Scale-in Timeout	If plan B is scaling in but total CU usage exceeds the Reserved Specification, preventing elastic CU release, and a subsequent elastic plan C successfully takes over the resources (its scale-out completes), the system terminates plan B's scale-in and updates its state to Scale-in Timeout. Plan B failed to reclaim elastic CUs after its end time, and plan C has taken over resource management. Note More Scale-in Timeout examples are in Special scenario description.

Unified resource pool mechanism

After elastic scale-out succeeds, the system merges elastic CUs and reserved CUs into a unified computing capacity pool. The two types are not differentiated at the scheduling and allocation level:

The total CU specification exposed by the resource group = Reserved computing resources (CU) + active elastic CUs.
Task scheduling allocates CUs from this unified pool on demand. It does not distinguish whether a task runs on elastic or reserved CUs—all CUs provide fully equivalent computing capability and service guarantees.

During scale-in, the system monitors total CU usage (CUs currently occupied by tasks) in real time and derives actual elastic CU usage:

Actual elastic CU usage = max(0, total CU usage of the resource group − Reserved computing resources (CU))

This formula applies as follows:

Total CU usage of the resource group	Elastic CU usage	Description
≤ Reserved specification	0	The block release condition is met. The system can reclaim all elastic CUs.
> Reserved specification	Total usage − Reserved specification	The excess is handled by elastic CUs. Billing continues for these CUs during scale-in until release completes.

Resource scaling mechanism

Elastic CUs are allocated or released as a block at the full quantity defined in the configuration plan. Fragmented scaling is not supported.

Operation	System behavior
Scale-out	The system initializes and allocates all elastic CUs at once.
Scale-in	When the total CU usage of the resource group ≤ Reserved Specification (CU), the system releases all elastic CUs as a block.

Scale-in safety mechanism

To protect running tasks from interruption, the scale-in process follows these safety rules:

At the Plan End Time, the resource group stops allocating CUs to new tasks. New tasks enter pending state.
When the Plan End Time is reached, if tasks are still running, the system does not forcibly terminate them but allows them to complete naturally.
During scale-in, the system monitors total CU usage. Only when total CU usage ≤ Reserved Specification (CU) does the system reclaim elastic CUs as a block.

Special scenario description

Scale-out Timeout & Scale-in Timeout

Scenario description:

The resource group has a reserved specification of 10 CUs. Three elastic plans are configured as follows:

Elastic plan	Scale-out specification	Plan time range
Elastic plan A	30 CU	9:00–11:00
Elastic plan B	20 CU	12:00–14:00
Elastic plan C	8 CU	15:00–17:00

The following diagrams and timeline tables illustrate the lifecycle state transitions of plans A, B, and C in multi-phase overlapping scenarios.

Time	Total CU usage of the resource group (assumed value)	Reserved specification	Actual elastic CU usage	System behavior and state
9:00	28 CU	10 CU	18 CU	Plan A starts scale-out. The system allocates 30 elastic CUs.
11:00	40 CU	10 CU	30 CU	Plan A starts scale-in, but total CU usage > reserved specification. Plan A enters the Scaling In state.
12:00	38 CU	10 CU	28 CU	The current total CU usage of the resource group > resource group Reserved Specification + plan B's Elastic Specification. Plan B cannot successfully take over resources. Because plan B failed to take over, plan A remains in Scaling In state, continuing to handle the load exceeding the reserved specification and ensuring stable task execution.
14:00	32 CU	10 CU	22 CU	By elastic plan B's Plan End Time, the total CU usage of the resource group > reserved specification + plan B's Elastic Specification. Plan B is marked as Scale-out Timeout. Plan A remains in the Scaling In state.
15:00	22 CU	10 CU	12 CU	The current total CU usage of the resource group > resource group Reserved Specification + plan C's Elastic Specification. Plan C cannot successfully take over resources. Plan A remains in the Scaling In state.
16:00	18 CU	10 CU	8 CU	The current total CU usage of the resource group = resource group Reserved Specification + plan C's Elastic Specification. Plan C successfully takes over resources. Plan A is marked as Scale-in Timeout because plan C has successfully taken over.
17:00	10 CU	10 CU	0	Plan C starts automatic scale-in and reaches Scale-in Succeeded.

Force Stop

Force Stop is available when an elastic plan is in one of the following states:

Current state	Force Stop behavior	Final state
Initializing or Scaling Out	The scale-out process terminates immediately without allocating elastic CUs. The Plan End Time updates to the Force Stop time.	`Scale-out Timeout (Force Stop)`
Scale-out Succeeded	An early scale-in triggers: The system stops allocating CUs to new tasks and waits for running tasks to complete. Once total CU usage drops to or below the reserved specification, all elastic CUs are released as a block. The Plan End Time updates to the Force Stop time. Note After Force Stop, if tasks still use elastic CUs, the plan shows `Scaling In (Force Stop)` until total CU usage ≤ Reserved Specification (CU). The system then releases all elastic CUs, and the state updates to `Scale-in Succeeded (Force Stop)`.	`Scale-in Succeeded (Force Stop)`

Procedure

Force Stop has two entry points based on the time plan state:

For a plan in the Initializing state, the time plan status is displayed as Pending. To force stop the plan:

On the Scheduled Elasticity tab, to force stop a plan in the Initializing state, click > Disabled in the Actions column to perform Force Stop on the plan.
For a plan in the Scaling Out or Scale-out Succeeded state, the time plan status is displayed as In Effect. To force stop the plan:

On the Scheduled Elasticity tab, for an elastic time plan in the In Effect state, click > Force Stop in the Actions column to perform Force Stop on the plan.

Examples

In the Scale-out Timeout (Force Stop) scenario, Force Stop terminates the scale-out immediately without allocating elastic CUs. The Plan End Time updates to the Force Stop time.

For example, a plan with time range 12:00–13:00 starts initialization at 11:30. If you force stop at 11:40, the Plan End Time updates to 11:40.
In the Scale-in Succeeded (Force Stop) scenario, the system triggers an early scale-in. The Plan End Time updates to the Force Stop time, and the Actual End Time records when scale-in completed.

For example, a plan with time range 11:00–12:00 is force stopped at 11:42. The Plan End Time updates to 11:42, but tasks still consume elastic CUs (total usage exceeds the reserved specification). Elastic resources are fully released at 12:59 when all tasks finish, and the Actual End Time records 12:59.