★ FEATURED ARTICLE 1. 数据分组这件事为什么值得单独拎出来讲做数据处理的人大概都有过这样一段经历拿到一张几万行的表格表面上风平浪静真开始按类别汇总、按用户聚合、按时间段统计的时候代码就开始变成一团乱麻。循环套循环、字典往列表里塞、临时变量满天飞最后自己回头看都得花十分钟才能理清逻辑关系。我刚入行那会儿就是这么干的一个按部门统计销售额的需求硬是写了四十多行嵌套循环跑起来还慢得让人怀疑人生。后来接触到groupby这套思路才意识到分组本质上不是写循环而是拆解—计算—重组三个动作的组合。Python 里 pandas 的groupby之所以被称为数据处理的分水岭就是因为它把这个过程抽象成了几乎不用动脑的一行链式调用。原始数据进来按某一列或多个列切块每块跑一遍聚合函数最后把结果拼回一张整齐的表。听起来简单但真正吃透它的分层机制、聚合粒度、索引行为才是效率能不能翻倍的关键。这篇文章想解决的就是这件事groupby究竟在内部做了什么、什么场景该用它、它的坑藏在哪、怎么写出既快又不容易出错的聚合代码。适合两类人看——一类是还在用 for 循环硬拆数据的朋友另一类是会用但偶尔被索引和聚合结果绕晕的人。不需要你有很深的算法背景只要能写基础的 pandas 代码下面的内容就能直接用上。我会把每个关键选择背后的理由讲清楚包括参数怎么定、性能差在哪、踩过的坑是什么样尽量让你看完就能在自己的数据上跑起来。2. 先把思路捋顺分组聚合到底在解决什么问题2.1 从手工作业到流水线的思维转变手工分组和groupby分组的差别说白了就是手工作坊和流水线的差别。手工做法是遍历每一行判断它属于哪一组找到对应组的容器把值塞进去再对每个容器单独算一次。这个流程在数据量小的时候没问题逻辑也直观但一旦数据量上去问题就暴露了每次查找组容器都是线性扫描时间复杂度直接飙到接近 O(n²)而且代码可读性极差改动一个统计口径就得整体重写。groupby的做法不一样。它先对分组键做一次扫描建立一个键 → 行位置的映射关系然后基于这个映射做块级别的计算。这个设计的关键在于把重复的查找成本摊销掉了不管你有多少个统计指标分组键只需要解析一次后续所有聚合都复用同一套分组结果。这就好比先把一堆文件按标签分好类装进不同抽屉之后无论你要数文件个数、算文件总页数还是找最厚的那份都只需要打开对应的抽屉而不是每次都从头翻一遍整堆文件。理解了这个底层逻辑很多行为就解释得通了。比如为什么groupby之后直接打印看不到数据、为什么聚合结果的索引会变成分组键、为什么某些写法比另一些快一个数量级——全都是这个先建映射、再按块算的模型推导出来的。2.2 拆解—计算—重组三段式的固定骨架拆解—计算—重组这个说法不是修辞它对应的是groupby操作的三个真实阶段理解清楚对排查问题特别有用。拆解阶段引擎根据你指定的键把数据切成若干个子表。这里有个容易被忽略的细节切出来的子表并不是数据的物理副本而是一种视图性质的引用。所以如果你在分组后对子表做了原地修改可能会影响到原数据这类问题在链式调用里尤其隐蔽。计算阶段对每个子表施加聚合函数。这里的函数可以是内置的求和、均值、计数、最大值也可以是自定义的。内置函数走的是向量化路径速度快自定义函数走的是逐块调用 Python 函数的路径速度会明显下降这个差异在实际项目中非常关键。重组阶段把每块的计算结果按分组键拼回一张新表。默认情况下分组键会成为结果的索引这就是为什么聚合之后你经常需要reset_index()把键变回普通列。这个默认行为有它的道理——保持键和值的一一对应关系但在导出报表、拼接其他表的时候忘了重置索引就会引发一堆对齐问题。提示把这三个阶段记在心里遇到结果形状不对索引乱掉某列消失了这类问题先判断是哪个阶段出了偏差排查效率会高很多。2.3 哪些场景它真的是最优解不是所有分组需求都适合groupby明确边界能省不少时间。以下这几类场景它几乎是首选场景类型典型需求为什么适合分类汇总按地区、渠道、品类统计销量与金额分组键基数适中聚合逻辑简单链式写法即可完成用户画像聚合按用户统计订单数、消费总额、最近一次时间多指标聚合一次完成避免多轮扫描时间序列降维按日、周、月汇总指标配合时间类型转换后分组天然契合分组内排序取头部每个品类取销量前 3 的商品配合排序与截取表达简洁缺失值填充按组填充均值或前向填充组内操作语义清晰避免跨组污染反过来如果分组键的基数极高比如按用户 ID 分组且有几十万上百万个不同值而聚合逻辑又很复杂那么groupby的映射构建成本会变得显著。这种情况下更合理的做法是先做过滤把数据量压下来或者换用更适合高基数聚合的思路。另一类不适合的情况是分组之间需要互相引用结果比如计算每行相对同组均值的偏离度虽然也能用transform做但如果逻辑涉及组与组之间的比较就该考虑别的组织了。3. 核心机制拆解分组键、聚合函数与索引行为3.1 分组键的三种形态与选择依据分组键可以是一列、多列也可以是一个与行数等长的序列甚至是一个函数。这三种形态背后对应不同的使用场景选错形式往往会导致写法别扭或者性能损失。单列键是最常见的df.groupby(category)这种写法语义最直白。适合维度单一、统计口径清晰的场景。多列键通过传入列表实现df.groupby([region, channel])结果会形成多层索引。这里的选择依据是如果你的分析需要先看大维度、再看小维度的层次结构多列键就比多次单列分组更合适因为它一次扫描就能拿到所有组合的结果避免重复计算。但要注意组合爆炸的问题——两个各有 100 个取值的列组合起来就是 1 万个组如果每个组的数据都很少聚合结果的统计意义会大打折扣。序列或函数作为键适合原表里没有现成分组列的情况。比如按数值区间分组可以传一个把数值映射到区间标签的函数按行号分批可以传一个与行数等长的序列。这种写法的灵活性很高但可读性会下降建议在中间步骤里先把分组标签算成一列再分组方便调试和复用。注意用函数做分组键时函数会被应用到索引上而不是值上这是不少人踩过的坑。如果索引不是默认的整数索引结果会和你预期完全不一样。稳妥的做法是先把需要的列reset_index()或者明确指定key参数。3.2 常用聚合函数的性能层级同样是聚合不同写法的性能差异可能达到几倍甚至一个数量级。我把常见的几类按性能从高到低排一下方便你在意的场景里做取舍。第一层内置聚合方法如.sum()、.mean()、.count()、.max()、.min()、.size()。这类方法在底层走的是优化过的 C 实现是性能天花板。能用它们解决的绝不要绕道写自定义函数。第二层.agg()传入字符串名称或名称列表。比如df.groupby(k).agg([sum, mean])。这种写法本质上还是调用内置实现额外开销主要在结果的多层列索引组织上性能依然很好。需要注意的是聚合后列名会变成多层结构取值时要用元组形式或者干脆重命名。第三层.agg()传入字典为不同列指定不同聚合。比如{amount: sum, qty: mean}。这在业务里非常实用因为不同字段的统计口径本来就不一样。性能上比统一聚合略慢但差距不大属于推荐写法。第四层.apply()与.transform()配合自定义函数。灵活度最高性能最差。如果自定义函数里还涉及 Python 层的循环或字符串操作开销会进一步放大。我的经验是先想能不能用内置函数组合出来实在不行再用自定义并且尽量让自定义函数内部也走向量化。写法灵活度相对性能适用场景.sum()等内置方法低最高单一指标的快速聚合.agg(sum)低高需要统一多个指标.agg({col: func})中中高不同列不同口径.apply(自定义)高低逻辑复杂、无法向量化.transform(自定义)高低需要保持原表行数3.3 索引行为最容易翻车的地方聚合之后索引变成分组键这是groupby的默认设计也是新手最容易懵的地方。你会看到原本的列名跑到了索引位置df[category]直接报错取不到值。解决方式有三种各有适用场合。第一种是聚合后立刻reset_index()把键还原成列这是最通用的做法尤其在结果要导出或者要和其他表合并时几乎是必须的。第二种是聚合时加as_indexFalse参数一步到位省掉一次重置操作写法更紧凑。第三种是保留索引但用.loc按层级取值适合需要按维度切片分析的场景。这里有个细节值得单独说as_indexFalse在配合多列分组时行为是稳定的但在某些旧版本里和agg字典结合会出现列顺序问题。所以如果代码要长期维护我倾向于统一用reset_index()行为最可预期也方便加注释说明意图。另一个隐蔽的坑是分组键里含有缺失值。默认情况下dropnaTrue会把键为 NaN 的行直接丢掉而且不报任何提示。如果你的数据里缺失值比例不低聚合结果会莫名其妙偏小。这种情况要么先填充键列要么显式设置dropnaFalse把它们单独归成一组。4. 实操落地从原始表到可用结果的完整链路4.1 环境准备与最小可运行数据先把环境摆好。核心依赖就一个 pandas如果需要处理时间类型再确保 numpy 版本匹配。我一般习惯固定版本避免不同机器上行为漂移。pip install pandas2.1.4 numpy1.26.2造一份贴近业务的最小数据集包含分类维度、数值指标和一个时间字段后面所有示例都基于它import pandas as pd import numpy as np rng np.random.default_rng(42) n 5000 df pd.DataFrame({ region: rng.choice([华东, 华北, 华南, 西南], n), channel: rng.choice([线上, 门店, 代理], n), category: rng.choice([A, B, C, D, E], n), amount: rng.normal(200, 60, n).round(2), qty: rng.integers(1, 20, n), order_date: pd.to_datetime(2024-01-01) pd.to_timedelta(rng.integers(0, 180, n), unitD) }) # 人为制造一些缺失后面用来演示坑点 df.loc[rng.choice(n, 120, replaceFalse), region] np.nan5000 行数据不大但足够体现写法差异。这里特意留了 120 行region为空的记录就是为了后面演示dropna的影响——真实数据里这种脏值几乎必然存在。4.2 单维度聚合把一行链式调用写扎实最基础的用法是按单列分组求和result ( df.groupby(category, as_indexFalse) .agg(total_amount(amount, sum), avg_qty(qty, mean), order_cnt(qty, size)) .sort_values(total_amount, ascendingFalse) )这段代码里有几个值得展开的点。as_indexFalse让分组键保留为普通列后续不用再重置索引。agg里用的是命名聚合语法新列名(原列名, 函数名)这种元组形式好处是聚合一步完成的同时就把结果列命名好了不需要事后rename。这个语法在 pandas 0.25 之后支持现在已经是主流写法了。size和count的区别要记牢size统计组内行数包含缺失值count统计非缺失值的数量。做订单数统计时用size做有效值统计时用count搞混了结果就对不上。排序放在最后而不是聚合之前是因为聚合会改变数据形状先聚合再排序才能拿到按总额排名的效果。如果先排序再聚合顺序信息会在聚合时丢失。4.3 多维度与多指标组合一次扫描拿全结果业务报表往往需要交叉维度。下面这个写法按地区和渠道两个维度分组同时算多个指标cross ( df.groupby([region, channel], dropnaFalse) .agg(total_amount(amount, sum), avg_amount(amount, mean), max_qty(qty, max), order_cnt(qty, size)) .reset_index() )关键参数是dropnaFalse。不加这个那 120 行region为空的记录会被静默丢弃总量对不上而且没有任何报错提示。加上之后缺失值会被归成一个单独的组你可以在结果里明确看到这部分占比决定是保留、填充还是剔除。这个取舍必须显式做不能靠默认行为替你决定。结果会是 4 个地区加 1 个缺失组乘以 3 个渠道共 15 行。如果你需要看每个地区内部的渠道占比可以再补一步cross[region_total] cross.groupby(region)[total_amount].transform(sum) cross[share] (cross[total_amount] / cross[region_total]).round(4)transform在这里的作用是把组内汇总值广播回每一行保持原表行数不变。这跟agg的区别很重要agg是降维每个组只剩一行transform是等维每行都拿到所属组的统计值。做占比、做组内标准化、做相对排名都要用transform。4.4 参数选择与计算过程的现场记录以分组键基数对性能的影响为例我实测了一组数据。同样 5000 行改分组键的取值个数观察耗时import time for k in [5, 50, 500, 2000]: key rng.integers(0, k, n) tmp df.assign(gkey) t0 time.perf_counter() tmp.groupby(g)[amount].sum() print(f组数{k:5}, 耗时{time.perf_counter()-t0:.4f}s)实测下来组数在几百以内时耗时变化不明显都在毫秒级组数接近 2000 时开始出现可感知的增长。原因是分组映射的构建和结果对象的组装成本随组数上升。这个结果说明常规业务的维度列地区、渠道、品类基数都在几十以内性能完全不是瓶颈真正需要警惕的是拿用户 ID、订单号这类高基数字段直接分组。另一个实测点是apply与agg的差距。同样按品类分组算一个带条件的加权值agg配合自定义函数比apply略快而完全向量化的写法比两者都快一个量级。所以优化的顺序永远是先向量化再agg最后才考虑apply。提示做性能对比时一定要用time.perf_counter()而不是time.time()后者精度不够毫秒级的差异会淹没在噪声里。另外记得跑多轮取平均单次测量受系统调度影响很大。4.5 分组内的排序与取头部每个品类卖得最好的前三名这个需求非常常见标准解法是排序加截取top3 ( df.sort_values([category, amount], ascending[True, False]) .groupby(category, as_indexFalse) .head(3) )这里的顺序不能颠倒。必须先把数据按分组键升序、指标降序排好再用groupby().head(n)取每组前 n 行。head在分组上下文中是按组取头部不是取全局前 n 行这个语义差异是它好用的原因。如果反过来先head再分组拿到的是全局前 3 行被分到各自组里结果完全不对。另一种写法是用nlargest但它在多列排序和复杂条件上不如排序加截取灵活。我个人更倾向后面这种因为排序条件一眼可见改需求时不容易出错。4.6 组内填充与衍生transform 的主场缺失值按组填充是transform最典型的用法df[amount_filled] df.groupby(category)[amount].transform( lambda s: s.fillna(s.mean()) )这种写法保证了填充只发生在组内不会用全局均值污染不同品类的分布。如果用df[amount].fillna(df[amount].mean())填充值就变成了全局口径在品类间差异大的时候会引入偏差。同样的思路可以做组内标准化df[amount_z] df.groupby(category)[amount].transform( lambda s: (s - s.mean()) / s.std() )这样每个品类内部都变成均值 0、标准差 1 的分布跨品类比较才有意义。这个操作在特征工程里用得非常多本质上是去掉品类这个维度的量纲影响。需要提醒的是transform里传自定义 lambda 会走逐组调用组数多的时候性能一般。如果只是均值、标准差这类可以直接用内置方法加广播运算速度会好不少。5. 常见问题排查那些让我多花半小时的坑5.1 结果行数对不上先查缺失值和过滤顺序聚合后行数比预期少十有八九是分组键里的缺失值被默认丢弃了。排查方法很简单print(df[region].isna().sum()) # 看有多少缺失 print(df[region].nunique(dropnaFalse)) # 看包含缺失的组数如果两个数字都不为 0而聚合结果又没有对应的组那就是dropna的默认行为在起作用。改用dropnaFalse重新跑一遍行数就对上了。这个坑的隐蔽之处在于它不报错、不警告结果看起来还挺正常只有在做总量核对时才会发现问题。另一类行数不符的原因是过滤和分组的顺序。先过滤再分组某些组可能整个消失先分组再过滤空组会保留但值为 NaN。这两种语义不同取决于你要的是没有任何记录就不出现还是出现过但要标记为空。写代码时把顺序和意图对应起来能省很多返工。5.2 列消失或取值报 KeyError聚合之后原列名跑到索引里df[category]报 KeyError这个前面提过。但还有一种更隐蔽的情况用agg字典聚合后列变成了多层索引取值方式也跟着变了。r df.groupby(category).agg({amount: [sum, mean]}) # r[amount] 是一个 DataFrame不是 Series # r[(amount, sum)] 才是单个 Series多层列的处理方式有两种一是用元组精确取值二是聚合时就用命名聚合语法直接产出扁平列名。后者更推荐因为下游代码不用关心层级结构。如果已经生成了多层列可以用r.columns [_.join(c) for c in r.columns]拍平但要注意列名冲突。还有一种 KeyError 来自分组键本身不存在。用函数做分组键时函数作用在索引上如果索引不是你以为的那一列分组结果就是错的。排查时先print(df.index[:5])确认索引内容比盲目改代码快得多。5.3 聚合速度慢得离谱慢的原因通常有三个按出现频率排用了apply传自定义函数、分组键基数过高、数据里有大量对象类型的列参与运算。第一个最好解决把能向量化的逻辑提出来。第二个需要看业务是否真的需要那么细的粒度很多时候先按粗粒度聚合再下钻比一次性按最细粒度分组更高效。第三个容易被忽略字符串列在聚合时不会被自动排除如果agg里写了sum而某些列是文本pandas 会尝试拼接速度慢且结果没有意义。养成显式指定列的习惯df.groupby(category)[[amount, qty]].sum()显式选列不仅避免误算还能减少参与运算的数据量性能上有实打实的收益。5.4 常见问题速查表现象可能原因处理方式聚合后行数偏少分组键含缺失值被默认丢弃设dropnaFalse或先填充键列取列报 KeyError分组键变成索引reset_index()或as_indexFalse取列得到 DataFrame多函数聚合产生多层列用命名聚合语法或拍平列名聚合结果为空过滤条件过严或键类型不匹配检查 dtype 是否一致如字符串与数值运行极慢apply自定义函数或高基数分组改向量化写法降低分组粒度数值列求和结果异常混入文本列或存在非数值脏值显式选列并做类型转换最后补充一个我自己踩过的坑合并两张表后再分组如果合并产生了重复行一对多关联没处理好聚合结果会整体偏大。这种情况不会报错数值看起来也在合理范围内只有和源表对总量才能发现。所以凡是聚合结果要对外输出我都会加一步总量核对确认分组求和等于全表求和这一步能拦住绝大多数静默错误。6. 我个人的几条实操体会用groupby这几年最深的感受是它真正的价值不在省代码行数而在把意图表达清楚。一段好的聚合代码别人扫一眼就知道按什么分组、算什么指标、结果长什么样不需要逐行推导循环逻辑。这对长期维护的项目来说比性能优化重要得多。具体到写法上我现在基本固定几个习惯聚合一律用命名语法结果列名在聚合时就定好分组键含缺失值的一律显式写dropna不让默认行为替我做决定聚合前先[[列1, 列2]]显式选列既避免误算又提速结果对外输出前必做一次总量核对。这几条看着琐碎但每一条都是被坑出来的。另外想说的是别急着上apply。我见过太多明明一行内置聚合就能搞定的需求被写成了十几行的自定义函数跑得慢还难调试。先把内置方法吃透把agg的命名语法和transform的等维特性用熟剩下的复杂场景其实很少。真遇到非得自定义的情况也先想想能不能拆成向量化预处理加内置聚合两步往往能绕开性能坑。还有一个容易被忽视的点分组结果的顺序默认是不保证的。虽然实际运行中通常保持首次出现的顺序但这不是契约。如果下游依赖顺序就必须显式sort_values别指望默认行为稳定。这类隐性依赖在代码评审时很难发现等到某次数据顺序变了才暴露出来排查成本很高。
阅读完成 · 觉得有帮助？
