Spark 分区大小大于执行程序内存
Spark partition size greater than the executor memory
我有四个问题。假设在 spark 中我有 3 个工作节点。每个工作节点有 3 个执行器，每个执行器有 3 个核心。每个执行器有 5 GB 内存。 （总共 6 个执行器，27 个内核和 15GB 内存）。如果发生什么情况：
我有 30 个数据分区。每个分区的大小为 6 GB。最佳情况下，分区数必须等于核心数，因为每个核心执行一个 partition/task（每个分区一个任务）。现在在这种情况下，由于分区大小大于可用的执行程序内存，每个执行程序核心将如何处理分区？注意：我没有调用 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 个执行器，1 个核心。这是公认的范式 afaik。
我有 30 个数据分区。每个分区的大小为 6 GB。最佳情况下，分区数必须等于内核数，因为每个内核执行一个 partition/task（每个分区一个任务）。现在在这种情况下，由于分区大小大于可用的执行程序内存，每个执行程序核心将如何处理分区？注意：我没有调用 cache() 或 persist()，只是在我的 rdd 上应用了一些狭窄的转换，如 map() 和 filter()。 >>> 分区数与核心数相同是不正确的。您可以使用 10 个内核为 1000 个分区提供服务，一次处理一个。如果您有 100K 分区和本地部署怎么办？您不太可能获得 100K 个执行器。 >>> 继续并将驱动程序端收集问题留给一边：您可能没有足够的内存来执行 Executor 上的给定操作； Spark 可以以牺牲处理速度为代价将文件溢出到磁盘。但是，分区大小不应超过最大大小，前段时间已得到加强。使用多核执行器可能会发生故障，即 OOM，也是 GC 问题的结果，这是一个困难的话题。
spark 会自动尝试将分区存储到磁盘上吗？ （我不是在调用 cache() 或 persist() ，而只是在调用操作后发生转换）>>> 如果可以避免，则不会，但是当内存紧张时，驱逐/溢出到磁盘可能并且将会发生，并且在某些情况下会从源或最后一个检查点重新计算。
因为我的分区数 (30) 大于可用内核数 (27)，所以我的集群最多可以处理 27 个分区，剩下的 3 个分区会怎样？他们会等待被占用的核心被释放吗？ >>> 他们将在某个时间点由免费执行者提供服务。
如果我调用存储级别设置为MEMORY_AND_DISK的persist()，那么如果分区大小大于内存，它会把数据溢出到磁盘吗？这些数据将存储在哪个磁盘上？工作节点的外部硬盘？ >>> 是的，它会溢出到本地文件系统。我认为您可以通过设置为 HDFS 配置，但本地磁盘更快。
这是一个有见地的博客：https://medium.com/swlh/spark-oom-error-closeup-462c7a01709d
您的数据分区大小看起来比核心内存大。您的核心内存约为 1.6 GB（5GB/3 核心）。这将是一个问题，因为您的分区将无法在 Core 中处理。要解决此问题，您可以尝试：
- 增加分区数量，使每个分区 < 核心内存 ~1.6 GB。所以将它们增加到大约 150 个分区。
- 如果你保持分区不变，你应该尝试增加你的执行器内存，也可能减少你的执行器中的内核数量。
如果一切顺利，它将不需要在磁盘上存储分区。但是，如果找不到足够的内存，它会寻找磁盘作为备份。如果你想将你的数据存储在磁盘上并出于某种原因持久化它，你需要调用 persist(DISK_ONLY).
他们会等到其中一个核心可用。
是的，它会溢出到磁盘上。我相信在哪里取决于您的集群配置。
我有四个问题。假设在 spark 中我有 3 个工作节点。每个工作节点有 3 个执行器，每个执行器有 3 个核心。每个执行器有 5 GB 内存。 （总共 6 个执行器，27 个内核和 15GB 内存）。如果发生什么情况：
我有 30 个数据分区。每个分区的大小为 6 GB。最佳情况下，分区数必须等于核心数，因为每个核心执行一个 partition/task（每个分区一个任务）。现在在这种情况下，由于分区大小大于可用的执行程序内存，每个执行程序核心将如何处理分区？注意：我没有调用 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 个执行器，1 个核心。这是公认的范式 afaik。
我有 30 个数据分区。每个分区的大小为 6 GB。最佳情况下，分区数必须等于内核数，因为每个内核执行一个 partition/task（每个分区一个任务）。现在在这种情况下，由于分区大小大于可用的执行程序内存，每个执行程序核心将如何处理分区？注意：我没有调用 cache() 或 persist()，只是在我的 rdd 上应用了一些狭窄的转换，如 map() 和 filter()。 >>> 分区数与核心数相同是不正确的。您可以使用 10 个内核为 1000 个分区提供服务，一次处理一个。如果您有 100K 分区和本地部署怎么办？您不太可能获得 100K 个执行器。 >>> 继续并将驱动程序端收集问题留给一边：您可能没有足够的内存来执行 Executor 上的给定操作； Spark 可以以牺牲处理速度为代价将文件溢出到磁盘。但是，分区大小不应超过最大大小，前段时间已得到加强。使用多核执行器可能会发生故障，即 OOM，也是 GC 问题的结果，这是一个困难的话题。
spark 会自动尝试将分区存储到磁盘上吗？ （我不是在调用 cache() 或 persist() ，而只是在调用操作后发生转换）>>> 如果可以避免，则不会，但是当内存紧张时，驱逐/溢出到磁盘可能并且将会发生，并且在某些情况下会从源或最后一个检查点重新计算。
因为我的分区数 (30) 大于可用内核数 (27)，所以我的集群最多可以处理 27 个分区，剩下的 3 个分区会怎样？他们会等待被占用的核心被释放吗？ >>> 他们将在某个时间点由免费执行者提供服务。
如果我调用存储级别设置为MEMORY_AND_DISK的persist()，那么如果分区大小大于内存，它会把数据溢出到磁盘吗？这些数据将存储在哪个磁盘上？工作节点的外部硬盘？ >>> 是的，它会溢出到本地文件系统。我认为您可以通过设置为 HDFS 配置，但本地磁盘更快。
这是一个有见地的博客：https://medium.com/swlh/spark-oom-error-closeup-462c7a01709d
您的数据分区大小看起来比核心内存大。您的核心内存约为 1.6 GB（5GB/3 核心）。这将是一个问题，因为您的分区将无法在 Core 中处理。要解决此问题，您可以尝试：
- 增加分区数量，使每个分区 < 核心内存 ~1.6 GB。所以将它们增加到大约 150 个分区。
- 如果你保持分区不变，你应该尝试增加你的执行器内存，也可能减少你的执行器中的内核数量。
如果一切顺利，它将不需要在磁盘上存储分区。但是，如果找不到足够的内存，它会寻找磁盘作为备份。如果你想将你的数据存储在磁盘上并出于某种原因持久化它，你需要调用 persist(DISK_ONLY).
他们会等到其中一个核心可用。
是的，它会溢出到磁盘上。我相信在哪里取决于您的集群配置。