多维聚合实战：生产级数据聚合的四大核心模式与避坑指南

1. 项目概述：为什么多维聚合不是“会groupby就行”，而是数据工程师的分水岭

我在银行风控系统干了八年，从写第一个SQL报表到带三支数据分析团队，踩过最深的坑，往往不是模型不准，而是聚合逻辑一错，整条指标链就崩了。你可能也遇到过：业务方要“按客户+产品线+地区看近30天滚动平均交易额，同时算出每个组合的交易金额中位数、标准差、最大最小值，再标出高价值交易占比”——这时候，如果还用df.groupby(['cust','prod','region']).agg({'amount': 'mean'})硬套，要么跑不出结果，要么跑出来是嵌套三层的MultiIndex，下游BI工具根本接不住，更别说加个条件判断或动态阈值了。这不是Pandas用得熟不熟的问题，而是你有没有建立起一套可复用、可审计、可扩展的聚合思维框架。

这篇内容讲的，就是这套框架。它不叫“高级技巧”，我管它叫“生产级聚合基建”。关键词里那个“Towards AI”，其实是个信号——它代表的是真实工业场景，不是Jupyter Notebook里跑通就完事的玩具数据。你看到的每一段代码，背后都对应着银行反欺诈系统的实时计算任务、信用卡中心的月度经营分析看板、或是资管公司风险敞口日报的ETL流水线。比如，当风控同事说“请把商户类别维度下的交易金额波动率（max-min）拉出来，我们明天早会要用”，他真正要的不是一行lambda，而是这个指标能稳定跑进凌晨三点的调度任务，且三年后新人接手时，光看函数名和docstring就能懂业务意图。这就是为什么我要花大篇幅讲unstack之后怎么填空值、rolling窗口的min_periods设成多少才不丢首周数据、expanding累计和在并发写入时如何避免重复计数——这些细节，教科书不写，但线上告警电话半夜打来时，它们就是你的救命稻草。

核心关键词“多维聚合”，拆开看是三个硬骨头：多（不止一个分组键）、维（时间、空间、业务层级等不同维度需协同处理）、聚合（不是简单求和，而是带状态、带上下文、带业务规则的计算）。它解决的典型问题，比如：某省分行发现零售贷款不良率突然跳升，你要在5分钟内定位是哪个地市、哪类产品、哪类客群在恶化；又比如，运营团队想验证“满减活动对高频低额用户是否比对低频高额用户更有效”，你需要在同一张表里同时产出分组后的均值、中位数、分位数、以及自定义的“活动响应强度指数”。这些需求，用基础groupby拼凑，代码会像毛线团一样越绕越紧；而用本文的结构化方法，你写的不是脚本，是可组装的分析模块。适合谁？刚转行的数据分析师、卡在ETL效率瓶颈的初级数据工程师、需要给业务方交付稳定指标的BI开发，甚至包括那些总被问“为什么上个月数据和这个月对不上”的数据产品经理——因为所有差异，90%都藏在聚合逻辑的细微差别里。

2. 多维聚合的整体设计思路：从“堆代码”到“搭积木”的范式转换

2.1 为什么必须放弃“单点突破”思维？

我见过太多人把聚合当成一道数学题：给定输入，套公式，出答案。这在Kaggle比赛里行得通，但在银行系统里会死得很惨。举个真实案例：去年我们做信用卡分期业务分析，最初版本用df.groupby(['customer_id', 'product_type']).agg({'amount': ['sum', 'count']})，跑得飞快。上线两周后，业务方提了个需求：“请把‘新客首笔分期’单独标记出来，只统计他们前三笔交易”。有人直接加了个query("is_new_customer == True").head(3)，结果整个作业耗时从2分钟涨到47分钟，因为head()触发了全量排序。后来我们重构，把“新客识别”作为预处理步骤生成布尔列，再用agg一次完成，耗时回到2.3分钟。这个教训的核心，是聚合不是孤立操作，而是数据流中的一个节点，它的上游输入质量、下游消费方式，决定了你选哪种聚合策略。

所以我的设计原则第一条：先画数据血缘图，再写代码。拿到需求，第一件事不是打开PyCharm，而是手绘三样东西：① 输入数据的原始结构（字段、类型、空值率、时间范围）；② 输出目标形态（是给Tableau拖拽的宽表？还是给Spark做特征工程的长表？或是API返回的JSON？）；③ 中间依赖项（比如“滚动平均”需要保证数据按时间严格排序，“多级分组”需要确认各维度的基数比是否会导致内存爆炸）。这三样画清楚，80%的架构问题就解决了。比如，如果你知道下游是Excel，那unstack后必须用fill_value=0，否则Excel会把NaN当错误；如果你知道数据要进Flink实时计算，那rolling(window=30)就得换成TUMBLING窗口，因为Pandas的滚动是基于索引位置，而流式计算是基于事件时间。

2.2 四大核心模式的选型逻辑：什么场景该用哪种？

不是所有聚合都值得用高级语法。我按使用频率和复杂度，把本文覆盖的模式分成四档，每档都有明确的“入场券”：

• 第一档：多列多函数聚合（agg({col: [func1, func2]})）
  入场券：需求里出现“同时”“并”“及”这类连词。比如“既要平均交易额，也要中位数，还要标准差”。这是最安全的起点，因为它不改变数据形状，只是丰富了指标维度。优势在于：① 计算一次完成，避免多次groupby的IO开销；② 所有结果在同一DataFrame里，后续过滤、排序、导出都方便。但要注意陷阱：当transaction_amount列有大量空值时，'mean'和'median'会给出不同数量的有效样本，导致业务方质疑“为什么平均值和中位数的分母不一样？”——这时必须加.dropna()或明确skipna=True参数，并在文档里注明处理逻辑。

• 第二档：自定义聚合函数（agg({'col': custom_func})）
  入场券：需求里出现“按业务规则”“根据XX阈值”“需考虑权重”等描述。比如“高价值交易占比”“加权平均费率”。这是区分初级和中级工程师的关键。很多人写lambda，但lambda无法调试、无法加日志、无法单元测试。我的铁律是：任何超过10行逻辑、或涉及条件分支的聚合，必须写成命名函数。函数名要直白，比如def calc_fraud_risk_score(series):，而不是def f(x):；docstring里必须写清业务依据，比如“参考银保监发〔2023〕12号文，单笔超300元视为高风险交易”。这样半年后审计时，你不用翻聊天记录，看函数就知道合规依据在哪。

• 第三档：滚动与扩展窗口（rolling()/expanding()）
  入场券：需求里出现“最近N天”“截至当前”“累计”“同比/环比”等时间动态词。这是最容易翻车的档位。新手常犯的错是忽略min_periods参数。比如rolling(window=7).mean()，前6天全是NaN，如果下游系统没做空值处理，整个看板就显示一片空白。我的经验是：对监控类指标，设min_periods=1，用首日数据填充；对分析类指标，设min_periods=3，宁可少算几天，也不用不可靠的均值。另外，expanding看似简单，但要注意它默认从第一行开始累积，如果数据有乱序（比如日志延迟到达），结果会错。必须前置sort_values('event_time').drop_duplicates(subset=['id'], keep='last')，这是血泪教训。

• 第四档：多级分组+重塑（groupby([a,b]).agg().unstack()）
  入场券：需求里出现“交叉分析”“矩阵视图”“对比A和B”等表述。比如“各城市不同年龄段用户的客单价对比”。这是最高阶的，因为涉及数据形态的根本转变。unstack不是万能的，它要求分组键的组合是“稀疏但完整”的。如果某个城市没有20-30岁用户，unstack后该列就是NaN，而业务方想要的是0。所以必须跟fill_value=0绑定使用。更关键的是，unstack后列名是元组，比如('amount', 'mean')，直接导出Excel会变成奇怪的多层表头。我的解决方案是：result.columns = ['_'.join(col).strip() for col in result.columns.values]，把('amount', 'mean')转成amount_mean，干净利落。

这四档不是线性升级，而是组合拳。真实项目里，你往往要同时用到三档：比如先用多列聚合算基础指标，再用自定义函数加工，最后用unstack生成报表。设计时，永远问自己一句：“这个聚合结果，下个环节的人拿去怎么用？”

3. 核心细节解析与实操要点：那些文档里不会写的“脏活”

3.1 多列聚合的列名陷阱与扁平化实战

看原文示例，result = df.groupby('merchant_category').agg({'transaction_amount': ['mean','median'],'processing_fee': ['min','max']})，输出是带双层列名的DataFrame。这在Jupyter里看着清爽，但放到生产环境就是灾难。比如，你想把结果存进数据库，to_sql()会报错，因为列名('transaction_amount', 'mean')含括号和逗号，数据库不认；又比如，你想用result['transaction_amount']['mean']取值，结果得到的是Series而非标量，因为外层是transaction_amount，内层才是mean。这些都不是bug，是Pandas的设计哲学——它优先保证语义清晰，而非易用性。

我的解法分三步走，且必须按顺序执行：

第一步：强制扁平化列名

# 原始result的列是MultiIndex，先转成列表 flat_columns = [] for col in result.columns: # col是元组，如('transaction_amount', 'mean') flat_name = '_'.join(str(x) for x in col) # 转成 'transaction_amount_mean' flat_columns.append(flat_name) result.columns = flat_columns

注意，这里用str(x)是为了兼容列名里有数字的情况（比如('amount', 95))，避免join报错。

第二步：处理缺失值的业务含义
原文示例没提空值，但现实数据里，processing_fee可能有20%是NaN。此时'min'和'max'会返回NaN，但业务方要的是“该商户类别的最低手续费是多少”，不是“不知道”。所以必须加skipna=True，且明确告知：

result = df.groupby('merchant_category').agg({ 'transaction_amount': ['mean','median'], 'processing_fee': lambda x: x.min(skipna=True) if not x.isna().all() else 0 })

这里用lambda是因为min函数本身支持skipna，但为了统一风格，我习惯把所有自定义逻辑都显式写出。

第三步：为下游系统预留接口
扁平化后，列名是transaction_amount_mean，但BI工具可能要求AMT_MEAN。我的做法是在函数末尾加个映射字典：

column_mapping = { 'transaction_amount_mean': 'AMT_MEAN', 'transaction_amount_median': 'AMT_MEDIAN', 'processing_fee_min': 'FEE_MIN', 'processing_fee_max': 'FEE_MAX' } result = result.rename(columns=column_mapping)

这个字典存在配置文件里，随时可改，不用动核心代码。

提示：永远不要相信“数据没有空值”。我在某城商行做尽调时，发现他们交易表里processing_fee字段的空值率是18.7%，原因是部分境外交易不收手续费。如果当时没加skipna=True，整个风险敞口报表就漏掉了近五分之一的商户。

3.2 自定义函数的调试与性能优化：别让lambda成为黑箱

原文用lambda x: x.max() - x.min()演示范围计算，简洁是真简洁，但问题也真多。首先，lambda无法加断点调试；其次，如果x是空Series，x.max()会报ValueError: max() arg is an empty sequence；最后，它无法复用——下次算“交易金额变异系数”，你还得重写一遍。我的替代方案是：所有自定义聚合，必须封装成类，且继承pandas.api.extensions.ExtensionArray（可选），至少要有__call__方法。

以“高价值交易占比”为例，这是风控核心指标：

class HighValueRatio: def __init__(self, threshold=300, currency='CNY'): self.threshold = threshold self.currency = currency # 为未来多币种扩展留接口 def __call__(self, series): # 1. 安全检查 if len(series) == 0: return 0.0 if series.isna().all(): return 0.0 # 2. 业务逻辑：高价值交易数 / 总交易数 high_count = (series > self.threshold).sum() total_count = len(series) # 3. 返回带业务注释的结果（便于审计） return { 'high_value_ratio': round(high_count / total_count * 100, 2), 'high_value_count': int(high_count), 'total_count': int(total_count) } # 使用时 result = df.groupby('category').agg({ 'amount': HighValueRatio(threshold=300) })

这个类的好处是：① 可以在__call__里加logging.debug打日志；② 单元测试时，直接assert HighValueRatio()(pd.Series([100, 400, 500])) == {'high_value_ratio': 66.67, ...}；③ 配置变更只需改threshold参数，不用动逻辑。

性能方面，很多人担心自定义函数慢。其实Pandas的agg底层是Cython优化的，只要你的函数不包含Python循环（比如for i in range(len(series)):），性能损失几乎为零。真正的瓶颈在IO和内存。比如，当你对10亿行数据做groupby(['user_id', 'date']).agg({'amount': HighValueRatio()})，内存会爆。这时必须用chunksize分批读取，或改用Dask。我的经验是：单机处理超5000万行，就该考虑分布式了。

3.3 滚动窗口的边界处理：为什么前N行总是NaN，以及怎么救

原文示例中，rolling(window=3).mean()的前两行是NaN，这是正确行为，但业务方不买账。他们说：“你们系统不能显示空白，要填0或者用首日数据。” 这不是技术问题，是产品需求。我的应对策略是“三明治填充法”：

• 底层：用min_periods=1保证不为空

  df_ts['rolling_avg'] = df_ts.groupby('category')['daily_revenue'].rolling( window=3, min_periods=1 ).mean().reset_index(level=0, drop=True)

  这样第1天就是1200.0，第2天是(1200+1350)/2=1275.0，第3天才是(1200+1350+1180)/3=1243.33。虽然数学上不严格，但业务上可接受。

• 中层：用fillna(method='ffill')向前填充
  如果业务方坚持“首日数据代表趋势”，就加一行：

  df_ts['rolling_avg'] = df_ts['rolling_avg'].fillna(method='ffill')

  这样第1天是1200.0，第2天也是1200.0，第3天是1243.33。注意，ffill只能填一次，不能无限填，所以要配合limit=1参数。

• 顶层：用where()做业务兜底
  最保险的是结合业务规则。比如，对“欺诈检测滚动均值”，我们规定：如果历史数据不足3天，就用全量历史均值替代：

  full_mean = df_ts['daily_revenue'].mean() df_ts['rolling_avg'] = df_ts['rolling_avg'].where( df_ts['rolling_avg'].notna(), other=full_mean )

注意：rolling的window参数单位是“行数”，不是“天数”。如果数据有缺失日期（比如周末无交易），window=3可能跨了5天。要精确按日滚动，必须先用resample('D').sum()补全日期，再rolling('3D')。这是金融时间序列的黄金法则。

3.4 多级分组的内存与性能陷阱：当unstack让你的机器变砖

groupby(['region','product']).agg().unstack()看起来优雅，但当region有300个、product有500个时，结果表会有15万列。Pandas会直接OOM。我在某股份制银行做POC时，就因这个翻过车——原计划用unstack生成全国31省×200款理财产品的收益矩阵，结果内存飙到64GB，笔记本风扇狂转。解决方案是“降维三原则”：

• 原则一：先聚合，再重塑
  错误做法：df.groupby(['province','product','month']).sum().unstack(['product','month'])—— 三级索引直接unstack，列数爆炸。
  正确做法：先按['province','product']聚合，再按['province','month']聚合，最后用pivot_table合并。pivot_table比unstack更智能，会自动处理稀疏性。

• 原则二：用pivot_table替代unstack

  # 更安全的写法 result = df_sales.pivot_table( values='revenue', index='region', columns='product', aggfunc='mean', fill_value=0 # 关键！直接填0，不用事后fillna )

  pivot_table底层做了优化，对缺失组合会自动跳过，不会生成全量笛卡尔积。

• 原则三：大维度用crosstab或SQL
  当维度基数超1000，果断放弃Pandas。用pd.crosstab(df['region'], df['product'], values=df['revenue'], aggfunc='mean')，它专为交叉表优化；或者，把数据推到数据库，用SELECT region, product, AVG(revenue) FROM sales GROUP BY region, product PIVOT (...)，让数据库引擎扛压。

4. 实操过程与核心环节实现：从零搭建一个银行级交易分析流水线

4.1 环境准备与数据模拟：为什么随机种子必须固定？

原文用np.random.seed(42)生成示例数据，这不仅是“让结果可重现”，更是生产环境的底线要求。在银行，任何分析结果都要能回溯。如果今天跑出的“客户A的月均交易额”是262.82，明天重跑变成263.15，风控同事会立刻质疑：“数据源变了？还是代码有随机性？” 所以，我的所有生产脚本开头三行必是：

import numpy as np import pandas as pd import random # 三重种子，覆盖所有随机源 np.random.seed(20240417) # Pandas/Numpy random.seed(20240417) # Python内置random pd.set_option('random_state', 20240417) # Pandas特定操作

日期选20240417，是因为这是本文发布日，方便日后审计。种子值不重要，重要的是它必须是常量，且写在配置文件里，而不是硬编码在脚本中。

数据模拟部分，原文用np.random.uniform(20,500,60)，这太理想化。真实交易数据有尖峰厚尾分布（少数大额交易拉高均值），所以我用scipy.stats.lognorm：

from scipy.stats import lognorm # 模拟更真实的交易金额：大部分小额，少数大额 s = 1.2 # 形状参数，控制偏态程度 scale = 150 # 尺度参数，决定中位数 amounts = lognorm.rvs(s=s, scale=scale, size=60).round(2) # 确保最小值不低于20元 amounts = np.clip(amounts, 20, None)

这样生成的数据，describe()出来的std会远大于mean，更贴近信用卡账单。

4.2 分析1：多维统计的完整实现（客户+品类+时间）

原文的“Analysis 1”只做了groupby(['customer_id','category'])，但实际业务中，时间维度必不可少。我们扩展为三维：

# 按客户、品类、月份分组 df_transactions['month'] = df_transactions['date'].dt.to_period('M') multi_agg = df_transactions.groupby(['customer_id','category','month']).agg({ 'amount': ['sum', 'mean', 'count', lambda x: x.quantile(0.95)], # 加95分位数 'fee': ['sum', lambda x: x.sum() / x.count() if x.count() > 0 else 0] # 平均费率 }) # 扁平化列名 multi_agg.columns = ['_'.join(col).strip() for col in multi_agg.columns.values] multi_agg = multi_agg.reset_index() # 导出为Parquet（比CSV快10倍，且支持分区） multi_agg.to_parquet('output/transaction_stats.parquet', partition_cols=['customer_id'], engine='pyarrow')

关键点：①to_parquet的partition_cols参数，让数据按customer_id分区存储，后续查单个客户时，只读对应分区，速度提升百倍；②lambda x: x.quantile(0.95)是业务刚需——风控要看“95%的交易都不超过多少钱”，不是看均值。

4.3 分析2：自定义风险指标的落地（高价值交易深度分析）

原文的risk_metrics函数只返回三个数，但实际风控需要更多上下文。我把它升级为“风险画像生成器”：

def generate_risk_profile(series, high_threshold=300, low_threshold=50): """ 生成客户交易风险画像 :param series: 交易金额Series :param high_threshold: 高价值阈值（元） :param low_threshold: 低价值阈值（元） :return: dict，含12个风险维度 """ if len(series) == 0: return {f'risk_{k}': 0 for k in ['high_pct', 'low_pct', 'volatility', 'concentration']} # 基础统计 total = series.sum() count = len(series) mean_val = series.mean() # 风险维度计算 high_count = (series > high_threshold).sum() low_count = (series < low_threshold).sum() # 波动率：标准差/均值，消除量纲影响 volatility = series.std() / mean_val if mean_val != 0 else 0 # 集中度：Top3交易额占总额比 top3_sum = series.nlargest(3).sum() concentration = top3_sum / total if total != 0 else 0 return { 'risk_high_pct': round(high_count / count * 100, 2), 'risk_low_pct': round(low_count / count * 100, 2), 'risk_volatility': round(volatility, 4), 'risk_concentration': round(concentration, 4), 'risk_total_spend': round(total, 2), 'risk_transaction_count': int(count), 'risk_avg_amount': round(mean_val, 2), 'risk_max_amount': float(series.max()), 'risk_min_amount': float(series.min()), 'risk_median_amount': float(series.median()), 'risk_95_percentile': float(series.quantile(0.95)), 'risk_skewness': round(series.skew(), 4) # 偏度，判断分布对称性 } # 应用 risk_analysis = df_transactions.groupby('customer_id')['amount'].apply(generate_risk_profile) risk_df = pd.DataFrame(risk_analysis.tolist(), index=risk_analysis.index) print(risk_df)

这个函数输出12个指标，覆盖了监管报送的所有常见字段。其中risk_skewness是隐藏王牌——正偏度大，说明有少量巨额交易，可能是洗钱；负偏度大，说明交易很均匀，可能是工资代发账户。

4.4 分析3：滚动窗口的工业级实现（7日滚动均值+异常检测）

原文的滚动均值只是计算，但生产中要立即报警。我们加入实时异常检测：

# 按客户ID分组，计算7日滚动均值和标准差 rolling_stats = df_sorted.groupby('customer_id')['amount'].rolling( window=7, min_periods=4 # 至少4天数据才计算，避免噪声 ).agg(['mean', 'std']).reset_index(level=[0,1], drop=True) # 合并回原数据 df_with_rolling = df_sorted.join(rolling_stats, on=['customer_id', 'date']) # 异常标记：当日交易额 > 滚动均值 + 2*滚动标准差 df_with_rolling['is_anomaly'] = ( df_with_rolling['amount'] > (df_with_rolling['mean'] + 2 * df_with_rolling['std']) ) # 输出异常明细（供风控人工复核） anomalies = df_with_rolling[df_with_rolling['is_anomaly']].copy() anomalies['anomaly_score'] = ( (anomalies['amount'] - anomalies['mean']) / anomalies['std'] ).round(2) anomalies = anomalies[['customer_id', 'date', 'amount', 'mean', 'std', 'anomaly_score']] print("检测到的异常交易：") print(anomalies.head(10))

这里min_periods=4是关键——既保证了计算稳定性，又不会因数据缺失而漏掉早期异常。anomaly_score是标准化得分，>2即为强异常，业务方一眼就能判断严重程度。

4.5 分析4：累积计算的幂等性保障（避免重复计数）

expanding最大的坑是：如果数据每天增量更新，昨天算到第100行，今天新增10行，expanding().sum()会从头再算110行，导致重复计数。解决方案是“状态快照法”：

# 假设每天跑一次，保存昨日的累积结果 yesterday_cumsum = pd.read_parquet('state/cumsum_state.parquet') # 上次运行结果 # 今日新数据 today_data = df_sorted[df_sorted['date'] > yesterday_cumsum['date'].max()] # 只对新数据计算增量累积 if not today_data.empty: # 获取昨日最后一条记录的累积值 last_cumsum = yesterday_cumsum.iloc[-1]['cumulative_spend'] # 对今日数据，用last_cumsum作为起点 today_data['cumulative_spend'] = ( today_data.groupby('customer_id')['amount'].expanding().sum().values + last_cumsum ) # 合并新旧状态 new_state = pd.concat([yesterday_cumsum, today_data[['customer_id', 'date', 'cumulative_spend']]]) new_state.to_parquet('state/cumsum_state.parquet')

这个模式确保了无论脚本跑多少次，结果都一致。state/目录就是你的“状态数据库”。

4.6 分析5：交叉表的业务友好输出（客户×品类矩阵）

原文unstack(fill_value=0)够用，但业务方要的是“可点击钻取”的报表。我们加一层交互逻辑：

# 生成交叉表 crosstab = df_transactions.groupby(['customer_id','category'])['amount'].mean().unstack(fill_value=0) # 添加汇总行和列 crosstab.loc['ALL_CUSTOMERS'] = crosstab.mean() # 所有客户的平均值 crosstab['ALL_CATEGORIES'] = crosstab.mean(axis=1) # 所有品类的平均值 # 排序：按“ALL_CATEGORIES”列降序，突出高价值品类 crosstab = crosstab.sort_values('ALL_CATEGORIES', ascending=False) # 导出为Excel，带条件格式（高亮>300的单元格） with pd.ExcelWriter('output/customer_category_matrix.xlsx', engine='openpyxl') as writer: crosstab.to_excel(writer, sheet_name='Matrix') workbook = writer.book worksheet = writer.sheets['Matrix'] # 添加条件格式 from openpyxl.formatting.rule import ColorScaleRule rule = ColorScaleRule(start_type='min', start_color='FFFFFF', end_type='max', end_color='FF0000') worksheet.conditional_formatting.add('B2:Z100', rule)

这样导出的Excel，业务方打开就能看到红色越深，表示该客户在该品类的消费越高，无需额外分析。

5. 常见问题与排查技巧实录：那些让我凌晨三点爬起来的Bug

5.1 问题速查表：高频故障与根因定位

5.2 独家避坑技巧：从血泪史中提炼的5条军规

军规一：永远用agg代替链式调用
错：df.groupby('cat')['amt'].mean().median()—— 这会先分组求均值，再对均值求中位数，完全错误。
对：df.groupby('cat')['amt'].agg(['mean','median'])—— 一次到位，语义清晰。

军规二：unstack前必做sort_index()
unstack对MultiIndex的顺序敏感。如果分组后索引是乱序的，unstack可能把同一组数据拆到不同行。务必在groupby后加.sort_index()：

result = df.groupby(['region','product']).agg({'revenue': 'mean'}).sort_index().unstack()

军规三：时间窗口计算，freq参数比window更可靠
rolling('7D')按日历天数滚动，rolling(window=7)按行数滚动。对交易数据，前者更符合业务（周末无交易，不应计入7天）。但rolling('7D')要求索引是datetime且无重复，所以先：

df_ts = df_ts.set_index('date').sort_index().asfreq('D', fill_value=0) result = df_ts.groupby('category')['revenue'].rolling('7D').mean()

军规四：自定义函数的输入，永远假设它是Series，不是ndarray
Pandas的agg传给函数的是pd.Series，不是np.array。所以series.max()可用，但np.max(series)可能失败。更糟的是，series.values是ndarray，series本身是Series，混用会出错。我的习惯是：函数内所有操作都用series.xxx，绝不碰series.values。

军规五：生产环境禁用inplace=True
df.dropna(inplace=True)看似省事，但Pandas的inplace在某些版本有bug，会导致链式赋值失效。一律写成：

df = df.dropna(subset=['amount', 'fee'])

虽然多了一行，但绝对安全。

5.3 性能调优实战：从2小时到2分钟的蜕变

某次给信用卡中心优化月报脚本