当spark任务的数量大于executor核心时会发生什么？spark是如何处理这种情况的
sgtfey8w1#
我认为这个问题有点离题。你问的不太可能。为什么？有了大量的数据，你将有许多分区，你可以重新分区。假设您有10000个分区，相当于10000个任务。执行器（core）将有效地为分区提供一个任务（1:1Map），完成后继续执行下一个任务，直到阶段中的所有任务完成，然后下一个任务将开始（如果它在plan/dag中）。更可能的是，在大多数地方（对于你的应用程序），你不会拥有一个由10000个executor核心组成的集群，但有些网站确实有这样的核心。如果分配的内核比需要的多，那么它们将保持空闲状态，不可供其他人使用。但通过动态资源分配，可以放弃执行者。我已经与Yarn和Spark独立工作，这是如何与k8我不确定。转换改变了您在资源方面的需求。e、 一个命令可能会导致较少的分区，因此可能会导致空闲。
z0qdvdin2#
是的，这种情况可能发生。在这种情况下，一些内核将处于空闲状态。可能发生这种情况的场景：你打电话来 coalesce 或者 repartition 分区数<核心数使用默认的 spark.sql.shuffle.partitions （=200）并且您有超过200个内核可用。这将是连接、排序和聚合的问题。在这种情况下，您可能需要增加 spark.sql.shuffle.partitions 请注意，即使您有足够的任务，其中一些（或大部分）任务也可能是空的。如果您有一个大的数据倾斜，或者您做了类似的事情，就会发生这种情况 groupBy() 或者 Window 没有一个 partitionBy . 在这种情况下，空分区将立即完成，从而使大多数核心处于空闲状态
coalesce
repartition
spark.sql.shuffle.partitions
groupBy()
Window
partitionBy
nbewdwxp3#
这和这个问题有关吗？不管怎样，你可以查看这个cloudera操作指南。在“调优资源分配”部分中，解释了spark应用程序可以通过打开动态分配属性来请求执行器。设置集群属性也很重要，例如num executors、executor cores、executor memory。。。因此，spark请求适合您的资源管理器提供的内容。
3条答案
按热度按时间sgtfey8w1#
我认为这个问题有点离题。你问的不太可能。为什么？
有了大量的数据，你将有许多分区，你可以重新分区。
假设您有10000个分区，相当于10000个任务。
执行器（core）将有效地为分区提供一个任务（1:1Map），完成后继续执行下一个任务，直到阶段中的所有任务完成，然后下一个任务将开始（如果它在plan/dag中）。
更可能的是，在大多数地方（对于你的应用程序），你不会拥有一个由10000个executor核心组成的集群，但有些网站确实有这样的核心。
如果分配的内核比需要的多，那么它们将保持空闲状态，不可供其他人使用。但通过动态资源分配，可以放弃执行者。我已经与Yarn和Spark独立工作，这是如何与k8我不确定。
转换改变了您在资源方面的需求。e、 一个命令可能会导致较少的分区，因此可能会导致空闲。
z0qdvdin2#
是的，这种情况可能发生。在这种情况下，一些内核将处于空闲状态。可能发生这种情况的场景：
你打电话来
coalesce或者repartition分区数<核心数使用默认的
spark.sql.shuffle.partitions（=200）并且您有超过200个内核可用。这将是连接、排序和聚合的问题。在这种情况下，您可能需要增加spark.sql.shuffle.partitions请注意，即使您有足够的任务，其中一些（或大部分）任务也可能是空的。如果您有一个大的数据倾斜，或者您做了类似的事情，就会发生这种情况groupBy()或者Window没有一个partitionBy. 在这种情况下，空分区将立即完成，从而使大多数核心处于空闲状态nbewdwxp3#
这和这个问题有关吗？
不管怎样，你可以查看这个cloudera操作指南。在“调优资源分配”部分中，解释了spark应用程序可以通过打开动态分配属性来请求执行器。设置集群属性也很重要，例如num executors、executor cores、executor memory。。。因此，spark请求适合您的资源管理器提供的内容。