Dask 并行与分布式计算

要解决什么问题

单机用 pandas 或 NumPy 时，数据一旦超过可用 RAM，就会 OOM；多核 CPU 也常常因为 GIL 或单线程逻辑吃不满。更麻烦的是，很多真实 workload 来自多文件 CSV/Parquet/JSON/日志，以及带依赖关系的自定义并行流程，而不是「读进内存再算」这一刀切模式。

Dask 的定位是：在保持 Python 生态习惯的前提下，把计算推到分块 + 任务图 + 调度器上执行，从笔记本级（约 100 GiB）扩到集群级（约 100 TiB）。

技能如何组织核心能力

这份技能把 Dask 拆成五个组件，并给出选型与参考文档路径：

• DataFrames：并行 pandas；适合超内存表格、多文件 glob 读取、惰性 .compute() 与 map_partitions 自定义分区逻辑。
• Arrays：分块 NumPy；适合 HDF5/Zarr/NetCDF 等科学数组，块大小通常瞄准约 100 MB。
• Bags：函数式处理文本/JSON/日志，常作为 ETL 前置，再转成 DataFrame。
• Futures：基于任务的即时并行，适合动态依赖、参数扫描、有状态 actors。
• Schedulers：线程（默认、数值友好）、进程（纯 Python/GIL 受限）、同步（调试）、分布式（多机与 Dashboard）。

常见路径是：先用同步调度器在小样本上验证图，再线程/分布式扩展；ETL 可走 Bag → DataFrame，数值可走 Array，自定义编排走 Futures。

适用边界与注意点

• 不要先把整表 read_csv 进内存再交给 Dask；应让 Dask 从磁盘/多文件 lazy 读取。
• 避免重复 .compute()，并控制任务图规模（块过小会产生百万级任务与调度开销）。
• 文件格式上优先 Parquet/HDF5/Zarr；CSV 更适合初次导入。
• 并行效果差时，检查块是否过大、是否该用进程调度器，以及数据依赖是否串行化了流水线。

更细的 DataFrame/Array/Bag/Futures/调度器与 best-practices 模式，技能内 references/*.md 可按组件按需展开。