Dask单调度器执行df.to_parquet()触发OOM，切换分布式调度器后恢复正常的原因探究

我来拆解下两种调度器的核心差异，以及你遇到这个问题的原因：

单调度器的执行痛点 #

默认情况下，Dask的单调度器（比如同步或线程调度器）任务执行逻辑偏粗放：

• 处理to_parquet操作时，它不会严格做到“处理完一个分区就写入磁盘并释放内存”，反而会倾向于将多个分区的数据加载到内存中等待批量处理。
• 哪怕你调整了分区大小，单调度器的内存管理机制也不够精细，无法及时清理已处理完成的分区内存，导致数据持续堆积，直到你的8GB内存被耗尽触发OOM。
• 简单来说，单调度器更像“攒够一批再干活”，而非“做一件清一件”，这直接导致内存占用一路飙升。

分布式调度器的优势 #

当你添加c = Client()启动本地分布式集群后，执行逻辑完全变了：

• 分布式调度器会把每个CSV分区的读取、转换、写入拆成独立小任务，按顺序调度执行。处理完一个分区的Parquet写入后，会立刻释放该分区占用的内存，再去处理下一个。
• 它自带内存监控和任务队列管理，能精准控制内存使用，避免多个大分区同时占用内存。哪怕是本地运行的分布式集群，这种“任务级细粒度调度”也比单调度器的批量处理模式高效得多。
• 这种设计本来就是为大规模数据集而生的，刚好匹配你后续处理350GB数据的需求。

额外小提示 #

如果非要尝试单调度器，可以显式设置更小的blocksize（比如blocksize='128MB'）强制缩小分区，但根据你的描述这种方法效果可能有限。对于大规模数据场景，分布式调度器（不管是本地还是AWS集群）都是更可靠的选择。

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