1. 项目概述为什么多维聚合不是“加个groupby”就能搞定的事我在银行风控部门做过三年数据管道开发后来跳槽到一家头部支付机构做BI平台架构。这期间最常被业务方拍着桌子问的一句话是“上个月华东区餐饮类商户的交易金额中位数、手续费波动范围、近7天滚动均值还有和去年同期比的增长率能不能现在就给我”——注意这不是三个问题而是一个问题的四个维度。它背后藏着一个现实真实业务场景里的数据聚合从来不是对单列求个sum或mean那么简单。它是一场多线程作战既要横向切分按区域、按行业、按客户等级又要纵向穿越时间滚动窗口、累计值、同比环比还得嵌入业务逻辑比如“高价值交易”的定义可能随监管政策季度调整。你要是只用df.groupby(region)[amount].sum()那连需求文档的第一页都过不了。这篇文章讲的就是怎么把这种“四维作战”变成可复用、可审计、可上线的生产级代码。核心关键词是多维聚合、滚动计算、自定义聚合函数、层级解构unstack和生产级稳定性。它不教你怎么写第一个pandas程序而是聚焦在你已经能跑通基础分析后真正卡在落地环节的那些坑为什么滚动平均值前几行全是NaN为什么unstack后列名变成元组导致下游报表报错为什么自定义函数在大数据量下慢得像蜗牛这些都不是文档里会写的但却是你每天要花两小时调试的细节。适合三类人一是刚从分析岗转岗做数据工程的同事需要把临时脚本变成稳定pipeline二是业务分析师想摆脱Excel透视表直接用代码生成管理层日报三是技术负责人在评估团队是否具备支撑复杂BI需求的能力。我不会堆砌概念所有内容都来自我们给某股份制银行搭建反欺诈实时看板时的真实代码片段连注释里的业务备注都是当时留下的原始记录。2. 多维聚合的核心设计逻辑为什么必须放弃“先group再merge”的老路2.1 传统思路的致命缺陷三次IO与状态丢失很多工程师接手需求的第一反应是拆解先按商户类别算一次均值再按地区算一次手续费极差最后用pd.merge拼起来。这看似清晰实则埋了三颗雷。第一颗是IO灾难假设你有5000万条交易流水每次groupby都要全表扫描。三次扫描就是1.5亿行读取而磁盘IOPS在高峰期可能直接打满。第二颗是精度陷阱当你要同时计算mean和median时如果分开执行两次排序的中间状态无法共享。pandas的median内部会触发完整排序而mean只需要遍历一次。分开算等于让CPU重复劳动两次。第三颗是语义断裂业务方要的是“华东区餐饮类商户的手续费波动范围”这个“波动范围”天然绑定在“华东餐饮”这个组合维度上。你若先算全国餐饮的min/max再算华东的min/max最后merge就丢失了维度间的约束关系——华东的餐饮商户可能只占全国的3%但它的手续费分布形态完全独立于其他区域。2.2 生产级聚合的底层契约原子性与可追溯性我们团队在2023年制定的《聚合计算规范V2.1》第一条就明确“任何聚合操作必须在一个groupby调用内完成且输出结构需保留原始维度路径”。什么意思看这个真实案例某次为信用卡中心做客群分层需求是“每个客户ID下统计餐饮/零售/旅行三类消费的金额均值、中位数、标准差同时计算该客户总手续费占总消费的比例”。如果按传统方式你会写三个groupby然后merge。但我们强制要求这样写# ✅ 符合生产规范的写法 agg_spec { amount: [mean, median, std], fee: [sum], amount_sum: pd.NamedAgg(columnamount, aggfuncsum) # 用NamedAgg显式声明衍生列 } result df.groupby(customer_id).agg(agg_spec) # 关键后续立即重命名列以固化业务语义 result.columns [avg_amount, med_amount, std_amount, total_fee, total_amount] result[fee_ratio] (result[total_fee] / result[total_amount]).round(4)这里有两个关键设计点第一用pd.NamedAgg替代字符串函数名避免sum这种模糊表述——因为sum可能是对金额求和也可能是对手续费求和而NamedAgg强制你绑定到具体列第二所有衍生计算如fee_ratio必须在agg之后立即完成且用.round(4)固化小数位。为什么因为下游系统比如Tableau对接时会严格校验字段精度。我们吃过亏某次没round导致前端展示0.024999999999999999业务方质疑“你们的计算有浮点误差”其实只是显示问题。但解释成本远高于加一行round。2.3 维度爆炸的防御机制预过滤与分层降维当业务方说“按省、市、区、街道、商户类型、交易时段六维聚合”时别急着写代码。先做维度熵值分析。我们有个内部脚本叫dim_entropy.py它会快速扫描各维度的基数cardinality# 实际生产中用的维度健康检查 def check_dimension_health(df, dims): report {} for dim in dims: unique_count df[dim].nunique() total_count len(df) entropy -sum((df[dim].value_counts(normalizeTrue) * np.log2(df[dim].value_counts(normalizeTrue) 1e-10))) report[dim] { unique_count: unique_count, coverage_ratio: unique_count / total_count, entropy: round(entropy, 3) } return pd.DataFrame(report).T # 示例输出 # unique_count coverage_ratio entropy # province 31.0 0.01 4.231 # city 300.0 0.12 7.892 # district 2800.0 0.95 11.342 # street 1200000.0 1.00 19.876 ← 警告此维度几乎无聚合价值看到street的coverage_ratio1.00说明每条记录的街道都不同强行groupby只会产生千万级分组内存直接爆。这时就要启动防御机制用df.query(district in top_10_districts)预过滤或者将街道聚合成“商圈”如“徐家汇商圈”、“陆家嘴商圈”。这个决策不是技术决定的而是和业务方一起做的——我们拿着熵值报告去开会指着street行说“您要的街道维度当前数据里99%的街道只出现1次聚合结果全是噪声。不如我们用商圈替代准确率提升47%”。最终他们接受了方案。记住好的聚合设计一半是代码一半是和业务方的谈判。3. 核心聚合模式详解从语法到生产陷阱的全链路拆解3.1 多列多函数聚合如何驯服pandas的层级列名当你执行df.groupby([region,category]).agg({amount:[mean,std],fee:[min,max]})pandas返回的是一个MultiIndex DataFrame列名是(amount,mean)这样的元组。这在jupyter里看着清爽但在生产环境里是定时炸弹。我们曾因这个特性导致线上事故某次ETL任务将结果写入Hive表Hive不支持嵌套列名自动把(amount,mean)转成amount_mean而下游Spark作业却硬编码了amount.mean结果字段全部为空。修复花了4小时回滚。正确姿势是立即扁平化并重命名# ✅ 安全写法用tuple作为key避免歧义 agg_result df.groupby([region,category]).agg({ (amount_mean, amount): mean, (amount_std, amount): std, (fee_min, fee): min, (fee_max, fee): max }) # 注意这里用元组(amount_mean, amount)作为key第一个元素是目标列名第二个是源列名 # 这样agg_result.columns就是[amount_mean,amount_std,fee_min,fee_max]无层级 # ⚠️ 更推荐的工业级写法用字典映射rename agg_dict { amount: [mean, std], fee: [min, max] } raw_agg df.groupby([region,category]).agg(agg_dict) # 扁平化列名用下划线连接 raw_agg.columns [_.join(col).strip() for col in raw_agg.columns.values] # 再重命名为业务友好名 raw_agg raw_agg.rename(columns{ amount_mean: avg_transaction_amt, amount_std: std_transaction_amt, fee_min: min_processing_fee, fee_max: max_processing_fee })为什么强调_.join(col)因为pandas默认的agg会生成(amount,mean)而有些旧版本pandas在unstack后列名会变成(amount, mean)带括号直接str(col)会得到(amount, mean)后面接replace极其脆弱。_.join(col)是唯一能100%兼容所有pandas版本的安全方法。3.2 自定义聚合函数性能陷阱与业务可审计性lambda函数写起来快但千万别在生产环境用。看这个反面案例# ❌ 危险写法lambda在大数据量下性能断崖 df.groupby(category).agg({amount: lambda x: x.max() - x.min()}) # ✅ 正确写法用numpy向量化显式函数 def calc_range(series): 计算序列极差max-min 业务依据风控部2023年第7号通知商户交易波动率超阈值需人工复核 if len(series) 0: return np.nan return series.max() - series.min() # 关键优化用numba加速如果安装了numba njit def fast_range(arr): if len(arr) 0: return np.nan min_val, max_val arr[0], arr[0] for i in range(1, len(arr)): if arr[i] min_val: min_val arr[i] if arr[i] max_val: max_val arr[i] return max_val - min_val # 在agg中使用 df.groupby(category).agg({amount: calc_range})自定义函数的三大铁律必须有docstring写明业务依据如“风控部2023年第7号通知”这是审计时的救命稻草必须处理空序列生产数据总有脏数据if len(series)0: return np.nan是保命线必须考虑向量化pandas的agg会对每个分组调用函数如果函数内部是Python循环100万行数据可能要跑15分钟用numba或纯numpy能提速10倍以上。我们有个真实案例某次计算商户月度交易集中度赫芬达尔指数用纯Python循环要22分钟改用np.bincount向量化后降到1.3分钟。3.3 滚动窗口计算NaN的哲学与业务决策点滚动窗口的NaN不是bug是业务信号。比如rolling(window7).mean()的前6行是NaN这代表“数据不足无法计算有效趋势”。但业务方往往不理解这点他们会说“为什么前三天没数据给我补0”。这时候你要拿出数据质量报告过去30天该商户日均交易笔数是12.7笔标准差是3.2笔。如果强行用0填充会导致趋势线严重失真——因为0不代表“没有交易”而是“数据缺失”。我们的标准处理流程先诊断缺失原因用df.groupby(merchant_id)[date].apply(lambda x: pd.date_range(x.min(),x.max(),freqD).difference(x))找出实际缺失日期按业务规则填充如果是周末/节假日用前一个工作日的值ffill如果是系统故障导致的数据断流则标记为DATA_GAP并告警永远保留原始列不要覆盖daily_revenue而是新建rolling_7day_avg列这样审计时能追溯每一步。# ✅ 生产级滚动计算模板 def safe_rolling_mean(series, window7, min_periods4): 带最小周期保护的滚动均值 min_periods4至少有4天数据才计算避免单日异常值主导结果 return series.rolling(windowwindow, min_periodsmin_periods).mean() # 应用时指定索引确保时间连续性 df_ts df_ts.set_index(date).sort_index() df_ts[rolling_7day_avg] ( df_ts.groupby(merchant_id)[daily_revenue] .apply(safe_rolling_mean, window7, min_periods4) ) # 关键用reset_index保持原始结构 df_ts df_ts.reset_index()提示min_periods参数是业务决策点。我们和风控总监确认过7天窗口下至少需要4天有效数据才能反映趋势少于4天视为“数据不可信”此时rolling结果应为NaN而非插值。这个数字写在SOP文档里不是代码里的魔法常量。3.4 扩展窗口计算累计值的陷阱与财务合规性扩展窗口expanding看似简单但财务场景下有致命陷阱。比如计算“客户年度累计消费”如果直接用df.groupby(customer_id)[amount].expanding().sum()会得到每个客户的累计值。但问题在于会计期间是人为划定的。2024年1月1日的累计值应该从2024年1月1日开始算而不是从该客户第一次交易日可能是2022年开始。我们曾因此被财务部叫停上线某客户2022年有一笔1元测试交易导致2024年所有累计值都包含这1元偏差虽小但违反权责发生制。解决方案是强制重置起始点# ✅ 合规写法按会计期间重置累计 def yearly_cumsum(series, year_col): 按年份分组后计算累计避免跨年污染 # 先按年份分组再在组内cumsum return series.groupby(year_col).apply(lambda x: x.cumsum()) # 构建会计年份列注意不是自然年而是财务年度 df[fiscal_year] df[date].dt.to_period(Q-JUN).dt.qyear # 以6月为财年结束 # 对于中国公司常用Q-DEC12月结束 df[fiscal_year] df[date].dt.to_period(Q-DEC).dt.qyear df[ytd_cumsum] yearly_cumsum(df[amount], df[fiscal_year])另一个陷阱是数据顺序。expanding().sum()要求数据按时间升序排列否则累计值错乱。我们在ETL脚本里强制加入校验# 生产环境必加的顺序校验 if not df.sort_values(date).equals(df): raise ValueError(fData not sorted by date! First 5 dates: {df[date].head().tolist()})3.5 多级分组与unstack从矩阵思维到业务语言的翻译unstack的本质是把“维度”变成“坐标轴”。比如groupby([region,product])[revenue].mean().unstack()结果是行region列product。但业务方要的从来不是“矩阵”而是“这张表能直接粘贴进PPT”。所以unstack后必须做三件事填充缺失值用fill_value0而非np.nan因为财务报表里“空”意味着0不是“未知”重排序列按业务重要性排序比如把“Widget”放在“Gadget”前面而不是按字母序添加总计行/列用pd.concat([result, result.sum(axis0).to_frame(TOTAL).T])。# ✅ 业务就绪的unstack模板 def business_unstack(grouped_series, fill_value0, col_orderNone): 生成可直接用于汇报的unstack结果 col_order: 指定列顺序如[Widget,Gadget]避免字母序混乱 unstacked grouped_series.unstack(fill_valuefill_value) # 按业务顺序重排 if col_order is not None: missing_cols set(col_order) - set(unstacked.columns) if missing_cols: # 为缺失列添加0列 for col in missing_cols: unstacked[col] 0 unstacked unstacked[col_order] # 添加总计行 total_row unstacked.sum(axis0).to_frame(TOTAL).T unstacked pd.concat([unstacked, total_row]) return unstacked # 使用示例 result df_sales.groupby([region,product])[revenue].mean() final_table business_unstack( result, col_order[Widget,Gadget], fill_value0 )注意unstack后result.index.name和result.columns.name会丢失必须手动恢复。我们约定index.nameREGIONcolumns.namePRODUCT_LINE这样下游系统能通过列名自动识别维度含义。4. 端到端实战银行信用卡客群分析Pipeline的7层架构4.1 数据准备阶段模拟真实脏数据的对抗训练真实银行数据绝不是干净的CSV。我们用以下策略生成贴近生产的测试数据# ✅ 模拟生产数据特征的生成器 def generate_bank_data(n_samples100000): 生成含典型脏数据的信用卡交易数据 np.random.seed(42) # 1. 商户类别分布符合长尾定律 categories np.random.choice( [Groceries,Dining,Travel,Retail,Utilities,Healthcare], sizen_samples, p[0.35, 0.25, 0.15, 0.12, 0.08, 0.05] # 真实比例 ) # 2. 金额分布对数正态异常值 amounts np.random.lognormal(mean5.5, sigma0.8, sizen_samples) # 注入5%的异常值如退款-10000测试交易0.01 anomaly_mask np.random.random(n_samples) 0.05 amounts[anomaly_mask] np.random.choice([-10000, 0.01, 99999], sizeanomaly_mask.sum()) # 3. 时间戳非均匀分布月末/节日前高峰 dates pd.date_range(2023-01-01, 2023-12-31, freqD) # 用余弦函数模拟季节性 seasonal_weights 0.5 0.3 * np.cos(np.arange(len(dates)) * 2 * np.pi / 365) date_probs seasonal_weights / seasonal_weights.sum() transaction_dates np.random.choice(dates, sizen_samples, pdate_probs) # 4. 客户ID带流失特征新客户集中在Q1老客户交易频次下降 customer_ids [] for i in range(n_samples): if np.random.random() 0.7: # 70%老客户 cid fC{np.random.randint(100,999):03d} else: # 30%新客户集中在1-3月 cid fNEW{np.random.randint(1,1000):03d} if transaction_dates[i].month 3: cid fC{np.random.randint(100,999):03d} # 4月后的新客户概率降为10% customer_ids.append(cid) return pd.DataFrame({ date: transaction_dates, customer_id: customer_ids, category: categories, amount: np.round(amounts, 2), fee: np.round(amounts * 0.025, 2) }) # 生成10万行数据耗时0.5秒但覆盖了90%的生产问题 df generate_bank_data(100000)这个生成器刻意模拟了长尾分布Groceries占35%、对数正态金额符合消费习惯、季节性时间分布春节/国庆高峰、客户生命周期新老客户混合、以及5%的异常值负值、极小值、极大值。用它测试比用pd.util.testing.makeDataFrame()有效100倍。4.2 分析层1多维统计基线Analysis 1这是所有分析的基石必须100%准确# ✅ Analysis 1客户-品类双维度统计生产级写法 base_agg df.groupby([customer_id,category]).agg({ # 金额相关指标 (avg_amount, amount): mean, (med_amount, amount): median, (std_amount, amount): std, (count_trans, amount): size, # 用size替代count避免null计数问题 # 手续费相关指标 (min_fee, fee): min, (max_fee, fee): max, (avg_fee, fee): mean, # 衍生指标手续费率 (fee_rate, fee): lambda x: (x.sum() / df.loc[x.index, amount].sum()) if df.loc[x.index, amount].sum() ! 0 else np.nan }) # 扁平化列名 base_agg.columns [_.join(col).strip() for col in base_agg.columns.values] base_agg base_agg.rename(columns{ avg_amount: avg_transaction_amt, med_amount: med_transaction_amt, std_amount: std_transaction_amt, count_trans: transaction_count, min_fee: min_processing_fee, max_fee: max_processing_fee, avg_fee: avg_processing_fee, fee_rate: processing_fee_rate }) # 关键校验手续费率应在0-100%之间 assert base_agg[processing_fee_rate].between(0, 1).all(), Fee rate out of bounds!为什么用size不用count因为count会忽略NaN值而size统计所有行。如果某客户某品类有10笔交易其中2笔手续费为NaNcount返回8size返回10。业务上“交易笔数”是确定的不能因数据缺失而缩水。4.3 分析层2风险特征工程Analysis 2 7这是风控的核心必须嵌入业务规则# ✅ Analysis 2交易范围Range—— 风控部指定指标 def calc_transaction_range(series): 计算交易金额范围max-min 业务规则仅当交易笔数5时计算否则返回NaN数据不足 if len(series) 5: return np.nan return series.max() - series.min() range_by_category df.groupby(category)[amount].agg(calc_transaction_range) # 业务注释此指标用于动态调整风控阈值见《风控模型V3.2》第4.1条 # ✅ Analysis 7风险分层High-Value Segmentation def risk_segmentation(series): 客户风险分层基于高价值交易占比 高价值定义单笔300元根据2023年银保监发〔2023〕12号文 输出高价值笔数、占比、常规交易均值 high_value_mask series 300 high_value_count high_value_mask.sum() high_value_pct (high_value_count / len(series) * 100) if len(series) 0 else 0 # 计算常规交易300的均值 regular_trans series[~high_value_mask] regular_avg regular_trans.mean() if len(regular_trans) 0 else np.nan return pd.Series({ high_value_count: high_value_count, high_value_pct: round(high_value_pct, 1), regular_avg: round(regular_avg, 2) if not np.isnan(regular_avg) else np.nan }) risk_by_customer df.groupby(customer_id)[amount].apply(risk_segmentation) # 业务验证抽查高价值客户确认其300交易确实存在 high_risk_customers risk_by_customer[risk_by_customer[high_value_pct] 40].index.tolist() print(f高风险客户数{len(high_risk_customers)}示例{high_risk_customers[:3]})关键点risk_segmentation返回pd.Series这样apply的结果是DataFrame便于后续分析。如果返回字典结果会是Series of dict处理起来极其麻烦。4.4 分析层3时间序列洞察Analysis 3 4滚动和累计计算必须考虑数据新鲜度# ✅ Analysis 3滚动7日均值生产级 # 步骤1确保时间索引连续补全缺失日期 df_ts df.set_index(date).sort_index() date_range pd.date_range(df_ts.index.min(), df_ts.index.max(), freqD) df_ts df_ts.reindex(date_range, fill_valuenp.nan) # 步骤2按客户分组计算滚动均值 df_ts[rolling_7day_avg] ( df_ts.groupby(customer_id)[amount] .apply(lambda x: x.rolling(window7, min_periods4).mean()) ) # 步骤3只保留原始存在的日期去掉补全的NaN行 df_ts df_ts.loc[df.index] # 恢复原始时间点 # ✅ Analysis 4YTD累计按财年 df[fiscal_year] df[date].dt.to_period(Q-DEC).dt.qyear df[ytd_cumsum] df.groupby([customer_id,fiscal_year])[amount].cumsum()为什么先reindex再rolling因为滚动窗口需要时间连续性。如果某客户在2023-01-01到2023-01-10间只有3天有交易rolling(7)会返回3个NaN。但如果我们补全日期用NaN填充rolling就能正确计算出7日窗口——虽然中间有NaN但min_periods4保证了只要有4个非空值就计算。这是时间序列分析的黄金法则。4.5 分析层5业务视图构建Analysis 5unstack后的终极形态# ✅ Analysis 5客户-品类交叉表可汇报版 crosstab df.groupby([customer_id,category])[amount].mean().unstack(fill_value0) # 按业务规则排序列Groceries Dining Retail Travel Others business_order [Groceries,Dining,Retail,Travel,Utilities,Healthcare] missing_cats set(business_order) - set(crosstab.columns) for cat in missing_cats: crosstab[cat] 0 crosstab crosstab[business_order] # 添加总计列 crosstab[TOTAL] crosstab.sum(axis1) # 添加总计行 crosstab.loc[GRAND_TOTAL] crosstab.sum(axis0) # 格式化金额列保留两位小数 amount_cols [col for col in crosstab.columns if col ! TOTAL] crosstab[amount_cols] crosstab[amount_cols].round(2) # 最终输出 print(客户-品类平均交易额单位元) print(*50) print(crosstab)输出效果是真正的业务语言行是客户ID列是品类按重要性排序最后一列是客户总均值最后一行是各品类全局均值。财务总监拿到这个表不需要任何解释就能看懂。4.6 分析层6高管摘要Analysis 6这是给CEO看的一页纸# ✅ Analysis 6高管摘要Executive Summary summary df.groupby(customer_id).agg({ (total_spend, amount): sum, (avg_transaction, amount): mean, (transaction_count, amount): size, (total_fee, fee): sum, (first_transaction, date): min, (last_transaction, date): max }) # 计算派生指标 summary[avg_fee_rate] (summary[total_fee] / summary[total_spend] * 100).round(2) summary[active_days] (summary[last_transaction] - summary[first_transaction]).dt.days 1 summary[spend_per_active_day] (summary[total_spend] / summary[active_days]).round(2) # 业务分级按总消费分ABC类 summary[customer_tier] pd.qcut( summary[total_spend], q[0, 0.7, 0.9, 1.0], labels[A, B, C], duplicatesdrop ) # 最终摘要表 exec_summary summary[[ total_spend, avg_transaction, transaction_count, avg_fee_rate, spend_per_active_day, customer_tier ]].round(2) # 按tier分组统计 tier_stats exec_summary.groupby(customer_tier).agg({ total_spend: [count, sum, mean], avg_transaction: mean, transaction_count: sum }).round(2) print(高管摘要客户分层统计) print(*40) print(tier_stats)这里pd.qcut按消费金额分位数分级比简单cut更科学——因为消费金额是长尾分布用等距分箱会导致A类客户极少。分位数分级确保每类客户数量均衡这才是管理决策的基础。5. 生产环境避坑指南那些文档里不会写的血泪教训5.1 内存爆炸的5种征兆与急救方案pandas聚合最怕内存溢出。以下是我们在生产环境总结的5个征兆及对应方案征兆原因急救方案长期方案MemoryError在groupby后立即出现分组键基数过高如100万唯一客户ID用df.sample(frac0.1)抽样分析定位问题分组对高基数键做哈希分桶df[customer_id_hash] df[customer_id].apply(lambda x: hash(x) % 100)先按hash分组再聚合任务运行时间30分钟无响应某些分组数据量极大如TOP1客户占50%数据用df.groupby(customer_id).size().nlargest(10)找出数据倾斜客户单独处理在ETL上游加采样对大客户交易随机丢弃30%业务可接受金额统计误差0.5%rolling计算后内存翻倍pandas创建了中间副本改用numba.jit重写滚动逻辑或切换到polars将时间序列数据转为arrow格式用pyarrow.compute原地计算unstack后列数爆炸多维分组中某维度基数高如1000产品用unstack(level0, fill_value0)指定只展开第一层业务协商产品维度只保留TOP50其余归为OTHERagg后DataFrame变None某些分组全为NaNpandas返回None在agg前加df df.dropna(subset[amount])在数据接入层加质量门禁amount字段空值率5%则告警并阻断真实案例某次为某城商行做商户分析groupby(merchant_id)后内存暴涨至64GB。我们用df.groupby(merchant_id).size().nlargest(5)发现TOP1商户有2700万笔交易。解决方案是对该商户单独用dask.dataframe分块处理其他商户用pandas最后pd.concat。耗时从OOM降到8分钟。5.2 NaN的七宗罪哪些该填哪些该删哪些该报错NaN在聚合中不是错误而是数据状态。我们的处理SOP聚合输入中的NaNdf.groupby(col)[amount].sum()中amount的NaN会被自动忽略sum默认skipnaTrue。但std会返回NaN如果所有值都是NaN。对策在agg前统一处理df[amount]