多维聚合实战：银行级pandas聚合的四大模式与避坑指南

1. 项目概述：为什么多维聚合不是“加个groupby”就能搞定的事

我在银行数据平台组干了八年，从最早用SQL写几十行嵌套子查询做客户分层，到后来在Spark上跑PB级交易流水，再到如今带团队设计实时风控指标引擎——所有这些经历反复验证一件事： 真正决定分析深度的，从来不是数据量有多大，而是你对聚合逻辑的理解有多细、控制有多准。 这篇讲的“多维聚合”，不是教你怎么把 sum() 和 mean() 塞进一个 agg() 里，而是带你拆解那些业务方拍着桌子要的指标背后，到底藏着几层逻辑嵌套、几个时间维度、多少业务规则陷阱。

比如上周风控部提了个需求：“请输出近90天内，每个省、每个卡种、每个商户类别的交易金额中位数，同时标出该类别下单笔超5万元交易占比，再叠加滚动30天的平均交易频次变化率。”——这看起来就是个“多维groupby+多个agg函数”的组合题？错。它实际包含：① 时间窗口的嵌套（90天总览 vs 30天滚动）；② 统计口径冲突（中位数抗异常值，但占比计算又依赖原始分布）；③ 业务规则硬约束（5万元是监管报备阈值，必须精确匹配，不能四舍五入）；④ 结果形态要求（最终要喂进BI看板，必须是规整的宽表，不能是MultiIndex Series）。少处理其中任何一环，交付物就可能被业务方打回来重做。

我见过太多人栽在看似简单的聚合上：有人用 rolling().mean() 直接算日均，结果发现节假日数据缺失导致窗口错位，整个趋势线全偏；有人写自定义函数时没处理空值，线上跑批时遇到某类商户无交易记录，直接抛 ValueError 中断任务；还有人用 unstack() 后没设 fill_value=0 ，下游Excel导出时一堆 NaN 被财务同事当成0参与计算，差点引发月度对账差异。这些坑，文档里不写，教程里不提，但每天都在真实生产环境里发生。

所以这篇内容的核心，不是罗列pandas语法，而是还原一个资深数据工程师面对真实业务需求时的完整思考链： 先判断问题本质属于哪类聚合模式，再选工具，再防坑，最后验证。 它覆盖的是银行、保险、支付机构等强监管行业的典型场景——因为这些领域对指标准确性、可追溯性、时效性的要求，倒逼我们把聚合这件事做到极致。如果你做的只是电商用户行为分析或APP埋点统计，很多细节可以简化；但如果你处理的是信贷资产质量、反洗钱可疑交易识别、或监管报送报表，那下面每一个小数点后的取舍，都值得你停下来多想三秒。

2. 多维聚合的本质：四种核心模式与业务映射关系

很多人把“多维聚合”理解成“groupby多个字段”，这是最危险的认知偏差。真正的多维，是维度类型、计算逻辑、时间粒度、结果形态四个层面的立体组合。我把它拆成四类基础模式，每类对应明确的业务场景和不可替代的技术实现路径。记住： 选错模式，后面所有优化都是徒劳。

2.1 横向多指标聚合：解决“同一维度下，不同字段要不同算法”的问题

这是最常被低估的模式。业务方说：“我要看每个省份的贷款余额平均值，但同时要看到不良率（不良余额/总余额），还要知道客户数中位数。”表面看是三个指标，但底层逻辑完全不同：平均值是对余额字段的数值运算，不良率是两个字段的比值运算，中位数是对客户数字段的排序取值。如果强行用 df.groupby('province')[['balance','bad_balance','customer_count']].agg(['mean','median']) ，你会得到一个结构混乱的结果—— bad_balance 的 mean 毫无业务意义。

正确解法是用字典映射精准控制：

result = df.groupby('province').agg({
    'balance': 'mean', 
    'bad_balance': 'sum', 
    'customer_count': 'median'
})
# 再手动计算不良率
result['bad_rate'] = result['bad_balance'] / result['balance']

提示：这里 bad_balance 必须用 sum 而非 mean ，因为不良余额是总量概念，不是单笔均值。我曾见同事误用 mean ，导致某省不良率算出来是0.3%，实际应为3.2%——差了一个数量级，只因没想清楚“余额”和“不良余额”在业务语义上的层级关系。

这种模式在财务报表、监管报送中高频出现。比如银保监会《G01-1资产负债项目表附注》要求按行业分类统计贷款余额、减值准备、不良贷款余额，三者计算逻辑完全不同，必须分字段指定聚合函数。

2.2 纵向自定义聚合：解决“标准函数无法表达业务规则”的问题

当业务规则涉及条件分支、权重分配、或跨字段逻辑时， lambda 和命名函数不是炫技，而是刚需。举个真实案例：某信用卡中心要计算“风险加权交易额”，规则是——餐饮类交易按1.0倍计入，旅游类按1.5倍，奢侈品类按2.0倍，其他按0.8倍。这根本没法用内置函数实现。

命名函数的优势在此刻凸显：

def risk_weighted_amount(group):
    # 先构建权重映射（实际项目中这个字典会从配置中心动态加载）
    weight_map = {'Dining': 1.0, 'Travel': 1.5, 'Luxury': 2.0, 'Others': 0.8}
    # 防御性编程：处理未定义类别
    group['weight'] = group['category'].map(weight_map).fillna(0.8)
    return (group['amount'] * group['weight']).sum()

result = df.groupby('customer_id').agg({'amount': risk_weighted_amount})

注意：这里必须用 group['amount'] * group['weight'] 而非 group['amount'].sum() * weight ，因为权重是按每笔交易独立应用的。我踩过的坑是早期用后者，导致高消费客户被整体加权，完全扭曲了风险分布。

更关键的是文档化。函数名 risk_weighted_amount 和docstring里写的“依据《信用卡风险管理办法》第3.2条设定权重系数”，让半年后接手的同事一眼看懂逻辑来源，而不是对着 lambda x: ... 抓耳挠腮。

2.3 时间轴动态聚合：解决“指标需要随时间滑动或累积”的问题

静态聚合（如“2024年Q1各省平均交易额”）只能回答过去的问题；而风控、运营、投研需要的是动态视角。这里必须区分两种窗口：

• 滚动窗口（Rolling） ：固定长度，向前滑动。典型用于检测异常。比如“连续3天交易额环比增长超50%”，就必须用 rolling(window=3) 计算3日均值，再与前一日比较。注意： min_periods=2 参数很关键——当数据不足3天时，是否允许用2天计算？在新上线渠道监控中，我们设为2；但在成熟市场反欺诈中，必须严格 min_periods=3 ，避免噪声干扰。

• 扩展窗口（Expanding） ：从起点开始累积。典型用于追踪长期趋势。比如“客户生命周期总消费额”，必须用 expanding().sum() 。但要注意： expanding().mean() 在数据初期波动极大（第一天均值=当日值，第二天均值=(day1+day2)/2），业务方常误读为“客户消费在下降”。我们的解决方案是在BI层加注释：“首7日均值仅供参考，稳定值需观察满30日”。

实操心得：滚动窗口的 window 参数绝不是拍脑袋定的。我们有套校验流程——先用 df['date'].diff().dt.days.describe() 看业务数据的实际时间间隔分布，再结合业务周期（如工资发放日、还款日）确定窗口。曾有个项目盲目用7天窗口，结果发现客户交易集中在每月5号和20号，7天窗口恰好切在两个高峰之间，趋势线完全失真。

2.4 空间结构重塑聚合：解决“结果要适配人脑认知方式”的问题

业务方看数据，从来不是看MultiIndex Series，而是看Excel里的交叉表、BI里的矩阵热力图。 unstack() 不是格式美化工具，而是认知对齐的关键步骤。比如销售分析中，“各区域各产品线的销售额”这个需求， df.groupby(['region','product'])['revenue'].sum() 返回的是：

region  product
North   Widget     15000
        Gadget     12000
South   Widget     18000
        Gadget     14000

而 unstack() 后变成：

product   Widget  Gadget
region
North      15000   12000
South      18000   14000

注意： unstack() 默认展开最内层索引（即 product ），如果想按区域展开成列，要用 unstack(level=0) 。更隐蔽的坑是缺失值处理——某区域某产品无销售时， unstack() 默认填 NaN ，但财务系统要求填0。必须显式写 unstack(fill_value=0) ，否则下游ETL会把 NaN 转成NULL，再导入数据库时触发NOT NULL约束报错。

这种重塑在监管报送中更是生死线。比如人行《金融统计监测管理信息系统》要求“按机构类型、贷款用途、期限结构”三维汇总，必须输出固定行列结构的XML， unstack() 生成的DataFrame正是XML生成器的直接输入源。

3. 实战拆解：银行信用卡客户分析的七层递进式聚合

现在我们用一个完整案例，把前面四类模式串起来。这不是教学演示，而是我去年在某股份制银行落地的真实项目——为信用卡中心构建客户价值分层模型。数据源是日增1200万笔的交易流水，要求T+1产出，指标需通过监管审计。以下代码全部来自生产环境精简版，关键参数和注释保留原貌。

3.1 数据准备与业务校验：别让脏数据毁掉所有聚合

import pandas as pd
import numpy as np
from datetime import datetime, timedelta

# 1. 加载原始交易数据（实际从Hive表读取，此处用模拟数据）
np.random.seed(42)
dates = pd.date_range('2024-01-01', periods=60, freq='D')
customers = [f'C{str(i).zfill(3)}' for i in range(1, 101)] * 60  # 100客户，每人60天
categories = np.random.choice(['Groceries','Dining','Travel','Retail','Healthcare'], 6000)
amounts = np.random.lognormal(mean=5.5, sigma=0.8, size=6000)  # 对数正态分布更贴近真实交易额
# 关键业务校验：剔除明显异常值（真实项目中此步在ETL层完成）
amounts = np.clip(amounts, 1, 50000)  # 单笔交易1元至5万元，符合银联规则

df = pd.DataFrame({
    'date': np.resize(dates, 6000),
    'customer_id': customers,
    'category': categories,
    'amount': np.round(amounts, 2),
    'fee': np.round(amounts * 0.025, 2),  # 固定费率2.5%
    'merchant_id': np.random.choice([f'M{str(i).zfill(5)}' for i in range(1, 5001)], 6000)
})

# 2. 业务强约束检查：必须满足监管对“交易日”的定义
# 根据《银行卡业务管理办法》，交易日以清算系统记账时间为准，非客户操作时间
# 此处模拟：剔除周末及法定节假日（真实项目调用央行节假日API）
holidays = ['2024-01-28', '2024-01-29', '2024-01-30', '2024-01-31', '2024-02-01']  # 春节假期
df = df[~df['date'].isin(pd.to_datetime(holidays))]
df = df[~((df['date'].dt.weekday >= 5))]  # 剔除周六日

print(f"原始数据量：{len(df)}，清洗后：{len(df)}，丢弃率：{round((6000-len(df))/6000*100,2)}%")
# 输出：原始数据量：6000，清洗后：4260，丢弃率：28.99%

实操心得：清洗丢弃率28.99%看似很高，但这是合规必需。我们曾因未剔除节假日数据，导致某周“日均交易额”虚高，风控模型误判为营销活动爆发，临时上调了某类商户限额，结果被银保监现场检查指出“未执行交易时间真实性校验”，扣减年度合规评分。从此所有聚合前必加这一步。

3.2 第一层：多指标横向聚合——客户基础画像

# 目标：每个客户的基础统计，用于初步分层
base_stats = df.groupby('customer_id').agg({
    'amount': ['sum', 'mean', 'std', 'count'],  # 总额、均值、标准差、笔数
    'fee': 'sum',  # 总手续费
    'date': lambda x: (x.max() - x.min()).days  # 活跃天数
}).round(2)

# 重命名列，符合业务术语
base_stats.columns = ['total_spend', 'avg_transaction', 'spend_std', 'transaction_count', 
                      'total_fee', 'active_days']

# 计算衍生指标（必须在agg后计算，避免重复扫描）
base_stats['fee_ratio'] = (base_stats['total_fee'] / base_stats['total_spend'] * 100).round(2)
base_stats['spend_per_day'] = (base_stats['total_spend'] / base_stats['active_days']).round(2)

# 业务规则：剔除低质客户（活跃天数<3天或总交易额<1000元）
base_stats = base_stats[(base_stats['active_days'] >= 3) & (base_stats['total_spend'] >= 1000)]
print(f"基础画像客户数：{len(base_stats)}")
# 输出：基础画像客户数：87

注意： date 字段用 lambda x: (x.max() - x.min()).days 计算活跃天数，而非 nunique() 。因为 nunique() 只统计有交易的日期，而业务要求的是“从首笔到最后笔交易跨越的自然日数”，这关系到客户生命周期价值（LTV）计算。曾有同事用 nunique() ，导致某客户3天内密集交易100笔，活跃天数算成3，实际LTV模型要求是30天（因首末交易日相隔30天），结果分层错误。

3.3 第二层：自定义纵向聚合——风险交易识别

# 业务规则：单笔超3万元为高风险交易（依据《反洗钱法》第20条）
def risk_transaction_metrics(group):
    high_risk_threshold = 30000
    total = len(group)
    high_risk_count = (group['amount'] > high_risk_threshold).sum()
    
    # 关键业务逻辑：高风险交易占比需排除零交易客户（但本例已过滤）
    high_risk_pct = round(high_risk_count / total * 100, 2) if total > 0 else 0
    
    # 更深层规则：高风险交易中，若超过50%发生在同一商户，则标记为“集中交易风险”
    if high_risk_count > 0:
        top_merchant = group[group['amount'] > high_risk_threshold]['merchant_id'].value_counts().iloc[0]
        concentration_ratio = round(top_merchant / high_risk_count * 100, 2)
    else:
        concentration_ratio = 0
        
    return pd.Series({
        'high_risk_count': high_risk_count,
        'high_risk_pct': high_risk_pct,
        'concentration_ratio': concentration_ratio
    })

risk_analysis = df.groupby('customer_id').apply(risk_transaction_metrics)
print("高风险交易分析样本：")
print(risk_analysis.head())

实操心得：这里 apply() 比 agg() 更合适，因为要跨字段（ amount 和 merchant_id ）联合分析。但 apply() 性能较差，我们在生产环境对100万客户做了压测—— apply() 耗时18秒，而改用 merge 先标记高风险再 groupby ，耗时降至3.2秒。不过对于T+1批处理，18秒可接受，优先保证逻辑清晰。

3.4 第三层：时间轴动态聚合——滚动消费趋势

# 按客户+日期排序，为滚动计算准备
df_sorted = df.sort_values(['customer_id', 'date']).set_index('date')

# 计算每个客户的7日滚动平均交易额（业务要求：必须满7天才计算，避免初期噪声）
rolling_7d = df_sorted.groupby('customer_id')['amount'].rolling(
    window=7, 
    min_periods=7  # 关键！必须满7天才输出值
).mean().reset_index(name='rolling_7d_avg')

# 为每个客户提取最新滚动值（即T-1日的7日均值）
latest_rolling = rolling_7d.groupby('customer_id').tail(1)[['customer_id', 'rolling_7d_avg']]
latest_rolling.set_index('customer_id', inplace=True)

# 合并到基础画像
base_stats = base_stats.join(latest_rolling, how='left')
base_stats['rolling_7d_avg'] = base_stats['rolling_7d_avg'].round(2)
print("滚动趋势数据合并完成")

提示： min_periods=7 是硬性要求。我们曾因设为 min_periods=1 ，导致新客户首日就有滚动均值（等于当日值），业务方误以为“客户消费能力稳定”，实际是数据缺陷。监管审计时被要求提供 min_periods 设置依据，我们提交了《滚动窗口参数校验报告》，证明7天能覆盖95%的客户消费周期。

3.5 第四层：空间结构重塑——品类偏好矩阵

# 目标：生成客户×品类的消费矩阵，用于聚类分析
category_matrix = df.groupby(['customer_id', 'category'])['amount'].sum().unstack(
    fill_value=0
).round(2)

# 业务要求：只保留前5大品类，其余归入"Others"
top_categories = df['category'].value_counts().head(5).index.tolist()
category_matrix = category_matrix[top_categories + ['Others']]  # Others列需提前创建
category_matrix['Others'] = df.groupby('customer_id')['amount'].sum() - category_matrix.sum(axis=1)

# 标准化：转换为占比（消除客户总额量纲影响）
category_matrix_pct = category_matrix.div(category_matrix.sum(axis=1), axis=0).round(4) * 100
print("品类偏好矩阵（百分比）：")
print(category_matrix_pct.head())

注意： unstack(fill_value=0) 后手动计算 Others ，是因为 unstack() 无法自动聚合未列出的类别。这里 Others 的计算逻辑是“客户总消费额减去TOP5品类消费额”，确保占比总和为100%。若直接用 unstack() 后 fillna(0) ， Others 会是0，导致占比失真。

3.6 第五层：复合聚合——客户价值分层模型

# 整合所有指标，构建RFM变体模型（Recency, Frequency, Monetary + Risk）
# R：最近交易距今天数（非活跃天数！）
df['days_since_last'] = (datetime.now().date() - df['date'].dt.date).dt.days
recency = df.groupby('customer_id')['days_since_last'].min()

# F：交易频次（已计算过）
frequency = base_stats['transaction_count']

# M：标准化消费额（用Z-score，消除量纲）
monetary = (base_stats['total_spend'] - base_stats['total_spend'].mean()) / base_stats['total_spend'].std()

# Risk：高风险交易占比（已计算）
risk_score = risk_analysis['high_risk_pct']

# 合并所有维度
rfm_risk = pd.concat([recency, frequency, monetary, risk_score], axis=1)
rfm_risk.columns = ['recency', 'frequency', 'monetary', 'risk_score']

# 业务分层规则（经风控委员会审批）
def customer_segment(row):
    if row['risk_score'] > 15:  # 高风险客户
        return 'High_Risk'
    elif row['monetary'] > 1.5 and row['frequency'] > 50:  # 高价值高活跃
        return 'Premium'
    elif row['monetary'] > 0.5 and row['frequency'] > 20:  # 中价值中活跃
        return 'Core'
    elif row['recency'] < 30:  # 近期有交易但价值一般
        return 'Potential'
    else:
        return 'Dormant'

rfm_risk['segment'] = rfm_risk.apply(customer_segment, axis=1)
print("客户分层结果分布：")
print(rfm_risk['segment'].value_counts())

实操心得：分层规则中的数字（15、1.5、50等）不是经验值，而是通过KS检验确定的最优分割点。我们用历史数据回测：将客户按 risk_score 从低到高排序，计算累计坏账率曲线，找到使好坏客户分离度最大的阈值。这样定的规则，模型AUC达0.82，远高于拍脑袋定的0.65。

3.7 第六层：监管报送聚合——G01-1附注格式生成

# 模拟监管报送要求：按行业（此处用category映射）、期限（短期/中长期）、担保方式（此处简化为有/无）三维汇总
# 业务映射表（真实项目中从监管字典库同步）
category_to_industry = {
    'Groceries': 'Wholesale_Retail', 'Dining': 'Accommodation_Catering',
    'Travel': 'Transportation', 'Retail': 'Wholesale_Retail',
    'Healthcare': 'Health_Social_Work'
}

df_report = df.copy()
df_report['industry'] = df_report['category'].map(category_to_industry)
df_report['term'] = 'Short_Term'  # 简化，实际按贷款合同
df_report['guarantee'] = 'Unsecured'  # 简化，实际按担保合同

# 三维聚合（注意：必须按监管要求顺序：industry→term→guarantee）
report_data = df_report.groupby(['industry', 'term', 'guarantee']).agg({
    'amount': 'sum',
    'fee': 'sum',
    'customer_id': 'nunique'
}).round(2)

# 重塑为监管要求的宽表格式（industry为行，term×guarantee为列）
# 先unstack两层
report_wide = report_data.unstack(['term', 'guarantee']).fillna(0)

# 重命名列，符合监管命名规范
report_wide.columns = ['_'.join(col).strip() for col in report_wide.columns.values]
report_wide = report_wide.rename(columns={
    'amount_Short_Term_Unsecured': 'loan_balance',
    'fee_Short_Term_Unsecured': 'provision_balance',
    'customer_id_Short_Term_Unsecured': 'customer_count'
})

print("监管报送格式数据（前5行）：")
print(report_wide.head())

提示：监管报送最怕列名不一致。我们用 '_'.join(col) 强制生成下划线连接的列名，再 rename() 映射到监管字典中的标准字段名。所有列名变更都记录在《报送字段映射日志》中，供审计追溯。

4. 高频问题排查与避坑指南：那些让老手也皱眉的细节

在银行做数据聚合，80%的时间花在解决“看似简单却死活不对”的问题上。以下是我在生产环境记录的TOP7问题，附带根因分析和一招制敌的解法。这些问题，文档不会写，但每个都可能让你加班到凌晨。

4.1 问题1： rolling().mean() 结果全是NaN，查了一小时发现是索引没设对

现象 ：对时间序列做滚动均值，输出全为NaN， df.index 显示是 RangeIndex 而非 DatetimeIndex 。

根因 ： rolling() 在 Series 上工作正常，但在 DataFrame 上必须指定 on 参数或确保索引是时间类型。更隐蔽的是，即使 df['date'] 是 datetime64 ，若未设为索引， df.groupby('id')['amount'].rolling(window=7) 仍会失败。

解法 ：三步强制校验

# 1. 确保date列是datetime类型
df['date'] = pd.to_datetime(df['date'])

# 2. 设为索引（推荐）
df = df.set_index('date')

# 3. 若必须保留date列为普通列，则显式指定on参数
df.groupby('id').rolling(window=7, on='date')['amount'].mean()

实操心得：我们在所有滚动计算前加了校验函数：

def validate_rolling_input(df, date_col):
    assert pd.api.types.is_datetime64_any_dtype(df[date_col]), f"{date_col} must be datetime type"
    assert not df[date_col].isnull().any(), f"{date_col} has null values"
    print("✓ Rolling input validated")

4.2 问题2： unstack() 后列名变成MultiIndex，下游系统读不了

现象 ： unstack() 后 result.columns 是 MultiIndex ，用 to_csv() 导出时列名变成 "('amount', 'sum')" 这样的字符串，BI工具无法识别。

根因 ： unstack() 默认保留层级结构，而CSV只支持扁平列名。

解法 ：用 droplevel() 或 map() 展平

# 方案1：删除外层（推荐，语义清晰）
result.columns = result.columns.droplevel(0)  # 删除'amount'层

# 方案2：用下划线连接所有层级
result.columns = ['_'.join(col) for col in result.columns.values]

# 方案3：指定聚合时就用扁平命名（最彻底）
result = df.groupby('category').agg(
    amount_sum=('amount', 'sum'),
    amount_mean=('amount', 'mean')
)

注意：方案3是pandas 0.25+的新语法，强烈推荐。它从源头避免MultiIndex，且列名语义明确，比 droplevel() 更安全。

4.3 问题3：自定义函数在 agg() 中报错“cannot concatenate”，但单独运行正常

现象 ： df.groupby('id').agg({'col': my_func}) 报 ValueError: cannot concatenate ，但 my_func(df[df['id']=='C001']['col']) 单独运行完美。

根因 ： agg() 传给函数的是 Series ，而你的函数内部用了 pd.DataFrame 方法（如 reset_index() ），或返回了非标量值（如 list 、 dict ）。

解法 ：函数必须返回标量或 pd.Series

# 错误示范：返回list
def bad_func(x):
    return x.tolist()  # 返回list，agg无法拼接

# 正确示范：返回标量或Series
def good_func(x):
    return x.mean()  # 标量

def good_func2(x):
    return pd.Series({'mean': x.mean(), 'std': x.std()})  # Series

提示：用 df.groupby().apply() 可返回任意结构，但性能差； agg() 要求严格，换来的是百倍性能提升。

4.4 问题4：多维groupby后 size() 和 count() 结果不同，哪个才是“笔数”？

现象 ： df.groupby(['a','b']).size() 返回100， df.groupby(['a','b']).count() 返回85，困惑哪个是真实交易笔数。

根因 ： size() 统计分组内所有行数（包括 NaN ）， count() 统计每列非空值数。若某行 c 列是 NaN ， count() 会跳过它。

解法 ：业务笔数永远用 size()

# 正确：交易笔数是行数，与字段是否为空无关
transaction_count = df.groupby(['region','product']).size()

# 错误：count()会漏掉含空值的交易
# transaction_count = df.groupby(['region','product'])['amount'].count()

实操心得：我们在所有“计数”场景统一用 size() ，并在代码注释中写明：“依据《银行业务数据统计规范》第4.1条，交易笔数指有效交易记录条数，不因字段缺失而减少”。

4.5 问题5： expanding().sum() 在数据开头出现巨大跳跃，趋势线失真

现象 ： expanding().sum() 结果中，第10行值突然比第9行大10倍，查看原始数据并无异常。

根因 ： expanding() 默认 min_periods=1 ，第1行=第1值，第2行=(第1+第2)/2，第3行=(第1+第2+第3)/3...但若第1值本身极大（如首笔50万交易），会导致初期均值被严重拉高。

解法 ：用 min_periods 设合理起点，并用 shift() 对齐

# 业务要求：至少5笔交易才开始计算累计均值
cumulative_mean = df.groupby('id')['amount'].expanding(
    min_periods=5
).mean().shift(1)  # shift(1)让第5笔交易对应第1个有效值

提示： shift(1) 是关键。它让结果从第5行开始有值，且第5行值=前5笔均值，符合业务“观察满5笔后才评估”的要求。

4.6 问题6：内存爆了！ groupby().agg() 卡死， htop 显示Python占95%内存

现象 ：对千万级数据做多维聚合，进程卡住，内存飙升至32GB。

根因 ： agg() 的字典映射会为每个字段-函数组合创建中间副本。10个字段×5个函数=50个副本，内存爆炸。

解法 ：分步聚合 + merge

# 错误：一步到位（内存杀手）
result = df.groupby('id').agg({
    'a': ['sum','mean'], 'b': ['max','min'], 'c': 'count'
})

# 正确：分步聚合，用字典存结果，最后merge
agg_dict = {}
agg_dict['a_sum'] = df.groupby('id')['a'].sum()
agg_dict['a_mean'] = df.groupby('id')['a'].mean()
agg_dict['b_max'] = df.groupby('id')['b'].max()
# ...其他

result = pd.DataFrame(agg_dict)  # 自动按index对齐

实操心得：分步法内存占用降为1/5，且便于调试——可单独检查 a_sum 是否正确，再合并。我们还加了内存监控：

import psutil
def log_memory():
    process = psutil.Process()
    print(f"Memory usage: {process.memory_info().rss / 1024 / 1024:.1f} MB")

4.7 问题7： rolling() 和 expanding() 在 groupby 后结果行数变少，丢失了部分客户

现象 ： df.groupby('id').rolling(window=7)['amount'].mean() 返回的行数比原始数据少200行。

根因 ： rolling() 在每个分组内独立计算，若某客户只有3笔交易，则 rolling(window=7) 无输出，该客户所有行都被丢弃。

解法 ：用 apply() 保持原始行数

# 保持原始行数，无窗口处填NaN
def safe_rolling(series, window=7):
    return series.rolling(window=window).mean()

result = df.groupby('id')['amount'].apply(safe_rolling).reset_index(name='rolling_avg')

注意： apply() 返回 Series ，需 reset_index() 重建索引。虽然性能略低，但保证了数据完整性——监管报送绝不允许丢失任何客户记录。

5. 工程化实践：如何把聚合逻辑变成可维护、可审计、可复用的资产

写一次聚合代码容易，让这段代码在三年后还能被新同事看懂、修改、审计，这才是真功夫。我在银行推行的“聚合代码工程化四原则”，已沉淀为团队开发规范。

5.1 原则一：聚合逻辑与业务规则分离——配置驱动一切

所有业务参数（如高风险阈值、滚动窗口天数、权重系数）不得硬编码在Python文件中，必须从配置中心加载：

# config.py
AGG_CONFIG = {
    "risk_threshold": 30000,  # 反洗钱阈值
    "rolling_window": 7,       # 运营监控窗口
    "category_weights": {
        "Dining": 1.0,
        "Travel": 1.5,
        "Luxury": 2.0
    }
}

# 在聚合函数中使用
def risk_metric(group):
    threshold = AGG_CONFIG["risk_threshold"]
    return (group['amount'] > threshold).sum()

优势：业务规则调整无需发版，配置中心修改后5分钟生效；所有参数变更留痕，满足监管审计要求。

5.2 原则二：每个聚合函数必须自带单元测试——用真实数据片段验证