首页 文章

Apache Spark：核心数与执行者数量

提问于
浏览 次
152

我试图了解在YARN上运行Spark作业时内核数量和执行程序数量之间的关系 .

测试环境如下：

  • 数据节点数：3

  • 数据节点机器规格：

  • CPU：Core i7-4790（核心数：4，线程数：8）

  • 内存：32GB（8GB x 4）

  • 硬盘：8TB（2TB x 4）

  • 网络：1Gb

  • Spark版本：1.0.0

  • Hadoop版本：2.4.0（Hortonworks HDP 2.1）

  • Spark作业流程：sc.textFile - > filter - > map - > filter - > mapToPair - > reduceByKey - > map - > saveAsTextFile

  • 输入数据

  • 类型：单个文本文件

  • 尺寸：165GB

  • 行数：454,568,833

  • 输出

  • 第二次过滤后的行数：310,640,717

  • 结果文件的行数：99,848,268

  • 结果文件的大小：41GB

该作业使用以下配置运行：

  • --master yarn-client --executor-memory 19G --executor-cores 7 --num-executors 3 （每个数据节点的执行程序，使用尽可能多的核心）

  • --master yarn-client --executor-memory 19G --executor-cores 4 --num-executors 3 （核心数量减少）

  • --master yarn-client --executor-memory 4G --executor-cores 2 --num-executors 12 （少核心，更多执行者）

经过的时间：

  • 50分15秒

  • 55分48秒

  • 31分23秒

令我惊讶的是，（3）更快 .
我认为（1）会更快，因为在改组时会有更少的执行者间通信 .
虽然（1）的核心数小于（3），但核心数不是关键因素，因为2）确实表现良好 .

（在pwilmot回答之后添加了以下内容 . ）

有关信息，性能监视器屏幕截图如下：

  • Ganglia数据节点摘要（1） - 作业于04:37开始 .

Ganglia data node summary for (1)

  • Ganglia数据节点摘要（3） - 工作于19:47开始 . 请在此之前忽略图表 .

Ganglia data node summary for (3)

该图大致分为两部分：

  • 第一：从开始到reduceByKey：CPU密集型，没有网络活动

  • 第二：在reduceByKey：CPU降低后，网络I / O完成 .

如图所示，（1）可以使用尽可能多的CPU功率 . 所以，它可能不是线程数量的问题 .

如何解释这个结果？

hadoop apache-spark yarn

7 回答

  • 0

    我认为其中一个主要原因是地方性 . 您的输入文件大小为165G，文件的相关块肯定分布在多个DataNode上，更多的执行程序可以避免网络拷贝 .

    尝试设置executor num equal blocks count，我认为可以更快 .

    回复于
  • 1

    来自RStudio's Sparklyr package page的 excellent 资源：

    SPARK定义：为Spark命名法提供一些简单的定义可能很有用：节点：服务器工作节点：作为集群一部分并可用于运行Spark作业的服务器主节点：协调工作节点的服务器 . 执行程序：节点内的一种虚拟机 . 一个节点可以有多个执行程序 . 驱动程序节点：启动Spark会话的节点 . 通常，这将是sparklyr所在的服务器 . 驱动程序（执行程序）：驱动程序节点也将显示在执行程序列表中 .

    回复于
  • 11

    为了使所有这些更加具体，这里有一个配置Spark应用程序以尽可能多地使用集群的工作示例：想象一个集群有六个节点运行NodeManagers，每个节点配备16个内核和64GB内存 . NodeManager容量，yarn.nodemanager.resource.memory-mb和yarn.nodemanager.resource.cpu-vcores应该分别设置为63 * 1024 = 64512（兆字节）和15 . 我们避免将100％的资源分配给YARN容器，因为该节点需要一些资源来运行OS和Hadoop守护进程 . 在这种情况下，我们为这些系统进程留下了一个千兆字节和一个核心 . Cloudera Manager通过计算这些并自动配置这些YARN属性来帮助您 . 可能的第一个冲动是使用--num-executors 6 --executor-cores 15 --executor-memory 63G . 但是，这是错误的方法，因为：63GB执行程序内存开销不适合NodeManagers的63GB容量 . 应用程序主机将在其中一个节点上占用一个核心，这意味着该节点上没有15核心 Actuator 的空间 . 每个执行程序15个核心可能导致错误的HDFS I / O吞吐量 . 更好的选择是使用--num-executors 17 --executor-cores 5 --executor-memory 19G . 为什么？这个配置在所有节点上产生三个 Actuator ，除了带有AM的节点，它将有两个 Actuator . --executor-memory派生为（每个节点63/3执行程序）= 21. 21 * 0.07 = 1.47 . 21 - 1.47~19 .

    cloudera博客中的一篇文章给出了解释http://blog.cloudera.com/blog/2015/03/how-to-tune-your-apache-spark-jobs-part-2/

    回复于
  • 0

    当你在HDFS上运行你的火花应用程序时，根据Sandy Ryza

    我注意到HDFS客户端遇到大量并发线程的问题 . 粗略的猜测是，每个执行程序最多可以实现5个任务的完全写入吞吐量，因此最好将每个执行程序的核心数保持在该数量之下 .

    所以我认为你的第一个配置比第三个慢，因为HDFS I / O吞吐量不好

    回复于
  • 12

    我没有我自己玩这些设置所以这只是推测，但如果我们将此问题视为分布式系统中的普通内核和线程，那么在您的群集中，您最多可以使用12个内核（4 * 3台机器）和24个线程（8 * 3）机） . 在前两个示例中，您将为您的工作提供相当数量的核心（可能的计算空间），但在这些核心上运行的线程（作业）数量非常有限，以至于您无法使用分配的大部分处理能力因此即使分配了更多的计算资源，作业也会变慢 .

    你提到你的问题是在洗牌步骤中 - 尽管限制洗牌步骤的开销是很好的，但通常使用集群的并行化更为重要 . 考虑一下极端情况 - 单线程程序，零洗牌 .

    回复于
  • 45

    我认为前两种配置存在一个小问题 . 线程和核心的概念如下 . 线程的概念是如果核心是理想的，那么使用该核心来处理数据 . 因此在前两种情况下没有充分利用内存 . 如果要对此示例进行基准测试，请选择每台机器上具有超过 10 cores 的机器 . 然后做基准测试 .

    但是，如果每个执行程序不超过5个核心，那么i / o性能将会出现瓶颈 .

    因此，执行此基准测试的最佳机器可能是具有10个核心的数据节点 .

    数据节点机器规格：CPU：Core i7-4790（核心数：10，线程数：20）RAM：32GB（8GB x 4）HDD：8TB（2TB x 4）

    回复于
  • 0

    Spark动态分配提供了灵活性并动态分配资源 . 在这个数量的最小和最大执行者可以给出 . 此外，还可以给出在应用程序启动时必须启动的执行程序的数量 .

    请阅读以下相同内容：

    http://spark.apache.org/docs/latest/configuration.html#dynamic-allocation

    回复于

相关问题