因为Dask DataFrame采用延迟计算与分块视图机制，dd.read_csv()仅构建任务图、不加载数据；真正读取和处理发生在.compute()等触发操作时，内存中只驻留活跃分区与元数据。
为什么 dask.dataframe.read_csv 不会一次性加载整个文件到内存
因为 Dask DataFrame 本质是延迟计算的分块视图，它只在调用 .compute() 或触发实际输出时才真正读取和处理数据。读取阶段只是构建任务图，把大文件按行数或字节数切分成多个 pd.DataFrame 分区（partitions），每个分区可独立加载、过滤、聚合。
常见错误是直接对未切分的大文件调用 pandas.read_csv，结果 OOM；而用 dask.dataframe.read_csv 时若没设 blocksize 或 npartitions，Dask 可能默认分区过粗（比如只分 1–2 块），仍导致单个分区超内存。
- 务必显式指定
blocksize="64MB"（推荐值，可根据机器内存调整） - 避免使用
skiprows或usecols以外的 pandas 特有参数，Dask 不支持converters、parse_dates等部分解析逻辑 - 若文件无表头，必须传
header=None并手动设columns=...，否则 Dask 会尝试读第一块推断列名，可能出错
如何安全地做筛选和聚合而不爆内存
Dask 的惰性执行特性在这里是关键：写 df[df.x > 100].y.mean() 不会立刻执行，而是生成一个紧凑的任务图；只有调用 .compute() 才触发分布式调度。但要注意某些操作会隐式触发计算，比如打印 df.head()（只取前 5 行，安全），但 len(df) 会触发全量扫描计数（慢且占资源）。
- 用
df.map_partitions(lambda part: part[part.x > 100])替代全局布尔索引，更可控 - 聚合优先走
df.groupby('key').agg({'val': 'sum'})，它会自动做 shuffle + 分区合并；避免先df.groupby(...).apply(...)，容易把中间结果撑大 - 如需去重，用
df.drop_duplicates(subset=['id'], split_out=4)，split_out控制输出分区数，防止单个分区过大
Client 和 LocalCluster 怎么配才不白开
本地运行时，默认 Client() 会启一个单线程调度器，等于没并行；必须显式创建 LocalCluster 并传给 Client，才能利用多核。但开太多 worker 进程反而因内存副本增多而更慢。
立即学习“Python免费学习笔记（深入）”；
- 推荐启动方式：
from dask.distributed import Client, LocalCluster<br>cluster = LocalCluster(n_workers=4, threads_per_worker=2, memory_limit='4GB')<br>client = Client(cluster)
-
memory_limit必须设，否则 worker 默认不限制内存，OOM 风险极高 - 如果文件是列存格式（如 Parquet），优先用
dask.delayed+dd.read_parquet，它支持按列裁剪和谓词下推，比 CSV 快 3–10 倍且更省内存
报错 MemoryError 或 KilledWorker 时先查什么
这两类错误表面是内存问题，但根因常不在数据读取，而在中间结果未及时释放或 shuffle 数据倾斜。Dask Dashboard（client.dashboard_link）里的 “Workers” 和 “Tasks” 页面能快速定位瓶颈。
- 看 “Memory” 柱状图是否持续逼近上限——说明
memory_limit设太小，或某 task 返回了超大对象（比如返回整个numpy.array而非标量） - “Task Stream” 中若大量红色长条卡在 “shuffle” 阶段，大概率是
groupby或join导致 key 分布不均，加shuffle='tasks'或预处理打散 key - 临时缓解可用
df = df.persist()把已计算分区缓存在内存/磁盘，避免重复读，但要配合client.cancel()清理不用的 future
最易被忽略的是文件编码和分隔符异常：CSV 中混入未转义的换行符或逗号，会让 Dask 在某一分区解析失败，错误堆栈却显示内存溢出。先用 head -n 1000 bigfile.csv | file -i 和 csvstat 快速验数据洁度。
