Polars 惰性图优化深度拆解：谓词下推与投影下推在千万级表上的省时实测
在大数据预处理与特征工程中，Python 开发者最熟悉的工具长期是 Pandas。然而，当数据集规模从几万行的小表膨胀到数千万行甚至上亿行时，Pandas 的性能会发生急剧的非线性崩塌。哪怕只是做一个简单的多表连接与过滤，服务器的内存占用就会以数倍于数据源体积的幅度疯狂上扬，频繁引发 OOM 崩溃。
这种性能崩溃的根源，在于 Pandas 固守的“迫切执行模式（Eager Execution）”。在迫切模式下，解释器无法获知后续的代码意图，每执行一行赋值语句，底层就必须硬性分配一块全新的内存缓冲区，将所有列全量加载并反序列化。
以 Rust 编写的新一代数据框架 Polars，其最核心的技术护城河正是现代数据库级别的惰性查询优化器（Lazy Query Optimizer）。通过将操作串联为有向无环图（DAG），并在真正触发计算（.collect()）之前对计算图进行深度代数重写，Polars 实现了投影下推（Projection Pushdown）与谓词下推（Predicate Pushdown）。
本文将结合 2000 万行真实工业日志数据，深入拆解 Polars 优化器的底层推导规则，并实测其在 I/O 削减与内存压制上的极致表现。
一、迫切执行与惰性图的本质鸿沟
为了看清两者的差异，我们考察一段典型的数据预处理逻辑：从一个包含 60 个字段、数据量为 2000 万行的 Parquet 表中，筛选出country == "US"且response_time > 500的记录，并最终只提取user_id和url两个字段。
在 Pandas 的迫切模式下，代码通常这样编写：
# Pandas 迫切模式执行流程 df = pd.read_parquet("large_logs.parquet") # 步骤 1: 全量解压 60 列数据进内存 (爆显存) df = df[df["country"] == "US"] # 步骤 2: 生成全表布尔掩码，全量深拷贝过滤 df = df[df["response_time"] > 500] # 步骤 3: 再次生成掩码，二次深拷贝 final_df = df[["user_id", "url"]] # 步骤 4: 丢弃剩余 58 列，保留目标字段这个流程在硬件层面造成了极其惊人的浪费：前三步中，CPU 花费了数十秒去解压、反序列化那 58 个最终根本不需要用到的字段；更严重的是，全量数据在内存中反复复制了三次，内存峰值直接飙升至原始文件大小的 4 到 6 倍。
而 Polars 的惰性模式（LazyFrame）完全颠覆了这一流程。调用pl.scan_parquet()时，Polars 根本不会真正读取数据，它只是在内存中迅速构建一个逻辑执行计划（Logical Plan）。此时，整个计算流是一个纯符号化的 AST 抽象语法树。
+-------------------------------------------------------------+ | 用户提交的原始逻辑图 (Raw AST) | | Scan(All 60 Cols) -> Filter(country) -> Filter(time) -> Select(2 Cols) | +-------------------------------------------------------------+ | v [Polars 优化器重写] +-------------------------------------------------------------+ | 优化后的物理执行计划 (Physical Plan) | | Parquet Scan Engine: | | - 投影下推: 只扫描 [country, response_time, user_id, url] 4 列! | | - 谓词下推: 将过滤条件下推至 Parquet Row Group 元数据过滤! | +-------------------------------------------------------------+二、两大核心下推机制的底层物理实现
Polars 优化器对计算图的重写，主要依托两大工业级数据库优化技术：
1. 投影下推（Projection Pushdown）
Apache Parquet 作为列式存储，其数据在磁盘上是按列独立切片存放的。
Polars 优化器遍历整个 DAG 图，识别出后续所有变换、聚合以及最终输出所真正需要的全部列集合（在上例中仅为 4 列）。
在生成底层物理扫描任务时，优化器直接修改 Parquet 读入配置，向 I/O 驱动下发仅针对这 4 列的读取请求。剩余的 56 列数据，其对应的磁盘扇区甚至不会被操作系统读取，更不会占用任何 CPU 周期进行 Snappy/ZSTD 解压。磁盘 I/O 吞吐和反序列化开销被瞬间抹去了 90% 以上。
2. 谓词下推（Predicate Pushdown）
这是优化器更具杀伤力的一项特性。传统的过滤是在内存中对每一行数据逐一比对。而谓词下推将WHERE过滤条件尽可能早地“推进”到存储引擎内部。
Parquet 文件的每个行组（Row Group，通常包含数万行数据）的元数据中，都精确记录了每一列在当前行组内的最小值（Min）和最大值（Max）。当 Polars 优化器将response_time > 500下推至扫描器时，扫描器在读取具体数据行之前，先读取行组的元数据：
- 如果某个行组的
response_time_max为 320，由于 320 < 500，优化器立即断定该行组内绝对不可能存在满足条件的记录； - 扫描器直接在文件指针上跳过（Seek Skip）整个行组的全部数据块，零读取、零解压。
三、千万级数据压测实录
为了量化下推优化带来的绝对代差，我们在具备 32 核 CPU、128GB 内存的服务器上，使用包含 20,000,000 行数据的真实日志表（压缩后 Parquet 体积为 4.8GB，未压缩原始数据约 26GB，共 48 列）进行了横向基准测试。
测试分为三组：
- Pandas Eager：常规 Eager 流水线；
- Polars Eager：直接使用
pl.read_parquet()并链式调用； - Polars Lazy (全优化开启)：使用
pl.scan_parquet()并在链式末端调用.collect()。
| 计算引擎与模式 | 端到端执行耗时 (s) | 物理内存峰值 (Peak RSS) | 磁盘读取总量 (I/O Read) | 相对 Pandas 综合加速比 |
|---|---|---|---|---|
| Pandas (Eager) | 48.6 s | 31.2 GB | 4.8 GB (全量读取) | $1.0\times$（基准） |
| Polars (Eager) | 9.4 s | 12.8 GB | 4.8 GB (全量读取) | $5.2\times$ |
| Polars (Lazy + 下推) | 0.78 s | 0.95 GB | 0.42 GB (仅按需读取) | $62.3\times$ |
压测结果展现了降维打击般的优势：
Polars 惰性优化版本将端到端计算耗时从 Pandas 的 48.6 秒直接压缩至惊人的0.78 秒，加速比超过 62 倍！
更震撼的是资源消耗层面的对比：
- 内存峰值从 Pandas 的 31.2GB 断崖式暴跌至0.95GB，内存占用削减了 97%；
- 实际磁盘物理读取总量从 4.8GB 骤降至0.42GB，验证了 44 个无关列被投影下推彻底过滤，且大量行组被谓词下推直接跳过。
四、执行计划分析与代码实战
在 Polars 中，我们可以通过.explain()方法打印出优化器推导后的物理执行计划，亲眼见证优化器的工作细节：
import polars as pl import time def benchmark_lazy_execution_plan(parquet_path: str): # 1. 建立符号化 LazyFrame，零数据加载 q = ( pl.scan_parquet(parquet_path) .filter(pl.col("country") == "US") .filter(pl.col("response_time") > 500) .select(["user_id", "url", "response_time"]) ) # 2. 打印未优化前的原始逻辑计划与优化后的物理执行图 print("=== 优化器物理执行图 (Physical Plan) ===") print(q.explain()) # 3. 触发物理执行 start_time = time.perf_counter() result_df = q.collect() cost_time = time.perf_counter() - start_time print(f"执行完毕，命中间隔行数: {len(result_df)}, 耗时: {cost_time:.4f} 秒") return result_df # 输出中将清晰展示： # PARQUET SCAN [user_id, url, response_time, country] # PROJECT 4/48 COLUMNS # SELECTION: [([(col("country")) == (String(US))]) & ([(col("response_time")) > (500)])]在打印出的explain()树状结构中，可以看到原本位于顶层的filter和select操作，被优化器直接下移并融合进了最底层的PARQUET SCAN算子内部，变成了扫描器的内置过滤参数。
五、编写高性能惰性代码的防坑指南
尽管 Polars 优化器极度智能，但在日常编码中，如果不注意代码规范，依然可能意外阻断优化器的下推推导：
- 切忌过早将中间结果
.collect()：许多习惯了 Pandas 交互式开发的工程师，喜欢每写两行代码就调一次.collect()查看输出，这会强行打断惰性图，迫使系统退化回迫切模式。在整个数据管道中，.collect()应当且仅应当在最终需要持久化或对接前端展示的最后一步被调用一次。 - 避免在过滤器中使用不可序列化的 Python 原生 Lambda：若在
.filter()中使用了pl.col("text").map_elements(lambda x: custom_fn(x))，优化器将无法解析 Python 字节码的内部逻辑，从而导致谓词下推彻底失效，迫使引擎只能把数据全量解压进内存后再由 Python 解释器逐行调用。应当始终优先使用 Polars 原生的表达式语法（Expression API）。 - 合理配置行组大小（Row Group Size）：谓词下推的跳过粒度取决于 Parquet 文件的 Row Group。如果在写入 Parquet 时将 Row Group 设置过大（例如 1000 万行一个组），行组内的 Min/Max 范围将涵盖几乎整个值域，导致谓词跳过机制完全失效；反之若设得过小（小于 5000 行），元数据本身将极度臃肿。最佳实践是将 Row Group 行数控制在 50,000 至 200,000 行之间，以最大化下推剪枝效率。