This topic describes the billing methods of Data Lake Analytics (DLA) and provides a comparison between these methods. The billing methods are pay-per-byte, pay-per-CU, standard resource plan, and CU-hour resource plan. The pay-per-CU billing method is supported only for DLA CU Edition. You can select a suitable billing method to meet your requirements.

Billing methods

Billing method Description Scenario References
Pay-per-byte When you use this billing method, you are charged based on the number of bytes that are scanned. Cluster deployment, maintenance, and upgrade are free of charge. This billing method is suitable for scenarios in which data is not frequently queried and the amount of data queried is small. If no data queries occur, you are not charged. Pay-per-byte
Pay-per-CU (for DLA CU Edition only) You are charged based on the CU specifications that you purchased. When you use this billing method, you can choose pay-as-you-go or subscription. This billing method has nothing to do with the number of bytes that are scanned. This billing method is suitable for scenarios in which data is frequently queried and the amount of data queried is large. This billing method also helps you use DLA with accurate budgeting. Pay-per-CU (for DLA CU Edition only)
Standard resource plan A prepaid resource plan. When you use this billing method, the quota of a resource plan is automatically consumed based on the number of bytes that are scanned. This billing method is suitable for scenarios in which data is not frequently queried and the amount of data queried is small. If no data queries occur, you are not charged. This billing method is cost-effective. The more resource plans you buy, the more discounts you enjoy. For more information about how to purchase a resource plan, see Standard resource plan. N/A
CU-hour resource plan CUs of DLA support the combination of pay-as-you-go (for DLA CU Edition) and resource plans. When you use this billing method, a resource plan is used to deduct the fees of the pay-as-you-go clusters. You can increase or decrease the CU specifications of the pay-as-you-go clusters at any time. If you increase the CU specifications of the pay-as-you-go clusters, you do not need to consider the price difference for the remaining subscription duration. The quota of a resource plan is consumed only if you use the resource plan. This billing method is easier to use and more cost-effective than subscription and pay-as-you-go. If your workloads frequently fluctuate and you may need to change the CU specifications of clusters every month or even every week, we recommend that you purchase pay-as-you-go clusters and use these clusters with CU-hour resource plans. If you change CU specifications of clusters, the quota of resource plans is automatically consumed based on the new specifications. This billing method is cost-effective. The more resource plans you buy, the more discounts you enjoy. For more information about how to purchase a resource plan, see CU-hour resource plan. N/A
The following table describes the differences between the billing method based on the number of bytes scanned and the billing method based on the number of CUs used.
Item Based on the number of bytes scanned Based on the number of CUs used
Billing method You are charged based on the number of bytes scanned. Less queries incur less fees. This billing method is suitable for scenarios in which data is not frequently queried. You are charged based on the number of CUs that you purchase instead of based on the number of bytes scanned. This billing method is suitable for scenarios in which data is frequently queried.
Supported data sources Object Storage Service (OSS), Tablestore, ApsaraDB RDS for MySQL, ApsaraDB RDS for SQL Server, AnalyticDB for PostgreSQL, AnalyticDB for MySQL, MaxCompute, ApsaraDB for MongoDB, ApsaraDB for Redis, and Elasticsearch Self-managed HDFS, Oracle, Kudu, and Druid data sources in addition to all the data sources that the billing method based on the number of bytes scanned supports
Number of SQL statements that can be concurrently executed 10 100
Maximum SQL runtime 30 minutes 12 hours
Access to self-managed Hive Metastore No YES
Built-in cache No YES
UDF No Supported later (under development)