技能介绍

要解决什么问题

你已经用 pandas 跑通了 ETL 或分析，但数据涨到几十万、几百万行后，CPU 成为瓶颈。直接换成 cuDF 并不总是「改 import」那么简单：空值语义（可空类型 vs NaN）、排序是否稳定、reshape 的索引层级，以及部分 API 仍会回退到 CPU。更麻烦的是数据略大于单卡显存时，要在溢出、RMM 池 和 dask-cuDF 之间做选择，否则先 OOM 再调参。

技能如何引导实现

本技能把实现路径收成三条，并按意图选路：

cudf.pandas 加速器：改动最小、第三方 pandas 兼容；用分析器确认热路径是否真的在 GPU 上，CPU 占比高则转到显式 cuDF。
显式 cuDF API：具名 DataFrame 迁移、热 ETL、语义敏感操作；中间数据尽量留在 GPU，仅在展示、绘图或 CPU 库边界用 .to_pandas() / .numpy()。
dask-cuDF：数据集超过单 GPU 内存；配合 enable_cudf_spill=True 等模式处理分区与溢出。

关键规则包括：约 10 万行以下 GPU 传输开销常盖过收益（小数据验正确性、大工作集测性能）；精度允许时尽早用 float32；对连接、分组、重塑、时间序列等，在代表性切片上保留 pandas 参考路径，对照形状、标签、空值计数与代表性值后再声称语义一致。

适用边界与注意点

与 pandas 结果不一致时，先查空值/填充、stable=True 排序、以及浮点非结合性（GPU/CPU 浮点结果可能永久不同，勿强行「修到完全一致」）。遇到 AttributeError / NotImplementedError，在窄边界 .to_pandas() 处理不支持操作，再用 .from_pandas() 回到 GPU 流水线。显存策略可简记：空闲显存远大于数据用单卡 cuDF；紧张则 cudf.set_option("spill", True)；仍不够再上 dask-cuDF。

截图预览

使用场景

现有 pandas 的 `read_parquet` + 分组聚合流水线在百万行以上跑不动，需要在尽量少改代码的前提下把热路径迁到 GPU。
要把具名 DataFrame 的 join、fillna、时间桶逻辑从 pandas 搬到 cuDF，上线前要在代表性切片上对照行数、空值计数和排序结果。
单卡显存装不下整表 ETL，需要在启用 `spill` 与切换到 dask-cuDF 之间选型，并调分区避免反复 OOM。
已启用 `cudf.pandas` 但性能没提升，需要用分析器定位仍回退 CPU 的操作并改为显式 cuDF 实现。

适合人员

维护夜间批处理 ETL、源数据为大型 CSV/Parquet 且当前全在 pandas 上跑的数据工程师，诉求是明确选 cudf.pandas 还是显式 cuDF。
在 Jupyter 里已有大量 pandas 笔记本、负责把特征工程预处理接到 CUDA 环境的 ML 平台工程师，需要边界转换与 dtype 策略。
做透视表、melt、stack/unstack 密集型分析的开发，迁移 GPU 时必须保留与 pandas 一致的 reshape 标签与 `fill_value` 语义。
单节点多 GPU 或数据超过单卡内存的分析师，需要按 dask-cuDF 模式分区并配置溢出与 RMM 池。