上周帮一个零售团队处理他们的销售流水一份两百多兆的Excel文件打开就卡等了三分钟才看到那一百多万行数据。列一多、表一宽Excel直接进入半瘫痪状态。我当时的处理方案很简单把数据丢给Pandas用Python脚本批量清洗、聚合、输出汇总表十分钟不到跑完还顺手给他们做了两张趋势图。今天这篇就是想把这条从Excel到百万级数据分析的路尽量完整地拆开讲清楚——Pandas处理入门到底要学什么哪些操作是高频刚需数据量上来之后又有哪些坑等着你。这不是一篇只讲API的入门文而是我实际处理过大几十个数据文件之后沉淀下来的经验。它适合两类人一种是每天泡在Excel里做报表、但明显感觉Excel已经扛不住数据体量的同学另一种是刚学完Python基础、想知道怎么用它来正经做数据分析的初学者。看完之后你至少能明白一件事为什么Pandas能撑起百万级数据分析这个场景以及你该从哪里下手。1. 为什么不建议继续用Excel硬扛大数据先声明一点我不是让你把Excel丢掉。Excel的交互体验、可视化、日常表格操作至今仍然是办公场景里效率最高的工具之一。但当你手里的数据开始往几十万行、上百万行走的时候Excel的两大问题就会暴露得淋漓尽致。1.1 Excel的卡顿源头在哪里Excel的卡顿核心在于它的内存管理方式。一个单元格只要有内容哪怕只是一个空字符串它都要为公式计算、格式渲染、条件格式预留资源。你想想Excel里一个100万行的表格有多少个单元格光指针和元信息就要吃掉好几个GB内存。更致命的是Excel对大数据执行筛选、排序、透视表这类操作时是整表重算的。你对一份百万行的表做个数据透视后台要重新索引全部数据CPU和硬盘都在被反复压榨表现出来就是转圈、无响应。我印象特别深的一次是处理一份将近120万行的订单明细列数不算多大概15列但其中夹杂着日期、时间、文本备注、金额字段。Excel打开花了40多秒之后随便点击一下都需要两三秒才有反应想按客户维度做个汇总直接卡死弹窗Excel无法完成此操作。最后我导出CSV用Pandas读进来整个数据集的读取、清洗、透视、导出一条管道下来7秒跑完。这不是Pandas特别神奇而是它的设计本来就是为了处理这种体量。1.2 Pandas处理大数据的三点优势Pandas相比之下有几个天然优势对比维度ExcelPandas内存占用方式每个单元格都带格式元信息开销巨大按列存储每列同一类型紧凑得多计算方式界面操作触发整表重算向量化运算按列批量计算性能高一个量级可重复性步骤靠人记改了数据要重做脚本写一次永久复用怎么清洗的清清楚楚规模上限百万行已是极限再往上直接崩处理千万行以内都很常见极限取决于机器内存扩展能力缺乏与Python生态协作能力机器学习、可视化、数据库对接随手就能接其中最核心的一份优势是按列存储。Pandas的DataFrame本质上是个列优先的数据容器你做计算的时候是整列整列地批量运算底层用的又是C语言实现的numpy数组所以同样是对100万行数据求平均Pandas只需要一次性扫过这一列Excel却要逐单元格去解释公式。这也是为什么能跑百万级的关键所在。1.3 什么样的数据量适合用Pandas说句实在话数据量在5万行以内我自己也经常用Excel处理没必要非上代码。但一旦你的数据规模往50万行靠拢或者你需要每天、每周重复做同一套汇总逻辑那Pandas的脚本化优势就体现出来了。代码写一遍以后的数据丢进去跑就行不用再拿鼠标点半天。另外还有一种情况也建议用Pandas——数据需要跨表关联。Excel里做多表匹配主要靠VLOOKUP两张表都很大时VLOOKUP慢得令人绝望而且跨文件引用极易出错。Pandas里一个merge函数就解决了一会儿我细说。2. 入门阶段必须掌握的五个DataFrame操作很多初学者学Pandas最大误区是把API当单词表背。看着文档里几百个方法今天学drop_duplicates明天学fillna学完就忘。我的建议很直接你的真实场景只需要从几个高频操作开始。2.1 读入数据是第一步也是第一个坑一切从读数据开始。日常最常见的是这两个函数import pandas as pd # 读Excel df pd.read_excel(sales_2024.xlsx, sheet_name订单明细) # 读CSV df pd.read_csv(sales_2024.csv, encodingutf-8)如果你是从Excel转过来的注意两个细节。第一CSV和Excel文件读进来之后的DataFrame完全一样但对百万级数据来说CSV的读取速度通常比xlsx快很多因为xlsx本质是个压缩的XML文件读取时要层层解包解析CSV就是纯文本逐行扫。第二编码问题非常容易踩到read_csv的时候如果遇到中文乱码先试试encodinggbk或者encodingutf-8-sigWindows出品的CSV多半要转一下编码。还有一个入门阶段容易忽略的参数是usecols。假如原始文件有30列你只需要其中的5列那就别把30列全读进来占内存df pd.read_csv(big_sales.csv, usecols[订单号, 日期, 金额, 客户ID, 渠道])这个习惯在数据量小的时候看不出来到百万级以后能少读一半内存。2.2 先摸家底info、head、describe这一套体检动作拿到数据之后不要急着清洗先做体检。我的固定操作是三连print(df.head()) print(df.info()) print(df.describe())head让你看前五行长什么样用来判断列名是否规范、数据长得是否像你预期。info输出的东西更有价值每一列的字段类型、非空数量、内存占用都在里面了。你知道吗info最后会显示一行memory usage: 156.8 MB这一行是判断你后续需不需要做内存优化的关键指标。如果你的数据读进来只有十几万行却占了几百MB那大概率是列的类型没优化后面我专门讲。describe适用于数值列会告诉你每列的均值、标准差、最小值、四分位数、最大值。这一段跑完哪些列有离群值哪些列明显异常心里基本就有数了。2.3 筛选、分组、聚合从自然语言到一行代码数据分析里最高频的三个动作就是筛选、分组、聚合。举个例子你脑子里想的是华东区、渠道为线上的订单里每个月的总销售额是多少。这句话翻译成Pandas就是三行filtered df[(df[区域] 华东) (df[渠道] 线上)] monthly_sales filtered.groupby(filtered[日期].dt.to_period(M))[金额].sum()第一行筛选用布尔条件组合。注意Pandas里多个条件必须用连接每个条件都要加括号否则报错。第二行按月份分组这里用到了dt.to_period(M)意思是把日期列转成月份周期相当于把日期按月份归类。很多人第一步就栽在分组上是因为忘了groupby之后对象的类型会变成DataFrameGroupBy不再是普通的DataFrame。你必须对它再做聚合操作sum、mean、count、agg才能得到结果。如果你要同时算多个指标比如既要总销售额又要订单数就配合agg使用result filtered.groupby(filtered[日期].dt.to_period(M)).agg( 销售额(金额, sum), 订单数(订单号, nunique) )这里订单数用nunique意思是去重计数如果你直接count它会数一下这个组里有几条记录而不是多少个不同订单。这个区别在电商数据里特别容易造成报表失真我在实际交付中反复跟业务团队确认过这个口径的差异。2.4 排序和去重永远记住你处理的是一张表排序用sort_values去重用drop_duplicatestop_customers df.sort_values(销售额, ascendingFalse).head(10) unique_orders df.drop_duplicates(subset[订单号])这两个操作很简单但实际场景里有个细节容易出错drop_duplicates默认保留第一条重复记录如果你想保留最后一条要加keeplast参数。另外如果原始数据里订单号本身存在空值去重之前得先确认一下空值占比避免把大量真实订单误删。空了的数据不算重复但Pandas默认也会把它当作重复项之一保留一条处理的时候要留意。2.5 缺失值处理先搞清楚为什么缺再决定怎么填缺失值处理看起来简单其实最考验你对业务的理解。处理手段无非就几种删除、填0、填均值、前向填充。但选哪一种取决于这个字段为什么为空。举个例子订单金额为空那大概率是异常单需要谨慎。用户年龄为空你可以考虑用该渠道的平均年龄填充。库存表里某个商品的补货日期为空可能只是因为它还没有排期跟异常没有关系。我在实战中的固定做法是先跑一下缺失值统计missing_ratio df.isnull().sum() / len(df) print(missing_ratio[missing_ratio 0])然后根据缺失比例和字段含义分列处理绝不无脑fillna一把梭。对数值型字段最常见的方案是fillna(0)但你要想清楚0是否是一个有业务意义的填充值。3. 百万级数据真正要命的三个性能瓶颈到了百万行这个量级你会发现普通的Pandas代码还能跑但就是慢。明明一个很简单的操作要等好几分钟这就是性能瓶颈。我踩过的三个最大的坑今天一次性说清楚。3.1 dtype是内存大户object类型会吞掉你的内存很多人读入数据之后从来不关心列类型。默认情况下Pandas会把文本列都识别为object类型而object类型在内存里存的其实是字符串指针比数值类型昂贵得多。我做过一次实测一个90万行的数据里面有三列是分类文本比如华东/华北/华南这种如果保持object类型光这三列就占了大约120MB内存把它们转成category后直接降到5MB左右内存减少九成以上。所以大数据的第一个优化动作永远是类型压缩。常用的招数df[区域] df[区域].astype(category) df[金额] df[金额].astype(float32) df[订单数] df[订单数].astype(int32)category类型适合那种重复值很多的列比如区域、渠道、产品大类这几个列在百万行数据里往往只有几十种取值用category再合适不过。数值列则用更小的子类型替代默认的float64和int64哪怕float32在精度上损失一点点做汇总分析完全够用。每次做完类型转换看一眼df.info()的memory usage你会直观感受到内存从几百MB掉到几十MB这会给后续所有操作腾出大量空间。3.2 循环是万恶之源向量化才是Pandas的舒适区新手最容易写的慢代码就是遍历每一行# 千万别这么写100万行会让你等到怀疑人生 for i in range(len(df)): if df.loc[i, 金额] 1000: df.loc[i, 等级] 高 else: df.loc[i, 等级] 低这行代码的逻辑没错但对100万行数据来说循环加loc逐行定位双重减速跑完起码要十分钟起步。Pandas的设计思想是向量化——对整列一次性操作底层用C语言的循环替你跑速度是一百倍以上的差距。同样的逻辑用向量化一行搞定df[等级] np.where(df[金额] 1000, 高, 低)如果条件复杂多个列参与判断可以用np.selectconditions [ df[金额] 5000, df[金额] 1000, df[金额] 0 ] choices [高, 中, 低] df[等级] np.select(conditions, choices, default未知)有很多人问我什么时候真的要用循环我的答案是当你需要逐行依赖前一行计算结果的时候比如计算累加收益、持仓状态机这类有顺序依赖的业务循环才不可避免。此时你可以考虑用numba加速或者尽量将这类操作拆解成累计函数。大多数想用循环的场景其实是没找到对应的向量化函数先找找不到再循环。3.3 groupby和merge在数据量上来之后的正确姿势groupby在百万级数据上如果直接跑通常问题不大但如果你在这个基础上又挂了多个agg还要排序再合并回原表那计算量会指数级上升。我常用的原则是能少合并就少合并groupby的结果如果只是最终报表就不concat回原表保持分组之后只输出结果。merge同理。两张百万级表做关联默认用howinner就行不要没事就搞howouter外连接会在匹配不到时产生大量空行内存和行数都会暴涨。另外merge之前建议先对被关联列做类型统一比如一边是int64一边是object即使内容一样merge也会判定无法匹配。我吃过这个亏客户ID一侧是从Excel读的数字被读成了float64一侧是字符串看起来都是10086merge出来全是NaN排查了很久才发现是类型不一致。所以merge前的类型检查要养成习惯用df.dtypes排查一遍再操作。4. 一次完整的百万行数据实操复盘理论说了不少我们干脆从头到尾跑一个完整案例。我构造一个模拟场景一份某电商平台的交易流水大约120万行包含订单号、用户ID、区域、渠道、商品ID、销售日期、销售额、成本、数量、优惠金额这10列。目标是算出每个区域每个渠道的月度销售额、订单量和利润。4.1 先做环境准备与数据体检我会先准备环境import pandas as pd import numpy as np df pd.read_csv(sales_120w.csv, encodingutf-8, parse_dates[销售日期]) df.info()这里parse_dates参数直接把日期列解析成datetime类型不要等后续再转换。info出来之后看内存占用我模拟的结果是大概980MB这个体量在普通配置的电脑上已经有点吃紧了。于是做类型压缩df[区域] df[区域].astype(category) df[渠道] df[渠道].astype(category) df[销售额] df[销售额].astype(float32) df[成本] df[成本].astype(float32) df[优惠金额] df[优惠金额].astype(float32) df[数量] df[数量].astype(int8) df[利润] (df[销售额] - df[成本] - df[优惠金额]).astype(float32)此时再跑一遍df.info()内存占用已经掉到差不多150MB这个数字对后续计算就很舒服了。4.2 深度清洗去重、缺失值、异常值三件套清洗环节是重头戏先统计缺失再处理重复和异常print(df.isnull().sum())假设发现优惠金额有2.3万行缺失这通常是订单没有优惠填充0是合理的df[优惠金额] df[优惠金额].fillna(0)再看订单号去重跑一个数量对比before len(df) after len(df.drop_duplicates(subset[订单号, 用户ID])) print(f去重前后差异: {before - after})如果差异显著说明有大量重复记录这些通常来自同一个用户重复下单产生的多条流水在订单明细分析里属于正常情况不需要删除。但如果同一订单号出现多次且你统计的是订单量这种口径就必须去重后再统计否则订单量会虚高。异常值这一块我习惯跑一个describe看分布print(df[[销售额, 数量, 利润]].describe())如果发现销售额最小值是负数或者利润出现了极度异常的极大值要单独抽查这些记录判断是促销冲正还是数据录入错误。模拟数据里我设定了少量销售负值退款单这类记录在汇总日常销售额时应该剔除但它们对退款分析有价值所以我会单独建一张退款表而不是简单删掉。4.3 管道化处理把清洗逻辑封装进函数清洗步骤一多临时写在脚本里就很乱。实际操作中我会把整套清洗封装成一个函数用pipe一次性串起来def clean_sales_data(df): df df.copy() df[优惠金额] df[优惠金额].fillna(0) df df[df[销售额] 0] df[利润] df[销售额] - df[成本] - df[优惠金额] df[销售日期] pd.to_datetime(df[销售日期]) return df df_clean ( pd.read_csv(sales_120w.csv, encodingutf-8) .pipe(clean_sales_data) )这么做的最大好处是以后每周收到新数据只需要重复跑一遍管道不会因为少执行某一步清洗而造成结果前后不一致。数据交付里最忌讳的就是这次我手动多过滤了一个条件这类操作结果下周对不上账。4.4 按区域渠道汇聚月度核心指标清洗完之后做汇总这是百万级数据里最典型的导出需求result ( df_clean .groupby([ df_clean[销售日期].dt.to_period(M), 区域, 渠道 ]) .agg( 销售额(销售额, sum), 订单量(订单号, nunique), 利润(利润, sum) ) .reset_index() ) result.to_csv(月度区域渠道汇总.csv, indexFalse, encodingutf-8-sig)这段代码在120万行数据上跑实测大概用了不到5秒。跑完之后result大约几百行这已经是可以直接交给业务方看的报表级输出了。这里有一个细节很重要就是groupby里分组键用了df[销售日期].dt.to_period(M)这是一个Series而不是列名字符串这样写是允许的而且能把日期直接按月归类。如果按月分组的场景很常见更推荐提前把月份字段单独生成一列这样后续写代码更清晰df_clean[月份] df_clean[销售日期].dt.to_period(M)4.5 结果校验别相信一次跑通的结果跑完汇总之后千万不要直接交差一定要做结果校验。最稳妥的校验方法是抽一个你熟悉的维度跟原始数据对齐。比如拿华东区域线上渠道某一个月的数据手工用Excel筛选原始文件算一下总销售额跟你代码输出的结果对一下。对不上的情况绝大多数是过滤条件不一致比如你有没有把退款单算进去有没有漏掉空区域的分组。我另外的习惯是在脚本里做两层自动校验# 校验1汇总后的总销售额等于过滤后的总销售额 assert abs(result[销售额].sum() - df_clean[销售额].sum()) 0.01 # 校验2每个分组的行数占比要合理 group_counts df_clean.groupby([ 区域, 渠道, 月份 ]).size() assert len(group_counts) len(result)这两层校验成本极低但你有没有做这步决定了交付的质量是看起来对还是真对。数据量越大的时候越要信不过自己的手要信校验逻辑。5. 两年里踩过最深的四个Pandas坑坑这个东西不真正踩一遍光看文档是记不住的。作为一个被坑过无数次的人我挑四个最伤的例子按惨痛程度排个序。5.1 inplaceTrue的虚假安全感刚学Pandas时特喜欢写df.dropna(inplaceTrue)总觉得加个inplace参数就万事大吉不用重新赋值。但实际上inplace在很多方法里是有隐患的。第一Pandas 2.x开始已经在官方文档里不推荐这种用法未来有可能被移除。第二inplace依赖函数内部修改原对象某些方法实际做的是复制一份再修改再回填根本没有省内存。第三链式调用的场景里inplace经常失效——你对一个切片执行inplace操作改的只是副本原DataFrame纹丝不动。我现在一律写成显式赋值df df.drop_duplicates(subset[订单号])这样代码意图明确debug时也方便打断点看中间状态。5.2 链式赋值引发的SettingWithCopyWarning链式赋值是我见过最隐蔽的Bug来源。和inplace类似问题出在你对切片的理解。下面这段代码df[df[金额] 100][折扣] 0很多新手以为这是把金额大于100的那几行折扣改成0实际上Pandas会警告你这可能是在试图修改一个副本。因为df[df[金额] 100]产生的是一个视图或副本到底改没改到原DataFrame取决于内部优化你不该依赖它。正确的写法永远是用.locdf.loc[df[金额] 100, 折扣] 0记住这条规则就好了在DataFrame里做条件修改一律df.loc[条件, 列名] 新值不要用链式括号。养成这个习惯之后我再没遇到过SettingWithCopyWarning。5.3 索引没有resetgroupby之后悄悄变了样groupby之后忘了reset_index是我看别人代码时最常见的问题。groupby的结果行数取决于分组键的取值组合数但索引是这些分组键的值你要是还想再继续跟其他DataFrame合并或者做进一步筛选就会发现索引乱七八糟对不上。如果你在groupby后直接执行to_excel你会发现左边多了一列看不到名字的索引。正确的姿势是想清楚这个中间结果是要继续参与计算还是作为最终报表。如果是中间结果分组之后加个reset_index()把分组键变成普通列后面怎么操作都不慌。这也是为什么我对agg结果的固定习惯是马上reset_index()。5.4 read_excel在大型Excel文件上的隐藏慢速很多人遇到大文件第一步还是pd.read_excel殊不知这可能是最慢的读法。Excel文件的底层是XML压缩格式读取时要实时解压和解析速度远比CSV慢。我测过一个约80MB的xlsxread_excel用了30多秒同样数据导出成CSV后read_csv只要5秒。如果是100MB以上的Excel差距还会更离谱。所以我的工作流是如果数据源是大型Excel文件第一步先用Excel另存为CSV或者用脚本把xlsx批量转成csv再做Pandas处理。如果实在只能读Excel可以考虑用openpyxl引擎配合usecols和nrows参数先只读一部分看看结构全量读取留到最后。还有一个相关的坑read_excel默认会读取整个sheet的所有行和列如果sheet里有大量空行Pandas也会傻乎乎地读进来再丢掉白白浪费内存和读取时间。加sheet_name参数指定要读的sheet能省则省。写在最后的一点个人经验我刚开始用Pandas处理百万级数据时心态是代码能跑就行后来才意识到干净、可读、可复现的脚本比跑得快重要得多。因为数据分析工作真正的交付物不是那几张报表而是如果有人想复现你的数据结论能不能照着你的脚本一步步跑出同样的结果。哪怕你只是给自己用一周之后回看你也会感谢当初写了清晰注释的自己。还有一个容易被低估的习惯每一步处理完都打印一下行数和shape数据从120万行变成90万行这一步到底是因为去重还是因为过滤退款心里要有数。做数据分析最怕的不是报错而是结果看着挺合理但实际上有偏差那种错误藏得最深也最难查。Pandas这条路入门不难难的是数据量上来之后那种感觉自己会用、但一跑就慢、一慢就不知道该优化哪里的迷茫。我的建议是先跑通再想性能最后再优化内存。别一上手就背一堆优化技巧等你真遇到那个让你干等10分钟的百万行文件时你自然会回来翻这篇。