dask dataframe替代pandas不能自动加速，关键在控制分块粒度、避免隐式.compute()、聚合前对齐分区键；groupby卡顿主因是默认未按key分区，需先repartition或set_index再聚合。
直接用 dask.dataframe 替代 pandas.DataFrame 并不能自动加速特征工程——很多团队改完就跑，结果比 Pandas 还慢。真正起效的关键在于：**控制分块粒度、避免隐式触发 .compute()、把聚合类操作提前对齐分区键**。
为什么 Dask DataFrame 一做 groupby 就卡住？
Dask 的 groupby 默认不保证数据按 key 分布在同一个分区里，它会先 shuffle 再聚合，而 shuffle 在磁盘 I/O 和序列化上开销极大。
- 错误写法：
df.groupby("user_id")["amount"].sum()→ 每次都触发全局 shuffle - 正确做法：先用
df.set_index("user_id", sorted=True)或df.repartition(on="user_id")，再groupby - 如果 key 有倾斜（比如某几个 user_id 占 80% 行数），
repartition后仍可能卡在单个分区，此时要加shuffle="disk"或改用dd.shuffle.shuffle(df, "user_id", shuffle="tasks")
UDF 在 Dask 里比 Spark 更危险
Spark 的 UDF 至少还能走 JVM 批处理；Dask 的 map_partitions + 自定义函数，一旦没写好，就会退化成单核串行执行，且内存无法释放。
Python 3.14.2
下载
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
- 别写
df.map_partitions(lambda x: x.apply(..., axis=1))—— 这等于把每个 chunk 当成小 Pandas 跑，失去并行意义 - 优先用内置方法：
df["col"].str.contains(...)、df["col"].dt.month、df.where(...) - 真要 UDF，必须确保函数本身是纯计算、无状态、输入输出类型明确，并用
meta=...显式声明返回结构，否则.compute()时会报ValueError: Metadata inference failed
读 Excel / CSV 时就该决定性能上限
dd.read_csv() 和 dd.read_excel() 的参数直接影响后续所有操作的并行效率，不是“读进来再说”。
-
blocksize（CSV）或sample（Excel）必须设：默认值往往太小（如 256KB），导致分区过多、调度开销压倒计算收益；建议从 20–50MB 起调 - Excel 读取务必加
engine="openpyxl"（非默认），否则dd.read_excel会 fallback 到单线程 Pandas 读取 - 列类型尽早指定：
dtype={"user_id": "uint32", "flag": "category"}，避免 Dask 自动推断失败后反复重试 - 别在
read_*后立刻.compute()—— 这等于白用 Dask；所有清洗逻辑应链式写完，最后统一.compute()
最常被忽略的一点：Dask 的「延迟计算」不是魔法，它靠的是任务图优化。一旦你在中间插入 .head()、.len().compute() 或打印 shape，整个图就被截断重算——特征工程流水线里这种调试习惯，比写错一个 repartition 更容易拖垮性能。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
