当前位置：首页 > news >正文

pandas多维聚合实战：解决银行风控与财务报表中的指标失真问题

news 2026/6/18 10:32:20

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

我在银行数据平台组干了八年，从最早用SQL写几十行嵌套子查询做客户分层，到后来在Spark上跑PB级交易流水，再到如今带团队设计实时风控指标引擎——所有这些经历反复验证一件事：真正决定分析深度的，从来不是数据量有多大，而是你对聚合逻辑的理解有多细。这篇文章讲的“多维聚合”，不是教你怎么敲df.groupby().sum()，而是解决那些让业务方拍桌子说“这结果不对”的真实场景：为什么同一个客户在不同报表里“平均交易额”差了37%？为什么风控模型上线后突然把2000个正常商户标成高风险？为什么财务月报和BI看板的“区域收入”永远对不上？这些问题的根子，全出在聚合环节——你没意识到mean()在跨维度时会悄悄丢失权重，没考虑时间窗口移动时首尾数据的截断效应，更没想过unstack()之后那个看似整齐的矩阵，其实已经把“North Retail”和“South Retail”当成完全独立的两个实体来处理，彻底抹掉了它们同属“Retail”品类的业务关联性。

我见过太多人把pandas当Excel用：导进数据→点几下groupby→导出CSV→发邮件。这种操作在样本测试时没问题，一旦进生产环境，轻则报表延迟、指标漂移，重则触发错误预警、影响信贷审批。比如去年我们一个合作银行的反欺诈系统，就因为滚动窗口没设min_periods=3，导致新商户前两天全是NaN，风控规则直接跳过校验，三天内漏检了17笔盗刷交易。这不是代码bug，是聚合思维没跟上业务节奏。这篇文章里所有案例，都来自我亲手调优过的生产系统：某股份制银行信用卡中心的客户价值分群模型、某保险集团偿付能力监测平台的多层级准备金归集逻辑、还有我们自己SaaS风控中台的实时交易特征计算引擎。它们共同指向一个事实——高级聚合的本质，是把业务规则翻译成可执行、可审计、可扩展的数据操作链。你不需要记住所有函数名，但必须理解：什么时候该用agg()字典映射而不是链式调用，为什么自定义函数里要显式处理空序列，滚动窗口的center=False和min_periods=1在什么场景下会引发指标失真。接下来的内容，我会像带新人一样，把每个操作背后的“业务意图”和“技术陷阱”掰开揉碎讲清楚。你不需要是pandas专家，但得是个能听懂业务需求、敢对着指标偏差追到底的数据实践者。

2. 核心思路拆解：五类聚合模式如何对应真实业务问题

2.1 为什么“多列不同聚合”是生产环境的刚需，而非炫技？

先看一个血泪教训：去年帮一家城商行重构对公客户存款分析模块时，业务方提的需求是：“我要看到每个行业客户的日均存款余额、存款波动率（标准差）、以及最近30天最大单笔转入金额”。表面看是三个指标，但背后逻辑完全不同：日均余额需要按客户ID分组后对每日余额取均值；波动率要求同一客户所有日余额序列的标准差；而最大单笔转入则必须穿透到每笔交易明细里找MAX。如果用传统方式——先算均值存表A，再算标准差存表B，最后查交易流水取MAX存表C，再JOIN三张表……光ETL调度就卡死。更致命的是，当客户当天有100笔交易时，“最大单笔转入”这个值会被重复计算100次，导致后续按行业汇总时严重高估。

pandas的agg()字典映射正是为这种场景而生。它不是简单并行计算，而是在一次分组扫描中完成所有聚合逻辑的原子化执行。关键在于理解其底层机制：pandas会为每个分组构建一个临时数据块，然后对指定列分别应用对应函数。这意味着transaction_amount列的['mean','median']和processing_fee列的['min','max']是在同一组数据上独立运算，不存在跨列干扰。更重要的是，这种写法天然规避了“中间表膨胀”问题——没有冗余字段，没有重复键，输出结果直接是扁平化的DataFrame，下游系统消费零成本。

提示：别被输出的MultiIndex吓住。那个两层列名（如transaction_amount -> mean）不是bug，是pandas刻意保留的元信息。当你需要导出到BI工具时，用result.columns = ['_'.join(col).strip() for col in result.columns.values]一行就能压平；若要对接API，result.reset_index().to_dict('records')直接转JSON。强行用pd.concat()拼接多个groupby结果，只会让代码越来越难维护。

2.2 自定义函数：当业务规则无法用内置函数表达时

内置函数覆盖80%场景，但剩下20%恰恰是业务护城河所在。比如风控中的“动态阈值”：对餐饮类商户，交易金额超过当日均值2倍且大于500元才报警；对珠宝类，则是均值3倍且大于2000元。这种带条件分支、依赖分组内统计量的逻辑，lambda x: x.max()-x.min()根本搞不定。

这里有两个致命误区：第一，用apply()替代agg()。apply()会对每个分组返回一个Series，再由pandas拼接，性能比agg()慢3-5倍；第二，忽略空序列处理。当某个商户当天只有一笔交易时，x.std()会返回NaN，但业务上这笔交易就是“波动率为0”，必须显式处理。

我坚持用命名函数而非lambda，原因有三：一是函数名即文档，def risk_adjusted_std(series)比lambda x: np.std(x) * (1 + len(x)/100)直观十倍；二是便于单元测试，你可以单独传入[100,200,300]验证逻辑；三是支持复杂状态管理，比如计算加权平均时需要生成权重向量，命名函数里可以加注释说明“权重按交易时间倒序分配，最新交易权重1.5，最旧0.5”。

注意：自定义函数的输入参数一定是pandas Series，不是DataFrame。如果你需要访问多列（如用交易金额和手续费一起算费率），必须用groupby(...).apply(lambda x: your_func(x))，此时x是DataFrame子集。但要注意性能损耗——apply()会失去pandas的向量化优势。

2.3 滚动窗口：时间敏感型分析的“滑动镜头”

滚动窗口的核心价值，是给静态聚合注入时间维度。但很多人没意识到：滚动计算不是数学题，而是业务决策的快照。比如反欺诈中的“7日滚动大额交易占比”，业务含义是“最近7天内，单笔超5000元交易占总交易笔数的比例”。如果窗口设为window=7但不排序，pandas会按原始索引顺序取7行，而原始数据可能是按商户ID排序的，结果算出来的是“某商户连续7笔交易”的占比，完全偏离业务本意。

正确姿势是三步走：先sort_values('date')确保时序正确；再set_index('date')激活时间索引；最后用rolling('7D')（推荐）或rolling(window=7)。前者按日历天数滚动（自动跳过非交易日），后者按行数滚动（适合高频交易）。更关键的是min_periods参数——设为1意味着首日就出值（用当日数据），设为7则前6天全NaN。我们生产系统一律设min_periods=3：既保证基础稳定性，又避免早期数据失真误导策略。

另一个隐藏坑是reset_index(level=0, drop=True)。很多教程直接复制粘贴这行，却不知它会丢弃分组键。正确做法是：df.groupby('category')['revenue'].rolling(window=3).mean().droplevel(0)，这样保留了category信息，后续可直接merge回原表。

2.4 扩展窗口：累计指标的“时间锚点”设计

扩展窗口和滚动窗口常被混淆，但业务语义截然不同。滚动窗口回答“最近N天怎样”，扩展窗口回答“从开始到现在怎样”。比如“客户生命周期总消费”必须用扩展窗口，因为它的基准点是客户首次交易日，而非当前日期。

这里有个反直觉的设计：expanding().sum()默认从第一行开始累加，但业务上往往需要“按自然周期重置”。例如银行要求“季度累计交易额”，就不能用全局expanding，而要先df['quarter'] = df['date'].dt.to_period('Q')，再groupby(['customer_id','quarter'])['amount'].expanding().sum()。否则会出现Q1累计值包含Q2数据的荒谬结果。

实操中我发现，90%的累计指标错误源于未处理初始值。比如计算“累计交易笔数”，第一笔交易后应为1，但expanding().count()在单行时返回1，没问题；而expanding().mean()在单行时返回该值本身，也合理。但expanding().std()在单行时返回NaN（标准差无意义），这时必须用expanding().std(ddof=0)强制计算，并补充.fillna(0)。这些细节，业务方不会告诉你，但会直接体现在报表的“异常值告警”里。

2.5 多级分组与unstack：从数据结构到业务认知的跃迁

groupby(['region','product'])['revenue'].mean().unstack()这行代码，表面是技术操作，实质是将业务关系映射为数据结构。unstack()把内层索引（product）转为列，外层索引（region）转为行，生成的矩阵天然符合“区域×产品”二维决策模型。但很多人没想透：为什么不用pivot_table()？因为pivot_table()需要指定values列，而unstack()直接作用于Series的MultiIndex，更轻量，且保留了分组时的原始数据类型（如int64不会被转成float64）。

真正的挑战在unstack之后。比如销售分析中，North区Gadget产品缺数据，unstack后变成NaN。业务上这是“无销售”，但财务系统可能要求填0。这时unstack(fill_value=0)比后续fillna(0)更高效。更深层的问题是维度爆炸：当加入第三个维度（如groupby(['region','product','channel'])），unstack两次会生成Panel结构，pandas已弃用。此时必须用pivot_table(index=['region','product'], columns='channel', values='revenue', aggfunc='mean')，并接受其内存开销更大的事实。

实操心得：永远用df.groupby([...]).size()先探查分组分布。如果某组合合只有1条记录，unstack后该单元格必为NaN，需提前用dropna=False或fill_value处理。我见过因未检查稀疏性，导致BI看板显示“South区Widget产品销售额为0”，实际是数据缺失，引发区域经理投诉的事故。

3. 实操细节与避坑指南：从代码到生产的完整链路

3.1 多列聚合的工程化实现：如何避免MultiIndex带来的维护噩梦

多列聚合输出的MultiIndex看似优雅，但在生产环境中是隐形炸弹。想象一下：你的日报脚本每天凌晨2点运行，输出一个含12个指标的报表。三个月后，运营同事说“把‘平均手续费’改成‘手续费中位数’”，你打开代码发现这一行：

result = df.groupby('merchant_category').agg({ 'transaction_amount': ['mean','median'], 'processing_fee': ['min','max'] })

看起来只需改'processing_fee': ['min','max']为['median']，但执行后报错：KeyError: ('processing_fee', 'median')。为什么？因为agg()返回的列名是('processing_fee','min')和('processing_fee','max')，当你只留一个时，pandas仍试图构建MultiIndex，但单元素元组不被识别。

解决方案分三级：

初级：用result[('processing_fee','min')]硬编码访问，但耦合度高，改名即崩；
中级：result.columns = ['_'.join(col) for col in result.columns]压平列名，后续用result['processing_fee_min']访问，安全但丢失语义；
高级：用pd.NamedAgg（pandas 0.25+）：

result = df.groupby('merchant_category').agg( amount_mean=pd.NamedAgg(column='transaction_amount', aggfunc='mean'), amount_median=pd.NamedAgg(column='transaction_amount', aggfunc='median'), fee_min=pd.NamedAgg(column='processing_fee', aggfunc='min') )

输出列名直接是amount_mean、amount_median，语义清晰，修改任意aggfunc不影响其他列名。

注意：NamedAgg不支持列表式聚合（如同时要mean和std），此时必须回归字典映射+列名压平方案。我的经验是：核心指标用NamedAgg保稳定，辅助指标用字典映射+自动化列名清洗。

3.2 自定义函数的健壮性加固：处理边界情况的七种武器

自定义函数在生产环境必须通过“压力测试”。以下是我在银行系统中总结的七种必处理场景及代码模板：

场景	问题表现	解决方案	代码片段
空分组	`groupby().apply()`遇到无数据分组时报错	用`if len(series) == 0: return np.nan`兜底	`def safe_std(series): return series.std() if len(series) > 1 else np.nan`
单值分组	`std()`、`skew()`等函数在单值时返回NaN	强制`ddof=0`并设默认值	`series.std(ddof=0) if len(series) > 1 else 0`
极端值	交易金额含负数（退款）导致均值失真	预过滤或业务逻辑判断	`series[series > 0].mean()`
数据类型	字符串列误参与数值聚合	类型校验	`if not pd.api.types.is_numeric_dtype(series): raise TypeError("非数值列")`
内存溢出	大分组（如百万级客户）计算中位数卡死	改用`quantile(0.5)`替代`median()`	`series.quantile(0.5)`更快更省内存
时序依赖	加权平均需按时间排序，但分组内未排序	在函数内`sort_index()`	`series.sort_index().values`
精度损失	金融计算要求小数点后2位，但`mean()`返回长浮点	显式`round(2)`	`round(series.mean(), 2)`

特别强调第7点：金融场景中，np.float64的精度误差在累加10万次后可达0.01元，必须用decimal或round()控制。我曾修复过一个基金估值系统，因未round导致季度分红差0.3分钱，被合规部叫停上线。

3.3 滚动窗口的工业级配置：从参数选择到结果校验

滚动窗口不是调个window参数就完事。以下是生产环境必须配置的五要素：

窗口类型选择：
- rolling(window=7)：按行数滚动，适合固定频率数据（如日交易）
- rolling('7D')：按日历滚动，自动跳过周末/节假日，适合业务日历
- rolling('30T')：按30分钟滚动，适合实时风控（需set_index('timestamp')）
min_periods黄金法则：
- 业务允许容忍：设为window//2 + 1（如7日窗设4）
- 严格不可缺：设为window（前N-1天全NaN）
- 我的默认：min_periods=3，平衡稳定性与及时性
center参数陷阱：
- center=False（默认）：窗口左对齐，第7天出第1-7天均值
- center=True：窗口居中，第4天出第1-7天均值 →会导致时间错位！反欺诈中“今日滚动均值”若用center=True，实际是“3天前的均值”，策略完全失效
闭包处理：
- closed='left'：窗口不包含右边界（推荐，避免未来数据泄露）
- closed='right'：包含右边界（默认），但若数据有延迟，可能引入脏数据
结果校验三板斧：
- 手工验算：取前10行数据，用Excel算滚动均值对比
- 边界检查：result.iloc[6]['rolling_avg'] == df.iloc[0:7]['daily_revenue'].mean()
- 空值审计：result['rolling_avg'].isna().sum()必须等于min_periods-1

实操心得：在脚本开头加校验函数：

def validate_rolling_result(result_col, window, min_periods): assert result_col.isna().sum() == min_periods - 1, "NaN数量异常" assert not result_col.iloc[min_periods-1:].isna().any(), "有效期内出现意外NaN"

3.4 扩展窗口的业务对齐：如何让“累计”真正反映业务逻辑

扩展窗口最大的坑，是把“技术累计”当“业务累计”。举个真实案例：某支付公司要算“商户月累计交易额”，工程师直接写：

df['cum_monthly'] = df.groupby('merchant_id')['amount'].expanding().sum()

结果发现某商户1月1日交易100元，1月31日交易200元，但cum_monthly在1月31日显示300元——正确。但2月1日又交易50元，cum_monthly变成350元！业务上2月累计应从0开始，但代码没重置。

正确解法是用时间周期作为分组锚点：

# 方案1：按自然月分组（推荐） df['year_month'] = df['date'].dt.to_period('M') df['cum_monthly'] = df.groupby(['merchant_id','year_month'])['amount'].expanding().sum() # 方案2：用date_range生成完整月份，left join补零（适合报表） month_start = df['date'].dt.to_period('M').dt.start_time df['month_start'] = month_start full_months = pd.date_range(df['date'].min(), df['date'].max(), freq='MS') # 后续用pivot_table填充

另一个关键是expanding()的method参数。默认'single'逐行计算，但大数据量时可用'table'批量优化。不过'table'不支持自定义函数，所以加权累计必须用'single'。

3.5 多级分组的维度治理：避免unstack后的“数据沼泽”

unstack()后生成的宽表，极易变成“数据沼泽”——列名混乱、缺失值泛滥、维度关系断裂。我的维度治理四步法：

第一步：冻结维度顺序
永远按业务重要性排序分组键：groupby(['region','product','channel'])，region最粗粒度放前，channel最细放后。这样unstack时，内层索引（channel）变列，外层（region,product）变行，符合阅读习惯。

第二步：预处理缺失值
在unstack()前，用df.groupby([...]).size().unstack(fill_value=0)探查稀疏度。若某组合合占比<0.1%，直接dropna()；否则用fill_value=0或业务默认值（如“未分类”渠道填-1）。

第三步：智能列名生成
避免unstack()后列名是('Gadget','North')这种元组。用：

result = df.groupby(['region','product'])['revenue'].mean().unstack() result.columns = [f"{prod}_{reg}" for reg, prod in result.columns] # 输出：Gadget_North, Widget_South...

第四步：降维保真
当维度>2时，不用多次unstack。改用pivot_table并指定aggfunc：

# 三维转二维宽表：region为行，product×channel为列 pivot = df.pivot_table( index='region', columns=['product','channel'], values='revenue', aggfunc='sum' ) # 列名自动为('Gadget','Online'), ('Widget','Store')...

注意：pivot_table的columns参数支持列表，但unstack()只支持单层索引。这是二者本质区别。

4. 端到端实战：零售银行信用卡分析的七层递进式建模

4.1 数据生成与业务真实性校验

我们复现的信用卡数据，绝非随机数。关键设计点：

客户分层：customers = ['C001','C002','C003'] *20模拟3个典型客群（C001高频小额、C002中频大额、C003低频超大额）
金额分布：np.random.uniform(20,500,60)但实际加了偏态处理——C001的amounts乘以0.7，C003乘以1.3，模拟消费能力差异
时间规律：dates = pd.date_range('2024-01-01', periods=60, freq='D')但用np.resize()制造不均匀分布（如C001集中在工作日，C003在周末）

生成后必做三件事：

df['fee'] = (df['amount'] * 0.025).round(2)—— 手续费严格按比例，避免浮点误差
df['date'] = pd.to_datetime(df['date'])—— 强制转datetime，为后续时间操作铺路
df.info()检查数据类型，确保category是category类型（节省内存），amount是float64

实操心得：在generate_data()函数末尾加assert len(df) == 60和assert df['amount'].min() >= 20，把业务规则固化为代码断言。这比写文档管用十倍。

4.2 七层分析的业务逻辑穿透

分析1：多指标聚合——为什么`count`必须和`mean`同列？

multi_agg = df_transactions.groupby(['customer_id','category']).agg({ 'amount': ['mean','median','count'], 'fee': ['min','max'] })

业务意图：count是交易频次，mean是单笔强度，二者同属“amount维度”，必须放在同一组计算。若分开写，count会按customer_id分组，mean按category分组，结果无法对齐。这就是agg()字典映射的不可替代性——它强制保持分组键一致。

分析2：自定义范围计算——`std`为何比`range`更有业务价值？

transaction_range函数计算max-min，但输出中std值（106-128）远小于range值（399-477）。业务上，std衡量波动稳定性，range只抓极值。风控中更关注std，因为高std意味着交易行为不可预测，需加强监控；而range大但std小（如固定500元/天），反而是优质客户。

分析3：滚动窗口——为何`rolling_7day_avg`首7行全NaN？

因为min_periods=7（默认），前6天不足7点，第7天才有值。但业务上“第3天滚动均值”有意义（用前3天），所以生产代码必须显式设min_periods=3。输出中date索引未重置，导致result_rolling.head(15)显示乱序，需sort_index()。

分析4：扩展窗口——`cumulative_spend`的“客户生命周期”视角

expanding().sum()结果中，C001的cumulative_spend在第1、4、7、10...行跳跃增长，对应其交易日期。这正是“客户生命周期价值（CLV）”的原始形态。后续可衍生：cumulative_spend.diff().clip(lower=0)得每日新增消费，cumulative_spend.pct_change()得增长率。

分析5：交叉分析——`unstack()`如何暴露客户偏好？

crosstab输出中，C001的Groceries和Dining值最高（313-314），C002的Groceries达368，C003的Retail仅239。业务解读：C001是都市白领（高频餐饮），C002是家庭主妇（重 groceries），C003是商务人士（重 travel）。这种洞察，单维度聚合永远得不到。

分析6：高管摘要——`avg_fee_percent`为何恒为2.5%？

因为fee = amount * 0.025，无论怎么聚合，费率恒定。这暴露了数据生成的简化假设。真实场景中，手续费分档（如5000元以下0.025%，以上0.02），此时agg({'fee':'sum','amount':'sum'})后计算total_fees/total_spend才真实。这是建模前必须确认的业务规则。

分析7：风险分层——`high_value_pct`的阈值设定艺术

high_value_threshold = 300不是随意定的。我们用df['amount'].quantile(0.75)得298.5，向上取整300，确保覆盖75%交易。regular_avg计算时用series[series <= 300].mean()，排除高值干扰，得到“常规消费能力”。这才是风控模型需要的特征。

4.3 生产环境部署 checklist

将分析脚本投入生产，必须过这七关：

输入校验：assert 'date' in df.columns and pd.api.types.is_datetime64_any_dtype(df['date'])
空值处理：df.dropna(subset=['amount','customer_id'])，并记录丢弃行数告警
性能监控：用%timeit测关键步骤，groupby().agg()应<1s（百万行内）
结果验证：assert abs(result['total_spend'].sum() - df['amount'].sum()) < 0.01
异常捕获：try...except Exception as e: logger.error(f"Analysis failed: {e}")
版本锁定：pandas==1.5.3（避免新版API变更），numpy==1.23.5
输出规范：result.to_csv('report.csv', date_format='%Y-%m-%d', float_format='%.2f')

最后提醒：所有分析必须附带__version__ = "2.1.0"和__author__ = "Your Name"，当指标异常时，能快速定位是哪个版本的逻辑变更导致。

5. 常见问题与排查技巧实录：那些让老手也挠头的坑

5.1 MultiIndex列名混乱：为什么`result['amount']['mean']`报错？

现象：执行df.groupby('cat').agg({'amount':['mean','std']})后，想取mean列，result['amount']['mean']报KeyError。

根因：pandas返回的是DataFrame，其列是MultiIndex，result['amount']返回一个Series（列名为('amount','mean')和('amount','std')），再['mean']就找不到键了。

三步诊断法：

print(result.columns)→ 看到MultiIndex([('amount', 'mean'), ('amount', 'std')])
print(type(result['amount']))→ 确认是Series
print(result['amount'].columns)→ 报错，因Series无columns属性

解决方案：

快捷法：result[('amount','mean')]直接用元组索引
安全法：result.xs('mean', level=1, axis=1)按level=1（内层）取'mean'
工程法：用NamedAgg避免此问题（见3.1节）

经验：在Jupyter中调试时，永远先result.head()再result.columns，别猜。

5.2 滚动窗口NaN蔓延：为什么`rolling().mean()`后全NaN？

现象：df['rolling_avg'] = df.groupby('cat')['val'].rolling(window=3).mean()，结果全NaN。

排查路径：

df['val'].isna().sum()→ 若>0，NaN会传染，先fillna(0)
df.groupby('cat')['val'].count()→ 若某分组<3行，该组全NaN
df.set_index('date').index.is_monotonic_increasing→ 若False，时间未排序，窗口取错行

终极解法：

# 强制排序+填充+分组 df_sorted = df.sort_values(['cat','date']).reset_index(drop=True) df_sorted['rolling_avg'] = df_sorted.groupby('cat')['val'].rolling( window=3, min_periods=1 ).mean().reset_index(level=0, drop=True)

5.3 unstack后维度错乱：为什么`unstack()`结果行数暴增？

现象：df.groupby(['A','B'])['val'].mean().unstack()后，行数从100变成1000。

真相：unstack()默认fill_value=np.nan，但若A和B组合有1000种，就会生成1000行。而原始groupby只有100个A值，说明B有10个唯一值，A×B笛卡尔积1000。

业务判断：

若A×B本应稀疏（如某些地区无某产品），用unstack(fill_value=0)
若A×B本应稠密，检查数据质量：df.groupby(['A','B']).size().value_counts()看是否大量1

修复命令：

# 只保留实际存在的组合 result = df.groupby(['A','B'])['val'].mean().unstack(fill_value=0) # 或用pivot_table限制 result = df.pivot_table(index='A', columns='B', values='val', aggfunc='mean', fill_value=0)

5.4 自定义函数性能崩溃：为什么`apply()`比`agg()`慢10倍？

性能对比实验（10万行数据）：

方法	耗时	原因
`df.groupby('cat')['val'].agg('mean')`	12ms	C语言向量化
`df.groupby('cat')['val'].apply(lambda x: x.mean())`	145ms	Python循环调用
`df.groupby('cat').apply(lambda x: x['val'].mean())`	210ms	DataFrame切片额外开销

优化铁律：

优先用内置函数：'mean','std','nunique'
自定义函数只用于业务逻辑，且内部用向量化操作（如np.where替代for）
必须用apply()时，加raw=True（传numpy array而非Series）

救命代码：

# 慢：遍历计算 def slow_func(series): total = 0 for v in series: total += v * 1.05 # 5%手续费 return total / len(series) # 快：向量化 def fast_func(series): return (series * 1.05).mean()

5.5 时间窗口对齐失败：为什么`rolling('7D')`结果和Excel不一致？

根源：pandas的'7D'按日历天数滚动，Excel的AVERAGE(OFFSET())按行数滚动。若数据有缺失日期（如周末无交易），pandas会向前取7个日历日（含空白），Excel只取7行。

验证方法：

# pandas取值逻辑 window_dates = pd.date_range(end='2024-01-10', periods=7, freq='D') # 得到2024-01-04至2024-01-10，共7天 # Excel取值逻辑 # 若2024-01-04至2024-01-06无数据，则Excel取2024-01-01,02,03,07,08,09,10（7行）

业务解法：