Spark分区大小大于executor内存

Question

我有四个问题。假设在spark中有3个worker节点。每个工人节点有3个执行器，每个执行器有3个核心。每个执行器有5 gb内存。（总共6个执行器，27个内核，15GB内存）。如果：

>

我有30个数据分区。每个分区的大小为6 GB。最佳情况下，分区的数量必须等于核心的数量，因为每个核心执行一个分区/任务（每个分区执行一个任务）。在这种情况下，由于分区大小大于可用的执行器内存，每个执行器核心将如何处理分区？注意：我没有调用cache（）或persist()，只是在RDD上应用了一些狭义的转换，如map（）和filter（）。

如果我调用存储级别设置为MEMORY_AND_DISK的persist()，那么如果分区大小大于memory，它会将数据溢出到磁盘？该数据将存储在哪个磁盘上？工作节点的外部HDD？

Answer 1

我回答，因为我知道每个部分的事情，可能忽略了你的一些断言：

我有四个问题。假设在spark中有3个worker节点。每个工人节点有3个执行器，每个执行器有3个核心。每个执行器有5 gb内存。（总共6个执行器，27个内核，15GB内存）。如果:>>>我将使用一个执行器，一个核心，会发生什么。这是公认的Afaik范式。

>

我有30个数据分区。每个分区的大小为6 GB。最佳情况下，分区的数量必须等于核心的数量，因为每个核心执行一个分区/任务（每个分区执行一个任务）。在这种情况下，由于分区大小大于可用的执行器内存，每个执行器核心将如何处理分区？注意：我没有调用cache（）或persist()，只是在RDD上应用了一些狭义的转换，如map（）和filter（）。>>>分区数与核心数相同不正确。您可以使用10个内核服务1000个分区，一次处理一个。如果你有100k分区和on-prem呢？你不太可能得到10万个执行者。>>>继续前进，将驱动程序端的收集问题放在一边：您可能没有足够的内存用于执行器上的给定操作；Spark可能会以牺牲处理速度为代价泄漏到文件到磁盘。但是，分区的大小不应该超过一个最大大小，这是一段时间前加强的。使用多核执行器可能会发生故障，即OOM的，也是GC问题的结果，这是一个困难的话题。

这是一个很有见地的博客:https://medium.com/swlh/spark-oom-error-closeup-462C7A01709D