本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 估算 Amazon EMR 集群容量
虽然 Amazon EMR 是一个可调整大小的平台，但请务必正确调整集群的大小。如果集群过小，适当调整大小可以避免集群运行缓慢；如果集群过大，则可以避免产生更高的成本。要预测这些问题，您可以计算工作负载所需的节点数量和类型。
## 主节点
此类节点负责协调数据和进程的分配。如前所述，主节点的计算需求较低。您可以使用单个主节点来管理 Amazon EMR 集群。但是，您最多可以使用三个主节点，这样就不会出现单点故障。如果一个主节点发生故障，Amazon EMR 会失效转移到其他两个主节点之一。
## 核心节点和任务节点
核心节点和任务节点的区别在于，任务节点不存储数据；它们仅提供执行并行计算任务的能力。
要计算核心节点和任务节点的数量，必须了解数据大小和大致的内存使用量。
### 核心节点
核心节点负责运行任务来处理数据，并将数据存储在 Hadoop Distributed File System（HDFS）中。要计算核心节点的容量，请确定核心节点的数量，然后将节点数量乘以每个节点的 Amazon Elastic Block Store（Amazon EBS）存储空间。
例如，如果定义 10 个核心节点来处理 1 TiB 的数据，并且您的一个 `m5.xlarge` 实例类型的 Amazon EBS 存储空间为 64 GiB，则您将拥有 `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 个任务节点。