[Data] Optimize autoscaler to support configurable step size for actor pool scaling

[dragongu]

Summary

Add support for configurable upscaling step size in the actor pool autoscaler. This enables rapid scale-up and efficient resource utilization by allowing the autoscaler to scale up multiple actors at once, instead of scaling up one actor at a time.

Description

Background

Currently, the actor pool autoscaler scales up actors one at a time, which can be slow in certain scenarios:

1. Slow actor startup: When actor initialization logic is complex, actors may remain in pending state for extended periods. The autoscaler skips scaling when it encounters pending actors, preventing further scaling.

2. Elastic cluster with unstable resources: In environments where available resources are uncertain, users often configure large concurrency ranges (e.g., (10,1000)) for map_batches. In these cases, rapid startup and scaling are critical to utilize available resources efficiently.

Solution

This PR adds support for configurable upscaling step size in the actor pool autoscaler. Instead of always scaling up by 1 actor at a time, the autoscaler can now scale up multiple actors based on utilization metrics, while respecting resource constraints.

Related issues

[gemini-code-assist]

Code Review

This pull request introduces a configurable upscaling step size for the actor pool autoscaler, which is a great improvement for scenarios requiring rapid scaling. The implementation is solid, calculating a desired scaling delta based on utilization and then capping it with various limits like resource budget, the newly configured max delta, and the pool's max size. The new configuration is well-documented, and the tests have been updated to cover the new logic. I have one suggestion to add a safeguard against a potential ZeroDivisionError if the upscaling threshold is misconfigured. Overall, this is a well-executed enhancement.

[cursor]

Bug: Existing test expectations incompatible with new reason message format

The test expects an exact match on the reason message format "utilization of 1.5 >= 1.0", but the code now generates a longer, more detailed format including plan_delta, max_scale_up, max_upscaling_delta, and final_delta. The test assertions checking exact reason strings will fail because they weren't updated to match the new message format. This causes multiple test cases in test_actor_pool_scaling() to fail (e.g., lines 91-95 and lines 162-167).

python/ray/data/tests/test_autoscaler.py#L90-L95

ray/python/ray/data/tests/test_autoscaler.py

Lines 90 to 95 in 191de57

	assert autoscaler._derive_target_scaling_config(
	actor_pool=actor_pool,
	op=op,
	op_state=op_state,
	) == ActorPoolScalingRequest(delta=delta, force=force, reason=expected_reason)

 

---