tencent cloud

Elastic MapReduce

Release Notes and Announcements
Release Notes
Announcements
Security Announcements
Product Introduction
Overview
Strengths
Architecture
Features
Use Cases
Constraints and Limits
Technical Support Scope
Product release
Purchase Guide
EMR on CVM Billing Instructions
EMR on TKE Billing Instructions
EMR Serverless HBase Billing Instructions
Getting Started
EMR on CVM Quick Start
EMR on TKE Quick Start
EMR on CVM Operation Guide
Planning Cluster
Administrative rights
Configuring Cluster
Managing Cluster
Managing Service
Monitoring and Alarms
TCInsight
EMR on TKE Operation Guide
Introduction to EMR on TKE
Configuring Cluster
Cluster Management
Service Management
Monitoring and Ops
Application Analysis
EMR Serverless HBase Operation Guide
EMR Serverless HBase Product Introduction
Quotas and Limits
Planning an Instance
Managing an Instance
Monitoring and Alarms
Development Guide
EMR Development Guide
Hadoop Development Guide
Spark Development Guide
Hbase Development Guide
Phoenix on Hbase Development Guide
Hive Development Guide
Presto Development Guide
Sqoop Development Guide
Hue Development Guide
Oozie Development Guide
Flume Development Guide
Kerberos Development Guide
Knox Development Guide
Alluxio Development Guide
Kylin Development Guide
Livy Development Guide
Kyuubi Development Guide
Zeppelin Development Guide
Hudi Development Guide
Superset Development Guide
Impala Development Guide
Druid Development Guide
TensorFlow Development Guide
Kudu Development Guide
Ranger Development Guide
Kafka Development Guide
Iceberg Development Guide
StarRocks Development Guide
Flink Development Guide
JupyterLab Development Guide
MLflow Development Guide
Practical Tutorial
Practice of EMR on CVM Ops
Data Migration
Practical Tutorial on Custom Scaling
API Documentation
History
Introduction
API Category
Cluster Resource Management APIs
Cluster Services APIs
User Management APIs
Data Inquiry APIs
Scaling APIs
Configuration APIs
Other APIs
Serverless HBase APIs
YARN Resource Scheduling APIs
Making API Requests
Data Types
Error Codes
FAQs
EMR on CVM
Service Level Agreement
Contact Us

Practical Tutorial on Setting Mixed Scaling Rules

PDF
フォーカスモード
フォントサイズ
最終更新日: 2025-01-03 15:05:10

Mixed Scene 1:

The business experiences noticeable peaks and valleys within a certain period, along with sudden, non-periodic short-term business peaks.
Example:
Every weekday at 8:30 AM, a fixed workload analysis and statistics task is required, lasting for 2 hours, which needs 1 additional node for computing power. At other times, the required computing power for unexpected peak loads is uncertain. In this case, three scaling rules can be configured to ensure sufficient computing power and cost savings.
Rule 1: Set a time-based scale-out rule by choosing to repeat the rule every Monday/Wednesday/Thursday/Friday and schedule it to scale out 1 node at 8:15 AM tomorrow, with a scheduled termination duration of 3 hours.
Rule 2: Set a load-based scale-out rule, and select the monitoring metrics as needed. It is recommended not to set a validity period, with the default being active all day, scaling out 1 node.
Rule 3: Set a load-based scale-in rule, and select the monitoring metrics as needed. It is recommended not to set a validity period, with the default being active all day, scaling in 1 node.
Note:
1. Scaling out resources takes time, and the time required is proportional to the number of resources being scaled out. It is recommended to prepare resources at least 15 minutes in advance. Typically, the time required is relatively short.
2. The priority order for the three scale-out rules is Rule 1 > Rule 2 > Rule 3; the number of resources to scale can be adjusted based on actual business needs.

Mixed Scene 2:

The business experiences noticeable variations in activity between day and night.
Example:
Business peaks occur every day at 6:30 AM and 5:30 PM, requiring an additional 10 nodes for computing power. The peak duration is uncertain, while a lower computing power requires only 1 node during other times. In this case, you can configure three scaling rules to ensure adequate computing power while optimizing costs.
Rule 1: Set a time-based scale-out rule by choosing to repeat the rule daily and schedule it to be triggered at 6:15 AM tomorrow to scale out 10 nodes.
Rule 2: Set a time-based scale-out rule by choosing to repeat the rule daily and schedule it to be triggered at 5:15 PM tomorrow to scale out 10 nodes.
Rule 3: Set a load-based scale-in rule, and select the monitoring metrics as needed. It is recommended not to set a validity period, with the default being active all day, scaling in 9 node.
Note:
1. The basic configuration sets the maximum number of nodes to 10 and the minimum to 1 to prevent resource wastage and ensure sufficient computing power without any elastic resource shortages. The priority order of the three scale-out rules is Rule 1 > Rule 2 > Rule 3.
2. Scaling out resources takes time, and the time required is proportional to the number of resources being scaled out. It is recommended to prepare resources at least 15 minutes in advance. Typically, the time required is relatively short.


ヘルプとサポート

この記事はお役に立ちましたか?

フィードバック