你如果和数据打交道超过几年大概率见过这个场面PM 丢过来一个 3GB 的 CSV说“你跑一下看看”。你打开编辑器习惯性敲下pd.read_csv10 秒过去光标还在转任务管理器里内存曲线开始抬头再过一会儿内存红了服务器内核直接被杀。我上个月处理一份 1.2 亿行、23 列的日志类数据时正是被这一步干掉的。后来换用 Polars同一个统计任务在 16GB 内存的笔记本上能跑完不用手工分块也没有 MemoryError。Polars 可能很多 Pandas 老用户已经听过但真正敢在核心流程里替换的其实不多。简单说Polars 是一个底层由 Rust 编写的 DataFrame 库它的 Python API 和 Pandas 长得有点像但执行方式完全不同采用 Arrow 列式内存默认多线程还内置了惰性查询优化器。正是这几个特性让它能在单机上把亿级数据处理这件事从“不可能”变成“可接受”。这篇文章不准备写官方文档式的介绍我会从自己在实际项目里遇到的性能瓶颈、Polars 底层为什么快、Pandas 到 Polars 的迁移语法、一个 1 亿行级别的完整案例以及迁移过程中踩过的坑这几个方面展开。适合正被 Pandas 内存问题折磨又不想为了一次分析就去搭 Spark/Dask 集群的人读。1. 内存爆掉那晚我重新审视了 Pandas 的边界先说明一点Pandas 在亿级数据上变慢不完全是因为 Python 慢而是因为它从设计上就不是为“单机全量处理超大 DataFrame”准备的。Pandas 的定位一直是交互式数据分析它把二维表格操作做得足够顺手读 CSV、筛选、分组、画图非常自然。可一旦数据量级到了几千万甚至上亿行这套模型的短板就会集中爆发。1.1 Pandas 不是变慢了而是它从来没为这种体量设计过Pandas 底层大量调用 C 和 NumPy热路径上的纯向量化操作并不算慢。真正慢的是执行模型本身。第一大多数 Pandas 操作是单线程执行的。虽然底层部分函数会释放 GIL但整个 DataFrame 运算是一步一步串联的“读数据 - 清洗 - 筛选 - 分组聚合 - 排序”这个链条里每一步都要等前一步全部跑完。你机器上的 8 核 16 线程大部分时间只有一个核在忙。第二中间副本太多。Pandas 的很多操作会生成完整的新 DataFrame。filter生成一份assign生成一份merge往往要生成好几份中间结果。行数越大这些临时对象对内存的压力就越接近灾难。很多人在处理 2GB 的 CSV 时会发现内存占用冲到 8GB、10GB不是因为数据本身大而是因为每个中间步骤都在复制数据。第三object类型的列很容易让内存开销失控。当一列里混着字符串、None、Python 对象时Pandas 会退化成存指针数组每个单元格指向一个独立的 Python 对象。这种布局不仅在内存上非常浪费还会让 CPU 缓存的局部性变得极差——数据在内存里东一块西一块读取时要到处跳。再加上 GIL 对 Python 回调的限制一旦代码里出现apply或者逐行循环性能就会直接掉回“解释一行执行一行”的水平。这些因素叠加起来才是 Pandas 在亿级数据上吃力的真正原因。不是说 Pandas “垃圾”而是它的设计目标里根本没有“单机并行处理超大 DataFrame”这一项。1.2 为什么不直接无脑上 Spark 或 Dask遇到 Pandas 跑不动很多人第一反应是上 Spark 或 Dask。我也短暂试过但很快就发现大多数场景并不适合。Spark 是为了集群而生的它真正的优势在于分布式存储和处理但代价是要管理集群、驱动程序、executor 调度还有一堆序列化和网络通信的开销。如果你只是要在一台机器上分析一份几十 GB 的文件Spark 的启动时间可能比数据处理时间还长。Dask 作为 Pandas 的并行化