PyArrow是处理中大型数据绕不开的内存解法，解决“能否运行”而非单纯提速；需显式启用engine="pyarrow"或dtype_backend="pyarrow"，且CSV解析兼容性差、Parquet默认启用并显著省内存。
PyArrow不是“推荐用”，而是处理中大型数据时绕不开的内存解法——它解决的不是“快一点”，而是“能不能跑起来”。
PyArrow后端真正起效的前提是显式启用
很多人装了pyarrow就以为Pandas自动加速了，结果读CSV还是OOM。事实是：pd.read_csv()默认完全不走PyArrow，哪怕你已安装最新版pyarrow。必须手动指定参数才生效：
-
engine="pyarrow"：仅对read_csv()、read_json()等文本格式有效，但会拒绝很多常用参数（比如parse_dates、自定义na_values） -
dtype_backend="pyarrow"：影响整张表的类型推断（如字符串列自动为string[pyarrow]），但不加速解析过程本身 -
read_parquet()例外——只要pyarrow已安装，它默认就用PyArrow引擎，无需加engine参数
CSV读取时PyArrow引擎的兼容性陷阱
PyArrow的CSV parser比Pandas严格得多，习惯写法很容易报错：
- 错误现象：
ValueError: unsupported type for column 'x': object，通常因某列混有数字和空字符串，而PyArrow不接受object类型 -
na_values和keep_default_na被完全忽略——它只认None、""、NULL、NaN字面量；自定义空值标记（如"N/A"）需提前用convert_options配置或预处理 -
dtype={"col": "str"}会失败，必须写成dtype={"col": "string[pyarrow]"}或pa.string() -
parse_dates不支持，日期列得先读入再转：.astype("timestamp[ns][pyarrow]")
Parquet场景下PyArrow才是默认主力
如果你的数据源是Parquet（尤其是分区表或大文件），PyArrow不是“可选项”，而是事实标准：
立即学习“Python免费学习笔记（深入）”；
-
read_parquet()在Pandas 2.0+中已深度绑定PyArrow 11+，无需额外配置，但要求路径结构与schema一致，否则可能静默跳过某些分区或加载极慢 - 真正优势不在“读得快”，而在“读得省”：相同数据，
string[pyarrow]比object类型内存占用低60%以上，且缺失值用单独的validity bitmap管理，不再依赖np.nan占位 - 想进一步控内存？别用
pd.read_parquet()全量加载，改用pyarrow.parquet.ParquetFile().iter_batches()流式分批处理，1.2TB文件也能压在20GB内存内跑完
最常被忽略的一点：PyArrow的收益不是线性的——小数据集（dtype_backend="pyarrow"，往往要重调整个ETL链路的类型假设。
