vaex.open()卡住因默认扫描元数据，应改用lazy=true；csv需先转parquet；多文件合并后filter变慢因分片处理，建议合并为单文件并确保row group statistics完整。
vaex.open() 为什么卡住不动
因为 vaex.open() 默认尝试读取文件元数据（比如列类型、统计信息），遇到超大 Parquet 或 HDF5 文件时，会扫描整个文件头甚至部分数据块，导致长时间无响应。这不是卡死，是它在“认真干活”。
- 用
vaex.open(path, lazy=True)强制跳过预扫描，立刻返回一个vaex.DataFrame对象 - 如果文件是 CSV，别用
vaex.open()—— 它不支持 CSV 懒加载，必须先转成 Parquet：vaex.from_csv("big.csv").export("big.parquet") - Parquet 文件若由 Spark 或 Dask 写出，可能含多层嵌套 schema，
vaex有时解析失败；加参数schemas=False可绕过 schema 推断
内存没涨但计算慢得离谱
懒加载不等于零开销。vaex 把计算延迟到 .evaluate() 或 .to_pandas() 那一刻，但表达式树构建、列依赖分析、分块调度本身有 CPU 开销，尤其链式操作多时。
- 避免反复写
df.x + df.y > 0.5多次——先存为虚拟列：df['flag'] = df.x + df.y > 0.5 - 用
df.count()替代len(df)，后者会强制触发完整评估 - 筛选后立刻调用
.extract()（如df[df.flag].extract()）可生成新懒数据集，切断旧计算图，减少后续调度负担
filter 后 shape 不变或报错 “out of memory”
这是最常被误解的点：vaex 的布尔索引（df[df.x > 0]）默认返回的是视图（view），不是物理子集，所以 df.shape 看起来没变；但一旦你调用 .to_numpy() 或写入磁盘，它才真正分配内存 —— 这时才爆 OOM。
- 确认是否真要物化结果：如果只是画图或统计，用
df.x[df.x > 0].mean()这类聚合即可，全程不加载全量数据 - 真要导出子集，用
df[df.x > 0].export("filtered.parquet")，它会流式写入，不占额外内存 - 警惕
df.copy()—— 它会立即加载所有列到内存，哪怕你只改了一列
多文件合并后 filter 速度反而下降
用 vaex.open_many([f1, f2, f3]) 合并多个 Parquet 文件后，vaex 默认把它们当独立分片处理。如果 filter 条件无法下推到每个文件内部（比如涉及跨文件 join 或全局 percentile），就会退化成逐文件扫描+合并结果。
立即学习“Python免费学习笔记（深入）”；
- 优先用单个大 Parquet 文件（用
vaex.from_parquet(...).export("merged.parquet")合并） - 如果必须用多文件，确保每份都带独立 row group 和 statistics（用
pyarrow.parquet.write_table(..., row_group_size=1_000_000)控制） - 检查
df._file_stats是否为空 —— 空说明 vaex 没法利用元数据跳过 block，性能必然差
真正难的不是打开文件，而是判断哪一步开始从“懒”变成“实”。每次调用 .values、.to_numpy()、.to_pandas()、.plot()（某些 backend）、.describe()，都在悄悄越过那条线。盯紧你的内存监控，比看文档更管用。
