Pandas数据处理：异常值检测、抽样与groupby聚合实践-北京尧图网络

做数据处理这行时间久了就会发现真正把人困住的往往不是模型调参而是拿到一张表之后的那半小时——字段脏、口径乱、有几列数字离谱到不敢信然后还得在当天交付之前把它整理成一张能拿去汇报的汇总表。Pandas 数据处理指南这类内容网上多得是但大多停在 API 手册的层面dropna()怎么写、groupby()怎么调。真正卡人的地方在于判断——这行数据到底算不算异常、抽多少样本才够用、聚合出来的数为什么和上游对不上。这篇就按异常值、抽样、数据聚合这三块把相对固定的处理套路摊开讲一遍重点放在为什么这么选和选错了会怎样。适合已经能写基础 Pandas 代码、但每次清洗都靠感觉、聚合结果老被质疑的读者也适合刚转岗做数据分析、想建立一套可复用流程的人。1. 先把三件事的边界划清楚1.1 一次返工暴露的问题口径没定就动手我见过也亲身经历过最典型的一种返工拿到一张订单明细先describe()看一眼发现金额列最大值是个七位数第一反应是脏数据直接df df[df.amount 10000]砍掉。跑完聚合出了一版报表交上去被人问了一句大客户那几笔去哪了才发现那几笔是真实的批量采购单。问题不在删错了行问题在于动手之前没有定义什么叫异常。金额大是业务事实金额为负可能是退款金额为空可能是下单未支付这三类东西在统计上都很异常但处理方式完全不同。所以我在任何一次清洗开始之前会先花十分钟做一件事把每个数值列的分布画出来hist或者简单看分位数再问业务方一句这个字段的合理区间。这一步看着慢实际上省掉的是整轮返工。同样的道理适用于抽样和聚合。抽样前不明确抽这批样本要验证什么抽出来的东西就没有判断标准聚合前不明确一行代表什么粒度sum出来永远对不上账。这三件事的共同点是技术动作只有一行代码判断逻辑占九成功夫。1.2 异常值、抽样、聚合之间的依赖关系这三者在实际工作流里不是并列关系而是有依赖链的。异常值处理会影响分布形态分布形态决定抽样方式是否合理抽样结果又会被用来快速验证聚合口径是否正确。举个具体场景一张千万级的用户行为表你要算各渠道的人均下单金额。如果先没处理异常值就抽样样本里混进几个极端值均值直接被拉飞如果先抽样再算聚合小渠道可能一个样本都没抽到那个渠道的指标就是空的。所以正确的顺序是先做全量体检和异常值标记再按分层方式抽样做快速迭代验证最后在全量数据上跑正式聚合。这个链条里有个容易忽略的点异常值标记不等于异常值删除。标记成新的一列布尔字段后续抽样时可以选择保留或排除聚合时可以用agg分别算含异常和不含异常两套指标。多留一条路后面被人追问的时候就有据可依。2. 异常值判定先分类再定量最后才动手改2.1 三种异常值处理方式完全不同我在实际项目里通常把异常值分成三类分类依据不是统计量而是成因类型典型表现处理方式风险录入型异常年龄 200、金额 -1、日期 1900-01-01直接置空或按规则修正低规则明确业务型异常大客户批量单、活动期爆量保留并打标记聚合时分组看高删了会丢真实信息统计型异常明显偏离同组分布但业务上说得通缩尾、对数变换、或分箱后处理中影响模型和均值区分方法很土但很有效对每一个极端值去业务系统里捞原始记录看两眼或者按维度下钻看它是否集中在某个渠道、某个时间段。如果集中出现大概率是业务型如果随机散布且数值离谱比如价格是 0.01大概率是录入型。注意不要用删掉 3σ 之外的点作为默认操作。偏态分布金额、时长、访问次数几乎都是下3σ 规则会把大量正常的长尾样本判成异常。2.2 统计口径怎么选3σ、IQR、MAD 的适用边界与参数推导三个常用口径各自的数学假设不一样选错了结论就错。3σ 规则假设数据近似正态。正态分布下落在 μ±1σ、±2σ、±3σ 内的概率分别是 68.27%、95.45%、99.73%。所以超出 ±3σ 的点在正态假设下期望占比 0.27%一千行里大概 2 到 3 个这个量级比较符合个别异常的直觉。但它对偏态分布极不友好——一个右偏的金额分布均值和标准差都被长尾拉大反而检测不出真正的极端值。IQR 规则Tukey 箱线图口径用四分位距。下界Q1 - k*IQR上界Q3 k*IQRk 默认 1.5。这个 1.5 不是拍脑袋来的正态分布下 Q1 和 Q3 大约在 μ∓0.6745σIQR ≈ 1.349σ1.5×IQR ≈ 2.02σ也就是大约覆盖 95.7% 的数据约 4.3% 的点会被判为离群。实际业务里这个比例偏高所以我通常把 k 调到 3.0此时对应约 ±4σ判出的点少很多更适合做极端值筛选。IQR 的优点是不依赖均值和标准差对偏态分布稳健。MAD 规则中位数绝对偏差更极端地稳健。先算med median(x)再算MAD median(|x - med|)判定界为med ± k * 1.4826 * MAD。这里的 1.4826 是让 MAD 在正态假设下能与标准差可比正态分布的中位数绝对偏差约为 0.6745σ其倒数即 1.4826。k 常取 3 到 3.5。MAD 的崩溃点是 50%也就是差不多一半的数据出错它才失效比标准差稳健得多。选型上我给个简单的判断表场景推荐口径参数数据近似正态身高、温度、误差3σk3轻度偏态客单价、停留时长IQRk1.5 到 3.0重偏态或有明显极值污染GMV、点击量MADk3.5有明确业务上下限业务规则优先按字段定义2.3 可直接复用的检测函数与逐行说明下面这个函数我几乎每个项目都会带一份输入一个数值 Series输出上下界import numpy as np import pandas as pd def outlier_bounds(s: pd.Series, method: str iqr, k: float 1.5): 返回 (下界, 上界)。s 需为数值型调用前请自行 dropna。 s s.dropna() if method iqr: q1, q3 s.quantile([0.25, 0.75]) iqr q3 - q1 return q1 - k * iqr, q3 k * iqr elif method mad: med s.median() mad (s - med).abs().median() if mad 0: # 超过一半的值相同MAD 退化为 0 return med, med scale 1.4826 * mad return med - k * scale, med k * scale elif method zscore: mu, sd s.mean(), s.std(ddof1) return mu - k * sd, mu k * sd raise ValueError(funknown method: {method})几个细节值得说。第一dropna()必须在函数内部做否则分位数计算会被 NaN 影响导致边界偏移。第二mad 0这个分支不能省很多业务字段比如固定费率、固定面额大部分值相同MAD 会算出 0上下界收成一个点后续所有值都判成异常这个坑我踩过一次排查花了半小时才反应过来。第三std用ddof1样本标准差Pandas 默认就是 1但如果你从 numpy 转过来那边默认是 0混用会导致边界略有差异。批量应用到多列的时候我一般这么写num_cols [amount, qty, duration] flag pd.DataFrame(indexdf.index) for col in num_cols: lo, hi outlier_bounds(df[col], methodmad, k3.5) flag[f{col}_out] (df[col] lo) | (df[col] hi) df pd.concat([df, flag], axis1) df[any_out] flag.any(axis1)用flag单独一组列而不是直接改原列原因是后面聚合时可能要用不同口径各算一版原始值保留着才有回头路。2.4 四种处理策略与各自代价检测出来之后怎么处理取决于这批数据要拿去干什么。删除只适用于录入型异常且比例要小。经验阈值是单列删掉不超过 1%多列合起来不超过 3%。超过这个量级说明要么判定口径太松要么数据源本身有问题该去查上游而不是在这删。截断winsorize把超出边界的值压到边界上。适合喂给模型或者算稳定均值代价是分布尾部被压平极端值的真实幅度信息丢失。Pandas 里一行就够df[col].clip(lo, hi)。置空把异常值换成 NaN后续用组内中位数填充。适合你暂时没想清楚怎么处理先隔离。注意置空之后要做一次缺失率检查别把一个本来干净的字段搞成 30% 缺失。分箱把连续值切成区间异常值自然落进10000 以上这一箱。这是我觉得最稳妥的一种——信息没丢聚合时还能单独看到这一档的表现。pd.cut或者pd.qcut都能做。2.5 这一步最容易犯的五个错第一个错在整表上算边界然后按组过滤。不同城市的客单价分布差异巨大用全局 IQR 去筛小城市会删掉大量正常值。正确做法是先groupby再逐组算边界transform回原表。第二个错用处理后的数据反过来再算一遍边界。迭代删异常是个陷阱第二轮边界会收窄第三轮继续收窄最后剩一堆紧凑在中间的值看起来很干净实际上分布已经被人为扭曲了。算边界和处理要用同一版数据一次到位。第三个错忘记记录处理日志。哪一列、用了什么口径、删了多少行、占比多少这些必须落成一张表。后面结果被质疑的时候这张日志比任何解释都有用。第四个错对有序类别做统计判定。比如等级字段编码成 1 到 5用 IQR 判出来 5 是异常这就很荒唐。类别型字段只做取值合法性校验不做统计离群判定。第五个错空值被当成异常值。s.mean()会自动跳过 NaN但(df[col] lo) | (df[col] hi)对 NaN 求值返回 False看着没问题一旦你写成~((df[col] lo) (df[col] hi))NaN 就被判成异常了。这两行在结果上不一致混用会出大事。3. 抽样抽多少、怎么抽、抽完怎么验证3.1 抽样目的决定抽样方式抽样不是数据太大跑不动的应急方案它是一种独立的技术手段。我把它按目的分成四种性能验证全量跑一遍要十分钟改一次代码跑一次太慢先抽 5% 验证逻辑对不对。这种抽样只要求快随机就行。分布代表性要用样本推断整体样本的分布必须贴近总体。这时候必须分层否则小群体可能一个都抽不到。抽多少有公式可算n z² * p * (1-p) / e²。取置信水平 95%z1.96、最保守的比例 p0.5、允许误差 e5%得到 n ≈ 384。这个数在实践里基本够用于比例估计如果是分城市、分渠道多维度看每个格子至少要 30 到 50 才行所以要按格子数乘上去。类别均衡做分类模型或者做对比分析时需要对每个类别抽同样的量。这时候用分层固定 n不用比例。快速迭代开发阶段反复调整清洗逻辑抽一批固定种子的小样本作为回归测试集每次改完跑一遍看结果有没有跳变。这个用法我觉得价值最高相当于给自己建了一套冒烟测试。3.2 pandas 的 sample() 参数逐个拆解DataFrame.sample的参数不多但每个都容易用错df.sample( nNone, # 行数与 frac 二选一 fracNone, # 比例 replaceFalse, # 是否有放回 weightsNone, # 每行的抽样权重 random_state42, # 随机种子务必固定 axisNone, # 0 抽行1 抽列 ignore_indexFalse, # 是否重建索引 )n和frac同时传会报错这个大家都知道。真正容易出事的是三个地方一是n超过行数且replaceFalse直接ValueError。安全写法是nmin(1000, len(df))。二是random_state不固定。同一份代码跑两次结果不一样别人复核的时候会以为出了 bug。我习惯在函数签名里把seed设成必填参数逼自己显式传。三是weights传了但没归一化。Pandas 内部会归一化所以传原始频次没问题但传的权重列如果有 NaN会直接报错需要提前fillna(0)。抽列的操作实战里用得少但偶尔救命df.sample(n20, axis1)可以从几百列里随机挑 20 列先看结构比一列列head()快得多。3.3 分层抽样与配额抽样的手写实现按比例分层最直观的写法是分组后各抽各的def stratified_sample(df, strata, frac0.1, seed42, min_n1): parts [] for key, g in df.groupby(strata, observedTrue): n max(min_n, int(round(len(g) * frac))) n min(n, len(g)) # 防止 n 超过组内行数 parts.append(g.sample(nn, random_stateseed)) return pd.concat(parts, ignore_indexTrue)用循环代替groupby().apply()是有原因的新版 Pandas 对apply里返回带分组列的结果会告警而且apply在分组数上千时性能明显劣化。循环写法啰嗦一点但行为可预测出问题好定位。min_n1这个参数很关键保证长尾小类至少有一个样本否则汇总时那一类就是空的。配额抽样每类固定抽 n 个只需要把n改成常数但要先检查最小类别的行数避免报错counts df[strata].value_counts() target min(counts.min(), 500) # 取最小类与目标值的较小者加权抽样在某些场景更合适比如想让高价值用户更容易进样本w df[amount].clip(lower0).fillna(0) 1 # 加 1 避免全零权重 samp df.sample(n5000, weightsw, random_state42)这里clip(lower0)和1都是必要的防御负权重会直接报错全零权重也会报错。3.4 抽完必须做一次分布校验抽完不看分布等于没抽。最简单的校验是逐列对比总样本和抽样样本的分位数def dist_check(full: pd.Series, samp: pd.Series, qs(0.1, 0.25, 0.5, 0.75, 0.9)): f full.quantile(qs) s samp.quantile(qs) diff (s - f).abs() / f.abs().replace(0, np.nan) return pd.DataFrame({full: f, sample: s, rel_diff: diff})相对偏差在 5% 以内我一般认为是可接受的抽样波动超过 15% 就要看看是不是分层没做或者随机种子选取导致偏斜。类别型字段用频次占比对比更直观cmp pd.concat([ df[channel].value_counts(normalizeTrue).rename(full), samp[channel].value_counts(normalizeTrue).rename(sample), ], axis1).fillna(0) cmp[gap] (cmp[sample] - cmp[full]).abs()gap最大的几行就是需要重点关注的长尾类别。如果某个渠道总体占 3% 但样本里占 0%说明分层没覆盖到得单独补抽。3.5 抽样环节的注意事项抽样前先排序是个隐形陷阱。如果原始数据是按时间或 ID 有序的sample虽然随机但reset_index之后如果不打乱后续某些按位置切片的操作会带上顺序偏差。另一个常被忽略的点抽样后的索引是乱的。ignore_indexTrue可以重建但如果你后面要用索引和原表做join就必须保留原索引别顺手重置。这两种需求在同一次分析里经常同时存在我的做法是抽样时保留索引需要干净索引的时候再单独reset_index(dropTrue)。还有一点小样本上算分位数不稳定。抽 100 行算 P99那个值基本没有参考意义。经验上要算 P99 至少需要 1000 行算 P999 需要上万行。看到别人拿几百行样本报 P99 指标心里要有数。4. 数据聚合groupby 的机制、选型与性能边界4.1 split-apply-combine 到底发生了什么groupby的执行过程分三步理解这三步能解释绝大部分为什么结果和我想的不一样。第一步 split按 key 列把行分组Pandas 内部会构建一个分组索引。这一步的关键是 key 的取值——NaN会被默认丢弃除非dropnaFalse这是聚合结果对不上账的头号原因。一张表里如果有 5% 的渠道字段为空groupby(channel).sum()出来的总量比全表sum()少 5%很多人第一次遇到会以为是求和算错了。第二步 apply对每组应用聚合函数。这里决定性能的是函数本身——sum、mean、count这类有 C 实现的聚合走的是快速路径而lambda包装的自定义函数会退化成逐组 Python 调用几十万组的时候慢几十倍都不止。第三步 combine把各组结果拼回一个 Series 或 DataFrame。这一步里索引怎么排sortTrue默认排序大分组数时会慢、结果用什么类型多列聚合返回 MultiIndex 列名都会影响后续操作。同一个逻辑下面三种写法结果一样性能差一个数量级# 写法 Alambda最慢 df.groupby(city)[amount].agg(lambda s: s.mean()) # 写法 B字符串快 df.groupby(city)[amount].agg(mean) # 写法 C直接方法最快 df.groupby(city)[amount].mean()我实测过一个 300 万行、8 万组的表写法 A 大约 6.8 秒写法 C 只用 0.4 秒。差距全在 Python 层的循环调用上。4.2 agg、transform、apply、filter 怎么选这四个是 groupby 之后最常用的方法但用途完全不同混用会导致结果形状不符合预期方法输出形状典型用途索引行为agg每组一行汇总统计出报表分组键做索引transform与原表同长组内标准化、组内填充、组内占比保留原索引apply任意复杂逻辑返回 DataFrame 或标量视返回值而定filter原表子集按组条件筛行如组内行数 100保留原行判断标准很简单结果要不要回填到原表的每一行。要就用transform不要就用agg。transform的经典用法是组内中位数填充df[amount_filled] df[amount].fillna( df.groupby(city, observedTrue)[amount].transform(median) )组内占比也是高频需求用transform一行搞定df[share_in_city] df[amount] / df.groupby(city, observedTrue)[amount].transform(sum)filter适合做剔除小样本组这类操作valid df.groupby(city, observedTrue).filter(lambda g: len(g) 100)注意filter返回的是原表的行子集不是聚合结果别拿它去出报表。apply是最后的兜底手段。它灵活但有两个已知问题一是慢二是在新版 Pandas 里如果函数返回的 DataFrame 包含分组列会触发DeprecationWarning并可能在未来版本行为变更。显式传include_groupsFalse可以消除告警代价是函数内部拿不到分组列的值。我的建议是能用agg或transform组合表达的就别用apply。4.3 命名聚合与多键聚合的写法规范多列多函数聚合用元组命名的方式输出列名干净不用二次改名summary ( df.groupby([city, channel], observedTrue) .agg( order_cnt(order_id, nunique), gmv(amount, sum), avg_amt(amount, mean), p90_amt(amount, lambda s: s.quantile(0.90)), users(user_id, nunique), ) .reset_index() )几个约定我强烈建议固定下来observedTrue必加分类字段做分组键时不加会产生大量空组合行数爆炸nunique而不是countcount只数非空值会漏掉重复分位数用lambda时明确写0.90而不是.9避免误读。聚合结果的列顺序不受控制如果需要固定顺序最后加一步summary summary[[city, channel, gmv, order_cnt, avg_amt, p90_amt, users]]。这一步看着多余但交付的时候列顺序乱了会被反复问。多键聚合还有一个隐蔽问题如果某个键有 NaNdropnaTrue会把整行丢掉。数据集里渠道字段经常有缺失要么提前fillna(未知)要么显式传dropnaFalsedf.groupby([city, channel], dropnaFalse, observedTrue)[amount].sum()4.4 pivot_table 与 crosstab 的适用场景groupby输出的是长表pivot_table输出的是宽表。前者适合继续做计算后者适合直接看和交付。wide pd.pivot_table( df, indexcity, columnschannel, valuesamount, aggfuncsum, fill_value0, marginsTrue, # 加一行/列合计 margins_name合计, observedTrue, )marginsTrue这个参数很实用自动加行列合计省得手工sum一遍。但要注意margins的合计是基于原始数据算的不是把各列加起来对有重复计数的指标如nunique两者结果不同——这一点在交付前必须核对。crosstab本质是频次版的pivot_table做交叉分布看得很清楚pd.crosstab(df[city], df[channel], normalizeindex, marginsTrue)normalizeindex表示按行归一化每行加起来是 1适合看每个城市里各渠道的占比。normalizecolumns则是按列归一含义完全不同选错了结论就反了。4.5 性能优化三类数据类型和大表聚合的实测差异聚合慢通常不是数据量大而是类型不对。三个具体的优化点分组键转 category。字符串键做分组时Pandas 需要对每个字符串做哈希和比较转成 category 之后底层变成整数编码分组速度快好几倍内存也降一个量级。for col in [city, channel]: df[col] df[col].astype(category)转 category 之后必须配observedTrue否则会为每个分类值的笛卡尔组合生成行。只选需要的列。df.groupby(...)之后再选列分组已经发生了先选列再分组内存和计算量都会降df[[city, channel, amount, order_id]].groupby([city, channel], observedTrue).agg(...)避免在高基数列上做不必要的 nunique。nunique需要额外构建哈希集合在千万级数据上成本不低。如果order_id本身已经唯一直接用size或count更快。我做过一组对照300 万行订单表按城市和渠道两键聚合得到五个指标优化项耗时秒相对基线基线字符串键 lambda12.41.00去掉 lambda用内置函数3.10.25分组键转 category1.60.13先选列再分组1.10.09最有效的不是用更快的机器而是把 lambda 干掉加类型转换两个操作加起来不到五分钟提速十倍。4.6 聚合结果对不上的排查顺序你这个数和我这边差 300 万——这句话我听过太多次。固定按这个顺序查八成能定位第一步核对过滤条件。你加了amount 0对方没有。这种差异通常是固定比例不是随机差额。第二步核对时间边界。 start还是 start end还是 end跨月的时候会差整整一天的量。第三步检查 NaN 处理。分组键有 NaN 吗sum跳过 NaN 这一点双方是否一致dropnaFalse加了没有第四步查重复行。df.duplicated([order_id]).sum()跑一下明细表做关联之后行数膨胀是最常见的多出来来源。第五步核对去重口径。nunique是精确去重如果对方用的是近似去重某些数据库的近似算法大基数下会差百分之几。5. 串成一条流水线从原始表到可用报表5.1 数据体检清单拿到新表我会先跑一遍固定的体检脚本输出一张诊断表。检查项包括行数、列数、各列缺失率、数值列的均值中位数和三个分位数、类别列的取值个数和 Top5 频次、主键重复数、时间列的最小最大值。def profile(df: pd.DataFrame) - pd.DataFrame: rows [] for col in df.columns: s df[col] rows.append({ col: col, dtype: str(s.dtype), missing_pct: round(s.isna().mean() * 100, 2), n_unique: s.nunique(dropnaTrue), min: s.min() if pd.api.types.is_numeric_dtype(s) else None, median: s.median() if pd.api.types.is_numeric_dtype(s) else None, max: s.max() if pd.api.types.is_numeric_dtype(s) else None, }) return pd.DataFrame(rows)这张表的价值在于快速锁定哪几列需要重点处理。缺失率超过 40% 的列先问清楚是不是本来就不该采取值个数等于行数的列基本可以确定是 ID别拿去做分组最大值是 99999 或者 1900-01-01 的典型占位符得当缺失处理。5.2 清洗与异常值标记清洗的顺序很重要我固定的顺序是类型转换 → 去重 → 占位符置空 → 异常值标记 → 缺失填充。类型转换放最前面因为后面所有操作都依赖正确的类型。金额从字符串转数值要用pd.to_numeric(errorscoerce)coerce会把转换失败的值变成 NaN 而不是抛异常配合一次isna()统计就能知道有多少脏值。去重要按业务主键去不是drop_duplicates()整行去。整行去重对同一订单两条记录字段全同有效但字段略有差异就漏了。按主键去重之前要排序保留哪一条要想清楚——通常是保留最新更新时间的那条。df (df.sort_values(update_time) .drop_duplicates(subset[order_id], keeplast))异常值标记放填充前面因为填充会改变分布用填充后的数据算边界就不准了。5.3 抽样做快速验证全量跑正式聚合之前先用 10% 分层抽样跑一遍看指标量级是否合理。这一步主要看三件事总金额和全量sum的偏差是否在 10% 以内、各渠道排名是否一致、有没有出现意外的空值或负值。如果抽样结果和预期差很远先怀疑聚合口径而不是怀疑抽样。我自己踩过的坑是分组键里有前后空格抽样时间接暴露了——某个渠道在样本里显示成两个类别因为一个带空格一个不带。5.4 聚合出结果并自检正式聚合之后加一步自检检查四个等式分组后各行求和等于全量求和除 NaN 组外、nunique之和大于等于全量nunique因为跨组重复、行数等于分组数、金额无负值。assert abs(summary[gmv].sum() - df[amount].sum()) 1e-6, 分组求和与全量不一致这类断言我建议直接写进代码。跑一次不报错后面每次都能省掉一次核对。5.5 固化成一个函数最后一步是把整条链路封成一个函数参数化口径和阈值。好处是换数据集的时候只改参数不用重新想逻辑。函数的返回值我一般给两个结果表和处理日志。日志里记录每一列用了什么方法、影响了多少行、占比多少。6. 常见问题速查6.1 报错类报错信息原因处理ValueError: Cannot take a larger sample than populationn超过行数且无放回nmin(n, len(df))或replaceTrueValueError: weights vector contains negative values权重列有负数先clip(lower0)TypeError: unhashable type: list分组键是列表类型转成tuple再分组KeyError: xxx列名有空格或大小写不符先df.columns df.columns.str.strip()SettingWithCopyWarning切片后赋值用.loc或先.copy()6.2 结果偏离类聚合值比预期少八成是分组键有 NaN 被丢弃加dropnaFalse试试。聚合值比预期多检查去重口径明细关联合并后行数膨胀。分位数算出来是整数数据类型是整型quantile结果被截断先astype(float)。抽样后分布严重偏移检查是否漏了分层或者weights用了极端倾斜的列。6.3 性能类groupby.apply慢优先改写成agg或transform组合。分组键是长字符串转category配observedTrue。sortTrue导致大分组慢显式传sortFalse除了需要按分组键排序输出。内存爆掉只选需要的列数值列用float32类别列转category必要时按分块读。6.4 我个人的避坑清单下面这几条是纯经验文档里不会写describe()的count是非空值数量不是行数。拿到结果先和len(df)对一下差值就是缺失数。浮点数求和会出现0.1 0.2 0.30000000000000004这类误差金额对比时用abs(a - b) 1e-6而不是。分位数插值方法默认是linear和某些数据库的PERCENTILE_CONT算法一致但和PERCENTILE_DISC不一致。跨系统对数时先确认这一点否则 P90 差几百块是常态。category类型做比较时如果两个 Series 的分类顺序不同的结果可能全 False。要比较值本身先转str。抽样和聚合都依赖随机种子但如果中间有sort_values没固定排序稳定性同一份代码在不同机器上结果可能有微小差异。复杂链路我倾向于在关键节点都把random_state显式传死。任何一次交付之前把结果表按指标列降序排一遍看 Top 10 和 Bottom 10。异常结果、价格为 0、编号为空这类问题排序看一眼就全暴露了比逐个字段核对快得多。这条流水线我在不同类型的项目上改过七八版最终稳定下来的核心就三条动手前先定口径改数据前先留原值交付前先跑断言。代码本身不复杂难的是每一次都不要跳过那十分钟的检查。

Pandas数据处理：异常值检测、抽样与groupby聚合实践

相关推荐

YOLOv11实现实时猜拳手势识别系统

Spring Boot多数据源配置实战：PostgreSQL与SQL Server集成

技术创作者1800天经验：持续写作的方法与价值

更多资讯

Windows本地AI智能体OpenClaw一键部署与优化指南

昇腾AI处理器与ComfyUI适配实战指南

VSCode远程连接WSL开发环境配置指南

扫地机器人技术演进与家庭物联网应用

Docker容器化AI工具链：环境一致性与生产实践

性能调优实战：从原理到参数优化的黄金方法论

今日更新

Agent-Reach：打通大模型触达外部系统的最后一公里

深度学习图像隐写分析实战：从CNN原理到毕设源码全解析

AI赋能知识产权供需匹配：专利评估、需求挖掘与多路召回工程实践

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？