问题描述
我有四个问题。假设在 spark 中我有 3 个工作节点。每个工作节点有 3 个执行程序，每个执行程序有 3 个内核。每个执行程序有 5 GB 内存。 （总共 6 个执行程序，27 个内核和 15GB 内存）。如果出现以下情况会发生什么：
-
我有 30 个数据分区。每个分区的大小为 6 GB。最佳情况下，分区数必须等于内核数，因为每个内核执行一个分区/任务（每个分区一个任务）。现在在这种情况下，由于分区大小大于可用的执行程序内存，每个执行程序核心将如何处理分区？注意：我不是在调用 cache() 或 persist()，这只是我在我的 rdd 上应用了一些狭窄的转换，如 map() 和 filter()。
-
spark 会自动尝试将分区存储在磁盘上吗？ （我不是在调用 cache() 或 persist() 而是只是在调用操作后发生了转换）
-
由于我的分区 (30) 大于可用内核数 (27)，所以在最大情况下，我的集群可以处理 27 个分区，剩下的 3 个分区会怎样？他们会等待被占用的内核被释放吗？
-
如果我调用存储级别设置为 MEMORY_AND_disK 的persist()，那么如果分区大小大于内存，它会不会将数据溢出到磁盘？这些数据将存储在哪个磁盘上？工作节点的外置硬盘？
解决方法
我根据我对每个部分的了解来回答，可能会忽略您的一些断言：
我有四个问题。假设在 spark 中我有 3 个工作节点。每个工作节点有 3 个执行程序，每个执行程序有 3 个内核。每个执行程序有 5 GB 内存。 （总共 6 个执行程序，27 个内核和 15GB 内存）。如果出现以下情况会发生什么： >>> 我会使用 1 个 Executor，1 个核心。这就是公认的范式。
-
我有 30 个数据分区。每个分区的大小为 6 GB。最佳情况下，分区数必须等于内核数，因为每个内核执行一个分区/任务（每个分区一个任务）。现在在这种情况下，由于分区大小大于可用的执行程序内存，每个执行程序核心将如何处理分区？注意：我不是在调用 cache() 或 persist()，这只是我在我的 rdd 上应用了一些狭窄的转换，如 map() 和 filter()。 >>> 分区数与内核数相同是不正确的。您可以使用 10 个内核为 1000 个分区提供服务，一次处理一个。如果您有 100K 分区和内部部署怎么办？您不太可能获得 100K Executor。 >>> 继续并将驱动程序端收集问题放在一边：您可能没有足够的内存用于执行器上的给定操作； Spark 可能会以处理速度为代价将文件溢出到磁盘。但是，分区大小不能超过最大大小，前段时间被加强了。使用多核 Executors 可能会发生故障，即 OOM，也是 GC 问题的结果，这是一个棘手的话题。
-
spark 会自动尝试将分区存储在磁盘上吗？ （我不是在调用 cache() 或 persist() ，而只是在调用操作后发生了转换）>>> 不是如果它可以避免它，而是当内存紧张时，驱逐/溢出到磁盘可能并且将会发生，并且在某些情况下会发生从源或最后一个检查点的重新计算。
-
由于我的分区 (30) 大于可用内核数 (27)，所以在最大情况下，我的集群可以处理 27 个分区，剩下的 3 个分区会怎样？他们会等待被占用的内核被释放吗？ >>> 他们将在某个时间点由免费的 Executor 提供服务。
-
如果我调用存储级别设置为 MEMORY_AND_DISK 的persist()，那么如果分区大小大于内存，它会不会将数据溢出到磁盘？这些数据将存储在哪个磁盘上？工作节点的外部硬盘？ >>> 是的，它会溢出到本地文件系统。我认为您可以通过设置配置 HDFS，但本地磁盘速度更快。
这是一篇有见地的博客：https://medium.com/swlh/spark-oom-error-closeup-462c7a01709d