1. 项目概述：为什么多维聚合不是“会groupby就行”，而是数据工程师的分水岭
我在银行风控系统干了八年，从最早用SQL写几十行嵌套子查询做客户分层，到后来带团队重构整个交易分析平台，踩过的坑比读过的文档还多。今天聊的这个主题——“Part 20: Data Manipulation in Multi-Dimensional Aggregation”，表面看是pandas里几个agg、rolling、unstack的用法，但实际它划开了一条线：一边是能跑通脚本的初级分析师，另一边是能扛住日均3亿笔交易、支撑实时反欺诈模型的数据工程师。
你可能已经会写df.groupby('region').sum()，但当业务方甩来一句：“我要看华东区餐饮类商户近7天滚动平均单笔交易额，同时对比去年同期，再按新老客打标，最后和风控阈值做交叉比对”——这时候，光靠基础groupby连需求文档都读不完。这正是本文要拆解的核心：多维聚合不是语法练习，而是一套面向真实业务约束的工程化思维。它解决的从来不是“怎么算”，而是“在数据量爆炸、维度交织、时效要求严苛、逻辑随时变更的前提下，怎么算得稳、算得快、算得清、算得可追溯”。
关键词里的“Towards AI”不是随便贴的标签。我见过太多团队把AI当万能膏药，结果模型训练数据一跑就报MemoryError——查下来发现预处理阶段一个groupby(['customer_id', 'merchant_category', 'date']).agg({'amount': ['mean', 'std', 'count']})没加as_index=False，生成了三层嵌套索引，下游直接卡死。这种问题不会出现在Kaggle教程里，但会真实发生在你凌晨三点被电话叫醒的生产环境里。
所以这篇文章不讲“pandas有多强大”，只讲三件事：第一，每种聚合模式背后真实的业务触发点（比如为什么滚动窗口必须是3天而不是5天）；第二，代码落地时那些文档里绝不会写的硬核细节（比如rolling().mean()返回的index错位陷阱）；第三，我亲手填平的五个致命坑——其中两个至今还在我们内部Wiki首页挂着红色警告。接下来的内容，全部来自我们给某全国性股份制银行搭建的信用卡实时风险引擎的真实代码片段，已脱敏，但逻辑和参数完全保留。你可以直接抄作业，但更建议你先想清楚：你手上的数据，到底在回答谁的问题？
