火花在AWS Graviton2最佳实践:k - means聚类的案例研究

本报告重点介绍如何调优火花的应用程序运行在一个集群实例。我们定义集群/火花参数的概念,并解释如何配置它们给定一组特定的资源。我们使用k - means机器学习算法为例,分析和调优参数来实现所需的性能,同时优化使用可用的资源。

写这份报告的时候,Graviton3只提供compute-optimized实例(C7g)。所以我们用Graviton2基于集群因为更多的实例类型(M6g、R6g C6g)使用基于需求。写这份报告后2月13日,AWS做了介绍通用M7g和memory-optimized R7g基于Graviton3 EC2实例。

这份报告是一个深入的指导。如果你喜欢较短的总结火花AWS Graviton2性能,请参阅我们之前的博客。

火花概念和组件

我们假定读者已经基本熟悉火花的概念和组件。读者需要一些经验与火花编码和资源使用情况的理解和执行分析通过引发Web UI。

环境设置

本文使用的是HiBench套件对引发性能分析。HiBench是专为大数据分析的Hadoop,火花,和流数据引擎。它可以运行不同的工作负载模式包括微基准测试等,字数,eDFSIO。它也可以运行SQL标准如扫描,加入,和聚合。最后,它可以运行机器学习标准k - means聚类,梯度增加卷发和许多更多。基准测试可以运行在不同的数据大小从微小到大数据。

HiBench工作负载运行在两个阶段:

1. 存储数据集到一个HDFS集群(数据准备)。
2. 存储的数据上运行的基准。

我们设置集群在AWS在以下方式:

1. 一个实例运行引发的纱线Hadoop集群伪分布模式。在这个配置中,Hadoop守护进程运行在单独的java进程。这种配置允许所有的执行人在单个机器上运行模拟一个完整的集群。这个配置也降低了延迟执行人之间的洗牌数据时搬到后续阶段。
2. 一个HDFS集群和一个副本在一个单独的实例在同一集群放置组的火花。然后HDFS集群配置为提高读/写存储器带宽相比相对有限的带宽NVMe SSD存储设备。

火花调优的最佳实践

不同的工作负载可能需要不同的调优基于计算的性质。例如,可以计算密集型或内存密集型数据分析问题。例如,机器学习中k - means聚类算法是计算密集型算法,虽然字数是密集的内存更大的内存。对于这个报告,我们探索调优参数k - means聚类在一个有效的方式运行在AWS实例。

我们将火花优化分为两个独立的类:

1. 集群的调优
2. 火花配置调整

集群的调优

调优在集群/工作负载级别涉及选择运行时参数火花计算给定一个具体的实例数量固定资源(CPU内核和内存)。例如,在HiBench以下参数可以设置为运行工作负载:

1. 遗嘱执行人在纱芯模式
2. 遗嘱执行人在纱模式数量
3. 遗嘱执行人的记忆
4. 驱动程序内存
5. 并行性
6. 洗牌分区号

假设有W工人集群节点上运行。每个工人节点有M C g的内存和CPU(个vCPU)核。下面的解释如何计算前面的参数。

遗嘱执行人/核心内存数量

有多种方法考虑执行器的数量:

1. 每个实例一个执行者和分配所有可用的资源(内存和CPU核心)遗嘱执行人。
2. 每个实例多个执行器以及它们之间分割可用资源。

原则上,这两种方法在相似的方式工作时总资源和并行性(并行任务的数量)设置相同。然而,有一些实际的差异,使得使用更多的执行人更合适:

1. 较低数量的执行者,如果一个执行人失败,更多的并行运行的任务会被打断。
2. 较小的执行人更容易计划/安排当实例可用较低的资源。

使用更多的执行人的缺点是,广播数据和缓存复制每一个执行者。因此,如果有E节点执行人,广播数据缓存复制E乘以相同的节点上。

大小的原则

减少负面影响的数据执行人之间的洗牌,尝试运行执行人在一些大尺寸的情况下,而不是许多小尺寸的实例。

以下是建议如何计算不同的纱/火花参数:

• 遗嘱执行人核心:一个(启发式)经验法则提出了资源分配5每个执行者CPU核,这意味着每个执行者可以并行运行5任务或更高。这是通过设置yarn.scheduler配置。在hadoop / etc / hadoop / yarn-site.xml maximum-allocation-vcores。可以设置每个容器最小数量的核心如果必要的话。
• 是很常见的分配相同数量的CPU和内存的火花司机,在计算必须考虑。在故事模式中,火花的司机运行的应用程序请求者(在Kubernetes集群,它运行作为一个单独的容器权限启动执行器容器)。

计算其余会直接:

• 数量的执行人:地板((N * C - N) / 5)
  • 在上面的公式中,每个节点都应该至少有一个核心的操作系统及其他运行的进程(减去核心的总数N)。这个计算假定执行人不司机(应用程序请求者)节点上运行。
    • 计算在伪分布节点安装运行HiBench时略有不同,由于资源分配给驱动程序运行在同一节点必须考虑。
  • 遗嘱执行人记忆:每个实例(M /执行人)* 0.9
    • 这个数量的内存被分配给一个节点执行人。由纱总内存分配到每个执行者是遗嘱执行人内存+内存开销。的内存开销非堆内存用于实习字符串,VM,和其他类型的开销。这个值是默认分配的内存总数的10%。
  • 并行性:
    • 定义了并行运行任务的数量。这个参数的最小值应该可用执行人核的数量。一些资源建议的价值等于总数执行人核心(一样的默认值火花)。火花的文档表明,每个CPU核心可以处理2 - 3并行任务,所以,可以设置更高的数量(例如,遗嘱执行人核心总数的两倍)。输入抽样分为相同数量的分区时返回的操作,比如加入,reduceByKey,并行化(火花每个分区创建一个任务)。
      • 这个参数只适用于计算原料抽样。它使用dataframes时被忽略。
    • 调整分区大小
      • 这就像并行性参数,但适用于dataframes。默认值为200,但用户可以将值设置为一个不同的数字。一种选择是数量设置为核心数量的两倍作为并行。我们所做的然而,一些采取不同的方法来设置分区大小:
        • 任务的最佳分区大小128 mb和256 mb。因此,输入数据的大小划分为128 mb (256 mb)找到合适的分区的数量。请注意,您必须设置分区CPU内核的一个因素的数量保持在集群工作负载的对称。

这种方法的缺点是,用户必须意识到反序列化后的输入数据的大小。此外,在每一个洗牌阶段数据大小是不同的。所以,一种方法是提高分区的数量,直到性能开始下降。

当阅读从桶HDFS文件,初始分区数量(任务)取决于HDFS分区的大小(默认128 mb)。所以,分区总数将总数据大小除以默认的分区大小。调整分区大小生效期间第一个数据洗牌时移动到下一个阶段。

纱parameter-naming公约

从纱线的参数。nodemanager参考节点的设置,而那些从纱线开始。调度程序是针对单一容器(执行者)节点上运行。

图1显示了方法参数定义集群的内存分配。

图1:火花内存分配参数对纱线集群。

火花/ HiBench配置参数

在spark-defaults火花参数可以设置。conf文件引发的文件夹。HiBench,火花参数设置在conf /火花。conf HiBench文件夹中。配置参数如下:

• 数量的执行人
  • executor.instances / hibench.yarn.executor.num
• 遗嘱执行人的记忆
  • executor.memory
• 遗嘱执行人内存开销因素(默认值是0.10)
  • executor.memoryOverheadFactor
• 遗嘱执行人核心
  • executor.cores / hibench.yarn.executor.cores
• 并行性
  • default.parallelism
• 调整分区大小
  • sql.shuffle.partitions

类似的参数为执行人存在驱动程序(应用程序请求者)。

纱配置参数

在core-site.xml Yarn-specific参数定义:

• nodemanager.resource.memory-mb
  • 可用内存的纱线执行人(当前)工人节点
• scheduler.maximum-allocation-mb
  • 最大内存分配给执行器容器(包括内存开销)
• nodemanager.resource.cpu-vcores
  • 可用的CPU核数纱(当前)工人节点执行人
• scheduler.maximum-allocation-vcores
  • 最大数量分配给执行器的核心容器

火花配置调整

火花可以调整取决于正在运行的应用程序。由开发人员优化内存,垃圾收集,和序列化代码的基础上,数据结构等参数。看到调优的火花文档的更多细节。

火花资源监控

监控资源用于火花集群上运行计算非常重要,因为它有助于发现如果:

1. 足够的资源分配工作(或一些任务失败),或
2. 资源超过要求和一个更小的集群或实例可以做同样的工作几乎相同的处理时间。

分析是可能引发性能和指标使用Web UI。进行深入的分析,在一个或多个运行期间的所有数据可以收集和使用火花的历史服务器。

等方法来收集指标直接从机器内存/磁盘/ CPU运行时(特别是伪分布集群在单个机器上)包括使用工具如系统活动报告(SAR)。

火花机器学习库

火花的机器学习库MLlib。它实现了ML算法,数据转换,以分布式方式和管道。MLlib允许用户保存训练模型和负荷预测阶段。新图书馆(也称为火花ML)是基于火花Dataframe API和应用优化的数据管道。本文演示了k - means聚类基准作为引发的案例研究资源配置和调优分析。

火花k - means资源优化:k - means聚类的介绍

k - means是一种无监督聚类算法。鉴于K集群的数量,该算法首先分配K(半)会点(重心)。和迭代改进它们的值,直到没有进一步细化是可能的,或达到最大迭代次数。

火花的k - means实现迭代在分区独立运行,收集每个迭代的结果回到重心细化的司机。所有的迭代都在相同的输入数据集;所以,它将数据缓存到内存速度计算的每一个执行者。

集群配置

我们的基准m6gd上运行。16个超大EC2实例,这个实例中有64个vcpu和256 gb的内存。考虑5芯/执行人(调度器最大CPU分配),执行人的数量设置为12,60个vcpu消费。对于k - means,我们只给1个vCPU司机(默认)但是设置驱动程序内存一样的执行人。每个执行人设置为16 gb的内存(指标的分析表明,该值可以增加)。纱的调度器和节点管理器参数设置。例如,调度器的最大分配18022 mb的内存定义(1.1 * 16 gb),和节点管理器资源设置为218264 mb(12执行人+维护)。

k - means基准参数

HiBench k - means基准默认值是:

• 集群的数量:5
• 最大迭代次数:5(巨大的工作量)

我们运行的k - means算法对Hibench三个大小不同的工作负载:

1. 大:20 m记录,3.7 gb
2. 大:100米记录,18.5 gb
3. 巨大的:200米记录,37.1 gb

k - means算法是计算密集型的。下面是k - means算法运行的CPU使用量大,巨大,HiBench和庞大的数据大小:

图2:CPU使用量大,巨大的,巨大的工作量。

所有执行者的总CPU使用率是93%基于核的数量分配每个执行者(60/64)。因此,显然,巨大的工作负载使用大部分的处理能力。

图3显示了所有的三个工作负载的内存使用情况。

图3:内存使用量大,巨大的,巨大的工作量。

所有工作负载的内存使用低于设定的最大数量的配置。这两个图表(CPU和内存使用)表明,一个调优的可能性是使用compute-optimized实例运行计算。这些实例更便宜比通用(M)和memory-optimized (R)的实例相同的大小。

同样重要的是要注意,总的数据大小的巨大工作量仅为37.1 gb。即使考虑到在质心计算内存使用,使用近200 gb的内存为k - means看起来过度。的原因是内存缓存,HiBench k - means基准执行,它可以改变我们优化集群运行代码。

缓存

在前面部分,最佳实践建议分配5芯/执行器,计算的执行人使用和分配的内存数量每个执行者基于实例的可用内存。然而,如果火花程序使用内存缓存,所有缓存复制所有的执行人。所以,如果你运行E执行人在同一实例,您的缓存使用E倍内存相比,运行一个执行者。

下面的图对比巨大工作量内存使用情况:

1. 12个执行人,每执行人5核心,16 gb的内存
2. 6执行人,10核心,32 gb的内存/执行器

和所有的执行人运行在相同的实例(伪分布配置)。

图4:内存使用量比较巨大的工作量对于12和6执行人在同一台机器上运行。

第二个配置显然将消耗更少的内存由于小数量的缓存复制。所以,当缓存大量数据,减少执行人与大尺寸的数量可以帮助减少内存使用量。分析表明,除了初始阶段进行数据预处理,处理时间的k - means阶段不不同。

在k - means洗牌

k - means的实现只需要洗牌少量的数据(这是一项昂贵的操作在分布式计算)。分离不同阶段通过收集centroid-based计算在每个分区为最终司机质心计算,一个很小的数据大小。因此,分配工作负载的集群实例不会产生相当大的影响性能。

结论

调优火花计算是特定于应用程序的,取决于不同的参数,如数据存储、缓存和洗牌。在缓存和存储情况下,可以使用磁盘存储当内存可能成为一个瓶颈(这可能大大降低AWS上的性能因为SSD读/写吞吐量是扼杀了)。

等应用k - means CPU密集且不涉及洗牌,大部分的调优内存管理。使用较少的执行人更大的大小、缓存磁盘和内存可用性的基础上,并使用compute-optimized实例的选择要考虑性能和成本优化。

引用

[1]调优火花,https://spark.apache.org/docs/latest/tuning.html

[2]HiBench套房,https://github.com/Intel-bigdata/HiBench

[3]Hadoop:设置一个节点的集群,https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/SingleCluster.html

[4]解码记忆火花,https://medium.com/walmartglobaltech/decoding-memory-in-spark-parameters-that-are-often-confused-c11be7488a24