多维聚合与滚动计算：银行级数据指标的生产实践

1. 项目概述：为什么多维聚合不是“加个groupby”就完事了？

我在银行数据平台组干了八年，从最早用SQL写几百行嵌套子查询做客户分层，到后来带团队重构整个风险指标计算引擎，踩过的坑比写的代码还多。今天聊的这个主题——“多维聚合中的数据操作”，听起来像教科书里的一个章节标题，但实际在生产环境里，它直接决定着风控模型能不能按时上线、月度经营分析报告能不能准时发出、甚至监管报送数据有没有偏差。我见过太多团队把 df.groupby().agg() 当成万能胶水，结果在千万级交易数据上跑出内存溢出，在跨季度滚动计算时发现时间窗口对不上，在给业务部门导出报表时被追问“为什么南区零售类目平均值和Excel里手动算的差0.3%”——最后查出来是 unstack() 没处理空值，自动填充了0，而业务逻辑里0和缺失值含义天差地别。

核心关键词就三个： 多维聚合、滚动计算、业务可解释性 。这不是炫技，而是生存技能。比如你手上有信用卡交易流水，业务方问：“过去90天，每个客户在餐饮、商超、旅游三类商户的消费金额中位数、单笔最大值、以及这三类消费占总消费的比重分别是多少？”——这问题里藏着四层嵌套：时间切片（90天）、客户维度、商户类型维度、指标维度（中位数/最大值/占比）。任何一个环节用错方法，结果就不可信。更现实的是，银行合规部要求所有指标计算逻辑必须可审计、可复现、可回溯，你不能只丢出一个 agg({'amount': 'median'}) ，还得说清楚median是怎么算的、遇到空值怎么处理、分位数插值用的是线性还是最近邻。

我带的新同事第一周任务就是重写一份老报表脚本。原脚本用5个独立的 groupby 分别算sum、mean、count、min、max，再用 pd.merge 拼起来，跑一次要47秒，且每次新增一个指标就得复制粘贴改三处。我们改成单次 agg() 字典映射，耗时压到6.2秒，代码行数减少60%，最关键的是——当运营同事质疑“为什么C001客户餐饮类平均消费是314.52而不是你们系统里显示的315.1？”时，我能直接打开函数定义，指着 np.median() 那一行说：“看，我们用的是numpy默认的线性插值，和你们Excel里PERCENTILE.INC一致。”这种确定性，才是数据工程师真正的护城河。

这篇文章不讲理论推导，只讲我在真实银行系统、支付风控平台、零售BI中反复验证过的七种硬核模式。每一种都配了可直接运行的代码、参数选择背后的业务逻辑、以及我亲手填过的坑。如果你正在为“指标越算越不准”、“报表越改越慢”、“业务方总说结果看不懂”发愁，接下来的内容就是你的解药。

2. 多维聚合的核心设计：为什么必须放弃“先group再merge”的旧思维

2.1 单次聚合的底层逻辑与性能真相

很多人以为 agg() 只是语法糖，其实它触发的是pandas底层完全不同的计算路径。当你写：

# ❌ 反模式：五次独立groupby
sum_amt = df.groupby('category')['amount'].sum()
mean_amt = df.groupby('category')['amount'].mean()
count_amt = df.groupby('category')['amount'].count()
min_amt = df.groupby('category')['amount'].min()
max_amt = df.groupby('category')['amount'].max()
result = pd.concat([sum_amt, mean_amt, count_amt, min_amt, max_amt], axis=1)

表面看逻辑清晰，实则灾难。pandas会对原始DataFrame扫描5次，每次都要重建分组索引、分配内存块、执行对应函数。在100万行数据上，这5次扫描的I/O开销和内存碎片化会吃掉70%以上的耗时。而正确写法：

# ✅ 生产级写法：单次聚合
result = df.groupby('category').agg({
    'amount': ['sum', 'mean', 'count', 'min', 'max'],
    'fee': ['sum', 'mean']
})

pandas会在一次扫描中，为每个分组同时计算所有指定函数。底层用Cython预分配好结果数组，避免Python循环的GIL锁争抢。我实测过某银行信用卡数据集（820万行），前者耗时214秒，后者仅需18.7秒——性能差距超过10倍。更关键的是， 结果一致性得到保障 ：所有指标基于完全相同的分组键和数据子集计算，不存在因中间步骤数据过滤导致的偏差。

提示： agg() 字典的键是列名，值可以是函数名字符串（如 'sum' ）、函数对象（如 np.sum ）、或函数列表。字符串形式最快，因为pandas有内置优化；自定义函数会稍慢，但换来的是业务逻辑的精确控制。

2.2 分层列名（MultiIndex）的实战处理技巧

单次聚合输出的列结构是 MultiIndex ，外层是原始列名，内层是聚合函数名。这在Jupyter里看着清爽，但对接下游系统时就是雷区。比如你要把结果写入数据库，字段名不能是 ('amount', 'mean') 这种元组。常见错误是粗暴用 result.columns = ['_'.join(col) for col in result.columns] ，结果生成 amount_mean 、 amount_count ，但业务方看到 amount_max 会困惑：“这是单笔最大值，还是日均最大值？”

我的标准处理流程分三步：

1. 语义化重命名 ：用业务语言替换技术术语
2. 空值安全处理 ： unstack() 前必须明确缺失值含义
3. 类型强制校验 ：避免 object 类型污染后续计算

# 步骤1：语义化重命名（关键！）
result = df.groupby(['customer_id', 'category']).agg({
    'amount': ['mean', 'median', 'count'],
    'fee': ['sum', 'mean']
})
# 将列名转为业务友好格式
result.columns = [
    'avg_transaction_amt', 
    'med_transaction_amt', 
    'transaction_count',
    'total_fee', 
    'avg_fee_per_txn'
]

# 步骤2：处理缺失值（以unstack为例）
# 错误示范：直接unstack()，缺失组合会变成NaN
crosstab = result.unstack('category')  # 生成MultiIndex列

# 正确做法：先填充再unstack，且填充值必须符合业务逻辑
# 例如：客户从未在某类商户消费，该类指标应为0（非缺失）
crosstab = result.fillna(0).unstack('category')

# 步骤3：类型校验（防止后续计算报错）
crosstab = crosstab.astype({
    'avg_transaction_amt': 'float32',  # 节省内存
    'transaction_count': 'uint32'       # 非负整数用无符号类型
})

注意： fillna(0) 不是万能的。在风控场景中，“客户无跨境交易”和“系统未采集到跨境交易”意义完全不同。这时要用 fillna(pd.NA) 保持缺失语义，并在后续SQL或BI工具中显式处理 IS NULL 逻辑。

2.3 多维分组的陷阱：当groupby键包含空值时

最隐蔽的坑在这里： groupby 默认会 丢弃所有含空值的行 。假设你的 region 字段有2%的空值， df.groupby('region') 后数据量直接少2%，但没人告诉你！更糟的是，如果空值集中在高价值客户群，你的区域分析结论就全偏了。

解决方案只有两个：

• 显式保留空值组 ：用 dropna=False 参数
• 业务层主动归因 ：把空值归入“未知区域”或“待核实”类别

# ✅ 强制保留空值组
result = df.groupby('region', dropna=False).agg({'amount': 'sum'})
# 输出中会出现 (region = NaN) 的行

# ✅ 更推荐：业务归因（示例）
df['region_clean'] = df['region'].fillna('UNKNOWN_REGION')
result = df.groupby('region_clean').agg({'amount': 'sum'})

# ⚠️ 绝对禁止：df.dropna(subset=['region']) 后再groupby
# 这等于主动删除数据，审计时无法追溯原始样本

我在某次监管检查中就被问到：“贵行报告中‘其他地区’客户数为何比CRM系统少17%？”追查发现上游ETL脚本用了 dropna=True ，而CRM把未识别地址全标为 OTHER 。从此我们所有分组操作都加 dropna=False ，并在数据字典里明确定义空值业务含义。

3. 自定义聚合函数：把业务规则刻进代码里

3.1 Lambda够用吗？为什么我坚持用命名函数

看到 agg({'amount': lambda x: x.max() - x.min()}) ，新手会觉得很酷。但在我维护的生产系统里，这种写法会被立即打回。原因有三：

• 不可调试 ：报错时栈追踪只显示 <lambda> ，你得翻遍代码找是哪个lambda
• 不可复用 ：同样计算范围值，风控模块和报表模块各写一个lambda，未来修改阈值要改两处
• 不可文档化 ：lambda里没法写docstring，半年后连你自己都不记得为什么用 max()-min() 而不是 quantile(0.95)-quantile(0.05)

所以我的铁律是： 所有业务逻辑必须封装为命名函数，且函数名即业务术语 。

def transaction_range(series):
    """
    计算交易金额范围值（最大值-最小值）
    【业务背景】用于识别高波动商户类别，波动率>150%的类别需加强实时监控
    【数据要求】输入series必须为数值型，空值已由上游清洗
    """
    if series.empty:
        return np.nan
    return series.max() - series.min()

# 在agg中调用
result = df.groupby('category').agg({'amount': transaction_range})

这个函数的价值远超计算本身。当合规部来查“商户波动率指标定义”时，我直接甩出函数链接；当新同事问“为什么餐饮类波动率突然升高”，我打开函数看注释里的业务背景；当需要升级为“剔除异常值后的范围”，我只需改函数内部逻辑，所有调用点自动生效。

3.2 加权平均的实战：如何让“最近交易”说话

银行风控有个经典需求：客户近期交易行为比历史行为更能反映当前风险。简单用 mean() 会把3年前的交易和昨天的交易同等加权，显然不合理。我们采用 线性加权 ，权重随时间衰减：

def time_weighted_avg(series, date_series, half_life_days=30):
    """
    基于时间衰减的加权平均（半衰期模型）
    【业务逻辑】距离当前越近的交易，权重越大；半衰期30天意味着1个月前的交易权重减半
    【实现原理】权重 = 2^(-t/half_life)，t为距最新交易的天数
    """
    if len(series) < 2:
        return series.mean()
    
    # 确保date_series是datetime类型
    dates = pd.to_datetime(date_series)
    latest_date = dates.max()
    days_diff = (latest_date - dates).dt.days
    
    # 计算衰减权重
    weights = np.power(2, -days_diff / half_life_days)
    
    # 加权平均（处理权重和为0的边界情况）
    if weights.sum() == 0:
        return series.mean()
    return np.average(series, weights=weights)

# 使用示例
df_sorted = df.sort_values('date')
result = df_sorted.groupby('customer_id').apply(
    lambda x: time_weighted_avg(x['amount'], x['date'])
)

这里的关键细节： 半衰期30天不是拍脑袋定的 。我们通过A/B测试发现，当半衰期设为30天时，欺诈交易识别的F1-score最高。这个参数必须和业务目标对齐，而不是技术最优。

实操心得：永远在函数里加 if len(series) < 2: 保护。生产数据总有意外，比如新注册客户只有1笔交易， np.average() 会报错，而 series.mean() 返回合理值。

3.3 复杂条件聚合：风险分层的代码实现

业务方常提这种需求：“把客户按单笔交易额>300元的频次分成三档：高频（≥5次）、中频（1-4次）、低频（0次），并计算各档客户的平均交易额。”这用SQL要写CASE WHEN嵌套，用pandas一行 agg() 就能搞定：

def risk_segmentation(series):
    """
    客户风险分层：基于高价值交易频次
    【分层规则】
      - 高频：单笔>300元的交易≥5次 → 标签'HIGH'
      - 中频：单笔>300元的交易1-4次 → 标签'MEDIUM'
      - 低频：无单笔>300元交易 → 标签'LOW'
    【返回】Pandas Series，含分层标签和对应平均交易额
    """
    high_value_count = (series > 300).sum()
    
    if high_value_count >= 5:
        label = 'HIGH'
        avg_amt = series.mean()  # 全量平均
    elif high_value_count >= 1:
        label = 'MEDIUM'
        avg_amt = series.mean()
    else:
        label = 'LOW'
        avg_amt = series.mean()
    
    return pd.Series({
        'risk_label': label,
        'avg_transaction_amt': round(avg_amt, 2),
        'high_value_count': high_value_count
    })

# 应用到分组
risk_result = df.groupby('customer_id')['amount'].apply(risk_segmentation)

这个函数的威力在于： 把业务规则翻译成可执行、可测试、可审计的代码 。当业务规则变更（比如把300元阈值提到500元），你只需改函数里一个数字，全系统自动更新。而SQL方案要改存储过程、改调度脚本、改报表SQL，漏改一处就出问题。

4. 滚动与扩展窗口：时间维度的正确打开方式

4.1 滚动窗口的三大生死线

滚动计算（rolling）看似简单，但生产环境里90%的问题都源于没守住这三条线：

• 时间对齐线 ：窗口必须按业务时间对齐，而非物理顺序
• 空值处理线 ：NaN不是bug，是业务信号
• 性能边界线 ：窗口大小必须有上限

时间对齐线：为什么 sort_values('date').rolling(7) 是错的？

错误代码：

# ❌ 危险！按物理顺序滚动，忽略日期连续性
df_sorted = df.sort_values('date')
df_sorted['7day_avg'] = df_sorted['amount'].rolling(7).mean()

问题：如果某客户在1月1日、1月3日、1月5日有交易， rolling(7) 会取最近7行（可能跨客户！），而非最近7天。正确做法必须用 time-based rolling ：

# ✅ 按时间滚动（关键！）
df_time = df.set_index('date').sort_index()
# 对每个客户单独滚动计算
df_time['7day_avg'] = df_time.groupby('customer_id')['amount'].rolling('7D').mean().reset_index(level=0, drop=True)

'7D' 表示7个日历日，pandas会自动处理周末、节假日。我曾因用 window=7 导致某银行周末交易监控失效——系统把周五、周六、周日三天交易算作“7天滚动”，实际只覆盖3天，漏掉大量异常。

空值处理线：NaN是业务事实，不是计算错误

滚动计算首N行必为NaN，这是数学必然。但业务上， 首3天无滚动均值，不等于“数据缺失” 。某次我们把NaN全 ffill() ，结果风控模型把新客户第一天的交易误判为“趋势上升”，因为用前一天的NaN填充后变成了0，导致 0→1200 被识别为暴涨。

正确策略是： 根据业务场景选择填充逻辑

性能边界线：窗口大小必须可控

rolling(window=365) 在百万级数据上会OOM。我们的解决方案是： 用 min_periods 参数设置最小有效窗口 ：

# ✅ 安全写法：至少需要3天数据才计算
df_time['30day_avg'] = df_time.groupby('customer_id')['amount'].rolling(
    '30D', 
    min_periods=3  # 少于3天数据返回NaN，不强行计算
).mean().reset_index(level=0, drop=True)

这样既保证计算质量，又避免小样本噪声。某次我们去掉 min_periods ，导致某客户只有2天交易就被算出“30天均值”，数值极不稳定，引发业务投诉。

4.2 扩展窗口：累计指标的审计陷阱

扩展窗口（expanding）常用于YTD（年初至今）指标，但最大的坑是： 它默认从数据集首行开始累积，而非业务年度首日 。

错误示范：

# ❌ 从数据第一条记录开始累积，可能跨年度
df_sorted['ytd_sum'] = df_sorted.groupby('customer_id')['amount'].expanding().sum()

正确做法必须 按业务周期切分 ：

# ✅ 按自然年分组累积
df['year'] = pd.to_datetime(df['date']).dt.year
df_yearly = df.sort_values(['customer_id', 'date'])
df_yearly['ytd_sum'] = df_yearly.groupby(['customer_id', 'year'])['amount'].expanding().sum()

更进一步，银行常用财年（4月1日-3月31日），这时要用 pd.Grouper ：

# ✅ 按财年累积（起始日：4月1日）
df['fiscal_year'] = pd.to_datetime(df['date']).dt.to_period('Q-MAR').dt.start_time.dt.year
# 或直接用时间分组
df_yearly = df.set_index('date').sort_index()
df_yearly['fy_cumsum'] = df_yearly.groupby('customer_id')['amount'].expanding(
    # 按财年重置累积
    method='table'  # pandas 1.4+ 支持
).sum()

注意： expanding() 的 method='table' 参数在旧版pandas不支持，必须升级。我们线上环境统一要求pandas>=1.4.0，否则无法保证财年计算准确。

4.3 滚动+分组+重采样的组合拳

真实场景中，滚动计算常和重采样（resample）结合。比如“每个客户每周的滚动3周平均交易额”：

# 步骤1：按客户+周分组，计算周度汇总
df_weekly = df.set_index('date').groupby(['customer_id', pd.Grouper(freq='W-SUN')]).agg({
    'amount': 'sum',
    'transaction_count': 'count'
}).reset_index()

# 步骤2：对每个客户，计算滚动3周均值
df_weekly['3week_avg_amt'] = df_weekly.groupby('customer_id')['amount'].rolling(3).mean().reset_index(level=0, drop=True)

# ✅ 关键：重采样后必须reset_index，否则rolling会跨客户

这个组合的价值在于： 降噪+对齐+可解释 。原始日粒度数据波动太大，周粒度更稳定；滚动3周能平滑短期异常；结果直接对应业务汇报周期（周报）。

5. 多级分组与透视：让业务方一眼看懂的数据形态

5.1 unstack的致命误区：为什么“行列互换”不是目的

很多教程教 unstack() 就止步于“把行变列”，但生产中真正重要的是： 如何让透视结果承载业务语义 。

看这个反例：

# ❌ 问题代码：unstack后列名混乱
result = df.groupby(['region', 'product'])['revenue'].mean()
crosstab = result.unstack()  # 列名是('revenue',) + MultiIndex

输出列名是 ('revenue', 'Widget') ，业务方根本看不懂。正确流程必须包含三步：

1. 预处理分组键 ：确保键值有业务含义
2. 语义化列名 ：用 rename_axis() 和 columns.set_names()
3. 空值业务化 ： fill_value 必须是业务可接受的默认值

# ✅ 标准流程
# 步骤1：清洗分组键（示例：标准化地区名称）
df['region_std'] = df['region'].map({
    'North': '华北', 'South': '华南', 
    'East': '华东', 'West': '西部'
}).fillna('其他')

# 步骤2：分组并语义化索引名
result = df.groupby(['region_std', 'product'])['revenue'].mean()
result.index.names = ['销售大区', '产品线']  # 中文索引名，业务方秒懂

# 步骤3：unstack并设置列名
crosstab = result.unstack('产品线', fill_value=0)  # 0代表“该大区无此产品销售”
crosstab.columns.name = '产品线'  # 列头名称

# 步骤4：添加总计行/列（业务刚需）
crosstab.loc['总计'] = crosstab.sum()
crosstab['总计'] = crosstab.sum(axis=1)

这样产出的表格，业务总监可以直接截图放进PPT，不用再解释“index level 0是什么”。

5.2 pivot_table vs groupby+unstack：何时该用哪个？

新手常纠结选哪个。我的经验法则：

• 用 pivot_table ：当需要同时做分组、聚合、透视三件事，且数据有重复键
• 用 groupby+unstack ：当分组逻辑复杂（需多列组合、自定义函数），或需链式操作

# ✅ pivot_table适用场景：简单聚合+透视
# 数据有重复(customer_id, date)，需先聚合再透视
df_pivot = df.pivot_table(
    index='customer_id',
    columns='category',
    values='amount',
    aggfunc='sum',  # 自动处理重复键
    fill_value=0
)

# ✅ groupby+unstack适用场景：复杂聚合
# 需要同时算sum、mean、count，且用自定义函数
result = df.groupby(['customer_id', 'category']).agg({
    'amount': ['sum', 'mean'],
    'fee': 'sum'
})
crosstab = result.unstack('category', fill_value=0)

关键区别： pivot_table 的 aggfunc 只支持单一函数，而 groupby.agg() 支持字典映射。当业务要求“每个客户在各类商户的交易总额+平均单笔+手续费总和”， pivot_table 做不到，必须用 groupby+unstack 。

5.3 多维透视的终极形态：Panel Data结构

当业务问题涉及三个及以上维度（如：客户×产品×时间×地区）， unstack 会生成四层 MultiIndex ，阅读困难。此时应转向 面板数据（Panel Data）结构 ：

# 构建三维透视：客户×产品×时间（周）
df['week'] = df['date'].dt.isocalendar().week
panel = df.groupby(['customer_id', 'product', 'week'])['amount'].sum().unstack(['product', 'week'])

# ✅ 更优：转为DataFrame with MultiIndex columns，再用xs()切片
# 业务方要查“C001客户所有产品的第10周数据”
week10_data = panel.xs('C001', level='customer_id')[10]  # 直接获取第10周

# ✅ 或用query()动态筛选
high_value_weeks = panel.query('week in [10, 11, 12]').loc['C001']

面板结构的优势是： 支持任意维度切片 。业务方说“把华东地区所有客户在旅游类产品的月度趋势图给我”，你一句 panel.xs('华东', level='region').xs('旅游', level='category').plot() 就搞定，不用重新写聚合逻辑。

6. 端到端实战：银行信用卡客户分析流水线

6.1 业务需求拆解：七个问题对应七种技术

我们以文章末尾的端到端案例为基础，但注入真实银行场景的血肉。某银行信用卡中心提出以下需求，我逐条映射到技术方案：

注意：所有方案都遵循同一原则—— 计算逻辑与业务定义100%对齐 。比如手续费占比，业务定义是 总手续费/总消费*100% ，就必须用 summary['total_fees']/summary['total_spend']*100 ，而不能用 mean(fee_rate) ，因为后者是平均费率，前者是实际成本占比。

6.2 生产环境加固：从脚本到服务的三道防线

在Jupyter里跑通不等于生产可用。我把这个分析流水线部署到银行数据平台时，加了三道防线：

防线一：数据质量门禁（Data Quality Gate）

在计算前插入质量检查，失败则中断并告警：

def data_quality_check(df):
    """生产级数据质量检查"""
    checks = {
        'date_range': len(df['date'].unique()) >= 30,  # 至少30天数据
        'null_amount': df['amount'].isnull().sum() == 0,  # 金额不能为空
        'valid_category': df['category'].isin(['Groceries','Dining','Travel','Retail']).all(),
        'customer_count': df['customer_id'].nunique() >= 100  # 至少100客户
    }
    
    failed_checks = [k for k, v in checks.items() if not v]
    if failed_checks:
        raise ValueError(f"数据质量检查失败: {failed_checks}")
    return True

# 在流水线开头调用
data_quality_check(df_transactions)

防线二：内存与超时控制

用 resource 模块限制资源，防止单次计算拖垮集群：

import resource

def limit_resources():
    """限制进程资源使用"""
    # 内存限制：2GB
    resource.setrlimit(resource.RLIMIT_AS, (2 * 1024**3, -1))
    # CPU时间限制：300秒
    resource.setrlimit(resource.RLIMIT_CPU, (300, -1))

limit_resources()

防线三：结果校验与黄金数据集比对

每次运行后，自动与上期结果比对，偏差超阈值则告警：

def result_validation(new_result, old_result, threshold=0.05):
    """结果合理性校验"""
    # 检查总量偏差
    total_new = new_result['total_spend'].sum()
    total_old = old_result['total_spend'].sum()
    if abs(total_new - total_old) / total_old > threshold:
        send_alert(f"总消费额偏差{abs(total_new-total_old)/total_old:.2%}，超阈值{threshold}")
    
    # 检查客户数是否异常波动
    if abs(len(new_result) - len(old_result)) / len(old_result) > 0.1:
        send_alert(f"客户数波动{abs(len(new_result)-len(old_result))/len(old_result):.0%}，超10%")

# 调用
result_validation(current_summary, last_summary)

这三道防线让我负责的指标计算服务连续3年SLA 99.99%，故障平均恢复时间<2分钟。

6.3 交付物设计：不只是代码，更是业务资产

最终交付给业务方的不是.py文件，而是：

• 可执行的Jupyter Notebook ：含每步计算说明、业务背景、结果解读
• 指标字典（Markdown） ：每个字段的业务定义、计算逻辑、数据源、更新频率
• SQL对照版 ：关键指标的等效SQL，供DBA审核和迁移
• 测试用例集 ：用pytest写的单元测试，验证边界场景

例如 transaction_range() 函数，配套交付：

## 指标：商户交易波动率
- **业务定义**：单客户在某商户类别的最大单笔交易额与最小单笔交易额之差，用于识别高风险商户
- **计算逻辑**：MAX(amount) - MIN(amount)，空值按0处理
- **数据源**：信用卡交易表（ods_credit_card_txn）
- **更新频率**：T+1日 02:00
- **SQL等效**：
  ```sql
  SELECT category, MAX(amount) - MIN(amount) AS transaction_range
  FROM ods_credit_card_txn 
  GROUP BY category

这样，当业务方说“为什么这个数和我们系统不一样”，我们能立刻定位到是数据源版本差异，而非计算错误。

## 7. 常见问题与避坑指南：那些没写在文档里的教训

### 7.1 “为什么我的rolling计算结果和Excel不一样？”

这是最高频问题。根源几乎全是**时间对齐方式不同**。Excel的`AVERAGEIFS`默认按日期范围筛选，而pandas `rolling('7D')`是按时间戳滚动。解决方案：

- **确认时间精度**：Excel可能用日期（2024-01-01），pandas用时间戳（2024-01-01 00:00:00），导致边界误差  
- **统一时间截断**：`df['date'] = df['date'].dt.date` 或 `df['date'] = pd.to_datetime(df['date']).dt.floor('D')`  
- **验证样本**：取一个客户7天内的完整交易记录，手动算平均，和代码结果逐行比对  

我曾为这个问题调试8小时，最后发现是测试数据里有一笔交易时间是`2024-01-01 23:59:59`，而pandas `rolling('7D')`把它算进了1月1日窗口，Excel的`=AVERAGEIFS()`因日期格式截断算成了1月1日0点，导致结果差0.01元。

### 7.2 “unstack()后列顺序乱了，怎么固定？”

`unstack()`默认按字典序排序列，但业务要求可能是“餐饮、商超、旅游、零售”。解决方案：

```python
# ✅ 固定列顺序
desired_order = ['Dining', 'Groceries', 'Travel', 'Retail']
crosstab = crosstab.reindex(columns=desired_order, fill_value=0)

更彻底的方案是在分组前就排序：

# 分组前按业务顺序排序
df['category_ordered'] = pd.Categorical(
    df['category'], 
    categories=['Dining', 'Groceries', 'Travel', 'Retail'],
    ordered=True
)
result = df.groupby(['customer_id', 'category_ordered'])['amount'].mean().unstack()

7.3 “自定义函数里用np.random.seed(42)为什么每次结果不同？”

这是pandas的 apply() 机制导致的。 apply() 会将Series分块传递给函数，每块都执行 seed(42) ，导致随机数序列被重置。正确做法：

• 避免在聚合函数中用随机 ：聚合必须是确定性的
• 如需随机采样，用 sample() 代替 random ： series.sample(n=10, random_state=42)

7.4 “内存爆了，怎么优化大表聚合？”

当数据超500万行，按以下优先级优化：

1. 列裁剪 ： df = df[['customer_id','category','amount','date']] ，删掉无关列
2. 类型压缩 ： df['customer_id'] = df['customer_id'].astype('category') ， df['amount'] = df['amount'].astype('float32')
3. 分块处理 ：`for chunk in pd.read_csv('data.csv', chunk