Spark中数据规模超过driver内存容量时会发生什么？

首先要明确一个基础认知：Spark Driver 本身并不承载业务数据的存储和计算，仅负责作业调度、DAG 生成、任务分配、元数据维护等轻量化工作，所有实际的业务数据处理逻辑都分布在各个 Executor 节点执行，所以常规情况下哪怕数据源是 TB/PB 级，只要 Executor 集群总资源足够，Driver 内存仅需数GB就能正常支撑作业运行。

如果出现超内存的场景，Spark 的处理逻辑如下：

• Shuffle 阶段自动落盘：当 Shuffle 的中间结果超出 Executor 分配的内存缓冲阈值时，超出部分会自动写入 Executor 的本地磁盘，后续任务拉取数据时再从磁盘读取，整个过程无需用户干预，仅会产生少量 IO 开销，不会触发 OOM。你也可以通过调整 spark.shuffle.memoryFraction 这类参数自定义内存缓冲的占比。
• 缓存阶段自动降级：如果你调用了 cache()、persist() 等缓存接口，Spark 会优先把缓存分区放到内存中，当内存不足以容纳所有缓存分区时，会基于 LRU（最近最少使用）策略把冷分区刷到磁盘（仅当你选择的存储级别包含磁盘时，默认的 MEMORY_ONLY 级别会直接丢弃冷分区，后续需要时重新计算），读取时再按需加载回内存。
• 只有当你显式调用 collect()、take(N) 这类需要把 Executor 端的全量/部分数据拉回到 Driver 侧的算子时，才可能出现 Driver 内存不足的问题，这种情况要么避免全量拉取 Driver 的操作，要么调大 spark.driver.memory 参数，否则会直接抛出 OOM 异常。

答案是符合的，核心原因是大数据领域的「内存计算」从来不是指整个计算过程完全不能接触磁盘，而是指优先将热数据、中间计算结果存储在内存中处理，尽可能减少不必要的磁盘IO开销，和传统 MapReduce 每一轮计算都要把全量中间结果落盘的机制有本质区别。

• Spark 的全链路设计都是内存优先的思路，磁盘只是内存不足时的降级兜底方案，绝大多数热点场景下频繁访问的核心数据都会停留在内存中，整体 IO 开销远低于传统磁盘优先的计算框架。
• 哪怕部分冷数据落到了磁盘，也只有当计算需要用到这部分数据时才会触发磁盘读取，不会出现全量计算都走磁盘的情况，本质上还是遵循内存计算的核心逻辑。
• 你可以根据业务场景灵活选择缓存策略：性能优先的场景可以选 MEMORY_ONLY，内存不足时丢弃冷分区、后续需要时重算；重计算成本远高于磁盘IO的场景可以选 MEMORY_AND_DISK，把冷分区刷到磁盘，这些都是内存计算框架下的常规性能取舍，不会改变其内存计算的本质。

内容的提问来源于stack exchange，提问作者N_A