多维聚合实战：从SQL到Pandas的OLAP数据操作心法

1. 项目概述：当数据不再是一张“平铺直叙”的表格

你有没有遇到过这样的场景：销售部门要按季度、按区域、按产品大类看毛利，同时还要对比去年同期；财务团队需要把成本拆解到“部门-项目-费用类型-发生月份”四个维度，再筛选出超预算的组合；甚至一个简单的用户行为分析，都要交叉统计“新老用户 × 设备类型 × 页面路径深度 × 当日活跃时段”。这时候，Excel 的透视表点到第三层就开始卡顿，SQL 里写个 GROUP BY 加上 CASE WHEN 嵌套三层，自己都快看不懂了——这已经不是“汇总”问题，而是多维聚合（Multi-Dimensional Aggregation）的实战现场。本篇标题中的 “Part 20: Data Manipulation in Multi-Dimensional Aggregation”，绝非教科书里抽象的“高维数组”概念，它直指现代数据分析中一个最硬核、也最容易被低估的环节：如何在保留原始数据颗粒度的前提下，自由、高效、可复现地对多个维度进行任意组合、切片、钻取与比较。核心关键词——多维聚合、数据操作、维度建模、OLAP思维、分组聚合、交叉分析——全部围绕一个现实目标：让数据从“静态报表”变成“可交互的决策仪表盘”。它适合三类人：一是刚从单表 GROUP BY 过渡到业务宽表开发的 SQL 工程师，二是用 Pandas 做分析但总被pivot_table参数绕晕的 Python 数据分析师，三是正在搭建 BI 系统、需要理解底层聚合逻辑的产品或数仓工程师。这不是讲理论，而是拆解我在真实项目中处理过 12TB 日志、支撑 37 个业务方自助分析需求时，反复打磨出的一套“多维数据操作心法”。

2. 多维聚合的本质：为什么不能只靠 GROUP BY 和嵌套子查询？

2.1 传统 SQL 聚合的“维度陷阱”

很多人一上来就写：

SELECT region, product_category, quarter, SUM(revenue) AS total_revenue, AVG(profit_margin) AS avg_margin FROM sales_fact GROUP BY region, product_category, quarter;

看起来没问题？错。这只是“固定维度组合”的快照。一旦业务方问：“给我看看华东地区手机类目下，Q1 各个月份的环比增长”，你就得重写一条新 SQL，加MONTH(sale_date)到 GROUP BY，再套一层窗口函数LAG()。更麻烦的是，如果他们接着问：“那华北地区电脑类目呢？能和华东手机放一张表对比吗？”——你立刻意识到：GROUP BY 是“单向切片”，而多维分析需要“立方体式导航”。就像你站在一座大楼里，GROUP BY 只允许你从一个固定角度（比如正南面）看整栋楼的楼层分布；而多维聚合，是给你配了一套电梯+旋转楼梯+AR眼镜，让你能随时切换到任意楼层、任意朝向、任意房间组合去观察。

我曾接手一个电商后台的订单分析模块，原始 SQL 有 43 个嵌套视图，每个视图对应一个“预设维度组合”。运营提一个新需求，DBA 就要花半天加一个视图，上线前还得全量跑一遍物化。后来我们重构时发现，90% 的查询其实只用到 5 个核心维度（时间、地域、渠道、商品类目、用户等级），但组合方式超过 200 种。这时候，硬编码 GROUP BY 就是自缚手脚。

2.2 维度建模：给数据世界装上“坐标系”

解决之道，是引入维度建模（Dimensional Modeling）思路。它不改变数据本身，而是为数据建立一套清晰、稳定的“地理坐标”。核心就两点：

• 事实表（Fact Table）：存“发生了什么”，是数字的海洋。比如sales_fact表，每一行是一个订单明细，字段是sale_id,amount,quantity,profit—— 这些都是可加的度量值（measures）。
• 维度表（Dimension Table）：存“在什么条件下发生的”，是描述的大陆。比如dim_time（含年、季、月、周、工作日标志）、dim_region（含大区、省份、城市、是否一线）、dim_product（含一级类目、二级类目、品牌、价格带）。这些表通过外键（如time_key,region_key）关联到事实表。

关键来了：维度表不是简单字典，它必须是退化维度（Degenerate Dimension）或缓慢变化维度（SCD）的合理设计。举个反例：如果dim_region里只存一个province字段，那“华东地区”就得靠WHERE province IN ('上海','江苏','浙江','安徽')硬编码，下次改成“长三角一体化区域”又要改代码。正确做法是，在dim_region里加一列region_group，值为'East_China'或'Yangtze_River_Delta'，并确保这个字段在 ETL 过程中自动更新。这样，所有分析都基于稳定语义，而不是 SQL 里的字符串列表。

提示：维度表的主键必须是代理键（surrogate key），而非业务键（如province_code）。因为业务键可能变更（比如“江苏省”缩写从JS改成Jiangsu），而代理键region_sk = 1024永远指向“那个江苏”。这是保证历史分析一致性的铁律。

2.3 OLAP 思维：从“查数据”到“玩数据”

多维聚合的终极形态，是OLAP（Online Analytical Processing）操作。它包含四大原子动作，每一种都对应一种数据操作需求：

这四种操作，就是多维聚合的“操作系统内核”。任何 BI 工具（Tableau/Power BI）拖拽维度的行为，底层都在生成对应的 Slice/Dice/Roll-up/Drill-down 逻辑。不懂这个，就永远在“调参数”，而不是“控逻辑”。

3. 核心数据操作技术栈：Pandas、SQL、DAX 的三维实战

3.1 Pandas：用pivot_table和crosstab构建内存立方体

Python 数据分析中，Pandas 是最贴近“交互式多维分析”的工具。但多数人只用df.groupby().sum()，浪费了它内置的 OLAP 能力。真正高效的多维操作，靠的是三个核心方法：

pd.pivot_table()：你的第一台“分析引擎”

它不是简单的行列转置，而是带聚合逻辑的动态立方体生成器。看这个真实案例：我们有用户行为日志user_log，含字段user_id,event_type,page_path,device_type,event_date。要分析“不同设备上，各页面路径的访问频次占比”，传统写法：

# ❌ 错误示范：两层 groupby，代码冗长，无法扩展 temp = df.groupby(['device_type', 'page_path']).size().reset_index(name='cnt') temp['total_by_device'] = temp.groupby('device_type')['cnt'].transform('sum') temp['pct'] = temp['cnt'] / temp['total_by_device']

而pivot_table一行搞定：

# ✅ 正确示范：声明式定义，维度即参数 result = pd.pivot_table( df, index='device_type', # 行维度（Y轴） columns='page_path', # 列维度（X轴） values='user_id', # 聚合对象（这里用 user_id 计数） aggfunc='count', # 聚合函数（等价于 COUNT(*)) fill_value=0, # 空单元格填0，避免 NaN margins=True, # 自动加总计行列（Total 行/列） margins_name='All' # 总计行名称 ) # result 现在就是一个 device_type × page_path 的二维矩阵，且含 All 行/列

关键参数深挖：

• aggfunc不仅支持'count'/'sum'/'mean'，还支持自定义函数：aggfunc=lambda x: x.nunique()统计去重用户数；
• margins=True是神功能，它自动执行 Roll-up：All行 = 所有设备的总访问量，All列 = 所有页面的总访问量，All,All单元格 = 全局总计；
• fill_value=0必须加！否则NaN会污染后续计算（比如result.sum(axis=1)会跳过 NaN 行）。

pd.crosstab()：专治“二元交叉分析”的轻量级武器

当你的分析只涉及两个分类维度（如gender×age_group），crosstab比pivot_table更简洁、更快：

# 生成性别×年龄段的频次交叉表 ct = pd.crosstab( df['gender'], df['age_group'], rownames=['Gender'], # 行名（可选） colnames=['Age Group'], # 列名（可选） margins=True, # 同样支持总计 normalize='index' # 神奇参数：按行归一化，直接得百分比！ ) # normalize='index' → 每行加起来是100%，即“男性中各年龄段占比” # normalize='columns' → 每列加起来是100%，即“20-29岁用户中男女占比” # normalize=True → 全局归一化，所有单元格加起来是100%

实操心得：crosstab在处理百万级数据时，比等效的pivot_table快 3~5 倍，因为它内部做了 C 语言级优化。但注意，它只能处理两个维度，第三个维度得靠groupby预处理。

pd.melt()+pivot_table()：解锁“宽表变立方体”的终极组合

现实数据常以宽表形式存在，比如sales_wide表含region,Q1_sales,Q2_sales,Q1_profit,Q2_profit。想分析“各季度利润占比”，就得先“熔化”（melt）成标准长表：

# 宽表 → 长表：把季度列名变成值 long_df = pd.melt( sales_wide, id_vars=['region'], # 保持不变的标识列 value_vars=['Q1_sales', 'Q2_sales', 'Q1_profit', 'Q2_profit'], # 要熔化的列 var_name='metric_quarter', # 新列名：原列名存这里 value_name='amount' # 新列名：原列值存这里 ) # long_df 现在有 region, metric_quarter, amount 三列 # 接着用 str.extract 拆解 metric_quarter 得到 metric 和 quarter long_df[['metric', 'quarter']] = long_df['metric_quarter'].str.extract(r'(\w+)_(\w+)') # 最后 pivot：行=region，列=quarter，值=SUM(amount)，按 metric 过滤 profit_by_qtr = pd.pivot_table( long_df[long_df['metric']=='profit'], index='region', columns='quarter', values='amount', aggfunc='sum' )

注意：melt是“逆透视”，pivot_table是“透视”，二者组合，就是数据形态的任意变形。我在处理某银行客户资产报表时，靠这套组合拳，把 87 个季度指标宽表，5 分钟内转成可任意切片的长表立方体。

3.2 SQL：写出让 DBA 点赞的多维查询

SQL 是多维聚合的基石。但写出高性能、易维护的多维查询，有三大心法：

心法一：用GROUPING SETS替代 N 个 UNION ALL

传统做法，要同时看“大区”、“大区+类目”、“大区+类目+月份”三个粒度，得写：

-- ❌ 低效：三次扫描，三次 GROUP BY SELECT region, NULL as category, NULL as month, SUM(sales) FROM t GROUP BY region UNION ALL SELECT region, category, NULL, SUM(sales) FROM t GROUP BY region, category UNION ALL SELECT region, category, month, SUM(sales) FROM t GROUP BY region, category, month;

而GROUPING SETS一次扫描搞定：

-- ✅ 高效：一次扫描，多种粒度 SELECT region, category, month, SUM(sales) as total_sales, GROUPING_ID(region, category, month) as gid -- 生成分组 ID，便于识别粒度 FROM t GROUP BY GROUPING SETS ( (region), -- 粒度1：仅大区 (region, category), -- 粒度2：大区+类目 (region, category, month) -- 粒度3：大区+类目+月份 );

GROUPING_ID返回一个整数，其二进制位表示对应维度是否参与分组：(region)→001= 1，(region,category)→011= 3，(region,category,month)→111= 7。你可以用CASE WHEN GROUPING_ID(...) = 1 THEN 'Region Level'来标注粒度。

心法二：用ROLLUP和CUBE自动生成层级与全组合

ROLLUP(a,b,c)=(a,b,c) + (a,b) + (a) + ()，适合有天然层级的维度（如时间：年→季→月）：

-- 时间维度天然层级，ROLLUP 完美匹配 SELECT year, quarter, month, SUM(sales), CASE WHEN GROUPING(month) = 1 AND GROUPING(quarter) = 0 THEN 'Quarter Total' WHEN GROUPING(quarter) = 1 AND GROUPING(year) = 0 THEN 'Year Total' END as level_desc FROM sales_fact GROUP BY year, quarter, month WITH ROLLUP;

CUBE(a,b,c)= 所有 2³=8 种组合，适合无层级的交叉分析（如region×channel×product_type）：

-- 获取所有可能的 region/channel/product_type 组合总计 SELECT region, channel, product_type, SUM(sales) FROM sales_fact GROUP BY CUBE(region, channel, product_type); -- 结果含：(r1,c1,p1), (r1,c1,ALL), (r1,ALL,p1), (ALL,c1,p1), (r1,ALL,ALL), ... , (ALL,ALL,ALL)

心法三：用FILTER子句替代 CASE WHEN，提升可读性

统计“Q1 销售额”和“Q1 毛利率”，传统写法：

SELECT region, SUM(CASE WHEN quarter='Q1' THEN sales ELSE 0 END) as q1_sales, AVG(CASE WHEN quarter='Q1' THEN profit_margin END) as q1_margin FROM t GROUP BY region;

FILTER让逻辑更清晰：

SELECT region, SUM(sales) FILTER (WHERE quarter='Q1') as q1_sales, AVG(profit_margin) FILTER (WHERE quarter='Q1') as q1_margin FROM t GROUP BY region;

FILTER是 PostgreSQL 9.4+ 和最新版 SQL Server 的标准语法，语义明确：只对满足条件的行执行聚合。它比CASE WHEN更安全（不会因漏写ELSE 0导致 AVG 计算错误），也更易维护。

3.3 DAX（Power BI）：用度量值构建动态分析模型

在 Power BI 中，多维聚合的灵魂是DAX（Data Analysis Expressions）。它不像 SQL 那样“写一次查一次”，而是定义动态度量值（Measure），随用户切片实时重算。核心就两条公式：

CALCULATE()：DAX 的“上帝函数”

它能修改当前上下文（Context），是实现 Slice/Dice/Roll-up 的核心。例如：

// 定义一个基础销售额度量 Sales Amount = SUM(Sales[Amount]) // 创建“华东地区销售额”度量，自动响应其他筛选器 East Sales = CALCULATE([Sales Amount], Region[RegionGroup] = "East_China") // 创建“Q1 同比增长率”，需跨时间上下文 YoY Growth Q1 = VAR CurrentQ1 = CALCULATE([Sales Amount], 'Date'[Quarter] = "Q1", 'Date'[Year] = 2024) VAR LastQ1 = CALCULATE([Sales Amount], 'Date'[Quarter] = "Q1", 'Date'[Year] = 2023) RETURN DIVIDE(CurrentQ1 - LastQ1, LastQ1)

CALCULATE的威力在于：它不改变数据模型，只临时“覆盖”当前筛选上下文。用户在报表里拖一个Product Category切片器，East Sales度量会自动计算“华东地区+所选类目”的销售额，无需额外写代码。

ALL()和ALLEXCEPT()：控制上下文的“刹车片”

当你要做“占比”分析（如“某类目销售额占全站比例”），必须清除部分上下文：

// 全站销售额（清除所有筛选，只留时间） Total Site Sales = CALCULATE([Sales Amount], ALL('Product'), ALL('Region')) // 某类目占全站比例（清除 Product 筛选，但保留 Region 和 Date） Category % of Site = DIVIDE([Sales Amount], CALCULATE([Sales Amount], ALLEXCEPT('Date', 'Region')))

ALL()清除指定表的所有筛选，ALLEXCEPT()保留指定列的筛选，其余清除。这是避免“分母错误”的关键。我曾见一个 BI 报表，毛利率占比总是不对，最后发现是用了ALL('Date')却没保留Year，导致分母是所有年份总和，分子却是单年数据。

4. 实战全流程：从原始日志到自助分析看板的 7 步落地

4.1 第一步：定义核心维度与事实（建模阶段）

不跳过这步，后面全是徒劳。我们以电商用户行为日志为例：

• 事实表fact_user_event：

  • event_id（PK）
  • user_id（FK to dim_user）
  • page_id（FK to dim_page）
  • device_sk（FK to dim_device）
  • time_sk（FK to dim_time）
  • event_duration_sec（度量：停留时长）
  • is_bounce（度量：是否跳出，0/1）

• 维度表dim_time（退化维度，每日 ETL 更新）：

  • time_sk（PK，格式：20240520）
  • date（DATE）
  • year,quarter,month,week_of_year,day_of_week,is_weekend,is_holiday

• 维度表dim_user（SCD Type 2，记录用户等级变更）：

  • user_sk（PK）
  • user_id（业务键）
  • user_level（当前等级）
  • valid_from,valid_to,is_current

关键决策：为什么dim_user用 SCD Type 2？因为用户等级会变（如 VIP→SVIP），而分析“SVIP 用户的历史行为”必须知道他在某天是不是 SVIP。Type 2 通过valid_from/to和is_current标志，完美支持“时间点快照查询”。

4.2 第二步：ETL 中的维度一致性保障

维度表不是静态字典，必须在 ETL 流程中强制校验。我们在 Airflow DAG 中加入三道检查：

1. 维度键完整性检查：SELECT COUNT(*) FROM fact_user_event f LEFT JOIN dim_time d ON f.time_sk = d.time_sk WHERE d.time_sk IS NULL，报错则中断，防止“未来日期”或“缺失日期”进入事实表。

2. 缓慢变化维度生效检查：对dim_user，运行SELECT COUNT(*) FROM dim_user WHERE is_current = TRUE GROUP BY user_id HAVING COUNT(*) > 1，确保每个user_id只有一个当前版本。

3. 业务规则检查：SELECT * FROM dim_time WHERE day_of_week NOT IN (1,2,3,4,5,6,7)，拦截数据质量问题。

实操心得：这些检查脚本不是摆设。去年双十一大促期间，上游日志系统时区配置错误，导致dim_time生成了day_of_week = 0的脏数据。正是这条检查，让我们在凌晨 2 点收到告警，30 分钟内修复，避免了全天的分析事故。

4.3 第三步：构建基础聚合层（Data Warehouse Layer）

在数仓中，我们不直接暴露 10 亿行的事实表，而是建聚合表（Aggregate Table），作为性能基石：

• agg_user_daily：按user_id,time_sk聚合，存session_count,page_view_count,total_duration
• agg_region_monthly：按region_sk,time_sk（月粒度），存new_user_count,active_user_count,avg_session_duration

创建agg_region_monthly的 SQL（PostgreSQL）：

CREATE TABLE agg_region_monthly AS SELECT r.region_sk, r.region_name, r.region_group, t.year_month as time_month, -- 从 dim_time 中提取 '202405' COUNT(DISTINCT f.user_id) as active_user_count, SUM(f.event_duration_sec) as total_duration_sec, COUNT(*) as event_count FROM fact_user_event f JOIN dim_region r ON f.region_sk = r.region_sk JOIN dim_time t ON f.time_sk = t.time_sk WHERE t.date >= '2024-01-01' -- 分区裁剪 GROUP BY r.region_sk, r.region_name, r.region_group, t.year_month; -- 添加复合索引，加速按 region_group + time_month 查询 CREATE INDEX idx_agg_reg_mon ON agg_region_monthly (region_group, time_month);

为什么建聚合表？因为fact_user_event单日 2 亿行，COUNT(DISTINCT user_id)全表扫描要 40 秒。而agg_region_monthly单月仅 2 万行，同样查询 0.2 秒。这是用空间换时间的经典 trade-off。

4.4 第四步：BI 层的度量值开发（Power BI 示例）

在 Power BI Desktop 中，连接agg_region_monthly表，开发以下度量值：

// 1. 基础度量 Active Users = SUM(agg_region_monthly[active_user_count]) // 2. 动态占比（自动响应切片器） Region Share = DIVIDE([Active Users], CALCULATE([Active Users], ALL(agg_region_monthly[region_group]))) // 3. 环比增长（用 DAX 时间智能函数） MoM Growth = VAR CurrentMonth = SELECTEDVALUE(agg_region_monthly[time_month]) VAR PrevMonth = DATEADD(SELECTEDVALUE(agg_region_monthly[time_month]), -1, MONTH) RETURN DIVIDE( CALCULATE([Active Users], agg_region_monthly[time_month] = CurrentMonth), CALCULATE([Active Users], agg_region_monthly[time_month] = PrevMonth) ) // 4. 条件高亮（返回颜色代码，用于卡片视觉对象） Status Color = SWITCH( TRUE(), [MoM Growth] > 0.1, "#00CC66", // 绿色：增长>10% [MoM Growth] < -0.05, "#FF6666", // 红色：下降>5% "#FFCC00" // 黄色：其他 )

关键技巧：SELECTEDVALUE()函数是安全的，当多值被选中时返回 BLANK()，避免MAX()或MIN()引发的静默错误。DATEADD是 Power BI 内置的时间智能函数，比手动字符串拼接CONVERT(INT, ...)更可靠。

4.5 第五步：前端交互设计（避免“维度爆炸”）

多维分析最大的敌人是“维度爆炸”——用户拖 5 个维度，生成 10 万行结果，页面卡死。我们的解决方案是：

• 默认限制：报表加载时，只显示region_group和time_month两个维度，其他（如device_type）隐藏在“高级筛选”抽屉中。
• 智能采样：当用户选择region_group = 'All'且time_month跨度 > 6 个月时，后端自动启用TABLESAMPLE SYSTEM (10)（PostgreSQL）或TOP 10000（SQL Server）采样，保证响应 < 2s。
• 异步加载：复杂下钻（如点击某个区域看城市明细）触发独立 API 请求，不阻塞主视图。

注意：不要试图在前端用 JavaScript 做大数据聚合。我曾见过一个 Vue 应用，把 50 万行 JSON 传给前端，用Array.reduce()计算，结果 Chrome 内存飙到 4GB。正确姿势是：聚合永远在服务端或数据库完成，前端只负责展示和交互。

4.6 第六步：性能压测与瓶颈定位

上线前，必须做真实压测。我们用pgbench（PostgreSQL）模拟并发：

# 模拟 50 个用户，持续 5 分钟，执行核心查询 pgbench -U analyst -d dw_db -f query_agg.sql -c 50 -T 300

query_agg.sql内容：

-- 核心查询：按 region_group 和 time_month 查活跃用户 SELECT region_group, time_month, SUM(active_user_count) as users FROM agg_region_monthly WHERE time_month BETWEEN 202401 AND 202406 GROUP BY region_group, time_month ORDER BY region_group, time_month;

压测结果发现：当time_month BETWEEN 202401 AND 202412（12个月）时，P95 响应从 120ms 涨到 1800ms。EXPLAIN ANALYZE显示，Bitmap Heap Scan占用 92% 时间。优化方案：

• 分区表：将agg_region_monthly按time_month范围分区（PARTITION BY RANGE (time_month)），每个分区存一年数据；
• 局部索引：在每个分区上建INDEX ON (region_group, time_month)；
• VACUUM ANALYZE：定期清理死元组，更新统计信息。

优化后，12 个月查询 P95 稳定在 210ms。

4.7 第七步：用户培训与自助分析赋能

技术再强，用户不会用也是零。我们设计了“30 分钟上手”培训：

• 第一课：认识你的维度（10 分钟）
  发放《维度词典》PDF，明确region_group的 5 个取值（East/North/South/West/Central）及其业务含义，附地图示意图。

• 第二课：拖拽三原则（10 分钟）
  ① 行/列放“分类维度”（region, device），值放“数字度量”（users, duration）；
  ② 切片器放“过滤维度”（time_month, user_level），一次最多选 3 个；
  ③ 点击图表任意位置，右键“下钻”看明细，左键“上卷”回退。

• 第三课：避坑指南（10 分钟）

  • ❌ 不要对time_month用“文本筛选”，必须用日期切片器；
  • ❌ 不要在一个图表里放超过 2 个“高基数维度”（如user_id），会崩溃；
  • ✅ 遇到“数据为空”，先检查右上角“筛选器”是否误开了；
  • ✅ 想看“占比”，直接右键度量值 → “显示值为” → “百分比”。

培训后，85% 的常规分析需求（如“华东 Q2 各城市用户数”）用户可自主完成，数据团队支持工单下降 60%。

5. 常见问题与排查技巧实录：那些深夜救火的真实案例

5.1 问题一：Pandaspivot_table输出全是 NaN，但数据明明有值

现象：df.head()看device_type和page_path都有值，pd.pivot_table(df, index='device_type', columns='page_path', values='user_id', aggfunc='count')却返回全 NaN 矩阵。

排查思路：

1. 检查device_type或page_path是否含不可见字符：df['device_type'].str.encode('utf-8').head()，发现iPhone前有\xa0（不间断空格）；
2. 检查数据类型：df['device_type'].dtype是object，但部分值是float（因 Excel 导入时空值变nan，再混入字符串）；
3. 检查values字段：user_id是字符串类型，count函数对字符串计数正常，但若user_id有None，count会忽略它。

根因与解决：

# 步骤1：清洗不可见字符 df['device_type'] = df['device_type'].str.replace('\xa0', ' ').str.strip() df['page_path'] = df['page_path'].str.replace('\u200b', '').str.strip() # 零宽空格 # 步骤2：统一数据类型，填充空值 df['device_type'] = df['device_type'].fillna('Unknown').astype(str) df['page_path'] = df['page_path'].fillna('/home').astype(str) # 步骤3：确认 values 字段可计数 df['user_id'] = df['user_id'].fillna('ANONYMOUS') # 避免 None 影响 count # 重试 pivot_table result = pd.pivot_table(df, index='device_type', columns='page_path', values='user_id', aggfunc='count')

实操心得：Pandas 对数据质量极度敏感。我养成了一个习惯：每次read_csv()后，立即运行df.info()和df.describe(include='all')，一眼看出哪些列有null、哪些类型异常。这比调试pivot_table报错快 10 倍。

5.2 问题二：SQLGROUPING SETS查询结果行数远超预期

现象：SELECT a,b,c FROM t GROUP BY GROUPING SETS ((a),(a,b),(a,b,c))返回 120 万行，但SELECT COUNT(*) FROM t只有 80 万行。

排查思路：

1. 检查GROUPING SETS是否误写成CUBE：CUBE(a,b,c)会生成 8 种组合，而GROUPING SETS只应生成 3 种；
2. 检查字段是否含NULL：GROUP BY会把NULL视为一个有效分组值；
3. 检查是否有重复键：a列存在大量相同值，但a,b组合唯一，a,b,c组合也唯一，理论上(a)分组行数 ≤(a,b)≤(a,b,c)。

根因与解决： 执行SELECT a, COUNT(*) FROM t GROUP BY a HAVING COUNT(*) > 10000，发现a = 'Unknown'有 50 万行。这意味着(a)分组中，'Unknown'单独成一行，计数 50 万；(a,b)分组中，'Unknown'与每个b值组合，又生成几百行；