本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 預估 Amazon EMR 叢集容量
雖然 Amazon EMR 是可調整大小的平台，但適當調整叢集大小也很重要。如果叢集大小過小，適當調整大小可避免叢集速度緩慢；如果叢集大小過大，適當調整大小可避免較高的成本。為了預測這些問題，您可以計算工作負載所需的節點數量和類型。
## 主節點
這種類型的節點負責協調資料和程序的分發。如前所述，主節點的運算要求較低。您可以使用單一主節點來管理 Amazon EMR 叢集。但是，您最多可以使用三個主節點，這樣就不會出現單點故障。如果一個主節點發生故障，Amazon EMR 會容錯移轉至另兩個主節點之一。
## 核心節點和任務節點
核心節點與任務節點之間的差異在於任務節點不儲存資料；它們僅提供執行平行運算任務的能力。
若要計算核心節點和任務節點的數量，您必須知道資料的大小和大約記憶體用量。
### 核心節點
核心節點負責執行任務來處理資料，並將資料儲存在 Hadoop 分散式檔案系統 (HDFS) 中。若要計算核心節點的容量，請定義核心節點的數量，然後將節點數量乘以每個節點的 Amazon Elastic Block Store (Amazon EBS) 儲存。
例如，如果您定義 10 個核心節點來處理 1 TiB 資料，並且您的 `m5.xlarge` 即時類型具有 64 GiB Amazon EBS 儲存，則您具有 `10 nodes × 64 GiB` 或 640 GiB 容量。根據 HDFS [複寫係數](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-instances-guidelines.html) 3，您的資料大小在節點中複寫 3 次，因此 1 TiB 資料需要 3 TiB 容量。由於此範例只有 640 GiB，因此您必須增加節點數量或變更執行個體類型，直到容量達到 3 TiB。
`m5.4xlarge` 執行個體類型具有 256 GiB 儲存。變更為 `m5.4xlarge` 執行個體類型並選取 12 個執行個體可提供足夠的容量。
`12 instances × 256 GiB of storage = 3072 GiB = 3 TiB available`
### 任務節點
任務節點僅執行任務。它們不儲存資料。若要計算任務節點的數量，您需要預估記憶體用量。此容量可以分為核心節點和任務節點。若要計算所需的任務節點數量，您可以從記憶體用量中減去上一步中計算的核心節點所提供的記憶體。
若要具有一系列擴展的記憶體，最佳實務是將所需的記憶體乘以 3。
假設您具有 28 個程序，每個程序為 20 GiB。
`3 × 28 processes × 20 GiB of memory = 1680 GiB of memory`
在此範例中，您的核心節點具有 64 GiB 記憶體 (`m5.4xlarge` 執行個體)。您的核心節點提供 `64 GiB × 12 nodes = 768 GiB of memory`，這在此範例中是不夠的。
若要找出短缺情況，請從所需的總記憶體中減去核心節點記憶體。
`1680 GiB – 768 GiB core node memory = 912 GiB memory shortage`.
任務節點可以提供剩餘的 912 GiB 記憶體。在此範例中，您的任務節點具有 32 GiB 記憶體 (`m5.2xlarge` 執行個體)。若要取得所需的任務節點數量，請將記憶體短缺量除以執行個體類型記憶體。
`912 GiB/32 GiB = 28.5 task nodes`
任務節點不能有小數，因此您需要四捨五入為 29 個任務節點。