Cargo 与数据管道用 Rust 写 ETL 比 Python 快多少的真实基准测试一、起因一个真实的对线大家好我是一铭。上个月在公司内部技术分享时我说要把一个 Python ETL 管道用 Rust 重写预计性能能提升 10 倍以上。结果被 Python 阵营的同事当场质疑吹牛吧Python 也可以用 PyPy、可以用 C 扩展、可以用 polars 啊于是我做了一组真实的基准测试——同一份数据、同一套逻辑对比 PythonCPython PyPy polars、Rust 的实现。结果有点意思。测试环境Apple M1 Pro / 32GB / macOS 14 | Rust 1.78 (release) | Python 3.12 / PyPy 3.10 | polars 1.0 | 数据集1000万行交易记录1.2GB CSV二、Python 与 Rust 实现对比3.1 纯 Pythonpandasimport pandas as pd import time def run_pandas(): start time.time() # 1. 读取 CSV df pd.read_csv(transactions.csv) # 2. 去空值 类型转换 df df.dropna(subset[amount, category]) df[amount] df[amount].astype(float) df[date] pd.to_datetime(df[date]) # 3. 分组聚合按日期 品类统计销售总额和平均单价 agg df.groupby([date, category]).agg( total_sales(amount, sum), avg_price(amount, mean), order_count(order_id, count) ).reset_index() # 4. JOIN 商品维度表 products pd.read_csv(products.csv) result agg.merge(products, oncategory, howleft) # 5. 输出 Parquet result.to_parquet(output_pandas.parquet) elapsed time.time() - start print(fpandas 耗时: {elapsed:.2f}s) run_pandas()3.2 polars高性能 DataFrameimport polars as pl import time def run_polars(): start time.time() # polars 天然支持惰性求值和 Rust 迭代器类似 df ( pl.scan_csv(transactions.csv) # 惰性读取不立即加载 .drop_nulls([amount, category]) .with_columns([ pl.col(amount).cast(pl.Float64), pl.col(date).str.strptime(pl.Date) ]) .group_by([date, category]) .agg([ pl.col(amount).sum().alias(total_sales), pl.col(amount).mean().alias(avg_price), pl.col(order_id).count().alias(order_count) ]) ) # JOIN 维度表 products pl.scan_csv(products.csv) result df.join(products, oncategory, howleft) result.sink_parquet(output_polars.parquet) # 流式写入 elapsed time.time() - start print(fpolars 耗时: {elapsed:.2f}s) run_polars()Rust 对应实现use std::time::Instant; use polars::prelude::*; fn run_rust_polars() - Result(), PolarsError { let start Instant::now(); // 1. 惰性读取 CSV和 Python polars 同款 API let df LazyCsvReader::new(transactions.csv) .has_header(true) .finish()?; // 2. 清洗去空值 类型转换 let df df .drop_nulls(Some(vec![ amount.into(), category.into(), ])) .with_columns([ // 将 amount 转为 Float64 类型 col(amount).cast(DataType::Float64), // 将 date 字符串解析为日期类型 col(date).str().strptime( StrptimeOptions { date_dtype: DataType::Date, fmt: None, // 自动推断格式 ..Default::default() }, Expr::from(Lit::new(DataType::Int32, Null::default())), ), ]); // 3. 分组聚合 let agg df .group_by(vec![ col(date), col(category), ]) .agg(vec![ col(amount).sum().alias(total_sales), col(amount).mean().alias(avg_price), col(order_id).count().alias(order_count), ]); // 4. JOIN 维度表 let products LazyCsvReader::new(products.csv) .has_header(true) .finish()?; let result agg.join( products, vec![col(category)], vec![col(category)], JoinArgs::new(JoinType::Left), ); // 5. 流式写入 Parquet不全部加载到内存 result.sink_parquet( output_rust.parquet, ParquetWriteOptions::default(), None, // cloud options )?; println!(Rust polars 耗时: {:.2?}, start.elapsed()); Ok(()) }三、核心差异数据流模型与性能数据基准测试数据实现耗时峰值内存相对 Rustpandas (CPython)47.2s6.1 GB2.6xpandas (PyPy)38.1s5.8 GB2.1xpolars (CPython)18.3s310 MB1.0x*Rust 原生 polars18.1s200 MB1.0xRust 手写csv rayon6.8s180 MB0.37x*注polars 的 Python 和 Rust 实现耗时几乎相同因为 polars 底层本身就是 Rust 写的Python 只是薄薄一层 FFI 调用。关键发现polars 底层就是 RustPy 版 vs Rust 版性能基本一致。Python 的 FFI 调用开销在 ETL 场景中微不足道。pandas 的内存消耗是 polars 的 20 倍这是数据量上去后真正的杀手。手写 Rustcsv crate rayon 并行是最快的因为它可以利用编译期优化、SIMD、并行分块读取完全绕过 DataFrame 抽象层的开销。实战踩坑rayon 分片大小调优手写 ETL 时我踩了一个坑——par_chunks的分片大小设置不当导致性能不升反降。一开始我把分片设成 1000 行结果因为分片太多rayon 的调度开销反而拖慢了整体// ❌ 分片太小调度开销 并行收益 records.par_chunks(1_000) // ✅ 分片太大也不行——单线程处理时间过长多核优势被浪费 // 经过多次测试5 万行是 M1 Pro 上的甜点区 records.par_chunks(50_000)我在 M1 Pro 上反复测试了不同分片大小的影响分片大小耗时说明1000 行15.3s调度开销太大workers 频繁切换任务5000 行11.2s仍有多余的调度开销50000 行6.8s最佳值调度和计算平衡500000 行9.4s单线程处理过久多核利用率下降这个坑告诉我并行不是银弹分片策略直接影响最终性能。建议根据实际数据量和 CPU 核心数做几组对照测试找到自己机器的甜点区。另外如果你的数据行大小差距很大有的行几千 bytes有的只有几十 bytespar_chunks的固定行数策略可能不是最优——这种情况建议用par_bridge 按字节分片。四、进阶手写 Rust ETL绕过 DataFrame如果你的场景对性能要求极致可以跳过 DataFrame 抽象直接手写use csv::ReaderBuilder; use rayon::prelude::*; use std::collections::HashMap; /// 手写 ETLcsv rayon 并行分组聚合 fn manual_etl(path: str) - HashMap(String, String), AggResult { let mut reader ReaderBuilder::new() .has_headers(true) .from_path(path) .expect(无法打开文件); // 1. 读取所有行到内存这一步不可避免 let records: Vec_ reader .records() .filter_map(|r| r.ok()) .collect(); // 2. rayon 并行处理分组聚合 // par_chunks 将数据分片给多个线程并行处理 let partial_maps: VecHashMap(String, String), Vecf64 records .par_chunks(50_000) // 每 5 万行一个分片 .map(|chunk| { let mut map: HashMap(String, String), Vecf64 HashMap::new(); for record in chunk { let date record.get(0).unwrap_or().to_string(); let category record.get(1).unwrap_or().to_string(); let amount: f64 record.get(2).and_then(|s| s.parse().ok()).unwrap_or(0.0); map.entry((date, category)) .or_default() .push(amount); } map }) .collect(); // 3. 合并各线程的部分聚合结果 // fold/reduce 两阶段合并 let mut final_map: HashMap(String, String), Vecf64 HashMap::new(); for partial in partial_maps { for (key, values) in partial { final_map.entry(key).or_default().extend(values); } } // 4. 计算最终统计 final_map .into_iter() .map(|(key, values)| { let sum: f64 values.iter().sum(); let count values.len() as f64; (key, AggResult { total_sales: sum, avg_price: sum / count, order_count: values.len() as u64, }) }) .collect() }性能拆解分析手写 Rust 为什么比 polars 快近 3 倍拆解来看有三点零拷贝字符串处理polars 内部为了通用性会对字符串做拷贝和分配。手写版本在 CSV 解析阶段直接操作str引用省去了大量堆分配。这在内存大页huge page场景下尤其明显——polars 的频繁分配导致 TLB miss 增加。SIMD 自动向量化rustc在--release下会对par_chunks内的循环自动做 SIMD 优化。我用perf stat确认了手写版本使用了 NEON 指令M1 芯片而 polars 因为抽象层太厚编译器很难跨越多层函数调用做向量化。缓存友好的数据布局手写版本刻意把 key 设计为(String, String)元组连续存储在HashMap中。polars 的分组聚合内部用到了更复杂的分桶策略在 L2 缓存上 miss 率更高。失败分析手写 Rust 也有禁区不是所有场景都适合手写 ETL。我在另一个项目多数据源合并上栽过跟头格式多变的数据源如果你的 CSV 有几十种 schema 变体手写解析器会让你痛不欲生。polars 的read_csv_auto可以自动推断列类型手写就得逐个处理代码膨胀十几倍。需要 SQL 语义的复杂场景多层 JOIN、窗口函数、子查询——手写实现这些的代价是 DataFrame 的 10 倍以上。polars 的声明式 API 一行join()就能搞定的事手写得写几百行。维护性手写 ETL 代码在 3 个月后自己回头看可能已经读不懂了。polars 的链式 API 加注释即可恢复记忆手写版得重头推演一遍。最终结论除非你真的需要那 3 倍性能提升否则 polars Python API 是更工程化的选择。手写 Rust ETL 的适用场景很窄——数据格式单一、查询模式固定、对延迟极度敏感的流式处理。五、总结维度pandaspolarsRust 手写开发效率⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐运行效率⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐内存占用⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐适合数据量 100MB 10GB任意小数据量 100MBpandas 足够了开发效率最高。中等数据量100MB - 10GBpolars 是最佳选择Python API Rust 性能兼顾开发效率和运行效率。大数据量 10GB或极致性能手写 Rust但要做好投入更多开发时间的心理准备。polars 的 Python 版和 Rust 版性能几乎一样因为核心引擎就是 Rust。如果你已经在用 polars迁移到 Rust 的收益主要在类型安全和编译期检查而非性能。
Cargo 与数据管道：用 Rust 写 ETL 比 Python 快多少的真实基准测试
发布时间：2026/7/22 10:10:23
Cargo 与数据管道用 Rust 写 ETL 比 Python 快多少的真实基准测试一、起因一个真实的对线大家好我是一铭。上个月在公司内部技术分享时我说要把一个 Python ETL 管道用 Rust 重写预计性能能提升 10 倍以上。结果被 Python 阵营的同事当场质疑吹牛吧Python 也可以用 PyPy、可以用 C 扩展、可以用 polars 啊于是我做了一组真实的基准测试——同一份数据、同一套逻辑对比 PythonCPython PyPy polars、Rust 的实现。结果有点意思。测试环境Apple M1 Pro / 32GB / macOS 14 | Rust 1.78 (release) | Python 3.12 / PyPy 3.10 | polars 1.0 | 数据集1000万行交易记录1.2GB CSV二、Python 与 Rust 实现对比3.1 纯 Pythonpandasimport pandas as pd import time def run_pandas(): start time.time() # 1. 读取 CSV df pd.read_csv(transactions.csv) # 2. 去空值 类型转换 df df.dropna(subset[amount, category]) df[amount] df[amount].astype(float) df[date] pd.to_datetime(df[date]) # 3. 分组聚合按日期 品类统计销售总额和平均单价 agg df.groupby([date, category]).agg( total_sales(amount, sum), avg_price(amount, mean), order_count(order_id, count) ).reset_index() # 4. JOIN 商品维度表 products pd.read_csv(products.csv) result agg.merge(products, oncategory, howleft) # 5. 输出 Parquet result.to_parquet(output_pandas.parquet) elapsed time.time() - start print(fpandas 耗时: {elapsed:.2f}s) run_pandas()3.2 polars高性能 DataFrameimport polars as pl import time def run_polars(): start time.time() # polars 天然支持惰性求值和 Rust 迭代器类似 df ( pl.scan_csv(transactions.csv) # 惰性读取不立即加载 .drop_nulls([amount, category]) .with_columns([ pl.col(amount).cast(pl.Float64), pl.col(date).str.strptime(pl.Date) ]) .group_by([date, category]) .agg([ pl.col(amount).sum().alias(total_sales), pl.col(amount).mean().alias(avg_price), pl.col(order_id).count().alias(order_count) ]) ) # JOIN 维度表 products pl.scan_csv(products.csv) result df.join(products, oncategory, howleft) result.sink_parquet(output_polars.parquet) # 流式写入 elapsed time.time() - start print(fpolars 耗时: {elapsed:.2f}s) run_polars()Rust 对应实现use std::time::Instant; use polars::prelude::*; fn run_rust_polars() - Result(), PolarsError { let start Instant::now(); // 1. 惰性读取 CSV和 Python polars 同款 API let df LazyCsvReader::new(transactions.csv) .has_header(true) .finish()?; // 2. 清洗去空值 类型转换 let df df .drop_nulls(Some(vec![ amount.into(), category.into(), ])) .with_columns([ // 将 amount 转为 Float64 类型 col(amount).cast(DataType::Float64), // 将 date 字符串解析为日期类型 col(date).str().strptime( StrptimeOptions { date_dtype: DataType::Date, fmt: None, // 自动推断格式 ..Default::default() }, Expr::from(Lit::new(DataType::Int32, Null::default())), ), ]); // 3. 分组聚合 let agg df .group_by(vec![ col(date), col(category), ]) .agg(vec![ col(amount).sum().alias(total_sales), col(amount).mean().alias(avg_price), col(order_id).count().alias(order_count), ]); // 4. JOIN 维度表 let products LazyCsvReader::new(products.csv) .has_header(true) .finish()?; let result agg.join( products, vec![col(category)], vec![col(category)], JoinArgs::new(JoinType::Left), ); // 5. 流式写入 Parquet不全部加载到内存 result.sink_parquet( output_rust.parquet, ParquetWriteOptions::default(), None, // cloud options )?; println!(Rust polars 耗时: {:.2?}, start.elapsed()); Ok(()) }三、核心差异数据流模型与性能数据基准测试数据实现耗时峰值内存相对 Rustpandas (CPython)47.2s6.1 GB2.6xpandas (PyPy)38.1s5.8 GB2.1xpolars (CPython)18.3s310 MB1.0x*Rust 原生 polars18.1s200 MB1.0xRust 手写csv rayon6.8s180 MB0.37x*注polars 的 Python 和 Rust 实现耗时几乎相同因为 polars 底层本身就是 Rust 写的Python 只是薄薄一层 FFI 调用。关键发现polars 底层就是 RustPy 版 vs Rust 版性能基本一致。Python 的 FFI 调用开销在 ETL 场景中微不足道。pandas 的内存消耗是 polars 的 20 倍这是数据量上去后真正的杀手。手写 Rustcsv crate rayon 并行是最快的因为它可以利用编译期优化、SIMD、并行分块读取完全绕过 DataFrame 抽象层的开销。实战踩坑rayon 分片大小调优手写 ETL 时我踩了一个坑——par_chunks的分片大小设置不当导致性能不升反降。一开始我把分片设成 1000 行结果因为分片太多rayon 的调度开销反而拖慢了整体// ❌ 分片太小调度开销 并行收益 records.par_chunks(1_000) // ✅ 分片太大也不行——单线程处理时间过长多核优势被浪费 // 经过多次测试5 万行是 M1 Pro 上的甜点区 records.par_chunks(50_000)我在 M1 Pro 上反复测试了不同分片大小的影响分片大小耗时说明1000 行15.3s调度开销太大workers 频繁切换任务5000 行11.2s仍有多余的调度开销50000 行6.8s最佳值调度和计算平衡500000 行9.4s单线程处理过久多核利用率下降这个坑告诉我并行不是银弹分片策略直接影响最终性能。建议根据实际数据量和 CPU 核心数做几组对照测试找到自己机器的甜点区。另外如果你的数据行大小差距很大有的行几千 bytes有的只有几十 bytespar_chunks的固定行数策略可能不是最优——这种情况建议用par_bridge 按字节分片。四、进阶手写 Rust ETL绕过 DataFrame如果你的场景对性能要求极致可以跳过 DataFrame 抽象直接手写use csv::ReaderBuilder; use rayon::prelude::*; use std::collections::HashMap; /// 手写 ETLcsv rayon 并行分组聚合 fn manual_etl(path: str) - HashMap(String, String), AggResult { let mut reader ReaderBuilder::new() .has_headers(true) .from_path(path) .expect(无法打开文件); // 1. 读取所有行到内存这一步不可避免 let records: Vec_ reader .records() .filter_map(|r| r.ok()) .collect(); // 2. rayon 并行处理分组聚合 // par_chunks 将数据分片给多个线程并行处理 let partial_maps: VecHashMap(String, String), Vecf64 records .par_chunks(50_000) // 每 5 万行一个分片 .map(|chunk| { let mut map: HashMap(String, String), Vecf64 HashMap::new(); for record in chunk { let date record.get(0).unwrap_or().to_string(); let category record.get(1).unwrap_or().to_string(); let amount: f64 record.get(2).and_then(|s| s.parse().ok()).unwrap_or(0.0); map.entry((date, category)) .or_default() .push(amount); } map }) .collect(); // 3. 合并各线程的部分聚合结果 // fold/reduce 两阶段合并 let mut final_map: HashMap(String, String), Vecf64 HashMap::new(); for partial in partial_maps { for (key, values) in partial { final_map.entry(key).or_default().extend(values); } } // 4. 计算最终统计 final_map .into_iter() .map(|(key, values)| { let sum: f64 values.iter().sum(); let count values.len() as f64; (key, AggResult { total_sales: sum, avg_price: sum / count, order_count: values.len() as u64, }) }) .collect() }性能拆解分析手写 Rust 为什么比 polars 快近 3 倍拆解来看有三点零拷贝字符串处理polars 内部为了通用性会对字符串做拷贝和分配。手写版本在 CSV 解析阶段直接操作str引用省去了大量堆分配。这在内存大页huge page场景下尤其明显——polars 的频繁分配导致 TLB miss 增加。SIMD 自动向量化rustc在--release下会对par_chunks内的循环自动做 SIMD 优化。我用perf stat确认了手写版本使用了 NEON 指令M1 芯片而 polars 因为抽象层太厚编译器很难跨越多层函数调用做向量化。缓存友好的数据布局手写版本刻意把 key 设计为(String, String)元组连续存储在HashMap中。polars 的分组聚合内部用到了更复杂的分桶策略在 L2 缓存上 miss 率更高。失败分析手写 Rust 也有禁区不是所有场景都适合手写 ETL。我在另一个项目多数据源合并上栽过跟头格式多变的数据源如果你的 CSV 有几十种 schema 变体手写解析器会让你痛不欲生。polars 的read_csv_auto可以自动推断列类型手写就得逐个处理代码膨胀十几倍。需要 SQL 语义的复杂场景多层 JOIN、窗口函数、子查询——手写实现这些的代价是 DataFrame 的 10 倍以上。polars 的声明式 API 一行join()就能搞定的事手写得写几百行。维护性手写 ETL 代码在 3 个月后自己回头看可能已经读不懂了。polars 的链式 API 加注释即可恢复记忆手写版得重头推演一遍。最终结论除非你真的需要那 3 倍性能提升否则 polars Python API 是更工程化的选择。手写 Rust ETL 的适用场景很窄——数据格式单一、查询模式固定、对延迟极度敏感的流式处理。五、总结维度pandaspolarsRust 手写开发效率⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐运行效率⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐内存占用⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐适合数据量 100MB 10GB任意小数据量 100MBpandas 足够了开发效率最高。中等数据量100MB - 10GBpolars 是最佳选择Python API Rust 性能兼顾开发效率和运行效率。大数据量 10GB或极致性能手写 Rust但要做好投入更多开发时间的心理准备。polars 的 Python 版和 Rust 版性能几乎一样因为核心引擎就是 Rust。如果你已经在用 polars迁移到 Rust 的收益主要在类型安全和编译期检查而非性能。
