Polars vs pandas 实战对比：新框架的语法能省多少代码

Polars vs pandas 实战对比：新框架的语法能省多少代码

pandas 是数据分析领域的"老大哥"，但它的痛点也很明显：单线程运算慢、语法不一致（locvsilocvs 方括号）、内存占用高。Polars 作为 Rust 编写的新 DataFrame 框架，主打"快、省、一致"。但"快"到底快多少？"省代码"到底省在哪？我们需要实战对比才能得出靠谱结论。

一、框架定位差异：为什么不是"替代"而是"补充"

先搞清楚定位，再谈对比。两个框架的设计哲学有本质区别：

打个比方：pandas 是开了 15 年的老餐馆，菜单丰富但厨房只有一个人，高峰期排队。Polars 是新开的快餐店，菜品少但厨房有 8 个厨师同时出餐，速度快。

graph LR A[数据输入] --> B[pandas<br/>立即执行+内存拷贝] A --> C[Polars Lazy<br/>构建表达式图] C --> D[查询优化器] D --> E[并行执行+零拷贝] B --> F[结果输出] E --> F style B fill:#fce4ec style C fill:#e1f5fe style D fill:#fff3e0

关键差异在中间步骤：pandas 每个操作立即执行并产生新的 DataFrame 拷贝，Polars Lazy 模式先构建表达式图，经过查询优化器再并行执行。这意味着 Polars 不会为了中间步骤浪费内存和 CPU。

二、代码量对比：六个典型场景

我们用 6 个数据分析最常见的场景，对比两个框架的代码量和可读性。

场景1：列筛选与重命名

# pandas 写法——为什么说语法不一致？ # 因为列操作有三种写法：df[col_list]、df.loc[:, col_list]、df.rename() # 新人经常搞不清该用哪种 df = pd.read_csv("sales.csv") result = df[["region", "amount", "order_date"]] # 列筛选：方括号语法 result = result.rename(columns={"order_date": "date", "amount": "revenue"}) # 重命名：字典映射 # Polars 写法——为什么说语法一致？ # 因为所有操作都是 df.select() + pl.col() 表达式链 # 筛选和重命名合在一个 select 里，不需要两步 result = pl.read_csv("sales.csv").select( pl.col("region"), pl.col("amount").alias("revenue"), # alias 在选择时直接重命名，省一步 pl.col("order_date").alias("date"), ) # 省了 1 行代码，但更重要的是：意图更清晰，筛选+重命名一步到位

场景2：分组聚合

# pandas 写法——agg 里的操作用字符串或函数，风格混搭 # 为什么 agg 接受字符串 "sum" 和函数 np.sum 两种写法？ # 这是历史遗留问题，早期版本只支持字符串，后来加了函数支持 # 但两种写法在复杂场景下行为不一致，比如 "sum" 会跳过 NaN，np.sum 不会 grouped = df.groupby("region").agg({ "revenue": "sum", # 字串方式 "orders": "nunique", # 字串方式 "avg_price": np.mean, # 函数方式——风格不一致 }) # Polars 写法——所有聚合都是表达式，风格统一 # 为什么每个聚合都是 pl.col().xxx()？ # 因为表达式链保证了操作的顺序性和组合性 # 你可以在一个 agg 里做：col → filter → sum → alias，链式组合 # pandas 的 agg 只能做单步操作，组合逻辑要拆成多行 grouped = df.group_by("region").agg( pl.col("revenue").sum().alias("total_revenue"), pl.col("orders").n_unique().alias("unique_orders"), pl.col("avg_price").mean().alias("avg_price"), ) # 代码量一样，但可读性更好：每个聚合的意图和别名一目了然

场景3：条件筛选+计算

# pandas 写法——筛选和计算分开写，中间变量多 # 为什么不能一行搞定？因为 pandas 的 query() 方法不支持复杂表达式 # 复杂条件只能用布尔索引，索引结果赋给中间变量再操作 mask = (df["region"] == "华东") & (df["revenue"] > 1000) filtered = df.loc[mask] # 步骤1：筛选 result = filtered.assign( revenue_pct=filtered["revenue"] / filtered["revenue"].sum() * 100 # 步骤2：计算占比 ) # Polars 写法——筛选和计算合在一个表达式链里 # 为什么能合在一起？因为 Polars 的 filter 和 with_columns 都是表达式 # 表达式可以串联，不需要中间变量 result = df.filter( (pl.col("region") == "华东") & (pl.col("revenue") > 1000) ).with_columns( pl.col("revenue").sum().alias("total_revenue"), # 先算总量 ).with_columns( (pl.col("revenue") / pl.col("total_revenue") * 100).alias("revenue_pct"), ) # 省了中间变量，但多了两行 with_columns——因为占比计算依赖总量 # 整体更清晰：每一步的数据流方向明确

场景4：窗口函数

# pandas 写法——窗口操作要用专门的 rolling/expanding API # 为什么 rolling 和 groupby 不能组合？ # 因为 pandas 的 rolling 是独立的方法链，不兼容 groupby 的 agg # 要做"分组内的滚动计算"，得手动拆解 df["rolling_7d"] = df.groupby("region")["revenue"].transform( lambda x: x.rolling(7).mean() # transform + rolling 组合——嵌套写法 ) # Polars 写法——窗口函数是表达式的一部分，直接在 group_by 里写 # 为什么能直接写？因为 Polars 把窗口操作设计成表达式的方法 # rolling、over、group_by 都是 pl.col() 的子操作，可以自然组合 df = df.with_columns( pl.col("revenue").rolling_mean(window_size=7).over("region").alias("rolling_7d"), ) # 省了 lambda 和 transform——表达式链比嵌套函数更直观

场景5：多表关联

# pandas 写法——merge 默认行为多，参数复杂 # 为什么 merge 有 4 种 join 类型但最常用只有 left 和 inner？ # 因为 right 和 outer 在实际业务中极少使用 # 但 pandas 把它们并列展示，新手容易选错 result = pd.merge( df_users, df_orders, on="user_id", how="left", # join 类型 suffixes=["_u", "_o"], # 列名冲突时的后缀——为什么需要？ # 因为两个表可能有同名列（比如 created_at） # pandas 自动加后缀避免冲突，但后缀命名不可控 ) # Polars 写法——join 默认 inner，参数精简 result = df_users.join( df_orders, on="user_id", how="left", ) # Polars 不需要 suffixes 参数——为什么？ # 因为 Polars 的列名是表达式级别的，同名列通过 pl.col("table.col") 区分 # 不需要全局后缀，列名冲突的处理更优雅

场景6：惰性执行与查询优化

# pandas——没有惰性模式，每个操作立即执行 # 为什么立即执行是性能杀手？ # 因为每一步都产生新的 DataFrame 拷贝，内存占用翻倍 # 比如 100MB 的数据经过 5 步操作，峰值内存可能达到 500MB df = pd.read_csv("sales.csv") # 读入100MB df = df[df["region"] == "华东"] # 过滤后复制80MB df = df.groupby("date").agg({"revenue": "sum"}) # 聚合后复制10MB df = df.sort_values("date") # 排序再复制10MB # 总内存峰值：100 + 80 + 10 + 10 = 200MB（加上原始100MB） # Polars Lazy——构建表达式图，优化后一次执行 # 为什么 Lazy 模式能省内存？ # 因为它不产生中间拷贝，所有操作在查询优化后合并成一次扫描 # 优化器会自动做：谓词下推（先过滤再读全量）、投影下推（只读需要的列） # 比如 100MB 的数据有 50 列，但你只用 3 列，优化器只读这 3 列的数据 df = pl.scan_csv("sales.csv") # scan_csv 是惰性读取，不立即加载 .filter(pl.col("region") == "华东") # 过滤条件记录但不执行 .group_by("date").agg(pl.col("revenue").sum()) # 聚合条件记录但不执行 .sort("date") # 排序条件记录但不执行 .collect() # collect 触发执行——所有操作一次完成 # 内存峰值：只有最终结果的大小，中间不产生拷贝

三、性能实测：什么时候 Polars 确实更快

用一个 500 万行的销售数据集做实测：

提速主要来自三个因素：

1. 并行计算：pandas 单线程，Polars 自动利用所有 CPU 核
2. 零拷贝：pandas 每步产生新 DataFrame，Polars Lazy 不产生中间结果
3. 查询优化：谓词下推让 Polars 只读需要的数据，pandas 读全量再过滤

但注意：数据量 < 10 万行时，提速不明显（差距在毫秒级）。pandas 的瓶颈在大数据量场景才显著暴露。实际选型时建议用生产环境的真实数据量做一次性能测试，不要仅凭第三方 benchmark 做决策。

四、什么时候不该换 Polars

代码量和性能不是唯一考量，以下场景 Polars 反而不合适：

1. 生态依赖深

如果你的分析流程依赖 pandas 生态的很多包（statsmodels、scikit-learn 的 DataFrame 输入、geopandas），Polars 没有直接替代。你得先把 Polars DataFrame 转成 pandas（df.to_pandas()），转换本身就有性能损耗。

2. 交互式探索场景

Jupyter Notebook 里逐步探索数据，pandas 的立即执行模式反而更方便——每一步都能立即看到结果。Polars Lazy 模式要最后 collect 才能看到，探索节奏被打断。当然 Polars 也有 eager 模式（pl.read_csv而不是pl.scan_csv），但 eager 模式就没有查询优化了。

3. 团队技能迁移成本

pandas 是行业通用技能，新人入职大概率会 pandas 不会 Polars。迁移到 Polars 意味着团队要重新学习一套 API，短期效率反而下降。

五、总结

Polars 在代码量上并没有大幅少于 pandas——大多数场景省 1-2 行，核心优势是语法一致性和表达式链的可读性。真正拉开差距的是性能：大数据量（> 100 万行）场景下，Polars Lazy 模式靠并行计算、零拷贝和查询优化，速度是 pandas 的 5-10 倍。

但迁移决策要看场景：纯数据处理流水线（ETL、批计算）选 Polars 收益最大；依赖 pandas 生态的分析流程（建模、地理分析）换 Polars 成本高；交互式探索用 pandas 更顺手。

务实的选择是：新项目用 Polars 起步，老项目在瓶颈环节局部替换（比如大表聚合改 Polars，其余保持 pandas），不要搞全量迁移一刀切。

最后提醒一点：这个方案在上生产之前建议先用灰度流量验证一周，确认资源消耗在预期范围内再全量推送。我们在实际项目中因为跳过了这步，有一次把缓存集群打挂了，教训深刻。