Spark：每个执行器的内核对应用程序运行时没有影响
我正在测试每个执行器的不同内核数（executor cores）对Spark上SVD的运行时的影响。随着执行器内核的固定，主数据RDD的分区数量也会发生变化。然而，对于给定数量的RDD分区，不同的执行器内核的SVD计算时间似乎没有显著变化。这有点令人困惑。
我的环境是：
我已经绘制了executor cores=[4，16]的结果，可以看到，对于给定的分区大小，当分区大小增加时，计算时间之间没有太大差异。所以我的问题是：
- 设置每个执行器的核心数有什么影响
共有1个答案
一般来说，每个执行器的内核的最佳平衡因工作负载而异；虽然每个执行器多个核通常会减少每个执行器的开销，但还有一些其他考虑因素会与每个执行器的核数成反比，主要围绕进程全局共享资源和争用瓶颈：
- 垃圾收集；现在，同一进程空间中的任务在内存分配/垃圾收集期间相互影响更大，成为共享争用瓶颈
另一方面，为每个执行器添加更多内核的好处包括：
- 减少每个执行器的内存开销；如果每个任务需要一定数量的内存，理论上，与许多小执行器相比，使用一个非常大的执行器可以将更多并发任务打包到一台机器上
- 共享内存空间对于广播变量/数据之类的东西来说是一大好处
Cloudera的这篇博客文章解释了许多这样的权衡和具体数字，特别是关于过大执行人的缺点。
在分区数较少的情况下，理论上分区数少于执行器数，只要任务在每种情况下均匀地分布到不同的执行器中，性能就应该优于或等于较大的执行器。然而，如果任务的打包将它们全部放在一个执行者身上，那么这只取决于工作量；shuffle-heavy-stuff可以受益于这样一个事实，即所有的进程都是本地的，但HDFS I/O-heavy-stuff将遭受争用。
-
请先用以下条款验证我： 执行器：它的将运行在上。每个节点可以有多个执行器。 核心：它是内的一个线程，运行在上。每个执行器可以有多个内核或线程。 > 当我们提交火花作业时，它意味着什么？我们是否将工作移交给Yarn或resource manager，它将分配资源给集群中的并执行它？它是正确的理解…？ 在spark集群中用于提交作业的命令中，有一个设置执行者数量的选项。 那么这些执行器+核的数量将会是
-
我正在对YARN上的Spark作业进行一些内存调优，我注意到不同的设置会给出不同的结果，并影响Spark作业运行的结果。但是，我很困惑，不明白为什么会这样，如果有人能给我一些指导和解释，我会很感激。 我将提供一些背景资料和张贴我的问题和描述案例，我已经经历了他们在下面。 我的环境设置如下： 存储器20G，每个节点20个vCore（共3个节点） Hadoop 2.6.0 火花1.4.0 我的代码对R
-
我试图在IntelliJ中运行cucumber特征文件。 Cucumber Options指向正确的文件夹，但在尝试执行JUnit运行程序类时，我会收到“无可用任务”通知。 我做错了什么？ 这是我的：
-
我正在通过阅读高性能Spark来学习如何配置Spark应用程序，其中提到的一句话让我感到困惑： 根据我的经验，设置Spark驱动程序内存的良好启发式方法只是不会导致驱动程序内存错误的最低可能值，即为执行程序提供最大可能的资源。 我的理解是驱动程序存在于它自己的节点中，而执行程序独立存在于工作节点上。我本以为我可以最大限度地利用驱动程序内存，而不必担心它会影响执行程序。 这本书的建议是真的吗？如果是
-
我使用log4j2，但我的一些依赖项使用log4j。当我从一个可执行jar文件运行应用程序时，我只得到几行日志和以下消息： 但当我在IntelliJ内部运行应用程序时，它会按预期工作，不会产生任何警告和所有日志。 我用maven enforcer来禁止log4j。我还尝试添加依赖项，但将范围设置为“提供”。 我也用一个版本号而不是一个范围来完成上面的工作。当应用程序在IntelliJ中运行时，所有
-
我是Spark的新手。我有一个应用程序，通过调用spark shell来运行每个spark sql查询。因此，它将生成一组如下所示的查询，并调用spark shell命令逐个处理这些查询。 Val Query=spark.sql（""SELECT userid as userid，评级为评级，电影为电影从default.movie表""）； 现在我想用spark submit而不是spark sh