pyarrow引擎在Pandas 2.0下读Parquet更快，因其原生支持Arrow内存模型、高效压缩解码、列裁剪与谓词下推、多线程I/O及更优CPU缓存利用。
为什么 pyarrow 引擎在 Pandas 2.0 下读 Parquet 更快
Pandas 2.0 默认仍用 fastparquet 作为后备引擎，但实际性能常不如 pyarrow——尤其在列裁剪、谓词下推、压缩解码（如 snappy、zstd）和多线程 I/O 上。pyarrow 原生支持 Arrow 内存模型，避免了中间序列化开销，且其 C++ 实现对现代 CPU 缓存更友好。
常见错误现象：pd.read_parquet() 在大文件上卡顿、CPU 利用率低、内存暴涨后 OOM，往往就是没指定引擎或装了旧版 pyarrow。
- 确认已安装
pyarrow>=11.0.0（Pandas 2.0 推荐最低版本），fastparquet可卸载或保留，但不主动调用 - 不用依赖 Pandas 自动选择：显式传
engine="pyarrow"，否则可能 fallback 到fastparquet -
pyarrow支持更多 Parquet 特性（如 nested types、dictionary page encoding），而fastparquet对某些 Spark 写出的文件兼容性差
如何正确调用 pd.read_parquet() 启用 pyarrow
不是装了 pyarrow 就自动生效。必须显式声明引擎，并注意参数适配。
- 基础写法：
pd.read_parquet("data.parquet", engine="pyarrow") - 启用列裁剪（只读需要的列）：
pd.read_parquet("data.parquet", columns=["col_a", "col_b"], engine="pyarrow") - 加过滤条件（谓词下推，跳过整行组）：
pd.read_parquet("data.parquet", filters=[("col_a", ">", 100)], engine="pyarrow")—— 注意语法是pyarrow的 list-of-lists 格式，非 Pandas 查询字符串 - 禁用元数据缓存（小文件多时减少开销）：
pd.read_parquet("data.parquet", use_legacy_dataset=False, engine="pyarrow")（Pandas 2.0+ 默认True，但新 Dataset API 更快）
pyarrow 引擎下容易踩的坑
很多“加速失败”其实源于配置错位或隐式降级。
立即学习“Python免费学习笔记（深入）”；
-
filters不生效？检查字段名是否大小写/下划线一致，且该列必须是 Parquet 文件的分区列或已统计（statisticsenabled）；fastparquet的 filter 语法不同，混用会静默失败 - 报错
ArrowInvalid: Unsupported logical type？说明文件用了pyarrow新增类型（如timestamp[us, tz=...]），升级pyarrow到最新稳定版（如 14.x+） - 内存占用反而更高？关掉
use_threads=True（默认开启）试试——某些 NFS 或容器环境线程争抢反而拖慢；也可设use_threads=2手动限流 - 读取后 DataFrame dtypes 异常（如 string 变成 object）？加
dtype_backend="pyarrow"（Pandas 2.0+ 新参数），让字符串、bool 等直通 Arrow 类型，避免 Python object 开销
验证是否真走 pyarrow 路径
别靠猜。最直接的方法是看异常堆栈或强制触发一个 pyarrow-only 特性。
- 临时删掉
fastparquet：pip uninstall fastparquet，再运行pd.read_parquet(...)，如果报ImportError: Unable to load parquet engine 'fastparquet'但依然成功读出，说明已在用pyarrow - 用
filters+ 非法值触发错误：filters=[("nonexistent_col", "==", 1)]，pyarrow报ArrowInvalid: Column 'nonexistent_col' not found，而fastparquet可能静默忽略或报不同错 - 查日志（需调试）：
import pyarrow.parquet as pq; pq.ParquetFile("x.parquet").metadata—— 若能正常返回，说明底层已加载pyarrow
真正耗时的点往往不在引擎切换本身，而在列选择粒度、过滤表达式是否可下推、以及 Arrow 类型与 Pandas dtype 的映射策略——这些比单纯换引擎影响更大。
