pd.read_parquet() 比 pd.read_csv() 快得多，因Parquet支持列裁剪和谓词下推，20列中读3列耗时不足CSV的1/8；需显式指定columns、设index=False，并注意compression与use_dictionary兼容性问题。
pd.read_parquet() 比 pd.read_csv() 快得多，不是“可能快”，而是只要数据量超过 100MB，基本就该切——这不是优化建议，是工程底线。
读取速度差距直接体现在 I/O 和列裁剪上
CSV 必须逐行扫描、解析整行文本、再做类型推断；pd.read_parquet() 只加载你指定的列（甚至支持谓词下推），跳过无关数据页。实测 20 列中只读 3 列时，Parquet 耗时通常不到 CSV 的 1/8。
- 用
columns=['user_id', 'event_time']参数可显式限定列，避免全量加载 - 不加
columns也比 CSV 快，但浪费带宽和内存——列式存储的优势得靠“主动裁剪”兑现 - 如果原始 CSV 有 50 列但分析只用 2 列，继续用 CSV 就等于主动给磁盘和内存加压
to_parquet() 默认参数已足够好，但三个配置项必须留意
默认用 engine='pyarrow'、compression='snappy'、index=False 是合理起点，但容易踩坑：
-
index=True（默认）会把 DataFrame 索引额外存成一列——多数分析不需要，且破坏列对齐，务必设为False - 若数据含大量重复字符串（如分类字段），改用
compression='zstd'可再省 10–15% 空间，但读写稍慢 - 跨平台共享时避免用
use_dictionary=True（PyArrow 默认开启），某些旧版 Spark 会读失败
类型丢失问题在 Parquet 中几乎不存在，但 CSV 里天天发生
CSV 读取时 pd.read_csv() 对 datetime、categorical、nullable integer 类型的推断极不可靠，常需反复加 parse_dates、dtype、converters 参数调试；而 pd.read_parquet() 直接还原原始 dtypes，连 Int64（带缺失的整型）和时区感知 datetime 都原样保留。
- 导出前确认
df.dtypes符合预期，to_parquet()会忠实保存 - 不要依赖
read_parquet(..., dtype=...)强制转换——它不起作用，类型信息已固化在文件元数据中 - 若发现读出来类型不对，问题一定出在写入阶段（比如用了低版本 PyArrow 或 Pandas）
read_csv() 开始让你等超过 10 秒，或日志里频繁出现 DtypeWarning ，说明 CSV 已经在拖慢整个迭代节奏——这时候再切 Parquet，已经晚了两轮分析。 
