Spark collect 为什么容易撑爆 Driver？toLocalIterator 能解决吗？
面试怎么回答
collect 会把各分区结果集中到 Driver，本地对象膨胀后可能远大于传输大小。toLocalIterator 能降低一次接收峰值，但仍受最大分区影响，调用方也不能再转成完整列表。小结果先聚合再返回，大明细优先分布式写出；外部写入还要控制并发与重试幂等，不能只调大 Driver 结果上限。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
Executor 还有很多空闲内存，任务却在最后一步把 Driver 撑爆了。排查代码发现只多了一行 collect。集群算得下的数据，为什么取回结果时反而装不下？
collect 把分布式结果集中到 Driver，toLocalIterator 只能降低一次取回的峰值；大结果应优先分布式写出，并控制分区大小和外部系统并发。
Driver 需要接住所有返回结果
collect 会把结果从各分区传到 Driver，再构造本地集合。结果在网络上、JVM 中和 Python 进程中的形态可能不同，序列化大小远小于最终对象内存也并不少见。
所以增加 Executor 内存通常无法直接解决接收端容量问题。先确认 OOM 发生在哪个进程、调用栈是否处于结果返回阶段，再看返回行数、字段宽度与 Driver 峰值，避免把所有内存问题都当成 Shuffle 倾斜。
结果大小限制是保护线，不是容量扩展
spark.driver.maxResultSize 用于限制每个 action 收集到的序列化结果总大小。触发这条限制时，说明结果收集路径需要评估；把限制调大或者设成无限，并不会让 Driver 的实际内存跟着增长。
同时要看是否调用了 toPandas、把嵌套列转成本地对象，或者在返回后又复制了几份集合。十万行窄表与十万行大 JSON 的内存需求完全不同，只按行数设阈值容易失真。
迭代读取也需要容纳大分区
toLocalIterator 逐步返回数据，能够避免一次把全部结果建成列表。PySpark 文档指出，其内存需求可达到最大分区的规模；启用预取时可能需要容纳两个最大分区，具体参数行为还要看运行模式。
因此一个超大分区仍然危险。调用方如果再写 list(iterator)，或者把每行都追加到数组中，实际上又把结果全部留在本地。必须让消费过程真正流式，并监控最大分区与本地累计对象。
一个典型场景：换了 API 仍然 OOM
比如导出脚本从 collect 改成迭代器，前几分钟内存平稳，之后仍持续增长。最初怀疑迭代器没有释放资源，查看调用方才发现为了最后统一写 Excel，每条记录都被保存到列表。
原检查只验证函数名变了，没有检查结果生命周期。正确改法是分批写出并释放缓冲，或者直接让 Spark 输出文件再由下游消费。如果格式本身要求在内存构建整个对象，就需要改变导出方式或限制规模。
大结果优先留在分布式链路中
可以先在集群内聚合、筛选、选择必要字段，再返回真正很小的统计结果。明细则使用支持分布式写入的文件或表接口，按合理文件大小与分区组织产物。
使用 foreachPartition 向外部系统写入时，要控制连接数、批量大小和幂等键，因为 Task 重试可能重复执行。把压力从 Driver 搬到一个数据库并不自动解决问题，验收应同时覆盖 Driver 内存、分区规模、输出完整性和接收端负载。