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

多维聚合实战：从SQL GROUPING SETS到Pandas透视表的立体分析

news 2026/6/14 17:35:07

1. 这不是“又一个聚合函数教程”，而是多维数据变形的实战控制台

你有没有遇到过这样的场景：销售报表里要同时按“地区+产品线+季度”三个维度看销售额，但原始数据只有一张扁平的交易流水表；或者用户行为分析中，需要快速对比“新老用户在iOS/Android上、工作日/周末的点击率差异”，而数据库返回的却是百万行带时间戳和设备标识的原始日志？这时候，光会写GROUP BY region, product_line, quarter已经远远不够了——你真正需要的，是一套能自由折叠、展开、旋转、切片、钻取的多维数据操作能力。这正是“Part 20: Data Manipulation in Multi-Dimensional Aggregation”所直指的核心：它不教你怎么求和求平均，而是教你如何把数据当成一块可塑的橡皮泥，在多个坐标轴上精准施力，捏出业务真正需要的视图。关键词“Multi-Dimensional Aggregation”背后，是OLAP（联机分析处理）的底层逻辑，是Pandas的pivot_table与melt的深层配合，是SQL中CUBE、ROLLUP与GROUPING SETS的战术选择，更是现代BI工具（如Tableau、Power BI）拖拽操作背后的硬核原理。它适合三类人：正在从SQL单表查询向复杂报表进阶的数据分析师；需要在Jupyter中快速生成多维交叉表进行探索性分析（EDA）的算法工程师；以及那些被老板一句“再加个按渠道细分的同比环比”就卡住半天的业务数据支持同学。这不是炫技，而是每天都在发生的、真实的数据交付压力下的生存技能。

2. 整体设计思路：为什么必须放弃“单层GROUP BY思维”

2.1 传统聚合的致命局限：一张平面，无法承载立体业务

我们先看一个典型失败案例。某电商公司想分析“各品类在不同城市等级（一线/新一线/二线）的GMV分布”，原始表结构如下：

order_id	user_id	city_tier	category	gmv
1001	u1	一线	手机	5999
1002	u2	新一线	美妆	299
...	...	...	...	...

如果只用最朴素的SQL：

SELECT city_tier, category, SUM(gmv) AS total_gmv FROM orders GROUP BY city_tier, category;

你确实能得到一个二维表格，但它只是“静态快照”。问题来了：

老板问：“一线城市的手机类GMV占所有一线城市的总GMV多少？” → 你需要额外计算占比，且每次都要重写子查询。
运营问：“美妆类在所有城市等级中的GMV排名是多少？” → 你需要对结果再排序，但原始聚合结果已丢失了全局上下文。
财务问：“所有品类在所有城市等级的总计是多少？” → 你得单独再跑一条SELECT SUM(gmv)，无法与明细结果并置。

这就是单层GROUP BY的“平面困境”：它强制你预设唯一的分组粒度，一旦确定，就锁死了所有其他观察视角。而真实业务是立体的——决策者需要随时在“钻取”（看更细，如一线→北京/上海）和“上卷”（看更粗，如各城市等级→全国总计）之间无缝切换。这种需求，单靠GROUP BY无法满足，它缺乏“层次感”和“可逆性”。

2.2 多维聚合的本质：构建一个可导航的“数据立方体”

多维聚合的设计哲学，是把数据想象成一个立方体（Cube）。每个维度（Dimension）就是一条坐标轴：X轴是city_tier（3个值），Y轴是category（5个值），Z轴甚至可以是quarter（4个值）。这个立方体的每个“单元格”（Cell）存储着该组合下的聚合值（如SUM(gmv)）。关键在于，这个立方体不是静止的，它支持四种核心导航操作：

切片（Slice）：固定一个维度，查看其子集。例如，“固定Z轴=Q1，查看X-Y平面的所有组合”。
切块（Dice）：在多个维度上同时限定范围。例如，“X轴∈{一线,新一线} 且 Y轴∈{手机,电脑}，查看这些组合的GMV”。
上卷（Roll-up）：沿某个维度向上聚合。例如，将city_tier从“一线/新一线/二线”上卷为“一二线/其他”，或将category上卷为“3C/美妆/服饰”大类。
下钻（Drill-down）：沿某个维度向下细化。例如，将city_tier从“一线”下钻为具体的“北京、上海、深圳、广州”。

这种设计之所以强大，是因为它把“计算逻辑”和“展示逻辑”解耦了。你只需一次性定义好立方体的结构（即哪些是维度，哪些是度量，如何分层），后续所有切片、上卷、下钻操作，都只是对这个立方体的“视图变换”，无需重新扫描原始数据。这正是现代OLAP引擎（如Apache Kylin、ClickHouse的物化视图）和高级BI工具的底层机制。而我们在SQL或Pandas中实现的“多维聚合”，就是在模拟这个立方体的构建与操作过程。

2.3 方案选型：SQL、Pandas、还是专用OLAP引擎？

面对同一需求，技术选型绝非随意。我根据过去十年在金融、电商、SaaS领域的项目经验，总结出三条清晰路径，每条都有其不可替代的适用场景：

路径一：纯SQL（推荐给数据仓库重度用户）

优势：零学习成本（如果你已会写SQL），直接在数仓（如Snowflake、Redshift、StarRocks）中执行，性能极佳（引擎原生优化）。

核心武器：GROUPING SETS（标准SQL）、CUBE（简化版GROUPING SETS）、ROLLUP（有序上卷）。它们能在一个查询中，同时返回多个粒度的结果。例如：

-- 一行代码，同时得到：(city_tier, category), (city_tier), (category), () 四个粒度的SUM(gmv) SELECT city_tier, category, SUM(gmv) FROM orders GROUP BY GROUPING SETS ((city_tier, category), (city_tier), (category), ());

何时选它：你的数据已在高性能数仓中，且团队SQL能力强；需要将结果直接灌入下游报表系统；对实时性要求高（秒级响应）。

路径二：Pandas（推荐给数据分析与建模场景）

优势：交互式强，调试直观，与Matplotlib/Seaborn无缝集成，支持复杂的自定义聚合函数（如计算中位数、分位数、自定义比率）。
核心武器：pd.pivot_table()（构建透视表）、pd.melt()（反透视，用于数据规整）、pd.crosstab()（快速交叉表）、groupby().agg()的多级索引输出。
何时选它：你在Jupyter中做探索性分析（EDA），需要快速试错；原始数据是CSV/Excel/数据库小表（<1000万行），内存足够；需要将聚合结果作为特征输入机器学习模型。

路径三：专用OLAP引擎（推荐给高并发、超大数据量场景）

优势：亚秒级响应海量数据（百亿行），内置缓存与预计算，支持实时数据摄入。
代表工具：Apache Druid（实时流处理强）、ClickHouse（单表分析快）、Doris（MySQL协议友好）。
何时选它：你的BI看板有数百人同时在线刷新；每日新增数据达TB级；业务要求“数据入库后1分钟内可查”。

提示：很多团队犯的错误是“一刀切”。我见过用Pandas硬扛10亿行订单数据的分析师，也见过在Snowflake里用Python UDF做复杂聚合的工程师。记住：工具是为场景服务的，不是为简历服务的。Part 20 的价值，恰恰在于让你看清每种方案的边界，从而在项目启动时就做出正确选择。

3. 核心细节解析：从“能跑通”到“跑得稳、跑得巧”

3.1 SQL多维聚合：`GROUPING SETS`的深度用法与陷阱

GROUPING SETS是SQL标准中最灵活的多维聚合语法，但它远不止于“写一堆括号”那么简单。我们以一个真实电商案例拆解其精妙之处。

业务需求：分析“各渠道（app/web/h5）、各用户等级（vip/normal）、各月份”的订单数与GMV，并要求同时提供：

渠道×用户等级的交叉汇总
渠道×月份的交叉汇总
用户等级×月份的交叉汇总
各维度的单独总计（如所有渠道的总GMV）
全局总计

错误写法（低效且易错）：

-- 单独写5个UNION ALL查询，维护成本爆炸，且无法保证原子性 SELECT 'channel' as dim1, channel as val1, NULL as dim2, NULL as val2, COUNT(*) as cnt, SUM(gmv) as gmv FROM t GROUP BY channel UNION ALL SELECT 'user_level', user_level, NULL, NULL, COUNT(*), SUM(gmv) FROM t GROUP BY user_level -- ... 还有3个，此处省略

正确写法（GROUPING SETS）：

SELECT channel, user_level, month, COUNT(*) AS order_cnt, SUM(gmv) AS total_gmv, -- 关键：使用GROUPING()函数识别空值来源 GROUPING(channel) AS is_channel_total, GROUPING(user_level) AS is_user_level_total, GROUPING(month) AS is_month_total FROM orders WHERE dt >= '2024-01-01' GROUP BY GROUPING SETS ( (channel, user_level, month), -- 最细粒度：3维交叉 (channel, user_level), -- 中粒度1：渠道×用户等级 (channel, month), -- 中粒度2：渠道×月份 (user_level, month), -- 中粒度3：用户等级×月份 (channel), -- 粗粒度1：仅渠道 (user_level), -- 粗粒度2：仅用户等级 (month), -- 粗粒度3：仅月份 () -- 全局总计 );

为什么这个写法更优？

一次扫描，多次产出：数据库引擎只需读取原始表一次，内部通过哈希分组等优化，高效生成所有组合结果，避免了5次全表扫描。
GROUPING()函数是灵魂：它返回0或1，表示该列是否参与了当前分组。例如，当is_channel_total=1且is_user_level_total=0时，说明这一行是“所有渠道中，某用户等级的总计”，channel列的值为NULL，但你知道这不是数据缺失，而是上卷逻辑导致的。这让你能在应用层（如Python脚本）精准地为不同粒度的行打上标签，生成带层级的报表。
可扩展性强：若明天要增加“设备类型（ios/android）”维度，只需在GROUPING SETS中添加新组合，无需重构整个查询逻辑。

注意：CUBE (a,b,c)等价于GROUPING SETS ((a,b,c),(a,b),(a,c),(b,c),(a),(b),(c),())，它会生成所有可能的组合，共2^n个。而ROLLUP (a,b,c)则生成有序上卷：(a,b,c),(a,b),(a),()。在业务逻辑明确时，优先用GROUPING SETS，因为它更精确、更易读、更易优化。

3.2 Pandas多维聚合：`pivot_table`的隐藏参数与性能调优

在Python生态中，pd.pivot_table()是多维聚合的明星函数，但它的默认行为常让新手踩坑。我们以一个用户行为日志分析为例：

原始DataFramedf_log包含：user_id,event_type（click/impression/purchase）,platform（ios/android/web）,hour_of_day（0-23）,duration_sec（停留时长）。

目标：生成一个透视表，行是platform，列是event_type，值是duration_sec的平均值，并且要包含“所有平台的总均值”和“所有事件类型的总均值”。

基础写法（功能正确，但有隐患）：

# ❌ 潜在问题：未指定aggfunc，且未处理缺失值 result = pd.pivot_table( df_log, values='duration_sec', index='platform', columns='event_type', aggfunc='mean' # 默认是np.mean，但会忽略NaN )

专业写法（稳定、可控、可解释）：

import numpy as np # ✅ 显式指定aggfunc为lambda，可自定义逻辑 def safe_mean(x): """安全均值：当x为空时返回NaN，而非报错""" return np.nan if len(x) == 0 else x.mean() result = pd.pivot_table( df_log, values='duration_sec', index='platform', columns='event_type', aggfunc=safe_mean, # 使用自定义函数 fill_value=0, # 将所有NaN替换为0（报表友好） margins=True, # 关键！自动添加All行和All列 margins_name='Total' # 自定义总计行/列名 ) # ✅ 进阶：添加多级聚合，例如同时看均值和计数 result_multi = pd.pivot_table( df_log, values='duration_sec', index='platform', columns='event_type', aggfunc={'mean': np.mean, 'count': 'count'}, # 返回MultiIndex列 fill_value=0, margins=True )

性能调优三大技巧（实测提升3-5倍）：

预过滤，而非后过滤：在pivot_table前，先用df_log.query("platform in ['ios','android']")缩小数据集。pivot_table内部会遍历所有行，数据越少，速度越快。
利用dropna=False：默认dropna=True会丢弃任何含NaN的行。如果你的platform或event_type列有缺失值，且你想保留它们（用'Unknown'填充），务必显式设置dropna=False，并在之前用df_log.fillna({'platform':'Unknown', 'event_type':'Unknown'})。
避免apply链式调用：不要写df_log.groupby(['platform','event_type']).duration_sec.mean().unstack()，这比pivot_table慢得多。pivot_table是Cython优化的，而unstack()是纯Python操作。

实操心得：我在一个1200万行的日志分析项目中，将pivot_table的fill_value从默认None改为0，并启用margins=True，报表生成时间从8.2秒降至1.7秒。原因在于，fill_value=0避免了后续fillna(0)的二次遍历，而margins=True由底层C代码实现，比手动concat([result, result.sum(axis=0).to_frame('Total').T])快一个数量级。

3.3 多维聚合的“元数据”管理：为什么维度建模是成败关键

所有多维聚合的威力，都建立在一个隐性前提上：你的原始数据已经过良好的维度建模（Dimensional Modeling）。如果源头数据是混乱的，再高级的聚合语法也是无源之水。我见过太多团队，花90%时间在写GROUP BY，却从不花10%时间梳理数据本身。

什么是维度建模？简单说，就是把业务实体抽象成“维度表（Dimension Table）”和“事实表（Fact Table）”。

维度表：描述业务环境的静态或缓慢变化的表。例如：dim_date（含年、季、月、周、工作日标志）、dim_product（含品类、品牌、价格带）、dim_user（含用户等级、注册渠道、地域）。它们通常有主键（如date_key,product_id），且行数相对较少（几万到几十万）。
事实表：记录业务过程的、高度规范化的事务表。例如：fact_orders（含order_id,date_key,product_id,user_id,gmv,qty）。它没有描述性字段，所有文本信息都通过外键关联到维度表。

为什么它对多维聚合至关重要？

一致性保障：dim_date中定义了is_holiday=1，那么所有基于日期的聚合（如“节假日vs工作日GMV对比”）都使用同一个定义，避免了在每个SQL里重复写CASE WHEN date IN ('2024-01-28','2024-01-29',...) THEN 1 ELSE 0 END。
可扩展性：当运营提出“按用户生命周期阶段（新客/成长期/成熟期/流失预警）分析”时，你只需在dim_user中增加一列lifecycle_stage，所有现有聚合查询无需修改，即可立即支持新维度。
性能飞跃：数仓引擎对维度表的主键有极致优化（如StarRocks的Bitmap索引），JOIN dim_date ON fact.date_key = dim_date.date_key比WHERE date BETWEEN '2024-01-01' AND '2024-12-31'快得多，因为前者是等值查找，后者是范围扫描。

落地建议（来自血泪教训）：

不要试图一步到位。从最核心的1-2个维度开始（如date,product），用两周时间把它做干净。
维度表的surrogate key（代理键）必须是整数，且自增。避免用业务键（如product_code）作为主键，因为业务键可能变更（如SKU合并），导致历史事实表关联断裂。
在ETL流程中，加入“维度一致性检查”步骤。例如，fact_orders.product_id必须全部存在于dim_product.product_id中，否则抛出告警。我曾因漏掉此检查，导致一份关键报表中“未知品类”的GMV占比高达37%，花了三天才定位到是上游ERP同步漏了200个SKU。

4. 实操过程：从原始日志到可交互多维报表的完整链路

4.1 场景设定：一个真实的SaaS产品分析项目

我们以一家CRM SaaS公司的产品分析为例，目标是回答：“不同客户规模（small/mid/large）、不同行业（tech/finance/retail）、不同签约年份（2022/2023/2024）的客户，其首月活跃度（DAU/MAU）和续约率（renewal_rate）如何分布？”

原始数据源：

stg_customers（原始客户表，含customer_id,industry,size,signed_date,status）
stg_events（原始事件日志，含event_id,customer_id,event_date,event_type,duration）
stg_renewals（续约表，含customer_id,renewal_date,renewal_amount）

挑战：三张表结构松散，industry和size字段存在拼写错误（如"Tech"/"technology"/"TECH"），signed_date格式不统一（'2023-01-15'/'Jan 15, 2023'），且stg_events日志量巨大（日均5000万行）。

4.2 步骤一：数据清洗与维度建模（耗时最长，但决定成败）

1. 构建dim_customer维度表：

-- 创建标准化的客户维度 CREATE TABLE dim_customer AS SELECT customer_id, -- 标准化industry：使用映射表或CASE WHEN CASE WHEN LOWER(industry) IN ('tech', 'technology', 'it', 'software') THEN 'tech' WHEN LOWER(industry) IN ('finance', 'banking', 'insurance') THEN 'finance' WHEN LOWER(industry) IN ('retail', 'ecommerce', 'shop') THEN 'retail' ELSE 'other' END AS industry_std, -- 标准化size：统一为small/mid/large CASE WHEN size IN ('Small Business', 'SMB', 'small') THEN 'small' WHEN size IN ('Mid-Market', 'mid', 'medium') THEN 'mid' WHEN size IN ('Enterprise', 'large', 'big') THEN 'large' ELSE 'unknown' END AS size_std, -- 解析signed_year YEAR(STR_TO_DATE(signed_date, '%Y-%m-%d')) AS signed_year, -- 添加生命周期状态 CASE WHEN status = 'active' THEN 'active' WHEN status IN ('cancelled', 'churned') THEN 'churned' ELSE 'pending' END AS lifecycle_status FROM stg_customers WHERE customer_id IS NOT NULL; -- 去除脏数据

2. 构建dim_date维度表（必备！）：

-- 生成2020-2030年所有日期的维度表 WITH RECURSIVE date_series AS ( SELECT '2020-01-01'::DATE AS dt UNION ALL SELECT dt + INTERVAL '1 day' FROM date_series WHERE dt < '2030-12-31' ) SELECT dt AS date_key, YEAR(dt) AS year, QUARTER(dt) AS quarter, MONTH(dt) AS month, DAYOFWEEK(dt) AS weekday_num, CASE WHEN DAYOFWEEK(dt) IN (1,7) THEN 'weekend' ELSE 'weekday' END AS day_type, -- 是否为节假日（需外部导入） COALESCE(holiday_flag, 0) AS is_holiday FROM date_series LEFT JOIN holidays ON date_series.dt = holidays.holiday_date;

3. 构建fact_customer_metrics事实表：

-- 关联维度，计算首月活跃度 CREATE TABLE fact_customer_metrics AS SELECT c.customer_id, c.industry_std, c.size_std, c.signed_year, d.year AS event_year, d.month AS event_month, -- 首月DAU：签约后30天内的去重客户数 COUNT(DISTINCT CASE WHEN DATEDIFF(e.event_date, c.signed_date) BETWEEN 0 AND 29 THEN e.customer_id END) AS dau_first_month, -- 首月MAU：签约后30天内的总事件数（近似） COUNT(CASE WHEN DATEDIFF(e.event_date, c.signed_date) BETWEEN 0 AND 29 THEN e.event_id END) AS mau_first_month, -- 续约率：有续约记录的客户为1，否则为0 CASE WHEN r.renewal_date IS NOT NULL THEN 1 ELSE 0 END AS renewal_flag FROM dim_customer c LEFT JOIN stg_events e ON c.customer_id = e.customer_id LEFT JOIN dim_date d ON DATE(e.event_date) = d.date_key LEFT JOIN stg_renewals r ON c.customer_id = r.customer_id GROUP BY c.customer_id, c.industry_std, c.size_std, c.signed_year, d.year, d.month;

注意：这里LEFT JOIN是关键。即使某客户在首月没有事件，dau_first_month也会是0，而不是NULL，这保证了后续聚合的完整性。而GROUP BY中包含了d.year, d.month，是为了支持按事件发生时间的多维分析。

4.3 步骤二：多维聚合查询（SQL端）

现在，我们基于已清洗好的fact_customer_metrics表，执行真正的多维聚合：

-- Part 20 的核心：一次查询，多维洞察 SELECT industry_std, size_std, signed_year, AVG(dau_first_month) AS avg_dau_first_month, AVG(mau_first_month) AS avg_mau_first_month, AVG(renewal_flag) AS renewal_rate, -- 计算DAU/MAU比率（粘性指标） AVG(dau_first_month) / NULLIF(AVG(mau_first_month), 0) AS dau_mau_ratio, -- 使用GROUPING()标记粒度 GROUPING(industry_std) AS g_industry, GROUPING(size_std) AS g_size, GROUPING(signed_year) AS g_year FROM fact_customer_metrics WHERE signed_year IN (2022, 2023, 2024) GROUP BY GROUPING SETS ( (industry_std, size_std, signed_year), -- 3维交叉 (industry_std, size_std), -- 行业×规模 (industry_std, signed_year), -- 行业×年份 (size_std, signed_year), -- 规模×年份 (industry_std), -- 仅行业 (size_std), -- 仅规模 (signed_year), -- 仅年份 () -- 全局总计 ) ORDER BY g_industry, g_size, g_year, industry_std, size_std, signed_year;

结果解读：

当g_industry=0, g_size=0, g_year=0时，这是最细粒度，如('tech','mid',2023)的指标。
当g_industry=1, g_size=0, g_year=0时，这是size_std和signed_year的交叉，industry_std列为NULL，表示“所有行业的mid规模客户在2023年的平均表现”。
当g_industry=1, g_size=1, g_year=0时，这是仅按signed_year的总计，如2023年的全局平均renewal_rate。

这个结果可以直接导入BI工具，生成一个带下拉筛选的交互式仪表盘：用户选择industry_std='tech'，表格自动过滤并高亮显示tech相关的所有行（包括其上卷行），真正做到“所见即所得”。

4.4 步骤三：Pandas端的动态探索与可视化

在Jupyter中，我们用Pandas对上述SQL结果进行二次加工，生成更直观的洞察：

import pandas as pd import matplotlib.pyplot as plt import seaborn as sns # 1. 读取SQL查询结果 df_sql = pd.read_sql(query, conn) # query即上一步的SQL # 2. 清理GROUPING列，生成可读的粒度标签 def get_granularity(row): if row['g_industry'] == 1 and row['g_size'] == 1 and row['g_year'] == 1: return 'Global Total' elif row['g_industry'] == 1 and row['g_size'] == 1: return f'Year: {row["signed_year"]}' elif row['g_industry'] == 1 and row['g_year'] == 1: return f'Size: {row["size_std"]}' elif row['g_size'] == 1 and row['g_year'] == 1: return f'Industry: {row["industry_std"]}' else: return f'{row["industry_std"]} × {row["size_std"]} × {row["signed_year"]}' df_sql['granularity'] = df_sql.apply(get_granularity, axis=1) # 3. 生成热力图：行业×规模的续约率矩阵 # 过滤出最细粒度（g_*=0）的数据 df_fine = df_sql[(df_sql['g_industry']==0) & (df_sql['g_size']==0) & (df_sql['g_year']==0)] pivot_renewal = df_fine.pivot_table( values='renewal_rate', index='industry_std', columns='size_std', aggfunc='mean', fill_value=0 ) plt.figure(figsize=(8, 6)) sns.heatmap(pivot_renewal, annot=True, fmt='.2%', cmap='RdYlGn') plt.title('Renewal Rate by Industry and Customer Size (2022-2024)') plt.show() # 4. 生成趋势图：各年份续约率变化 df_yearly = df_sql[df_sql['g_industry']==1][df_sql['g_size']==1].sort_values('signed_year') plt.figure(figsize=(10, 4)) plt.plot(df_yearly['signed_year'], df_yearly['renewal_rate'], marker='o') plt.title('Overall Renewal Rate Trend (2022-2024)') plt.ylabel('Renewal Rate') plt.xlabel('Signed Year') plt.grid(True) plt.show()

这个Pandas流程的价值在于：它把SQL的“结构化输出”变成了“可感知的洞察”。热力图一眼看出tech行业的large客户续约率最高（78%），而retail行业的small客户最低（42%）；趋势图则揭示出2023年续约率出现断崖式下跌，触发了对2023年产品策略的复盘。这才是Part 20的终极目的：让数据说话，而且说得清晰、说得有力。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 “为什么我的`GROUPING SETS`结果里全是NULL？”

这是初学者最高频的问题。现象：执行GROUP BY GROUPING SETS ((a,b), (a), ())后，a和b列大量为NULL，但你知道数据里明明有值。

根本原因：GROUPING SETS的语义是“对每个集合分别分组”，而不是“在所有集合的并集上分组”。当你写((a,b), (a), ())时，引擎会：

对(a,b)分组：生成a和b都有值的行；
对(a)分组：生成a有值、b为NULL的行（因为b没参与分组）；
对()分组：生成a和b都为NULL的行（全局总计）。

所以，NULL不是错误，而是设计使然。它告诉你：“这一行的值，是在哪个粒度下计算出来的”。

排查技巧：

永远与GROUPING()函数联用。在SELECT列表中加上GROUPING(a), GROUPING(b)，然后按这两个值分组查看。你会发现，GROUPING(a)=0 and GROUPING(b)=0的行，a和b都不为NULL；GROUPING(a)=0 and GROUPING(b)=1的行，a有值、b为NULL。
用COALESCE()美化输出：SELECT COALESCE(a, 'All Channels') AS channel, ...，让报表更友好。
警惕NULL的双重含义：在GROUPING SETS中，NULL表示“上卷”，但在原始数据中，NULL表示“缺失”。务必在ETL阶段清洗掉原始NULL，否则你会分不清哪个NULL是逻辑上的，哪个是脏数据。

5.2 “`pivot_table`太慢了，100万行要20秒，怎么办？”

Pandas的pivot_table在数据量增大时，性能会急剧下降。这不是Bug，而是其设计使然：它需要构建一个完整的二维索引结构。

实测有效的加速方案：

方案1：改用pd.crosstab（针对计数类聚合）：

# 比pivot_table快3-5倍 result = pd.crosstab( index=df['platform'], columns=df['event_type'], values=df['duration_sec'], aggfunc='mean', # 或'count' normalize=False )

方案2：用groupby().size().unstack(fill_value=0)（针对计数）：

# 这是最快的计数方式，底层是C优化 result = df.groupby(['platform', 'event_type']).size().unstack(fill_value=0)

方案3：升级到Polars（下一代DataFrame）：
```
import polars as pl # Polars的pivot比Pandas快10倍以上，且内存占用低50% result = ( pl.from_pandas(df) .pivot( values='duration_sec', index='platform', columns='event_type', aggregate_function='mean' ) .to_pandas() )
```
我在处理一份800万行的广告曝光日志时，将Pandaspivot_table换成Polarspivot，时间从47秒降至3.2秒，内存峰值从4.2GB降至1.1GB。Polars是未来，值得投入学习。