我们知道spark中的并行性是由内存分区、核心/插槽/线程和最终任务决定的。那么在设计spark submit时，是否需要为一个spark-submit/spark应用程序的每个工作节点设置多个executor？我认为执行器主要是在工作节点之间建立并行性，而不是在同一个工作节点上。就像每个工作节点上的并行进程的容器，并实现分布式通过在worker-nodes/spark集群中拥有多个这样的容器来实现并行性。
dgtucam11#
每个节点有一个执行器有很多好处-配置相对简单，Spark不需要在每个节点上分发广播变量超过一次，处理线程共享同一个JVM堆，该堆由节点上所有可用线程进行垃圾收集。后者，有一个JVM堆，根据情况可能是优点或缺点：一个大的JVM堆可能比多个小的JVM堆执行得更好或更差。2请参阅下面的参考资料了解更多信息。
5jdjgkvh2#
Executor是一个单独的JVM进程，由相关的资源分配器或协议在工作节点上为Spark App启动。每个Spark App都通过资源分配器获取自己的setExecutor。除非动态资源分配应用，否则Executor在Spark App的持续时间内保持运行。
Spark文档中没有任何地方说明一个给定的Worker Node不能**为同一个Spark App拥有多个Executor。在一个繁忙的忙碌中，如果你想让Spark App开始执行，只要有足够的资源可用，你很可能会遇到这种情况。
也就是说，AZURE Cloud上的Data Bricks，我想是AWS上的Data Bricks-每个工作节点/计算节点都有一个Executor。正如我们所说的，Fat Executors在普通的Spark中被认为是一个问题，但Databricks自己进行工程设计，所以现在不会出现问题。使用Spark Standalone，您将获得每个Worker 1个Executor，除非您使用spark.executor.cores并且Worker有足够的核心来容纳超过1个Executor。https://medium.com/expedia-group-tech/part-3-efficient-executor-configuration-for-apache-spark-b4602929262是一个很好的源代码。云和数据砖稍微改变了一些事情。所以，是的，有，但你不能显式地控制它。
spark.executor.cores
2条答案
按热度按时间dgtucam11#
每个节点有一个执行器有很多好处-配置相对简单，Spark不需要在每个节点上分发广播变量超过一次，处理线程共享同一个JVM堆，该堆由节点上所有可用线程进行垃圾收集。后者，有一个JVM堆，根据情况可能是优点或缺点：一个大的JVM堆可能比多个小的JVM堆执行得更好或更差。2请参阅下面的参考资料了解更多信息。
5jdjgkvh2#
Executor是一个单独的JVM进程，由相关的资源分配器或协议在工作节点上为Spark App启动。每个Spark App都通过资源分配器获取自己的setExecutor。除非动态资源分配应用，否则Executor在Spark App的持续时间内保持运行。
Spark文档中没有任何地方说明一个给定的Worker Node不能**为同一个Spark App拥有多个Executor。在一个繁忙的忙碌中，如果你想让Spark App开始执行，只要有足够的资源可用，你很可能会遇到这种情况。
也就是说，AZURE Cloud上的Data Bricks，我想是AWS上的Data Bricks-每个工作节点/计算节点都有一个Executor。正如我们所说的，Fat Executors在普通的Spark中被认为是一个问题，但Databricks自己进行工程设计，所以现在不会出现问题。
使用Spark Standalone，您将获得每个Worker 1个Executor，除非您使用
spark.executor.cores并且Worker有足够的核心来容纳超过1个Executor。https://medium.com/expedia-group-tech/part-3-efficient-executor-configuration-for-apache-spark-b4602929262是一个很好的源代码。云和数据砖稍微改变了一些事情。
所以，是的，有，但你不能显式地控制它。