我已经阅读了之前的一些帖子，遗憾的是我认为我不能做我想做的事情，但也许有一个我不了解的最新解决方案。我想在某一点上使用Scala标准库提供的并行集合在地图中执行一些并行操作。但是，据我所知，我应该在Spark执行开始时设置spark.task.cpus，为每个任务分配足够数量的内核。我的配置由14个节点组成，每个节点有8个核心。
在地图中，我有两个点集合，应使用欧几里德距离进行比较，以检查至少有一对是否符合距离阈值。因此，我最终得到了类似的东西：
collection1.exists(point1 =>
collection2.exists(point2 => dist(point1, point2) <= threshold))
如果比较在开始时不是正数，则表示非常重的步骤。但是，如果集合是并行的，则可以更快地测试它们。最后请注意，由于前面步骤中会发生过多的复制，我无法分解集合或过多地减小它们的大小，在这种情况下，随机播放时间将成为瓶颈。
连连呢？ 如果我在问题描述中遗漏了某些内容，请告诉我，我将添加所需的所有有用信息。
由于
编辑：我添加一个例子来澄清我的情景。
实施例： 我从一个集合开始：
{(1, col_1), (2, col_2), (3, col_3)}
我想执行成对比较（增加第二个键），所以我最终得到一个新的集合：
{((1,2),(col_1, col_2)), ((1,3),(col_1,col_3)), ((2,3), (col_2, col_3))}
现在，使用之前的测试过滤新集合，即O（| col_i | * | col_j |）。为了避免在执行中产生瓶颈，我决定限制与每个测试相关的集合的大小。但是，这会导致最初创建与每个密钥关联的多个条目。例如：
{(1, col_1_a), (1, col_1_b), (1, col_1_c), (2, col_2_a), (2, col_2_b), (3, col_3_a), (3, col_3_b), (3, col_3_c), (3, col_3_d)}
以及比较集合中的条目数量增加：
{((1,2), (col_1_a, col_2_a)), ((1,2), (col_1_a, col_2_b)), ..., ((2,3), (col_2_b, col_3_d))}
每个集合的最大长度之间存在权衡，这限制了单个测试所需的时间，以及生成的测试总数，这增加了创建所有对所需的随机播放。为了在我看来最大化性能，使用并行集合并增加每个col_i的最大大小将是方便的，因为它将导致最大的核心使用，而不是受分配给每个执行器的任务数量的限制。这是对的吗？增加Spark集合中的分区数会导致相同的结果吗？我逐渐看到剩下的任务越来越少，每台机器都没有被充分利用。