Amazon EMR搭配NVIDIA RTX PRO 4500：Spark性能提升3.7倍

多年来，Apache Spark一直是大规模数据处理的支柱。然而，随着数据集不断增长，人工智能和机器学习（AI/ML）流水线变得越来越复杂，现代工作负载需要更强大的计算能力。机器学习模型的特征工程、大规模提取转换加载（ETL）转换以及实时分析工作负载本质上都是计算密集型的。GPU加速实例提升了性能，将过去需要数小时的任务缩短到几分钟，使您能够更快地迭代模型并降低运营成本。您可以在单批次中处理更大的数据集，实时做出决策，并在不过度配置基础设施的情况下实现强劲性能。

我们很高兴分享在Amazon EMR上进行的基准测试结果，Amazon Elastic Compute Cloud (Amazon EC2) G7实例，由NVIDIA RTX PRO 4500 Blackwell服务器版GPU驱动。对于运行Apache Spark工作负载的数据工程师和数据科学家，这意味着更快的流水线、更短的迭代周期，以及更多时间专注于洞察。

Amazon EMR on EKS原生支持Apache Spark的NVIDIA cuDF插件。这项支持是AWS和NVIDIA联合工程的结果，旨在为Amazon EMR认证cuDF插件，为RTX PRO 4500共同优化Spark执行路径，并通过在Amazon EC2 G7实例上共享TPC-DS基准测试验证大规模性能。现在，在Amazon EMR on EKS上运行的Apache Spark工作负载，使用Amazon EC2 G7 GPU实例比同等CPU实例快达3.7倍，且无需修改现有Spark代码。

在TPC-DS 3 TB基准测试中，在64 GB内存级别，配备RTX PRO的EC2 G7实例在4.7分钟内完成。如果您运行大规模数据处理流水线，您可以将作业运行时间缩短三分之二以上，同时保持与您已在生产环境中使用的应用程序完全兼容。

最能从中受益的使用场景是速度直接释放业务价值的场景。在AI/ML特征工程中，更快的Spark作业意味着数据科学团队可以更快地迭代特征，缩短从原始数据到训练模型的时间。在复杂的ETL流水线中，如金融交易、点击流聚合或供应链数据整合，GPU加速将多小时的批处理窗口压缩为近实时处理。对于实时分析，运行欺诈检测、个性化引擎或运营仪表板的团队可以在更严格的延迟窗口内处理更大量的数据，而无需重新设计架构。

除了数据分析，G7实例还将支持广泛的AI和图形工作负载，包括会话式AI、内容生成、推荐系统以及视频流和渲染。它们基于AWS Nitro系统构建，提供生产级AI、分析和图形工作负载所需的安全性和资源效率。

以下部分将介绍集群配置、基准测试方法和性能结果。

集群配置

我们使用四种实例类型进行基准测试，以衡量G7 GPU实例与同等CPU实例在Spark SQL性能方面的实际表现。g7.4xlarge还提供80 Gbps网络带宽（CPU基线为15-17 Gbps），并使用RapidsShuffleManager。但是，CPU运行在此集群规模下没有表现出网络或shuffle瓶颈。所有测试均使用Amazon EMR on EKS 7.12.0，Apache Spark 3.5.6和cuDF插件26.04.2，运行完整的TPC-DS基准测试，3 TB规模，共103个查询。每个实验运行5次迭代。我们报告中位数。数据以Parquet格式存储在Amazon Simple Storage Service (Amazon S3)上（同区域网关端点）。所有实例都在单个可用区中启动。TPC-DS基准测试在3 TB规模下运行103个查询。

实例规格

这四种实例类型共享相同的计算足迹：16 vCPU和64 GB系统内存。g7.4xlarge额外包含一个NVIDIA RTX PRO 4500 Blackwell GPU，具有32 GB专用视频内存（VRAM），cuDF插件使用它来加速Spark SQL操作。所有速度和成本比较的基线是m9gd.4xlarge（Graviton），该组中成本最低的CPU实例。

g7.4xlarge使用RTX PRO 4500 Blackwell服务器版GPU。CPU基线覆盖所有三种主要架构：m8id.4xlarge（Intel x86）、m8a.4xlarge（AMD x86）和m9gd.4xlarge（Graviton arm64）。

Spark配置

所有实例均使用八个执行节点，配置如下：

CPU实例使用与GPU相同的30 GB memoryOverhead，以确保内存比较是公平的。此设置为双方预留了shuffle和缓存的堆外内存。

对于GPU实例，cuDF插件自动将Spark SQL操作卸载到GPU。无需更改代码。GPU实例的executor.memoryOverhead值设置得更高，以适应GPU内存管理和RAPIDS shuffle管理器。executor.memoryOverhead值在GPU实例上设置得更高，以容纳GPU内存管理和RAPIDS shuffle管理器。

cuDF插件对于不支持的运算符和用户定义函数（UDF）会自动回退到CPU执行。您的作业仍然完成，但这些阶段在没有GPU加速的情况下运行。要识别哪些操作在GPU上运行而与CPU相比，请设置spark.rapids.sql.explain=NOT_ON_GPU。spark.rapids.sql.explain=NOT_ON_GPU 在您的 Spark 配置中。为了在工作负载迁移前进行评估，请使用 NVIDIA cuDF 工具 在迁移到 G7 实例之前估算 GPU 加速潜力。

要调整类似 concurrentGpuTasks 和 pinnedPool.size 的设置，请使用 Amazon EMR on EKS 上的 Spark 历史服务器，它提供每个阶段的执行详情，以识别 CPU 回退和 shuffle 瓶颈。

开始使用

参考 在 Amazon EMR on EKS 上为 Apache Spark 使用 cuDF 加速器 获取详细的设置说明。

前提条件

在 Amazon EMR on EKS 上运行 GPU 加速的 Spark 之前，请确保满足以下条件：

• Amazon EMR on EKS 版本 6.9.0 或更高（本文使用 emr-7.12.0-spark-rapids-latest）。

-spark-rapids 发布变体预装了 NVIDIA cuDF 插件。

kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.9.0/nvidia-device-plugin.yml

• Amazon Elastic Kubernetes Service (Amazon EKS) 集群 使用 G7 实例的 GPU 节点组。
• 节点 AMI： AL2023_x86_64_NVIDIA（Amazon EKS 优化加速 AMI）。
• NVIDIA 设备插件 已安装在集群中，以将 GPU 暴露给 Kubernetes Pod：
• Amazon EMR on EKS 虚拟集群 已注册到 EKS 命名空间。

要验证节点上的 GPU 可用性：

kubectl get nodes "-o=custom-columns=NAME:.metadata.name,GPU:.status.allocatable.nvidia\.com/gpu"

注意：在 Amazon EMR 上开始使用 GPU 加速的 Spark 很简单。要使用最新的 cuDF 插件，请使用 initContainer 技术将最新版本（例如，截至 2026 年 5 月的 26.04.2）覆盖到 Amazon EMR RAPIDS 镜像上。这会将捆绑的 cuDF JAR 替换为较新版本，同时保留所有其他 Amazon EMR 依赖项。我们建议使用最新的 Amazon EMR 版本，以获得最新的 cuDF 插件，以实现更好的性能。在我们的基准测试中，从 cuDF 插件 25.08.0 升级到 26.04.2 将运行时间减少了 36–38%。从 NVIDIA 仓库 下载最新的 cuDF 插件 JAR。AWS 支持涵盖 Amazon EMR。对于特定 cuDF JAR 的问题，请在 GitHub 上提交问题或联系 NVIDIA：[email protected]。

性能基准与成本效率

我们在 us-east-1 的 8 节点集群上以 3 TB 规模运行了完整的 TPC-DS 基准测试套件（103 个查询）。下表总结了结果：

单次运行成本 是基准测试期间集群的总成本：集群 $/小时 ×（中位运行时间 ÷ 3,600）。每小时费率结合了所有 8 个节点的 EC2 按需成本和 Spark Pod 消耗的 vCPU 和内存的 Amazon EMR on EKS 费用。两者均按秒计费（至少一分钟），因此您只需支付作业运行期间使用的费用。所有运行均使用 us-east-1 中的 Amazon EMR on EKS 7.12.0，GPU 和 CPU 侧均为 8 × 4xlarge 节点（128 vCPU）。g7.4xlarge 集群运行费率为 $26.35/小时（8 × $3.042 EC2 = $24.34，加上 $2.01 的 Amazon EMR on EKS），在 281 秒内完成，每次运行成本为 $2.06。CPU 集群的每小时费率较低（$10.43–$10.99），但需要 1,010–1,043 秒，单次运行成本为 $2.93–$3.18。所有价格均反映 2026 年 5 月 us-east-1 的按需价格。G7 实例还符合 EC2 Spot 和 Compute Savings Plans 的条件，这可以进一步降低周期性批处理工作负载的成本。

每次运行成本计算仅包括 EC2 和 Amazon EMR 费用。它们不包括 EKS 控制平面费用、EBS 卷、S3 请求和存储成本，以及驱动 Pod。

图 1：按实例类型列出的所有 103 个 TPC-DS 查询在 3 TB 规模下的总运行时间。g7.4xlarge 通过 GPU 加速在 4.7 分钟内完成了基准测试，比 CPU 实例（16.8-17.4 分钟）快 3.7 倍

图 2：每次基准运行的总成本，包括所有 8 个节点的 Amazon EC2 实例和 Amazon EMR on EKS 成本。尽管每小时费率高出约 2.5 倍，但 g7.4xlarge GPU 实例每次运行的成本比 Graviton 低 31%，因为它完成工作负载的速度快 3.7 倍

GPU 加速的优势领域

GPU 加速在 281 秒内完成了 103 个查询的 power run，而 CPU 需要 1,032 秒，总体加速 3.7 倍，每次运行节省 750 秒。GPU 在 103 个查询执行中的 102 个上速度更快。

对于长时间运行、计算密集和 shuffle 密集的查询，GPU 加速带来最大的收益，因为内核吞吐量超过了启动开销。最大的绝对时间节省：

所有 103 次执行的加速比分布：

每查询中位加速比 2.94×（几何平均 2.84×）。最重的查询（q50、q76、q93）是聚合和 shuffle 连接密集型查询，可干净地转换为 GpuHashAggregate 和 GpuBroadcastHashJoin。

CPU 占优的场景

使用 RAPIDS 26.04.2，以下查询展示了 CPU 更快的工作负载模式：

选择正确的实例

G7 实例要求在您的账户中有 G-instance vCPU 服务配额（对于 GPU 类型，默认值通常为 0）。通过 Service Quotas 控制台申请提高配额，或使用按需容量预留（ODCR）来保证重复批处理作业的可用性。

基于这些基准测试结果，请考虑为您自己的 Apache Spark 工作负载评估 GPU 加速。首先确定当前管道中的计算密集型操作，特别是涉及大规模聚合、连接或机器学习特征工程的操作，这些操作可能受益于此处的性能改进。

结论

带有 NVIDIA RTX PRO 4500 的 Amazon EMR on EKS 为运行大规模数据密集型 Spark 工作负载的团队提供了有意义的一步。无论您是构建需要快速特征迭代的机器学习管道，运行跨海量数据集的复杂 ETL 转换，还是为无法等待缓慢批处理作业的实时分析提供支持，G7 上的 GPU 加速 Spark 都能提供更高的性能和速度。随着数据和 AI 工作负载的不断演变，Amazon EMR 上的 GPU 加速分析正成为数据团队的基础。今天就开始在 Amazon EMR on EKS 上使用 GPU 加速 Spark，请访问 Amazon EMR 文档 启动您的第一个 G7 驱动集群，亲自体验性能提升。