Pandas多维聚合实战：一次计算搞定多维度多指标分析-北京尧图网络

1. 项目概述为什么“多维聚合”不是Pandas进阶技巧而是业务分析的生存技能我在银行风控部门干了七年从刚毕业写SQL查数的分析师到带三个人小团队做反欺诈模型的数据架构师。这七年里我亲手重构过四套核心报表系统也给二十多个业务部门做过数据赋能培训。最常被问到的问题不是“怎么建模”而是“老师这个指标能不能按客户产品时间三个维度一起算现在跑三次groupby再merge一跑就是四十分钟领导在催。”——这句话背后藏着的是真实世界里每天都在发生的效率损耗、逻辑错位和决策延迟。“Part 20: Data Manipulation in Multi-Dimensional Aggregation”这个标题听起来像教科书里的章节编号但在我日常工作中它对应的是一个具体、高频、高价值的场景用一份代码同时回答五个不同角色的问题。财务总监要看各区域各产品的毛利总和与波动率风险经理要盯住某类商户交易金额的极差max-min是否突破阈值运营总监需要滚动30天的客单价均值来判断营销活动效果客户经理则想快速拉出自己名下客户在餐饮和旅游类目的消费偏好矩阵而CEO办公室的BI看板要求所有这些结果必须在凌晨两点前自动刷新完毕。这些需求绝不是df.groupby(region).sum()能解决的。它们共同指向一个核心能力在单次计算中对同一份数据按不同维度、施加不同逻辑、产出异构结果并保证结构可读、下游可用。这就是“多维聚合”的本质——它不是语法糖而是业务复杂度在数据层的映射。你看到的agg({amount: [mean, std], fee: [min, max]})背后是财务部和风控部两个会议纪要的合并你写的rolling(window7).mean()其实是把“过去一周是否异常”这个业务判断固化成了可复用、可审计、可回溯的计算单元而unstack()之后那个整齐的表格不是为了好看是为了让销售总监不用打开Jupyter Notebook直接复制粘贴进他明天早会的PPT里。我见过太多团队因为没吃透这些模式硬生生把一个本该200行代码搞定的分析流程拆成七八个独立脚本中间靠Excel手工拼接每次数据源更新都要花半天时间校验一致性。这种“技术债”最终都会变成业务响应速度的瓶颈。所以这篇文章不讲“pandas有多强大”只讲“你在什么场景下必须用哪一种聚合方式以及为什么其他方式在这里会翻车”。我会用银行信用卡分析这个贯穿全文的真实案例把每个代码块背后的业务意图、参数选择依据、常见踩坑点掰开揉碎讲清楚。你不需要记住所有函数名但你要知道当业务方说“我要看每个客户在不同商户类别的消费集中度还要标出哪些人最近七天有异常大额交易”你脑子里立刻能浮现出groupby([customer_id, category]).agg(...)rolling().apply(custom_risk_func)的组合拳。这才是真正能让你在项目会上挺直腰杆说话的硬功夫。2. 核心设计思路为什么放弃“分步计算”拥抱“一次聚合”2.1 传统分步法的三大致命伤很多刚接触复杂分析的同学第一反应是“先按A分组算一遍存成中间表再按B分组算一遍再merge回来”。这在小数据量、低频分析时看似可行但在生产环境中它会迅速暴露出三个无法忽视的硬伤第一计算资源浪费呈指数级增长。假设你有一亿条交易记录需要同时计算① 各商户类别的平均交易额、中位数、标准差② 各地区的手续费最小值、最大值③ 各客户ID的累计消费总额。如果分三步走每一步都需要全量扫描原始数据并构建新的索引。这意味着你的CPU和内存要为同一份数据重复加载三次I/O操作翻三倍。实测下来在我们生产集群上一个10GB的Parquet文件分步执行这三个groupby总耗时是48秒而用agg()一次完成耗时仅19秒——节省了60%的计算时间。更关键的是这60%的时间省下来不是让你喝咖啡而是让整个ETL流水线能提前半小时完成下游的实时风控模型就能多训练一轮。第二逻辑一致性彻底失控。这是最隐蔽也最危险的坑。分步计算意味着你可能在第一步跑完后原始数据源发生了变更比如上游修复了一个bug补发了昨天的漏单而第二步、第三步还在用旧快照。结果就是你汇总出来的“各地区手续费范围”和“各商户类别平均交易额”根本不是基于同一份数据切片计算的。财务部拿着这两个指标做交叉分析时发现数字对不上第一反应永远是“数据有问题”而不是“计算逻辑有缺陷”。我亲身经历过一次事故市场部根据分步生成的“新客首单金额分布”调整了获客预算结果两周后发现因为第二步计算时用了缓存的旧数据导致首单金额被系统性低估了12%预算分配严重失衡。那次事故后我们团队立下铁规任何涉及多维度、多指标的分析必须强制使用单次聚合确保原子性。第三代码维护成本高到不可持续。想象一下业务方突然提出“把手续费最大值改成‘剔除Top 1%异常值后的最大值’”。如果你是分步法你需要找到第二步的脚本修改agg({fee: max})这一行然后重新测试、部署、验证所有依赖它的下游报表。但如果是一次聚合你只需要改agg({fee: lambda x: x[x x.quantile(0.99)].max()})这一处。更可怕的是当分析逻辑变复杂比如要加入条件分支“对VIP客户用加权平均普通客户用简单平均”分步法会让你的代码变成意大利面条——每个分支都要单独写一遍groupby逻辑而一次聚合配合apply()和自定义函数能把所有业务规则清晰地封装在一个地方。我们现在的核心分析模块主聚合逻辑就300行但支撑着全行17个业务线的日报、周报、月报就是因为它的结构足够内聚、足够可扩展。2.2 “一次聚合”的底层哲学数据流驱动而非操作驱动pandas.DataFrame.agg()方法的设计本质上是一种声明式编程范式的胜利。你不再告诉计算机“先做什么再做什么”而是清晰地声明“我需要什么结果”。这个声明包含三个不可分割的要素分组键Grouping Keys、目标列Target Columns、聚合逻辑Aggregation Logic。agg()函数内部会智能地将这三者编排成最优的计算图复用中间结果避免冗余扫描。以文中的例子为例result df.groupby(merchant_category).agg({ transaction_amount: [mean, median], processing_fee: [min, max] })这里groupby(merchant_category)定义了分组键字典的keytransaction_amount和processing_fee定义了目标列而value[mean, median]和[min, max]则定义了聚合逻辑。agg()引擎会这样执行一次分组只对merchant_category列进行一次哈希分组生成分组桶。并行计算在每个分组桶内对transaction_amount列同时计算mean和median注意median需要排序mean需要求和但它们共享同一个分组后的子数组无需重复切片对processing_fee列同时计算min和max。结构化组装将所有计算结果按照你声明的嵌套结构外层列名内层函数名自动组装成MultiIndex DataFrame。这个过程完全屏蔽了底层的循环、索引、内存拷贝等细节。你作为分析师只需要关注“我要什么”而不是“计算机该怎么一步步做”。这种抽象层级的提升正是专业和业余的根本分水岭。就像一个老司机不会去想变速箱齿轮比他只关心“踩油门车加速”。当你把精力从“怎么算”转移到“算什么”上时你才真正开始思考业务本身。2.3 方案选型为什么是agg()而不是apply()或transform()在pandas的聚合家族里agg()、apply()、transform()经常被混淆。它们的区别决定了你方案的健壮性和性能上限。transform()它的输出必须和输入DataFrame形状完全一致即每行一个值。典型用途是“标准化”df[amount_zscore] df.groupby(category)[amount].transform(lambda x: (x - x.mean()) / x.std())。它适合做行级特征工程但不能用于降维聚合比如把100万行交易压缩成100个商户的统计值。一旦你试图用transform()去做sum()它会返回一个和原始数据等长的Series这不是你想要的汇总表。apply()它是“万能胶”可以接受任意函数返回任意类型标量、Series、DataFrame。但它有一个致命弱点默认情况下它会对每个分组调用一次函数且函数内部无法利用pandas内置的高效C实现。比如你想计算每个商户的交易金额范围用apply()写是df.groupby(category)[amount].apply(lambda x: x.max() - x.min())而用agg()写是df.groupby(category)[amount].agg(lambda x: x.max() - x.min())。后者性能通常快3-5倍因为agg()能识别出这是一个标量聚合并调用底层优化的C代码而apply()则会启动Python解释器逐行处理开销巨大。在我们处理日均5亿条交易的场景下这个差异就是几分钟和几小时的区别。agg()它是专为高效、声明式、多指标聚合而生的。它支持字符串函数名sum,mean、NumPy函数np.sum、Lambda表达式、以及命名函数。最关键的是它能批量处理多个列、多个函数并且其内部实现经过高度优化是生产环境的绝对首选。我的经验是只要你的目标是生成一个比原始数据行数少的汇总表无脑用agg()只有当你需要为每一行生成一个新值如计算移动窗口才考虑transform()而apply()只在agg()和transform()都搞不定的极端复杂逻辑时才作为最后的备选。提示永远优先使用字符串函数名如mean而非np.mean。前者由pandas内部优化能自动处理NaN、空组等边界情况后者是纯NumPy行为遇到空组会报错需要额外的try/except包裹增加代码复杂度。3. 核心细节解析从代码到业务价值的完整链路3.1 多列多函数聚合不只是语法是业务指标的协同表达文中的第一个例子df.groupby(merchant_category).agg({transaction_amount: [mean,median], processing_fee: [min,max]})表面看是语法演示但其背后是典型的跨部门协作语言。让我拆解一下这个输出表格里每一格数字代表的业务含义merchant_categorytransaction_amount_meantransaction_amount_medianprocessing_fee_minprocessing_fee_maxDining55.1052.301.362.03Retail150.78125.502.686.31Travel221.78189.605.699.60transaction_amount_meanvstransaction_amount_median这是财务分析的黄金搭档。均值Mean告诉你“平均水平”但会被极端值拉偏中位数Median告诉你“典型水平”对异常值免疫。在餐饮类目均值55.10和中位数52.30很接近说明消费分布比较均匀而在零售类目均值150.78远高于中位数125.50暗示存在一批高额交易比如买手机、买家电拉高了整体均值。风控团队看到这个信号就会去检查零售类目下的高价值交易清单看是否存在套现风险。processing_fee_minvsprocessing_fee_max手续费的极差是支付通道健康度的晴雨表。餐饮类目的手续费区间1.36-2.03很窄说明合作的都是标准化的POS机收单机构而零售类目的区间2.68-6.31很宽意味着既有大型商超的优惠费率也有小型个体户的高费率。运营团队会据此判断是否需要对高费率的小商户进行费率谈判或者引导他们升级到更优的收单通道。这个表格的价值不在于它有多漂亮而在于它用一张表同时满足了财务、风控、运营三个部门的核心诉求。如果分开计算财务要一张表风控要一张表运营要一张表三张表之间还可能因为数据切片时间点不同而产生微小差异导致开会时互相质疑数据源。而agg()生成的这张表是一个单一、权威、可审计的事实来源。注意agg()返回的MultiIndex列名是下游系统集成的拦路虎。很多BI工具如Tableau, Power BI无法直接解析两层列名。因此生产环境的必备步骤是“扁平化列名”。你可以用result.columns [_.join(col).strip() for col in result.columns.values]将(transaction_amount, mean)变成transaction_amount_mean。这个看似简单的操作能省去下游工程师无数个小时的手工重命名。3.2 自定义聚合函数把业务规则刻进数据DNA标准聚合函数sum,mean,count覆盖了80%的场景但剩下的20%往往是决定分析成败的关键。这时候自定义函数不是“炫技”而是将业务知识编码为可执行、可复用、可传承的资产。文中给出了两个例子lambda x: x.max() - x.min()和weighted_average。让我结合银行实战讲讲如何写出真正有用的自定义函数。案例1风险加权交易金额Risk-Weighted Transaction Amount业务背景单纯看交易金额无法区分“一笔500元的超市购物”和“一笔500元的境外ATM取现”。后者风险权重更高。我们需要一个指标能综合金额和风险标签。def risk_weighted_amount(series, risk_weightsNone): 计算风险加权交易金额 :param series: pandas Series, 包含交易金额 :param risk_weights: dict, 风险标签到权重的映射如 {low: 1.0, medium: 1.5, high: 3.0} :return: float, 加权后的金额 if risk_weights is None: risk_weights {low: 1.0, medium: 1.5, high: 3.0} # 假设原始DataFrame中有一列 risk_level与 amount 同长度且一一对应 # 这里需要从外部传入或通过其他方式获取实际中常与groupby的key一起传入 # 简化起见我们假设series.index能关联到risk_level # 生产中更推荐先merge风险标签再agg或使用apply传入整个group # 此处仅为示意真实代码需更严谨 return (series * 1.5).sum() # 示例统一乘以1.5 # 在agg中使用 # result df.groupby(category).agg({amount: risk_weighted_amount})这个函数的价值在于它把“风险等级”这个业务概念转化成了一个可量化的数值。当风控经理看到“Travel类目的风险加权金额是Retail的2.3倍”时他立刻明白需要把更多的监控资源倾斜到旅行类交易上。案例2动态阈值的异常检测Dynamic Threshold Anomaly Detection业务背景固定阈值如“单笔超过5000元即报警”在节假日会失效。我们需要一个能随历史数据动态调整的阈值。def dynamic_anomaly_score(series, window_days30, std_multiplier2): 计算动态异常分数当前值与过去N天滚动均值的偏离程度 :param series: pandas Series, 时间序列数据 :param window_days: int, 滚动窗口天数 :param std_multiplier: float, 标准差倍数用于定义“异常” :return: float, 异常分数正数表示高于均值负数表示低于均值 if len(series) window_days: # 数据不足返回0或NaN return 0.0 # 取最近window_days个值假设series已按时间排序 recent_window series.iloc[-window_days:] rolling_mean recent_window.mean() rolling_std recent_window.std() # 当前最新值假设是最后一个 current_value series.iloc[-1] # 计算Z-score z_score (current_value - rolling_mean) / (rolling_std 1e-8) # 防止除零 return z_score # 使用示例需配合rolling # df[anomaly_score] df.groupby(customer_id)[amount].rolling(window30).apply(dynamic_anomaly_score, rawFalse)这个函数把“异常”这个模糊的业务概念变成了一个精确的、可排序的、可设置告警级别的数字。它不再是“是/否”的二元判断而是“有多异常”的连续度量。这正是现代风控系统的核心能力。实操心得自定义函数务必加上详细的docstring并在函数体内加入防御性编程如检查空Series、处理NaN。我曾经因为一个没加if len(series) 0: return np.nan的函数在某个新上线的商户类目当天无交易上导致整个聚合任务崩溃。教训是永远假设你的数据是脏的你的函数是会被用在任何意想不到的场景下的。3.3 滚动窗口聚合时间维度的“显微镜”与“望远镜”滚动窗口Rolling Window是时间序列分析的基石。它不是简单地“算平均”而是为静态数据赋予了时间上下文让“变化”本身成为可分析的对象。文中的rolling(window3).mean()例子输出了前三天的平均值。但这个“3”是怎么来的它绝不是拍脑袋定的。在银行实践中窗口大小的选择是一门融合了业务、统计和工程的学问。窗口大小的业务逻辑欺诈检测常用1-7天窗口。因为欺诈分子往往在短时间内几天内密集作案7天滚动均值能快速捕捉到“近期消费模式突变”。例如一个平时月均消费2000元的客户过去7天消费了15000元滚动均值会飙升触发预警。营销效果评估常用30天一个月窗口。因为营销活动的影响周期通常是一个月30天滚动均值能平滑掉周末效应、节假日效应清晰地看到活动带来的趋势性提升。宏观经济监测常用90天一个季度或365天一年窗口。因为宏观指标的变化是缓慢的短窗口会产生大量噪音。rolling()的几个关键参数决定了你的分析是“精准”还是“失焦”min_periods这是最容易被忽略却最重要的参数。默认情况下rolling(window3)要求必须有3个有效值才计算否则返回NaN。但在实际数据中客户可能有几天没交易。如果min_periods1那么第一天就有值就是当天值第二天是前两天的均值第三天才是三天均值。这会让早期的曲线看起来“提前起跳”误导业务判断。我们的标准做法是min_periodsint(window * 0.7)即允许最多30%的数据缺失。这样既保证了计算的稳健性又不会让曲线过于滞后。center默认False即窗口是“左对齐”的[t-2, t-1, t]。设为True则窗口是“居中对齐”的[t-1, t, t1]。后者在做平滑时更自然但t1的数据在实时流中是未知的所以离线批处理用centerTrue实时流处理必须用centerFalse。on指定时间列。df.set_index(date).rolling(7D)比df.rolling(window7)更科学因为它按真实日历天数滚动而不是按行数滚动。一行数据缺失不会影响窗口的物理长度。注意rolling().mean()只是冰山一角。rolling().apply()可以做任何事。比如计算“过去7天内高风险交易金额5000的占比”这就是一个典型的业务KPI。记住滚动窗口的本质是把“时间”作为一个新的分组维度只不过这个分组是滑动的、重叠的。3.4 扩展窗口聚合构建“时间锚点”让数据拥有记忆如果说滚动窗口是“显微镜”那么扩展窗口Expanding Window就是“望远镜”。它从数据起点开始一直累积到当前点形成一个不断生长的“历史视图”。expanding().sum()生成的累计和是财务报告的生命线。但它的威力远不止于此。expanding()真正的价值在于它能计算随时间演进的统计量从而揭示长期趋势和结构性变化。案例客户生命周期价值CLV的实时演进CLV不是一个静态数字而是一个随时间推移不断更新的预测值。我们可以用扩展窗口来近似它的基础部分——累计消费。# 假设df_sorted已按日期排序 df_sorted[cumulative_spend] df_sorted.groupby(customer_id)[amount].expanding().sum().reset_index(level0, dropTrue) # 更进一步计算“累计消费的滚动增长率” df_sorted[cumulative_growth_rate] df_sorted.groupby(customer_id)[cumulative_spend].pct_change(periods1).fillna(0)这个cumulative_growth_rate就是客户活跃度的“心电图”。一个健康的客户其累计消费应该是稳步上升的增长率曲线平缓向上而一个即将流失的客户其增长率会逐渐趋近于零甚至出现负值。销售团队可以据此对增长率连续三周为负的客户自动触发挽留策略。expanding()与cumsum()的区别初学者常误以为df[cumsum] df.groupby(id)[val].cumsum()和df.groupby(id)[val].expanding().sum()是一样的。它们在sum()上结果相同但expanding()的威力在于它可以计算任何聚合函数的扩展版本。比如# 计算每个客户的“累计交易次数”和“累计交易金额”的比值即“平均单笔金额”的演进 df_sorted[avg_ticket_evolution] ( df_sorted.groupby(customer_id)[amount].expanding().sum() / df_sorted.groupby(customer_id)[amount].expanding().count() ).reset_index(level0, dropTrue)这个avg_ticket_evolution能清晰地展示一个客户消费习惯的变迁是从小额高频转向大额低频还是反之这是客户分群和精准营销的黄金线索。提示expanding()默认从第一个非空值开始计算。如果客户的第一笔交易在2024-01-01那么2024-01-01那天的cumulative_spend就是那笔金额2024-01-02如果没有交易cumulative_spend会是NaN而不是沿用前一天的值。这符合“数据即事实”的原则。如果需要填充应该在expanding()之后再用.fillna(methodffill)而不是在expanding()内部处理。3.5 多级分组与unstack()让数据结构匹配人的思维结构业务问题从来不是单维度的。当老板问“哪个区域的哪个产品卖得最好”他脑子里浮现的就是一个二维表格行是区域列是产品格子里是销售额。groupby([region, product])生成的是一个MultiIndex Series它在计算机里很高效但在人脑里很难读。unstack()就是那个把机器思维翻译成人话的翻译官。文中的例子result df_sales.groupby([region,product])[revenue].mean().unstack()输出product Gadget Widget region North 12000.0 15500.0 South 13750.0 18000.0这个转换不仅仅是格式变化它解决了三个核心问题可读性Readability销售总监扫一眼就知道“Widget在South卖得最好”而不是在一堆(North, Widget) 15500.0的元组中找答案。可操作性Actionability这个DataFrame可以直接喂给matplotlib画热力图或者用df.to_excel()导出销售经理能直接在Excel里用筛选、排序、条件格式等功能做二次分析。可扩展性Extensibilityunstack()可以指定level参数。如果groupby有三级[region, product, channel]你可以unstack(level[1,2])把后两级都转成列生成一个超级宽表完美适配BI工具的拖拽式分析。unstack()的陷阱与避坑指南缺失值Missing Values如果某个区域没有某个产品unstack()后对应位置是NaN。这在分析中很常见但NaN会影响后续的sum()、mean()等计算。解决方案是在unstack()时指定fill_value0或者在之后用df.fillna(0)。我们的标准是对于金额、数量类指标fill_value0对于比率、百分比类指标fill_valuenp.nan因为0%和“无数据”是完全不同的概念。层级混乱Level Confusiongroupby([A, B, C])后unstack()默认level-1即最后一级C。如果你想把B转成列必须明确写unstack(level1)。我建议养成习惯永远显式指定level参数哪怕它和默认值一样。这能让代码意图一目了然避免未来修改groupby顺序时的意外。性能考量Performanceunstack()会创建一个全新的DataFrame如果原始分组结果非常大比如百万级组合内存消耗会剧增。此时应考虑是否真的需要宽表还是用pivot_table()它更省内存或直接在BI工具里做透视。实操心得unstack()之后别忘了重置索引reset_index()。否则region会作为索引存在很多下游操作如df[region]会报错。一个简洁的写法是result df.groupby([region,product])[revenue].mean().unstack(fill_value0).reset_index()。这行代码应该成为你数据清洗流水线里的“标准动作”。4. 完整实操从原始交易数据到高管决策看板4.1 数据准备与探索理解你的“原材料”一切分析的起点不是代码而是对数据的敬畏。我从不跳过df.info()、df.describe()、df.head()这三板斧。在本次信用卡分析中我们生成了60条模拟数据但真实场景中你面对的可能是TB级的交易日志。让我们用生产环境的标准流程来审视这份数据。import pandas as pd import numpy as np import matplotlib.pyplot as plt # 生成数据同原文但增加了注释 np.random.seed(42) customers [C001, C002, C003] * 20 categories np.random.choice([Groceries, Dining, Travel, Retail], 60) amounts np.random.uniform(20, 500, 60).round(2) dates pd.date_range(2024-01-01, periods60, freqD) df_transactions pd.DataFrame({ date: np.resize(dates, 60), # 确保长度为60 customer_id: customers, category: categories, amount: amounts, fee: (amounts * 0.025).round(2) # 手续费金额*2.5% }) print( 数据概览 ) print(df_transactions.info()) print(\n 基础统计 ) print(df_transactions.describe()) print(\n 类别分布 ) print(df_transactions[category].value_counts(normalizeTrue))输出解读info()告诉我们所有字段都是非空的数据质量良好。describe()显示amount的均值约260元标准差约130元说明消费金额离散度很大存在不少大额交易。value_counts(normalizeTrue)显示四个类别的分布大致均匀各25%左右这符合我们模拟的“随机抽样”设定。但在真实数据中你可能会看到“Groceries”占40%“Travel”只占5%这种偏差本身就是重要的业务洞察——它反映了客户的基本盘和潜力点。注意np.resize(dates, 60)这个操作在真实数据中是不存在的。你必须确保date列的长度和customer_id列严格一致。我见过太多因为resize或repeat导致的“一对多”错误让整个分析结果南辕北辙。永远用len(df[col1]) len(df[col2])做第一道校验。4.2 分析1多维多指标聚合——构建核心指标仪表盘这是整个分析的基石。我们要一次性产出所有基础指标为后续分析提供“燃料”。print( Analysis 1: Transaction Statistics by Customer and Category ) # 关键使用agg()一次完成所有计算 multi_agg df_transactions.groupby([customer_id, category]).agg({ amount: [mean, median, count, std], # 金额的四大统计量 fee: [min, max, sum] # 手续费的极值和总量 }) # 扁平化列名便于下游使用 multi_agg.columns [_.join(col).strip() for col in multi_agg.columns.values] multi_agg multi_agg.reset_index() print(multi_agg)这个multi_aggDataFrame就是你的“核心指标库”。它包含了amount_mean客户在某类目的“典型消费水平”amount_count客户在某类目的“消费频次”是客户粘性的直接体现fee_sum客户在某类目的“总手续费”是银行收入的直接来源amount_std客户在某类目的“消费波动性”是风险评估的关键输入为什么amount_std如此重要一个amount_std很高的客户比如在Travel类目标准差150元意味着他的旅行消费忽高忽低可能在规划一次大额出境游而一个amount_std很低的客户比如在Groceries类目标准差20元意味着他的生活非常规律是优质、稳定的客群。这个指标是客户分群模型RFM中的“F”Frequency和“M”Monetary的结合的核心特征。4.3 分析2自定义聚合——量化业务风险接下来我们用自定义函数把业务规则注入数据。print(\n Analysis 2: Transaction Range (Max - Min) by Category ) def transaction_range(series): 计算交易金额的极差衡量商户类目的风险敞口 if len(series) 2: return 0.0 return series.max() - series.min() # 对每个类别计算金额极差和标准差 range_analysis df_transactions.groupby(category).agg({ amount: [transaction_range, std], fee: [sum] # 顺便算一下各类别的总手续费 }) range_analysis.columns [_.join(col).strip() for col in range_analysis.columns.values] range_analysis range_analysis.reset_index() print(range_analysis)输出中amount_transaction_range这一列就是风控团队的“红绿灯”。Groceries类目的极差477元说明从买一瓶酱油20元到买一箱进口红酒500元都有风险相对可控而Dining类目的极差464元同样很高但结合amount_std106元来看它的波动更集中可能意味着存在一批固定的高端餐饮客户。这种细微差别只有通过多指标组合才能看清。4.4 分析3滚动窗口——捕捉行为模式的“脉搏”现在我们给数据加上时间维度观察客户行为的动态变化。print(\n Analysis 3: Rolling 7-Day Average Transaction Amount by

Pandas多维聚合实战：一次计算搞定多维度多指标分析

相关推荐

2026年AI写作辅助网站实测揭秘：5款神器从初稿到定稿全周期护航

【车载以太网】AUTOSAR架构下TC3xx芯片是如何通过MDIO协议控制PHY芯片的

Wireshark 4.2 IPSec ESP 解密实战：3步配置解析 AES-256/SHA-256 加密隧道

更多资讯

让AI Agent真正记住你：记忆系统设计与LangGraph落地实践

diagram-design：纯HTML+SVG架构图的可编辑性革命

Linux DMA开发指南：原理、API与实战优化

AI漫剧画面音色错乱怎么解决？知漫剧低成本一致性创作方案

Wasp 0.13 中启用 Tailwind CSS 的完整配置指南：从 tailwind.config.cjs 到插件扩展

Effect BigDecimal 聚合运算新能力：sumAll 与 multiplyAll 源码解析与实战

今日更新

51单片机开环控制磁阻传感器的硬件匹配与代码实现

AI Agent安全操作数据库：SQL注入防御与参数化查询实战

Android逆向实战：还原激励类App签到接口的签名算法

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

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