Updated on 2024-01-23 GMT+08:00

Elastic Resource Pools

Billing Modes

Elastic resource pools provide compute resources for DLI jobs. Elastic resource pools support the following billing modes:

  • Pay-per-use: Pay-per-use is a postpaid mode. Dedicated Resource Mode is selected by default. Resources are not released when idle.

    Dedicated resources are billed by the calendar hour based on the CUs purchased since they are created. The billing is calculated in seconds and settled hourly. Computing fee = Unit price x Number of CUs purchased x Number of hours

    Pay-per-use billing is applicable to test projects with low resource consumption, as it results in lower costs.

  • Package: DLI enables you to buy an elastic resource pool CUH package, and you will be billed by CUH when you submit jobs in the pool after purchasing the package. You are advised to combine elastic resource pool CUH packages with pay-per-use queues.

    If you purchase an elastic resource pool CUH package, your resource usage will first be deducted from the included quota, and any additional usage beyond the package limit will be billed on a pay-per-use basis. The included quota will reset based on the subscription period. See Package Billing for more information on package billing.

This section describes the billing rules of pay-per-use DLI elastic resource pools.

Application Scenarios

  • Pay-per-use: It is suitable for test projects with random jobs, small data volume, and low resource consumption, as it results in lower costs and does not require any prepayment.
  • Pay-per-use + package: It is suitable for scenarios where the queue usage can be estimated or scenarios where resource consumption is low, such as test projects. During usage, the quota for the elastic resource pool CUH package will be first deducted. If the usage exceeds the quota, you will be charged in pay-per-use mode.

Constraints and Limitations

  • Pay-per-use dedicated elastic resource pools are billed by calendar hour since they are created. Dedicated Resource Mode is selected by default for pay-per-use billing for elastic resource pools.
  • Elastic resource pools are billed by the second and settled hourly, with hours calculated on the hour.
  • Pay-per-use elastic resource pools are billed based on the number of CUs purchased, rather than the CUs utilized to execute jobs.
  • A pay-per-use elastic resource pool can be deleted one hour after it is created.
  • You can combine pay-per-use with CUH packages. Your resource usage will first be deducted from the quota included in your CUH package, and any additional usage beyond the package limit will be billed on a pay-per-use basis. The quota included in an elastic resource pool CUH package will reset every month.
  • If the consumption of resources in a single billing cycle is less than 1CU for an elastic resource pool, it will be rounded up to 1CU.
  • The scaling in or out of an elastic resource pool starts counting time after the scaling is successfully completed, not from the time when the scaling process begins.
  • After the queue is scaled out for the elastic resource pool, the system starts billing you for the added CUs.

    When there is no demand for certain CUs due to business adjustments, it is important to release them promptly; otherwise, they will continue to incur charges.

  • Queues in an elastic resource pool are not charged separately; the billing is based on the elastic resource pool as a whole for the compute resources used.

Billing Rules

Billing rules for elastic resource pools vary depending on the billing mode.

Table 1 Billing rules for elastic resource pools

Billing Mode

Resource

Description

Pay-per-use

Elastic resource pool

Computing fee = Unit price x Number of CUs x Number of hours

Pay-per-use dedicated DLI elastic resource pools are billed by the calendar hour based on the CUs purchased since they are created, regardless of whether there are any jobs running on them.

Suppose you purchase a pay-per-use queue. At the bottom of the purchase page, you will find a breakdown of the costs, which will include the CU range based on your selected configuration and the calculated configuration fees for the purchase duration.

Billing Examples

The prices are just examples. The actual prices are those displayed on DLI Pricing Details.

Example: Pay-per-use dedicated elastic resource pool (including billing examples in scaling scenarios)

The billing on elastic resource pools by CUH is divided into three periods based on chronological order: the creation period, the usage period, and the deletion period. Figure 1 shows the definitions of the three periods.
Figure 1 Billing on elastic resource pools by CUH
  • start_time: time when the elastic resource pool is successfully created and in the Available state.
  • start_time_next: next hour after the time when the elastic resource pool is successfully created and in the Available state. For example, if start_time is 09:45:00, the value of start_time_next is 10:00:00.
  • end_time: time when the elastic resource pool is successfully deleted.
  • end_time_before: the hour before the time when the elastic resource pool is successfully deleted. For example, if end_time is 14:25:00, the value of end_time_before is 14:00:00.
  • Creation period = start_time_nextstart_time
  • Usage period = end_time_beforestart_time_next
  • Deletion period = end_timeend_time_before

Computing fee = Unit price x Number of CUs x Number of hours

The billing on the elastic resource pool by CUH differs in the three periods. For details, see the scenario description listed in Table 2.

Table 2 Billing on elastic resource pools by CUH

Scenario

Description

Creation Period

Usage Period

Deletion Period

Scenario 1

  • A created elastic resource pool became Available at 09:40:00, and the next hour is 10:00:00.
  • The elastic resource pool is deleted at 11:40:00, and the previous hour is 11:00:00.
  • Throughout the entire period, there are 64 CUs allocated to the elastic resource pool, and no elastic scaling will occur during this time.
  • The creation period is calculated as follows:

(10:00:00 – 09:40:00) = 1/3 hours

  • Total CUHs = 64 CUs/3 hours = 22 CUHs (rounded up)
  • The usage period is calculated as follows:

(11:00:00 – 10:00:00) = 1 hour

  • Total CUHs = 64 CUs/1 hour = 64 CUH
  • The deletion period is calculated as follows:

(11:40:00 – 11:00:00) = 2/3 hours

  • Total CUHs = 64 CUs x 2/3 hours = 43 CUHs (rounded up)

Scenario 2

  • A created elastic resource pool became Available at 09:40:00, and the next hour is 10:00:00.
  • The elastic resource pool is deleted at 11:40:00, and the previous hour is 11:00:00.
  • The elastic resource pool starts with 64 CUs, increases to 128 CUs at 10:10:00, and then decreases back to 64 CUs at 11:10:00.
  • The creation period is calculated as follows:

(10:00:00 – 09:40:00) = 1/3 hours

  • Total CUHs = 64 CUs/3 hours = 22 CUHs (rounded up)
  • The usage period is calculated as follows:

    Duration before scale-out = 10:10:00 – 10:00:00 = 1/6 hours

    Duration after scale-out = 11:00:00 – 10:10:00 = 5/6 hours

  • Total CUHs = (64 CUs x 1/6 hours + 128 CUs x 5/6 hours) = 118 CUHs (rounded up)
  • The deletion period is calculated as follows:

    Duration before scale-in = 11:10:00 – 11:00:00 = 1/6 hours

    Duration after scale-in = 11:40:00 – 11:10:00 = 1/2 hours

  • Total CUHs = (128 CUs x 1/6 + 64 CUs x 1/2 hours) = 54 CUHs (rounded up)

Scenario 3

  • A created elastic resource pool became Available at 09:40:00, and the next hour is 10:00:00.
  • The elastic resource pool is deleted at 10:50:00, and the previous hour is 10:00:00.
  • The elastic resource pool starts with 64 CUs and increases to 128 CUs at 10:10:00.
  • The creation period is calculated as follows:

(10:00:00 – 09:40:00) = 1/3 hours

  • Total CUHs = 64 CUs/3 hours = 22 CUHs (rounded up)

None

  • The deletion period is calculated as follows:

    Duration before scale-in = 10:10:00 – 10:00:00 = 1/6 hours

    Duration after scale-in = 10:50:00 – 10:10:00 = 2/3 hours

  • Total CUHs = (64 CUs x 1/6 hours + 128 CUs x 2/3 hours) = 96 CUHs (rounded up)

Impact of Arrears

Figure 2 shows the statuses a pay-per-use DLI queue can have throughout its lifecycle. After a DLI queue is purchased, it enters the validity period and operates properly during this period. If your account goes into arrears or exceeds the expenditure quota, the queue enters a grace period and then a retention period.

Figure 2 Lifecycle of a pay-per-use DLI resource

Arrears Reminder

The system deducts fees from your account balance for pay-per-use resources at the end of each billing cycle. You will be notified by email, SMS, or in-app messages when your account falls into arrears or exceeds the expenditure quota.

Impact of Arrears

Your resources enter the grace period and you cannot submit jobs in DLI, including SQL, Spark, and Flink jobs. You will need to pay for the fees incurred during the grace period, which you can see on the Billing & Costs > Billing Center > Overview page of the Huawei Cloud console.

If you do not bring your account balance current before the grace period expires, your resources will enter the retention period and become frozen. You cannot perform any operations on the pay-per-use resources during this period.

If you do not bring your account balance current before the retention period ends, your resource will be released and the data cannot be restored.

For details about how to top up your account, see Topping Up an Account.

For details about expenditure quotas, see Expenditure Quota.

Combination of Pay-per-Use and Package

DLI allows you to use package and pay-per-use together.

If you purchase an elastic resource pool CUH package, your resource usage will first be deducted from the included quota, and any additional usage beyond the package limit will be billed on a pay-per-use basis. The quota included in an elastic resource pool CUH package will reset every month.

For details about how to use a package, see Package Billing.