在AWS Graviton2上部署Apache Spark，可获得高达58%的性价比优势

https://community.arm.com/arm-community-blogs/b/infrastructure-solutions-blog/posts/apache-spark-performs-better-on-aws-graviton2

作者：Masoud Koleini 2022年3月15日

介绍

Apache Spark是一个分布式大数据计算引擎，运行在一组机器上。在Spark上，并行计算可以使用称为RDD（弹性分布式数据集）的数据集抽象执行，也可以使用Spark SQL API作为SQL查询执行。Spark Streaming是一个Spark模块，允许用户将流数据表示为RDD/数据帧抽象。这些抽象贯穿函数，结果存储在存储后端。结果也可以发送到输出流。Apache Spark主要适用于大数据处理，在大数据处理中，数据不能驻留在一台机器的内存中。

在本博客中，我们比较了在M6gd（AWS Graviton2）和M5d（Intel Skylake SP或Cascade Lake）AWS实例上运行在单节点yarn-cluster上的Apache Spark的性能。HDFS（Apache Hadoop分布式文件系统）数据存储在连接到实例的基于NVMe的SSD存储器上。

AWS Graviton2：基于Arm Neoverse的处理器

AWS已经使用Arm Neoverse内核构建了Graviton 2处理器，这些内核针对云工作负载进行了优化。与x86实例相比，基于Graviton2的实例提供了更好的性价比。Graviton2实例的性价比优势取决于部署的应用程序类型。与x86应用程序相比，某些应用程序的性价比可以提高40%。

AWS报告称，在运行Spark工作负载时，基于Graviton2的Amazon EMR的性能有所提高，因此在M6g、C6g和R6g实例类型上运行集群的价格更低.

基准环境

基准工具

HiBench是Hadoop、Spark、Flink和Kafka的大数据基准测试工具，在本博客中用于比较不同架构AWS实例上的Spark性能。它有六个工作负载类别：Micro Benchmarks、机器学习、SQL、图形、流媒体和Web搜索。每个工作负载都定义了一个数据规模配置文件，该配置文件来自于一组tiny, small, large, huge, gigantic, 以及bigdata.。每个数据配置文件的大小在工作负载配置文件中定义。

为了比较不同AWS实例上Spark计算的吞吐量，选择了三种不同类别的两种工作负载：

Spark SQL：来自SQL工作负载的聚合
实现Spark SQL聚合函数。
Spark ML:ML工作负载的K-means
实现了涉及大量数据处理的K-means聚类算法。

一些bigdata基准测试所需的存储空间大于M5d（x86）实例上的NVMe分区。因此，我们在本博客中省略了bigdata概要测试。此外，由于Spark专门用于large 数据集计算，因此我们也忽略了 tiny 和small数据集的结果。

Spark cluster

对于基准测试，Sharn Hadoop集群是伪分布式的，其中Hadoop在单个节点上运行，其守护进程在单独的JVM上运行。基准数据存储在同一节点上运行的HDFS集群中，使用NVMe SSD作为其存储后端。

Spark版本是3.1.2，Yarn Hadoop版本是3.3.1。Spark/Thread配置使用最佳实践和建议，将测试实例的可用资源考虑在内。下表显示了用于不同实例大小的执行器、执行器内核和执行器内存的数量：

表1。不同情况下的Yarn 执行器参数

可以根据集群上运行的计算类型调整集群参数。为了简单起见，Spark基准测试对所有工作负载使用类似的参数。执行器内核的数量设置为5，并计算执行器的数量，因此Core的总数仍然小于实例上可用的VCPU。Yarn执行器内存的计算遵循相同的原则，因此执行器使用的总内存仍然小于总可用内存。一些vCPU和内存留给操作系统进程和守护进程（按照HiBench简介中的建议进行推荐设置）。

AWS实例设置

基准测试在支持NVMe的通用计算实例上运行，支持三种不同的大小：8xlarge、12xlarge和16xlarge。

实例的规格如下：

表2。测试的实例配置

性价比比较

基准测试在单个节点上运行，类似于Spark集群，网络延迟非常低。感兴趣的指标是字节/秒（吞吐量）。图1中的图表展示了在m6gd上运行的Spark的性价比（字节/美元）（条形图，左轴）。m6gd.16xlarge 和 m5d.16xlarge，这是两个具有相似资源的实例。

这些实例部署在us-east-1上，并使用按需价格计算性价比。对于选定的工作负载，M6gd的性价比优势在聚合（aggregation）方面高达37%，在K-均值大型数据集（直线图，右轴）方面高达58%。

图1。SQL/聚合性价比比较，16xlarge实例

图2。ML/K-means性价比比较，16xlarge实例

表3和表4是M6gd实例相对于M5d实例在聚合和K-means方面的性价比数字和改进百分比（数据来自图1和图2）。

表3。16xlarge实例的大型到巨型数据集上的Sql/聚合 bytes/$

表4。用于16xlarge实例的大型到巨型数据集的ml/K-means bytes/$

Spark集群通常处理数TB的数据，产生许多工作节点来运行执行器。性价比计算（表3和表4）显示了用户如何通过在M6gd实例上运行集群来显著降低成本。下一节中的吞吐量基准向用户展示了通过在M6gd上运行作业可以获得的性价比优势和计算性能。

基准测试性能结果

本节中的图表显示了8xlarge、12xlarge和16xlarge实例的基准测试结果。每个图表的左轴是以字节/秒为单位的吞吐量（条形图）。右轴是M6gd相对于M5d实例的性能改进（折线图）。

Spark SQL基准测试

以下图表比较了8xlarge、12xlarge和16xlarge实例大小的M6gd和M5d实例上的聚合性能吞吐量。HiBench SQL聚合基准测试显示，在M6gd和M5d的巨大数据集上，吞吐量分别高出29%（8xlarge）、18%（12xlarge）和9.74%（16xlarge）。

图3：SQL/聚合吞吐量比较 8xlarge实例

图4：SQL/聚合吞吐量比较 12xlarge实例

图5：SQL/聚合吞吐量比较 16xlarge实例

表5、6和7是SQL聚合基准的吞吐量数字和M6gd相对于M5d实例的改进。

表5：SQL/聚合吞吐量比较数据 8xlarge实例

表6：SQL/聚合吞吐量比较数据 12xlarge实例

表7：SQL/聚合吞吐量比较数据 16xlarge实例

Spark ML基准

图6、图7和图8中的图表表示M6gd和M5d实例的K-means基准。K-means基准测试显示，在这个庞大的数据集上，高达21.6%（8xlarge实例）的吞吐量。在这个庞大的数据集上，吞吐量分别提高了23.6%（12xlarge实例）和26.88%（16xlarge实例）。

图6。ML/K-means吞吐量比较，8xlarge实例

图7。ML/K-means吞吐量比较，12xlarge实例

图8。ML/K-means吞吐量比较，16xlarge实例

表8、9和10是K-means基准的吞吐量数字和M6gd相对于M5d实例的改进。

表8：ML/K-means吞吐量比较数据，8xlarge实例

表9：ML/K-means吞吐量比较数据，12xlarge实例

表10：ML/K-means吞吐量比较数据，16xlarge实例

选择正确的EBS卷

我们还对具有通用SSD卷（gp2）的实例运行了基准测试。当作业具有较小的I/O大小和不频繁的磁盘访问时，我们的实验表明，在gp2上运行Spark作业与使用基于NVMe的卷之间的差异可以忽略不计。聚合和K-means基准就是这样。但是，如果Spark作业需要大量磁盘访问（例如，micro benchmarks中的WordCount ），用户在通用SSD卷上的性能会很差。这种低性能是由于对存储施加了IOPS/吞吐量限制。因此，为作业选择正确的卷类型可以在不影响性能的情况下降低成本，从而为用户带来好处。