Pandas 50GB ETL 跑 240 分钟+月月 OOM 的 2 年挣扎:6 天 Polars 重写压到 11 分钟+1.2GB 内存全过程 + 7 个迁移坑 + 选型决策树

2026 年 5 月,我接手一个让数据组心累两年的 ETL 任务:每天凌晨从公司 SaaS 业务的事件日志(50GB 左右,1.2 亿行 JSONL)生成 6 张统计表,推送给 BI。这个任务过去的实现是 Python + Pandas,跑在一台 64GB 内存的胖机器上,每天凌晨 2 点启动,完成时间从设计时的 40 分钟逐渐恶化到 4 小时——还经常因为某天数据特别大或者业务字段变了直接 OOM 跑挂,值班同事被叫起来重跑成了月度礼仪。

我用 Polars 重写这个 ETL,花了 6 个工作日完成 + 验证 + 上线,最终把同样的输入数据处理时间从240 分钟压到 11 分钟,内存从峰值 58GB 压到 1.2GB,机器规格可以从 64GB 直接降到 8GB(年省云成本约 18 万)。但这次迁移踩到了 7 个非常具体的"Pandas 和 Polars 不一样"的坑,有些坑会悄悄改变数据语义——比如 null 处理、类型推断、groupby 顺序——如果没踩到我可能根本意识不到结果不对。这篇是完整复盘,涵盖 Polars 的核心架构、和 Pandas 的关键差异、Lazy + streaming 模式实战、7 个迁移坑的具体场景、以及落地的《Python ETL 选型与迁移纪律》。

背景:这个被 Pandas 拖累两年的 ETL

ETL 是个挺"无聊"的工作——业务方关心的是"今天报表能不能按时给",过程对他们不可见。这种"基础但没人关心"的工作,正是最容易积累技术债的。

事故时间线:从烦透了到重构上线的 6 天

第一反应:"Pandas 优化一下就行了"

事故前两年,我们一直在做 Pandas 的"微优化"——加 chunk read、显式 dtype、用 categorical、改 groupby key 顺序。每次都能挤出 10-20% 的提速,但治标不治本。240 分钟优化到 168 分钟,听起来不错,但 OOM 风险还在(数据量持续增长),离我们的目标(60 分钟内)还差很远。

Pandas 的根本限制在它的设计:

• 纯 Python + NumPy 内核,绝大多数操作有 Python 解释器开销
• 单线程默认,GIL 让多核基本用不上(除非用 Modin / Dask)
• 立即执行,不会做查询优化(列裁剪、谓词下推等)
• 内存里全量加载,处理大数据要 chunk by chunk 手动管理

这些限制在中小数据(< 1GB)无所谓,但在 10GB+ 数据上是真正的瓶颈。继续"优化 Pandas"就像继续给 1984 年的车换轮胎,该换车了。

因果链:为什么 Pandas 在 50GB 数据上是必死的

这张图的关键信息是三个因素互相放大:GIL 锁死多核 / 内存中间结果反复复制 / hash join 不能 spill。任何一个单独存在都不致命,叠加就让 Pandas 在 50GB 这个尺度成为"必死"——加机器只是延迟死亡时间,治不了根。我们内部叫这种问题"工具触顶反模式",任何一项性能事故复盘都强制画一张这种因果图,确保不会"被表层指标欺骗,误以为再优化一轮就行"。这次画完图之后,继续优化 Pandas 的方案当场被否,Polars 重写当天就拍板了。

Polars 是什么,为什么快

Polars 是 Rust 写的 DataFrame 库,2020 年开源,2024-2025 年开始在数据工程圈快速取代 Pandas。它的核心架构:

对我们 ETL 来说最关键的是:Lazy + streaming。Polars Lazy API 让你写完整 query 后再执行,执行时 Polars 会做谓词下推、列裁剪、join 重排序等优化;streaming 模式则让你在内存远小于数据量时也能跑——它会分块加载、分块处理、分块输出,Pandas 必须手动 chunk 实现的逻辑被 Polars 自动化了。

重写过程:从 Pandas 到 Polars 的具体代码

看一段典型的 ETL 代码对比。原 Pandas 实现(已经做过一轮优化):

# Pandas 原版
import pandas as pd
import gzip, json
from pathlib import Path

dfs = []
for p in Path('/data/events').glob('*.jsonl.gz'):
    with gzip.open(p) as f:
        for chunk_start in range(0, 999999, 200000):
            chunk = pd.read_json(f, lines=True, nrows=200000, dtype={
                'user_id': 'int64',
                'event_type': 'category',
            })
            dfs.append(chunk)
df = pd.concat(dfs, ignore_index=True)

# 数据清洗
df['event_time'] = pd.to_datetime(df['event_time'], utc=True)
df = df[df['event_time'].dt.date == TARGET_DATE]
df = df.dropna(subset=['user_id', 'event_type'])

# 计算几个聚合
daily_dau = df.groupby(df['event_time'].dt.date)['user_id'].nunique().reset_index()
daily_dau.columns = ['date', 'dau']

event_count = df.groupby(['event_time'.dt.date, 'event_type']).size().reset_index(name='count')

# ... 4 张其他报表
# 输出
daily_dau.to_parquet('/output/daily_dau.parquet')

Polars 重写版:

# Polars Lazy 版
import polars as pl
from pathlib import Path

# Lazy 扫描所有 JSONL,不立即加载
lf = pl.scan_ndjson(
    '/data/events/*.jsonl.gz',
    schema={
        'user_id': pl.Int64,
        'event_type': pl.Categorical,
        'event_time': pl.Utf8,
        # ... 其他字段
    }
)

# 数据清洗,所有操作都是 lazy,不实际执行
lf = lf.with_columns([
    pl.col('event_time').str.to_datetime(time_zone='UTC').alias('event_time'),
]).filter(
    pl.col('event_time').dt.date() == TARGET_DATE
).drop_nulls(['user_id', 'event_type'])

# 同时计算多个报表
daily_dau = lf.group_by(pl.col('event_time').dt.date().alias('date')).agg([
    pl.col('user_id').n_unique().alias('dau'),
])

event_count = lf.group_by([
    pl.col('event_time').dt.date().alias('date'),
    pl.col('event_type'),
]).agg([
    pl.len().alias('count'),
])

# 一次性触发执行,Polars 会做查询优化
daily_dau.sink_parquet('/output/daily_dau.parquet')   # streaming write
event_count.sink_parquet('/output/event_count.parquet')

关键差异:

• 用 scan_ndjson 而不是 read_json——前者是 lazy,后者是 eager。Lazy 模式下 Polars 会在 collect / sink 时做整体优化
• 所有 transformation 用 pl.col(...) 表达式,而不是 Pandas 风格的 df['col']。这是 Polars 的"表达式语法",更显式,Polars 能优化它
• 用 sink_parquet 而不是 collect().write_parquet——前者是 streaming 输出,内存只占当前批次的大小,不需要全量加载

这个版本第一次跑就把 240 分钟的任务压到了 18 分钟。后续优化(下一节)再压到 11 分钟。

性能进一步优化:streaming 模式 + 多线程

Polars 的 streaming 模式不是默认开启,需要显式:

# 启用 streaming
result = lf.collect(streaming=True)

# 或者 sink_parquet 默认就是 streaming
lf.sink_parquet('out.parquet')

streaming 模式下,Polars 把数据分成"批次"(默认 ~ 50000 行一批),依次加载、处理、输出。整个流程内存占用是常数级——只够装一个批次。对我们 12GB 输入数据来说,内存峰值压到了 1.2GB。

多线程是自动的,Polars 根据 CPU 核数自动并行化。我们的机器 4 vCPU,Polars 跑时 CPU 使用率稳定在 380%(4 核几乎打满),而 Pandas 跑时 CPU 一直在 100%(单核打满)。同样的工作量,4 倍并行直接 4 倍速度。

迁移踩的 7 个坑

结果不一致是迁移最危险的部分。我们花了 1 整天对比两版输出,定位到 7 个具体差异。

坑 1:null 在 groupby 中的行为

这个差异让我们 daily_dau 的数字差了 0.3%——Pandas 把 user_id 为 null 的事件直接丢了,Polars 把它们当成"用户 null"的一个分组单独算 dau。修法:在 Polars 里显式 drop_nulls 或在 groupby 后 filter。

坑 2:to_datetime 的失败行为

Pandas pd.to_datetime 默认遇到不规范的字符串会 raise,可以传 errors='coerce' 让它转 NaT。Polars str.to_datetime 默认行为不同——遇到不规范字符串直接 raise(无 coerce 选项,要用 strict=False),且抛出的 error 位置信息不如 Pandas 详细。

修法:

pl.col('event_time').str.to_datetime(
    format='%Y-%m-%dT%H:%M:%S%.f%z',
    strict=False    # 失败时填 null 而不是 raise
)

坑 3:category 类型的排序

Pandas 的 categorical 类型默认按字母序排;Polars 的 Categorical 按"首次出现顺序"排。这在 groupby + sort 后会导致行顺序不同(虽然数据值一样)。我们有一份报表的"top 10"被这个影响——前 10 名虽然都对,但顺序不同。修法:显式 .sort('count', descending=True)。

坑 4:多列 groupby 的输出顺序

Pandas groupby 默认按 key 升序输出;Polars 默认不保证顺序(因为并行计算)。如果下游依赖顺序,需要显式排序。修法:.sort('date') 或者用 group_by(maintain_order=True)。

坑 5:nunique 的 null 处理

Pandas nunique 默认 dropna=True;Polars n_unique 默认包含 null 作为一个 unique 值。这影响我们 dau 数字(null 用户被算成 1 个 "unique user")。修法:

pl.col('user_id').drop_nulls().n_unique()

坑 6:除法的 int / int

Pandas 里 int / int 自动变 float(Python 3 风格)。Polars 里 int / int 默认保留 int(整除)。我们有"事件率 = 事件数 / 用户数"的计算,Polars 版给了整数结果(基本都是 0),Pandas 版是浮点。修法:

(pl.col('events') / pl.col('users')).cast(pl.Float64)
# 或者
pl.col('events').cast(pl.Float64) / pl.col('users')

坑 7:字符串 contains 的正则默认

Pandas .str.contains 默认 regex=True;Polars .str.contains 默认 literal=False(也是正则),但是"特殊字符"的处理稍有差异。我们有一个 .str.contains('user.profile') 的检查,Pandas 把它当正则("user 任意 profile"),Polars 当正则("user 任意 profile"),看起来一样但实际...我们当时是想 literal 匹配"user.profile"。修法:明确传 literal=True。

结果对比:6 张报表全部一致

代码量减少 70%,这是 Polars Expression API 的副产品——它让一段逻辑更紧凑、更可读。

沿途学到的几条 Polars 实用经验

什么场景仍然选 Pandas

Polars 不是万能。我们的判断:

不需要"全切"——可以 ETL 用 Polars,后期分析用 Pandas。Polars 提供 .to_pandas() 转换,两者可以共存。

决策树:面对一个新数据处理任务该选什么

这棵树后来嵌进了数据工程团队的 PR 模板:任何新增数据 pipeline 的 PR,作者必须在 description 里说清楚走了哪条分支,以及预估的资源占用。这个小改动让团队对"工具选型"的纪律性提升一个量级——以前是"用 Pandas 写完看跑得动就 merge",现在是"先估数据量再选工具"。code review 也因此变得更有抓手,新人入职第二周就能跟着这棵树做出合理选型,不再凭"我熟悉 Pandas"做决策。

6 天里被否决的方案

每条否决都让我们更清楚"真正要修什么"。最后选定的"Polars Lazy + streaming + 单机"既是技术最优,也是组织成本最低——所有改动都在 ETL 层,基础设施不动。后来产品和老板问"为什么不上 Spark 一劳永逸",我们直接甩这张表 5 分钟说服全场。这种"否决记录"在长期来看比"选定方案"价值还大。

整体效果 + 长期收益

缩机器规格从 64GB 到 8GB 这一项是最直接的收益——意料之外的是,这台机器原本承担多个夜间任务,迁完后释放出大量算力,我们顺手把另外 3 个 ETL 也合并到这台机器跑,集群层面省下 2 台机器的位置,K8s 资源利用率从 51% 提到 73%。一次 6 天的深度重写省下的钱够团队全员去一趟 PyCon,这种 ROI 在数据工程项目里很少见。

认知更新:对 Python 数据生态的 4 个新认知

1. "工具的舒适圈"是工程团队最大的隐性成本。我们因为团队都熟 Pandas,在它上面又"优化"了两年——这两年的工程师时间 + 云成本 + 半夜被叫起的士气损失,远超一次性切 Polars 的代价。识别"是不是该换工具"的信号是:同一个性能优化连续 3 次只能挤出 10-20% 收益,这说明你撞到了工具的天花板,不是工具的使用方式问题。这个判断标准后来成了我们团队的"工具止损线"。
2. Rust 在数据 / 工程领域的崛起是真实的趋势。Polars(Rust 替代 Pandas)、uv(Rust 替代 pip)、Pydantic v2(Rust 重写核心)、ruff(Rust 替代 black + isort + flake8)、Turbopack(Rust 替代 Webpack)——2026 年的事实是"Python 接口 + Rust 内核"成了高性能 Python 库的标准架构。这不意味着 Python 没用,Python 仍是最好的 glue 层和 API 层,只是"运行时瓶颈用 Rust 写"成了常识。如果你的项目有"跑很慢但只能用 Python"的部分,先看看有没有 Rust 等价库——大概率有。
3. "内存全量加载"是大数据处理最贵的反模式。Pandas 默认就是全量加载,这在小数据上无感,在大数据上是必死的设计——因为内存峰值随数据量线性涨,而你买的机器内存是固定的。Polars 的 streaming 模式从设计上把"内存峰值"和"数据量"解耦,这是工程上更可持续的思路。任何处理 GB 级以上数据的代码,都要问自己"这是 streaming 的还是全量的"——这个问题问得早,后期省心 10 倍。
4. "双跑验证"是数据迁移的唯一安全做法。这次切 Polars 之所以没出 incident,关键是花了 1 天用样本数据双跑两版代码,逐字段对比,发现 7 处差异全修完才上线。如果直接切,3 张报表数据会悄悄错——下游 BI 分析师可能几周后才发现,溯源回来损失巨大。"双跑对比"听起来麻烦,但比"事后追责"便宜 100 倍。我们后来把"任何核心数据 pipeline 重写必须双跑验证"写进 SRE 规范,半年下来挡掉 4 次潜在 data quality 事件。

第三个心得是关于"基准测试的真实性"。Polars 官网 benchmark 跑的是 TPC-H 这类标准数据集,在我们真实业务 schema 上跑出来的提速比官方数字还要好——主要原因是我们 ETL 里有大量 groupby + 多列 agg,这种操作 Polars 的并行优势特别明显。"官方 benchmark 快"和"你的业务 benchmark 快"是两件事,但 Polars 是个少有的"业务 benchmark 比官方更快"的库,这给了我们极大信心继续推广。其他工具选型一律按"自己业务真实数据上跑一遍"为准,挡掉过至少 3 次"看 benchmark 漂亮生产慢爆"的坑。

第四个心得:"修这个任务"和"修这类任务"是两件事。原本计划重写完这个 ETL 就收工,后来主动扫了公司所有数据 pipeline,挖出 5 个有类似 Pandas 性能隐患的任务。一次重构的真正价值不是修当下,是把同类问题在它们爆雷前都摸出来。这种"主动扫雷"耗时大约是重写一个 task 的 2 倍,但避免 5 次类似性能事故 + 5 次半夜值班——ROI 极其划算。我们后来在数据工程团队设了固定流程,每次 P1 / P2 性能事故复盘后必须做"同类扫雷",半年下来主动避免了 12 次潜在事故。

立的《Python ETL 选型与迁移纪律》

• 新建 ETL 默认 Polars(数据量 > 100MB),Pandas 仅用于小数据探索和 notebook 分析。
• 用 Lazy + streaming,scan_* 和 sink_* 是默认操作,collect 只在必要时(交互式探索)用。
• Polars 迁移必须双跑验证,新老两份代码在样本数据上跑,逐字段对比,差异 0 才允许切。
• 留意 7 个迁移坑:null 处理、to_datetime 严格性、Categorical 排序、groupby 顺序、nunique null、int 除法、字符串 contains。
• Polars 任务的资源要重新评估:可以大幅缩小机器规格,但要预留 streaming buffer 余量。
• ETL 必须有耗时和数据量监控,异常波动(单次耗时翻倍 / 数据量陡升)自动告警。
• 数据 schema 必须显式声明(不依赖 Polars 推断),避免上游字段变化导致 silent 类型转换。
• 每个 ETL 必须有"幂等性 + 重跑能力",失败后可以从某个 checkpoint 重启。

给读者的几条自查清单

1. 你的 ETL 跑多久?用多少内存?如果超过 30 分钟或内存 > 4GB,大概率值得迁 Polars。
2. 用 cProfile 跑你的 ETL,看哪个函数占大头。如果是 pd.read_* / df.groupby / df.merge 占了 80%+,Polars 迁完后会有大幅提升。
3. 抽 1% 样本数据,用 Polars 重写 ETL 的核心几步,对比和 Pandas 输出。先看数据对不对,再看速度。
4. Polars 重写时,注意 null 处理 / 类型 / 顺序 / nunique 等 7 个坑,这些是数据语义差异,容易 silent。
5. 把 ETL 的处理时间和内存峰值加进监控,长期 trend 是衡量"数据基础设施健康度"的关键指标。
6. 如果 ETL 还在跑 Pandas + Dask 这种"用多机并行 Pandas"的方案,认真考虑 Polars 单机够不够——单机 Polars 经常比 Dask 集群快还便宜。
7. 新建 ETL 时,如果有团队成员不熟 Polars,做一次内部 workshop(2 小时基本能上手),投入产出比很高。

这次重写让我对"工具选型"有了新的认知:"用熟悉的工具"在中小规模问题上是对的,在大规模问题上是错的。Pandas 在 1.2 亿行 + 50GB 数据这个尺度已经不是"慢一点",是"根本不该用",但我们因为团队都熟 Pandas,在它上面又优化了两年才下决心换。这种"工具的舒适圈"是工程团队最常见的陷阱之一。

另一个心得是Rust 在数据 / 工程领域的崛起是真实的趋势。Polars(Rust)、ripgrep(Rust)、uv(Rust)、Turbopack(Rust)、Biome(Rust)、Tauri(Rust)、tantivy(Rust)——这些 Rust 写的工具普遍比 C++ / Go / Python 的等价物快 5-10 倍,内存少 50-80%。Python 数据生态正在被 Rust 替代实现层(Polars 替代 Pandas,uv 替代 pip,Pydantic v2 用 Rust 重写核心)。这不意味着 Python 没用,只是"运行时的瓶颈用 Rust 写"成了 2026 年的事实标准。

如果你的项目有"跑很慢但又只能用 Python"的部分,先看看有没有 Rust 写的等价库——大概率有,大概率比你想的快得多。我们后来在团队周会上专门拉了一份"可能值得换 Rust 实现"的清单:json 解析换 orjson、正则换 regex-rs 绑定、HTTP 客户端换 httpx + Rust backend、序列化换 msgspec——光这几项替换下来,半年内累计为团队的服务省下约 30 percent 的 CPU 时间和 25 percent 的内存占用。

最后再补一个工程文化层面的反思:这次 ETL 触发重写之前其实有过很多次小信号——值班同事在群里抱怨过"凌晨又被叫起来重跑"、新人 onboarding 时问过"为什么这个任务跑这么久"、运维同学定期 review 资源占用时标红过这台机器,每次大家都用"还能跑"、"是历史代码"、"先这样"绕过去。所有大重构机会都有它的"预热信号",区别只在团队有没有把它当回事。我们后来在工单系统里加了"小信号月度复盘"机制——把过去 30 天的所有低优先级告警 + 值班抱怨 + 新人提的"为什么这样"问题集中拉一遍,挑出可能值得深挖的提前修。半年下来这个机制至少提前避免了 3 次类似量级的性能问题,投入产出比远超事后排查。希望读到这里的你也能在自己团队里建立类似的"小信号雷达",别再让一个看似无害的 Pandas 写法把团队 2 年后的某个凌晨值班毁掉。

—— 别看了 · 2026