使用 Amazon EMR 针对 Apache Spark 的运行时将 Apache Spark 3

2026-01-27 12:41:05

用 Amazon EMR 运行 Apache Spark 351 工作负载的性能提升

关键要点

Amazon EMR 提供了针对 Apache Spark 的优化运行时，性能比 Apache Spark 351 快 45 倍，并在成本效益方面提高了 28 倍。自 2022 年底以来新增了 35 项优化，能显著提升 Spark 的运行效率。基于 TPCDS 3 TB 数据集的基准测试表明，Amazon EMR 71 的运行时间比 Apache Spark 351 快 45 倍。

Amazon EMR 针对 Apache Spark 的优化运行时是100 API兼容开源 Apache Spark 的高性能运行时。通过改进查询计划、更快的查询和优化默认设置，它提供了比 Apache Spark 更快的开箱即用的性能。包括 Amazon EMR on EC2、Amazon EMR Serverless、Amazon EMR on Amazon EKS 以及 Amazon EMR on AWS Outposts 在内的多个服务均使用这一优化运行时，其性能比 Apache Spark 351 快 45 倍，基于来自 TPCDS 在 3 TB 规模的行业标准基准，其成本效益比达到 28 倍需注意，我们的 TPCDS 派生基准结果与官方 TPCDS 基准结果不具可比性。

自 EOY 2022 发布的 EMR 69 版本以来，我们已经新增了 35 项优化，包含在 EMR 70 和 EMR 71 中。这些改进默认开启，并与 Apache Spark 完全兼容。一些最近的改进包括

Spark 物理计划操作符改进持续改善 Spark 运行时性能，改变了操作符算法：优化哈希连接中使用的数据结构以提高性能和内存需求，使得在更多情况下能够使用更高效的连接算法。优化部分窗口的排序。优化汇总操作。改进洗牌分区的排序算法。优化哈希聚合操作符。更高效的小数算术运算。

基于 Parquet 统计信息的聚合。

Spark 查询规划改进在 Spark 的 Catalyst 优化器中引入了新规则以提高效率：

自适应最小化多余连接。自适应识别并禁用在运行时无帮助的优化。

从复杂的查询计划中推导出更先进的布隆过滤器和动态分区裁剪过滤器，以减少从 Amazon Simple Storage Service (Amazon S3) 交换和读取的数据量。

减少请求到 Amazon S3 通过最小化不必要的请求和为 Parquet 文件页脚引入缓存，减少从 Amazon S3 读取 Parquet 文件时发送的请求。

Java 17 作为 Amazon EMR 70 的默认 Java 运行时 Java 17 经历了广泛的测试和优化，提高了性能，因而成为 Amazon EMR 70 的默认 Java 运行时。

有关 EMR Spark 性能优化的更多信息，请参考优化 Spark 性能。

在本文中，我们分享了测试方法和基准测试结果，将 Amazon EMR 的最新版本70 和 71与 2022 年底的版本69和 Apache Spark 351 进行了比较，以展示 Amazon EMR 最新实现的成本改善。

Amazon EMR 71 与 Apache Spark 351 的基准测试结果

为了评估 Spark 引擎的性能，我们使用 3 TB 的 TPCDS 数据集进行基准测试。在 Amazon EMR 上使用 EMR Spark 集群进行基准测试，并在 designated 的 Amazon EC2 集群上安装 Apache Spark 351 进行开源 SparkOSS基准测试。我们在包含九个 r5d4xlarge 实例的单独 EC2 集群上进行了测试，分别运行 Apache Spark 351、Amazon EMR 690 和 Amazon EMR 71。主节点具有 16 个 vCPU 和 128 GB 内存，而八个工作节点总共有 128 vCPU 和 1024 GB 内存。为了突出开箱即用的体验，我们使用 Amazon EMR 默认值进行测试，并对 Apache Spark 进行最低限度的设置调整以提供公平比较。

我们选择了 3 TB 规模的源数据，其中包含 177 亿条记录，约 924 GB 的压缩数据以 Parquet 文件格式存储。设置说明和技术细节可以在GitHub 仓库中找到。我们使用 Spark 的内存数据目录来存储 TPCDS 数据库和表的元数据。sparksqlcatalogImplementation 设置为默认值 inmemory。事实表按日期列进行分区，生成的分区范围为 2002100。未为这些表预计算统计数据。

在三次迭代中运行了总共 104 个 SparkSQL 查询，使用每个查询在三次迭代中的平均运行时间进行比较。Amazon EMR 71 三次迭代的平均运行时间为 051 小时，日期分别比 Amazon EMR 69 快 19 倍，比 Apache Spark 351 快 45 倍。以下图表展示了总运行时间秒。

接下来，下面的图表展示了 Amazon EMR 71 与 Apache Spark 351 之间每个查询的加速比。同样，Amazon EMR 在所有 TPCDS 查询中均比 Apache Spark 更快，但在某些查询中的加速效果要明显得多。水平轴代表按 Amazon EMR 加速比降序排列的 TPCDS 3 TB 基准查询，而纵轴则显示由于 Amazon EMR 运行时导致的查询加速比。

成本比较

我们的基准测试输出了总运行时和几何均值数据，来模拟实际复杂决策支持用例下的 Spark 运行时性能。成本指标亦能提供更多见解。成本估算是根据以下公式计算的。它们考虑了 Amazon EC2、Amazon Elastic Block Store (Amazon EBS) 以及 Amazon EMR 的成本，但不包括 Amazon S3 的 GET 和 PUT 成本。

Amazon EC2 成本包含 SSD 成本= 实例数量 r5d4xlarge 每小时费用作业运行时间小时4xlarge 每小时费用 = 1152 每小时根 Amazon EBS 成本 = 实例数量 Amazon EBS 每 GB每小时费用根 EBS 卷大小作业运行时间小时Amazon EMR 成本 = 实例数量 r5d4xlarge Amazon EMR 成本作业运行时间小时4xlarge Amazon EMR 成本 = 027 每小时总成本 = Amazon EC2 成本根 Amazon EBS 成本 Amazon EMR 成本

根据计算，Amazon EMR 71 的基准结果表明，与 Apache Spark 351 相比，其工作成本改善达 28 倍，而与 Amazon EMR 69 相比则提高了 17 倍。

指标Amazon EMR 71Amazon EMR 69Apache Spark 351运行时间小时051087176EC2 实例数量999Amazon EBS 大小20 GB20 GB20 GBAmazon EC2 成本5299021825Amazon EBS 成本001002004Amazon EMR 成本124211000总成本65411151829成本节省基准Amazon EMR 71 提高了 17 倍Amazon EMR 71 提高了 28 倍

运行 OSS Spark 基准测试

为了运行 Apache Spark 351，我们使用以下配置设置 EC2 集群。我们使用一个主节点和八个类型为 r5d4xlarge 的工作节点。

EC2 实例vCPU内存GiB实例存储GBEBS 根卷GBr5d4xlarge161282 x 300 NVMe SSD20GB

前提条件

运行基准测试所需的前提条件：

银河加速器免费版本根据 emrsparkbenchmark GitHub 仓库中的说明，在你的 S3 存储桶和本地计算机中设置 TPCDS 源数据。按照构建 sparkbenchmarkassembly 应用程序的步骤中的步骤构建基准应用程序，并将其复制到你的 S3 存储桶。或者，将 sparkbenchmarkassembly351jar 复制到你的 S3 存储桶。

此基准应用程序是基于分支 tpcdsv213 构建的。如果你正在构建新的基准应用程序，请在从 GitHub 仓库下载源代码后切换到正确的分支。

在 Amazon EC2 上创建并配置 YARN 集群

按照 emrsparkbenchmark GitHub 仓库的说明，在 Amazon EC2 上使用 Flintrock 创建 OSS Spark 集群。

基于此测试的集群选择，使用了以下配置：

flintrockconfigyamlyarnsitexmlenableyarnsh

运行 Apache Spark 351 的 TPCDS 基准测试

执行以下步骤以运行 Apache Spark 351 的 TPCDS 基准测试：

使用 flintrock login CLUSTERNAME 登录 OSS 集群主节点。提交你的 Spark 作业：TPCDS 源数据位于 s3a//ltYOURS3BUCKETgt/BLOGTPCDSTEST3Tpartitioned。查看前提条件以设置源数据。结果将生成在 s3a//ltYOURS3BUCKETgt/benchmarkrun。

你可以在 /media/ephemeral0/sparkrunlog 中跟踪进度。

使用 Amazon EMR 针对 Apache Spark 的运行时将 Apache Spark 3

bashsparksubmit master yarn deploymode client class comamazonawsekstpcdsBenchmarkSQL conf sparkdrivercores=4 conf sparkdrivermemory=10g conf sparkexecutorcores=16 conf sparkexecutormemory=100g conf sparkexecutorinstances=8 conf sparknetworktimeout=2000 conf sparkexecutorheartbeatInterval=300s conf sparkdynamicAllocationenabled=false conf sparkshuffleserviceenabled=false conf sparkhadoopfss3aawscredentialsprovider=comamazonawsauthInstanceProfileCredentialsProvider conf sparkhadoopfss3aimpl=orgapachehadoopfss3aS3AFileSystem conf sparkjarspackages=orgapachehadoophadoopaws334 sparkbenchmarkassembly351jar s3a//ltYOURS3BUCKETgt/BLOGTPCDSTEST3Tpartitioned s3a//ltYOURS3BUCKETgt/benchmarkrun /opt/tpcdskit/tools parquet 3000 3 false q1v213q10v213q11v213q12v213q13v213q14av213q14bv213q15v213q16v213 q17v213q18v213q19v213q2v213q20v213q21v213q22v213q23av213q23bv213 q24av213q24bv213q25v213q26v213q27v213q28v213q29v213q3v213q30v213 q31v213q32v213q33v213q34v213q35v213q36v213q37v213q38v213q39av213 q39bv213q4v213q40v213q41v213q42v213q43v213q44v213q45v213q46v213 q47v213q48v213q49v213q5v213q50v213q51v213q52v213q53v213q54v213 q55v213q56v213q57v213q58v213q59v213q6v213q60v213q61v213q62v213 q63v213q64v213q65v213q66v213q67v213q68v213q69v213q7v213q70v213 q71v213q72v213q73v213q74v213q75v213q76v213q77v213q78v213q79v213 q8v213q80v213q81v213q82v213q83v213q84v213q85v213q86v213q87v213 q88v213q89v213q9v213q90v213q91v213q92v213q93v213q94v213q95v213 q96v213q97v213q98v213q99v213ssmaxv213 true gt /media/ephemeral0/sparkrunlog 2gtamp1 amp!

总结结果

Spark 作业完成后，从输出 S3 存储桶中下载测试结果文件 s3a//ltYOURS3BUCKETgt/benchmarkrun/timestamp=xxxx/summarycsv/xxxcsv。你可以使用 Amazon S3 控制台导航到输出存储桶位置或使用 Amazon 命令行工具 (AWS CLI)。

Spark 基准应用程序创建一个时间戳文件夹，并在 summarycsv 前缀下写入汇总文件。你的时间戳和文件名将与上述示例不同。

输出 CSV 文件包含四列，无表头名称：

查询