Overview

Elastic Resource Pool

An elastic resource pool provides compute resources (CPU and memory) for running DLI jobs. The unit is CU. One CU contains one CPU and 4 GB memory.

You can create multiple queues in an elastic resource pool. Compute resources can be shared among queues. You can properly set the resource pool allocation policy for queues to improve compute resource utilization.

Specifications

DLI offers compute resources in the specifications listed in Table 1.

Constraints

• The region of an elastic resource pool cannot be changed.
• Jobs of Flink 1.10 or later can run in elastic resource pools.
• The network segment of an elastic resource pool cannot be changed after being set.
• You can only view the scaling history of resource pools in the last 30 days.
• Elastic resource pools cannot access the Internet.

Scenario

Resources too fixed to meet a range of requirements.

The quantities of compute resources required for jobs change in different time of a day. If the resources cannot be scaled based on service requirements, they may be wasted or insufficient. Figure 1 shows the resource usage during a day.

• After ETL jobs are complete, no other jobs are running during 04:00 to 07:00 in the early morning. The resources could be released at that time.
• From 09:00 to 12:00 a.m. and 02:00 to 04:00 p.m., a large number of ETL report and job queries are queuing for compute resources.
  Figure 1 Fixed resources
  

Resources are isolated and cannot be shared.

A company has two departments, and each run their jobs on a DLI queue. Department A is idle from 08:00 to 12:00 a.m. and has remaining resources, while department B has a large number of service requests during this period and needs more resources to meet the requirements. Since the resources are isolated and cannot be shared between department A and B, the idle resources are wasted.

Figure 2 Resource waste due to resource isolation

Elastic resource pools can be accessed by different queues and automatically scaled to improve resource utilization and handle resource peaks.

You can use elastic resource pools to centrally manage and allocate resources. Multiple queues can be bound to an elastic resource pool to share the pooled resources.

Architecture and Advantages

Elastic resource pools support the CCE cluster architecture for heterogeneous resources so you can centrally manage and allocate them.

Elastic resource pools have the following advantages:

• Unified management
  • You can manage multiple internal clusters and schedule jobs. You can manage millions of cores for compute resources.
  • Elastic resource pools can be deployed across multiple AZs to support high availability. (This function will be supported in later versions.)
• Tenant resource isolation

  Resources of different queues are isolated to reduce the impact on each other.

• Shared access and flexibility
  • Specifications can be scaled in seconds to help you handle request peaks.
  • Queue priorities and CU quotas can be set at different time to improve resource utilization.
• Job-level isolation (supported in later versions)

  SQL jobs can run on independent Spark instances, reducing mutual impacts between jobs.

• Automatic scaling (supported in later versions)

  The queue quota is updated in real time based on workload and priority.

Using elastic resource pools has the following advantages.

You can perform the following operations on elastic resource pools:

• Creating an Elastic Resource Pool
• Managing Permissions
• Adding a Queue
• Binding a Queue
• Managing Queues
• Setting CUs