Dask读CSV卡死或爆内存因默认字节切分导致跨行解析错误；map_partitions需避免闭包携带大对象；persist()用于复用中间结果，compute()用于调试；LocalCluster需据计算类型选线程/进程模式。
为什么直接用 dask.dataframe 读 CSV 可能卡死或爆内存？
不是数据太大，而是默认分区策略太粗糙。Dask 会按字节粗略切分文件，若某一分区恰好落在长文本字段中间（比如 JSON 字段跨行），read_csv 就会解析失败或反复重试；更常见的是，它把一行完整记录硬拆成两半，导致后续 compute() 时抛出 ParserError: Expected x fields in line y。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 务必显式指定
blocksize（如"64MB"），避免默认按 128MB 切分导致单分区过大 - 加上
sample=100000让 Dask 多采样几行推断 schema，尤其当 CSV 含空值或混合类型列时 - 如果文件有固定头部但无标准 header 行，用
header=None+names=[...]显式定义列名，否则 Dask 可能误把数据当 header
如何让 map_partitions 真正并行且不拖慢整体？
map_partitions 看似简单，但常因“闭包携带”翻车：函数内部引用了本地大对象（如 sklearn 模型、全局 lookup dict），Dask 会尝试序列化整个对象传给每个 worker，引发网络阻塞甚至 OOM。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 把大对象拆成只读参数，通过
args=或kwargs=显式传入，而非闭包捕获 - 避免在
map_partitions内部做 I/O（如打开文件、查数据库），改用dask.delayed+client.submit控制粒度 - 若逻辑含状态（如累计计数），优先用
reduction或aggregate，而非在每个分区里维护临时变量
persist() 和 compute() 在什么场景下必须二选一？
两者根本区别不在“是否计算”，而在于“结果存哪”。compute() 返回 Python 对象（Pandas DataFrame / NumPy array），立刻占满本机内存；persist() 把结果留在集群内存中，供后续多个操作复用——但如果你只调一次 compute()，persist() 反而多占资源、拖慢首次响应。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 交互式调试阶段用
compute()快速看结果；生产 pipeline 中，若同一中间结果被df.groupby(...).sum()和df.describe()同时依赖，先df.persist() - 调用
persist()后，记得检查client.cluster.dashboard_link，确认数据真分布在各 worker 上，而非全挤在 scheduler - 对超大宽表（>500 列），
persist()前加df = df.repartition(npartitions=client.ncores * 2)，防止单分区列太多反成瓶颈
为什么 LocalCluster 开了 8 个 worker 却只跑满 2 核？
默认 LocalCluster(n_workers=8) 是进程模式，但若你的代码含大量 GIL 绑定操作（如正则匹配、字符串处理），Python 多进程无法真正并行——实际是 8 个进程排队等 GIL，监控显示 CPU 使用率始终卡在 200%（双核满载）。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
Client(LocalCluster(n_workers=4, threads_per_worker=2))改为多线程模式，适合 Pandas/Numpy 类计算 - 若必须用进程（如调用 C 扩展或防止内存泄漏），提前用
dask.config.set({"distributed.worker.memory.target": 0.8})防止 worker 因内存抖动被杀 - 检查
client.run(lambda: __import__("psutil").cpu_count())，确认 worker 进程看到的 CPU 数和你预期一致，某些容器环境会限制 cgroup 导致误判
分布式不是加机器就快，关键在数据分片是否均匀、计算是否可并行、中间结果是否被反复加载——这些细节没对齐，集群再大也只跑出单核性能。
