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

多维聚合不是GROUP BY：构建可导航数据立方体的七步实战法

news 2026/7/4 10:28:09

1. 这不是简单的“加总求平均”——多维聚合中的数据变形术到底在解决什么问题？

如果你正在处理销售报表、用户行为宽表、IoT设备时序快照，或者哪怕只是Excel里一张带地区、月份、产品线、渠道四个维度的汇总表，那你大概率已经踩进过这个坑：明明写了GROUP BY region, month, product_category，结果一跑SQL，发现“华东Q3高端机销量”和“全国Q3所有机型销量”根本不在同一张结果表里；或者用Pandas做pivot_table时，想同时看“各城市按周粒度的订单量+复购率+客单价”，却被迫拆成三段代码、生成三个DataFrame再手动merge；更别提当业务方突然说“再加一列：对比去年同期的环比变化率”，你得重写整个聚合逻辑，连索引对齐都得手动校验。这些不是操作失误，而是多维聚合天然携带的结构性矛盾——它要求我们同时处理“分组切片”“跨维度滚动”“层级钻取”“指标衍生”四类动作，而传统单层GROUP BY或基础透视表只解决了第一个问题。本篇标题里的“Data Manipulation in Multi-Dimensional Aggregation”，核心不是教你怎么写SUM()，而是讲清楚：当维度从2个涨到5个、指标从1个变成8个、时间粒度要支持日/周/月/年自由切换时，如何让数据变形过程不崩、不漏、不歧义、不重复计算。我带过的17个BI项目里，83%的线上报表故障根源不在数据库性能，而在多维聚合环节的中间态数据被错误地reset_index()、fillna()或concat()——比如把“空值填充为0”直接用在了“未发生交易的区域-月份组合”上，结果把真实的零销量和缺失数据混为一谈。所以这篇内容适合三类人：需要交付稳定多维报表的分析师、正在重构OLAP查询引擎的后端工程师、以及刚学完Pandas基础但一碰stack()/unstack()就卡壳的数据科学新人。它不讲抽象理论，只讲我在电商大促实时看板、金融风控宽表构建、制造业设备健康度建模中反复验证过的实操路径。

2. 多维聚合的本质不是“分组”，而是构建可导航的立方体空间

2.1 为什么必须抛弃“GROUP BY思维”，转向“立方体建模思维”

很多人把多维聚合等同于“多字段GROUP BY”，这是最危险的认知偏差。举个真实案例：某零售客户要求看“各门店（120家）× 各商品类目（45个）× 各促销类型（6种）”的周销量。如果用纯SQL写：

SELECT store_id, category, promo_type, SUM(sales) as total_sales FROM sales_fact WHERE week_id BETWEEN '2024-W20' AND '2024-W24' GROUP BY store_id, category, promo_type;

表面看没问题，但当业务方第二天追加需求：“再加一列：该门店该类目下所有促销类型的销量总和”，你就得重写——因为原SQL的GROUP BY粒度锁死了，无法在同一结果集中同时存在“细粒度组合”和“粗粒度汇总”。这暴露了本质：多维聚合真正的对象不是行，而是维度坐标构成的超立方体（Hypercube）中的单元格（Cell）。每个单元格存储一个或多个度量值（如销量、毛利、订单数），而“聚合”动作实质是定义单元格间的父子关系与计算路径。比如“华东区销量”不是对“上海店+南京店+杭州店”的简单SUM，而是立方体中“region=华东”这一层级节点对其子节点的roll-up操作。这种结构天然支持：

钻取（Drill-down）：华东 → 上海 → 徐汇区门店
上卷（Roll-up）：iPhone → 智能手机 → 所有电子品类
切片（Slicing）：固定promo_type='满300减50'，观察其他维度变化
切块（Dicing）：同时限定region='华东' AND month='2024-05' AND category='大家电'

提示：当你发现自己在代码里频繁写df.groupby(['a','b']).agg({...}).reset_index()再merge另一个groupby(['a'])结果时，说明你已经在用“拼图方式”模拟立方体，效率低且易错。真正的解法是先定义维度层次（Dimension Hierarchy），再声明计算规则（Calculation Rule）。

2.2 维度建模的三大铁律：正交性、完整性、一致性

多维聚合失效的根源，90%出在维度设计阶段。我见过最典型的反例：把“用户等级”和“会员有效期”塞进同一个维度表，导致“VIP用户（等级5）但已过期”和“普通用户（等级1）但有效期剩余365天”在聚合时被强制归入同一分类，完全扭曲业务逻辑。因此必须遵守：

第一铁律：正交性（Orthogonality）
每个维度必须独立表达单一业务概念。例如“时间维度”应严格分离：

date_key（20240520）→ 唯一日期标识
week_id（2024-W21）→ 自然周
fiscal_month（2024-F05）→ 财政月（可能与自然月错位）
season（Summer）→ 季节标签
它们之间是映射关系（lookup table），而非嵌套关系。一旦把week_id和fiscal_month硬编码进同一字段，后续做“周同比”和“月环比”就会冲突。

第二铁律：完整性（Completeness）
维度表必须覆盖所有可能的业务状态，包括“未知”“不适用”“待确认”。某物流项目曾因维度表缺失delivery_status='转运中'枚举值，导致该状态订单在聚合时被过滤掉，老板看到的“当日妥投率”虚高12%。正确做法是在维度表首行插入代理键（Surrogate Key）：

sk_delivery_status	delivery_status	status_desc
-1	Unknown	数据未同步
-2	Not Applicable	无需配送（自提订单）
1	Pending	待揽收
2	InTransit	转运中

第三铁律：一致性（Consistency）
同一维度在不同事实表中必须保持相同结构和语义。比如“产品维度”在销售事实表和库存事实表中，product_category字段的取值范围、命名规范、层级深度必须100%一致。我们曾用MD5哈希校验两个事实表关联的产品维度键，发现库存表中23%的category值多了一个空格，导致关联后出现大量NULL，最终在聚合时被dropna()误删。

2.3 度量值的陷阱：可加性、半可加性、不可加性的实战判别法

度量值（Measure）不是随便选个数值字段就能聚合的。我整理了一张在12个行业项目中验证过的判别清单，直接决定你的SUM()是否合法：

度量值示例	可加性类型	判别依据	错误聚合后果	实操方案
订单金额	可加性（Additive）	在任意维度上求和都有意义（华东+华南=全国）	无	直接`SUM()`
库存数量	半可加性（Semi-additive）	可按时间维度求和（周初+周末≠周总量），但可按产品维度求和	把“每日库存快照”直接`SUM()`导致库存虚高300%	用`LAST_VALUE()`取期末值，或`AVG()`算日均
用户数	不可加性（Non-additive）	“上海用户数+北京用户数”有意义，但“5月用户数+6月用户数”无意义（重复计数）	用`COUNT(DISTINCT user_id)`在月粒度聚合，再`SUM()`会严重高估	必须用`COUNT(DISTINCT)`，且禁止跨时间维度累加
毛利率	导出型（Derived）	由（收入-成本）/收入计算得出，不能直接聚合	对毛利率字段`AVG()`得到错误值（应先汇总收入/成本再计算）	永远先聚合分子分母，最后一步计算比率

注意：很多团队把“转化率”设为预计算字段存入事实表，这是灾难性设计。当需要按新维度（如新增的“流量来源细分”）重新切分时，你无法从原始转化率反推点击数和成交数。正确姿势是只存原子度量（clicks, orders），转化率作为视图层计算字段。

3. 核心操作链：从原始事实表到可交互立方体的七步变形流程

3.1 步骤1：清洗维度键——用代理键替代自然键的硬核理由

原始数据中，product_id可能是字符串“PROD-00123-A”，store_code可能是“SH-NJ-001”。这些自然键（Natural Key）在聚合中会引发三类问题：

长度溢出：Hive表中STRING类型JOIN比BIGINT慢47%（实测TPC-DS基准）
变更污染：某品牌将“PROD-00123-A”更名为“PROD-00123-B”，历史记录全部断联
空值灾难：store_code=NULL在GROUP BY中被单独归为一组，但业务上它可能代表“总部直营”或“数据缺失”，语义模糊

解决方案：为每个维度表生成代理键（Surrogate Key）。不是简单用ROW_NUMBER()，而是采用哈希代理键（Hash Surrogate Key）：

# PySpark示例：基于维度属性生成稳定哈希键 from pyspark.sql.functions import sha2, concat_ws, lit dim_product = dim_product.withColumn( "sk_product", sha2(concat_ws("|", "product_id", "brand", "category", lit("v1")), 256) ).withColumn("sk_product", expr("conv(substr(sk_product, 1, 15), 16, 10)")) # 截取前15位转十进制

这样做的好处：

同一产品在不同ETL批次中生成相同sk_product，保证历史一致性
sha2输出固定长度，避免JOIN时隐式类型转换
conv(...,16,10)将十六进制转十进制，适配下游系统整型主键要求

实操心得：我们曾用ROW_NUMBER()生成代理键，结果因上游数据顺序变动导致键值漂移，修复时不得不重建3个月的历史快照。哈希键彻底终结了这个问题。

3.2 步骤2：构建维度层次——用树形结构管理“省-市-区-街道”的血缘关系

多维聚合中，“华东区销量”不是简单WHERE region='华东'，而是要自动包含其下所有省市。这就要求维度表自带层级关系。以地理维度为例，正确的建表结构必须包含：

sk_location：本级代理键
location_name：本级名称（如“上海市”）
level_type：层级类型（Province/City/District/Street）
parent_sk：父级代理键（“上海市”的parent_sk指向“华东区”的sk_location）
path：完整路径（/CN/EAST/SHANGHAI/）

关键技巧：用path字段实现快速钻取。当用户点击“华东区”下钻到“上海市”时，SQL只需：

SELECT * FROM fact_sales WHERE sk_location IN ( SELECT sk_location FROM dim_location WHERE path LIKE '/CN/EAST/SHANGHAI/%' -- 匹配所有子节点 )

比递归CTE快8倍（实测1.2亿行事实表）。更进一步，在ETL中预计算level_depth（华东=1，上海=2，徐汇区=3），这样“上卷到省级”只需WHERE level_depth=1，无需任何JOIN。

3.3 步骤3：事实表瘦身——剥离非度量字段，只留原子事实

这是最容易被忽视的一步。很多团队把order_status、payment_method、user_gender全塞进事实表，导致：

存储膨胀：某电商事实表因冗余字段达2.3TB，查询延迟从800ms升至4.2s
关联爆炸：一个订单关联5个维度表，JOIN后行数从1亿暴增至8亿

正确做法：事实表只保留三类字段：

维度外键（Foreign Keys）：sk_product,sk_store,sk_time等，全部为代理键
原子度量（Atomic Measures）：quantity_sold,revenue,shipping_cost等不可再分的数值
事务标识（Transaction ID）：order_id,invoice_no，仅用于溯源，不参与聚合

所有描述性字段（如product_name,store_address）必须移入对应维度表。某金融项目将loan_purpose（贷款用途）从事实表移到维度表后，聚合查询性能提升63%，因为GROUP BY时不再对长文本字段排序。

3.4 步骤4：预计算汇总层——为什么不能全靠“即席查询”

有人认为“现代OLAP引擎足够快，何必预计算？”。这是用个人笔记本的体验去想象生产环境。真实场景：

某实时风控系统需在500ms内返回“该用户过去30天在12个省份的交易频次+金额分布”，涉及3个维度交叉（user×province×day）
查询引擎若每次实时GROUP BY，需扫描2.7亿行明细，CPU打满仍超时

我们的解法：构建三级汇总层（Aggregation Layer）：

层级	粒度	更新频率	典型查询响应
L0（明细层）	订单级	实时（秒级）	>5s（仅调试用）
L1（轻度汇总）	日×产品×渠道	小时级	<800ms
L2（高度汇总）	月×大区×品类	日级	<200ms

关键创新：L1层不存SUM(revenue)，而存revenue_list ARRAY<DECIMAL>，用AGGREGATE函数动态计算。例如：

-- Presto语法：避免预计算固定指标，支持灵活衍生 SELECT province, count(*) as order_cnt, reduce(revenue_list, 0, (s,x)->s+x, s->s) as total_revenue, reduce(revenue_list, 0, (s,x)->s+if(x>1000,1,0), s->s) as high_value_order_cnt FROM l1_summary GROUP BY province

这样既节省存储（ARRAY比展开行省67%空间），又保留计算灵活性。

3.5 步骤5：处理稀疏性——当90%的单元格是空值时怎么办

多维立方体天然稀疏。一个5维模型（地区×产品×渠道×时间×客户等级），若每维取值数为[30,200,15,365,5]，理论单元格数达30×200×15×365×5=1.64亿，但实际填充率常低于0.3%。强行物化会导致：

存储浪费：99.7%的空间存NULL
查询变慢：引擎需扫描大量空值

我们的工业级方案：稀疏矩阵压缩存储 + 动态填充策略。

存储层：用Parquet的dictionary encoding压缩维度键，对度量值列启用RLE（游程编码），实测稀疏数据压缩率达92%

查询层：定义sparsity_threshold=0.5%，当某维度组合的填充率低于阈值时，自动触发COALESCE填充：

-- 对“新上线产品在冷门渠道”的空值，用同类产品均值填充 SELECT COALESCE( actual_sales, AVG(actual_sales) OVER ( PARTITION BY product_category, channel_type ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING ) ) as imputed_sales FROM sparse_cube

注意：填充必须标注来源。我们在结果表中增加sales_source VARCHAR字段，值为'actual'或'imputed_by_category_avg'，确保分析师知道哪些数字是估算的。

3.6 步骤6：指标衍生引擎——用DSL替代硬编码的计算逻辑

业务指标如“复购率=二次购买用户数/总购买用户数”“LTV/CAC比值”绝不能写死在SQL里。我们开发了轻量级指标DSL（Domain Specific Language）：

# metrics.yaml retention_rate_7d: type: ratio numerator: sql: "COUNT(DISTINCT CASE WHEN days_since_first_order <= 7 THEN user_id END)" denominator: sql: "COUNT(DISTINCT user_id)" dimensions: [region, product_category] time_window: "last_30_days"

ETL工具解析此DSL，自动生成带WITH子句的SQL：

WITH base AS ( SELECT sk_region, sk_product_category, user_id, DATEDIFF(CURRENT_DATE, first_order_date) as days_since_first_order FROM fact_orders WHERE order_date >= DATE_SUB(CURRENT_DATE, 30) ), numerator AS ( SELECT sk_region, sk_product_category, COUNT(DISTINCT user_id) as cnt FROM base WHERE days_since_first_order <= 7 GROUP BY sk_region, sk_product_category ), denominator AS ( SELECT sk_region, sk_product_category, COUNT(DISTINCT user_id) as cnt FROM base GROUP BY sk_region, sk_product_category ) SELECT n.sk_region, n.sk_product_category, CAST(n.cnt AS DOUBLE) / NULLIF(d.cnt, 0) as retention_rate_7d FROM numerator n JOIN denominator d ON n.sk_region=d.sk_region AND n.sk_product_category=d.sk_product_category

好处：业务方改指标只需编辑YAML，无需找工程师，发布周期从3天缩短至15分钟。

3.7 步骤7：版本化立方体——如何让“昨天的报表”和“今天的报表”不打架

最痛的场景：运营同事说“昨天看华东区销量是1200万，今天怎么变成1150万了？数据被篡改了！”。真相是：维度表更新了——昨天“苏州工业园店”还属于“苏州市”，今天被划归“江苏省直管区”，导致聚合路径改变。

解决方案：立方体版本控制（Cube Versioning）。

每次维度表或事实表更新，生成唯一cube_version（如20240520-1423-v3）

查询时强制指定版本：

SELECT * FROM sales_cube_v3 WHERE cube_version = '20240520-1423-v3' -- 锁定历史快照

自动化：在调度系统中，当检测到维度表updated_at变化，触发新版本立方体构建，并保留旧版本30天

我们用此方案后，数据争议事件下降98%，因为所有报表都可追溯到精确的版本快照。

4. 高阶实战：处理真实世界中的四大“反模式”及破解方案

4.1 反模式1：时间维度错乱——当“财务月”和“自然周”打架时

某车企客户要求“2024年Q2各车型销量”，但财务系统按4-4-5周历（每月28天，每季91天），而销售系统用自然月。直接WHERE date BETWEEN '2024-04-01' AND '2024-06-30'会导致：

4月1日-3日的订单被计入Q1（财务口径）
6月29日-30日的订单被计入Q3（财务口径）

破解方案：双时间维度桥接表（Bridge Table）
创建dim_time_bridge表，明确映射关系：

calendar_date	fiscal_year	fiscal_quarter	fiscal_week	is_fiscal_qtr_start
2024-04-01	2024	Q2	2024-W14	true
2024-06-30	2024	Q2	2024-W26	false

聚合时用桥接表关联：

SELECT b.fiscal_quarter, p.model_name, SUM(f.revenue) as revenue FROM fact_sales f JOIN dim_time_bridge b ON f.sk_date = b.calendar_date JOIN dim_product p ON f.sk_product = p.sk_product WHERE b.fiscal_quarter = '2024-Q2' GROUP BY b.fiscal_quarter, p.model_name

此方案让财务和业务口径并存，无需改造源系统。

4.2 反模式2：渐变维度（SCD Type 2）在聚合中的“时间旅行”难题

用户画像维度常用SCD Type 2（缓慢变化维度），即同一用户ID在不同时间有不同属性。例如：

user_id	gender	start_date	end_date	is_current
U123	Male	2024-01-01	2024-04-15	false
U123	Female	2024-04-16	9999-12-31	true

若直接JOIN事实表，2024年4月的订单会关联到gender='Female'，但该用户3月的订单呢？传统方案用BETWEEN start_date AND end_date，但大数据量下JOIN性能极差。

破解方案：事实表打宽+时间戳对齐
在ETL中，将SCD维度属性打宽到事实表：

-- 用窗口函数获取订单时间点的最新维度属性 SELECT f.order_id, f.order_date, LAST_VALUE(d.gender) OVER ( PARTITION BY f.user_id ORDER BY d.start_date RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) as gender_at_order_time FROM fact_orders f JOIN dim_user_scd d ON f.user_id = d.user_id

这样聚合时无需JOIN，直接GROUP BY gender_at_order_time，性能提升12倍。

4.3 反模式3：多值维度（Multi-Valued Dimension）——一个订单含多个优惠券怎么办

电商订单常有“满减券+品类券+红包”叠加，若强行用GROUP BY order_id, coupon_id，会把1个订单拆成3行，导致SUM(quantity)虚高3倍。

破解方案：优惠券数组化 + 聚合函数化解
将多值维度转为ARRAY：

order_id	coupon_ids ARRAY
O123	['COUP-001', 'COUP-005']

聚合时用TRANSFORM函数：

-- 统计“使用满减券的订单占比” SELECT COUNT(*) FILTER (WHERE contains(coupon_ids, 'COUP-001')) * 100.0 / COUNT(*) as coupon_usage_rate FROM fact_orders

或展开统计：

SELECT coupon_id, COUNT(*) as order_cnt FROM fact_orders CROSS JOIN UNNEST(coupon_ids) AS t(coupon_id) GROUP BY coupon_id

关键是绝不让多值维度进入GROUP BY主键，否则必然重复计数。

4.4 反模式4：实时与离线数据融合——当Flink流和Hive批处理结果对不上

某实时大屏显示“当前小时GMV：245万”，而离线报表显示“今日累计GMV：1890万”，但245×24=5880万 ≠ 1890万，误差达210%。根因：流处理用TUMBLING WINDOW（整点切分），而离线用PARTITIONED BY date（自然日），导致1点的数据在流中算入1点窗口，在离线中算入5月20日分区。

破解方案：统一时间锚点（Time Anchor）
定义全局event_time_anchor：

流处理：TUMBLING WINDOW基于event_time，但输出时增加anchor_date = TO_DATE(event_time)
离线处理：PARTITION仍用ds，但计算时强制WHERE event_time >= anchor_date AND event_time < anchor_date + INTERVAL '1' DAY

最终聚合层只认anchor_date，彻底隔离时间切分逻辑。上线后，流批数据差异从210%降至0.3%（可归因于网络延迟）。

5. 工具链选型与避坑指南：从Pandas到StarRocks的实操决策树

5.1 小规模探索（<100万行）：Pandas的隐藏配置技巧

很多人抱怨Pandas pivot慢，其实是没开对配置。关键三步：

预设类别（Category）：对维度列转category类型，内存降65%，groupby提速3.2倍

df['region'] = df['region'].astype('category') df['product_category'] = df['product_category'].astype('category')

禁用自动排序：pivot_table(sort=False)跳过内部sort_values，提速40%
用agg替代apply：df.groupby(['a','b']).agg({'sales':'sum', 'orders':'count'})比apply(lambda x: pd.Series(...))快8倍

注意：Pandas的melt()/pivot()本质是内存密集型操作。当df.memory_usage().sum() > 0.6 * psutil.virtual_memory().available时，必须切分处理，否则直接OOM。

5.2 中等规模（100万-1亿行）：Spark SQL的调优红线

Spark不是“加大executor内存就行”。我们总结出五条必调参数：

参数	推荐值	为什么
`spark.sql.adaptive.enabled`	true	自动合并小文件，避免Shuffle阶段OOM
`spark.sql.adaptive.coalescePartitions.enabled`	true	将1000个小分区合并为50个，减少Task数
`spark.sql.autoBroadcastJoinThreshold`	80MB	防止大表Broadcast导致Driver内存溢出
`spark.sql.optimizer.dynamicPartitionPruning.enabled`	true	关联时自动过滤无效分区，减少扫描量
`spark.sql.adaptive.localShuffleReader.enabled`	true	本地Shuffle读取，减少网络IO

实测：某1200万行销售数据聚合，调优后耗时从210秒降至48秒，资源消耗降37%。

5.3 大规模实时（>1亿行）：StarRocks vs Doris的抉择逻辑

两者都是MPP架构，但场景适配不同：

StarRocks：强在高并发点查。某广告平台需支撑2000QPS的“某用户最近100次点击详情”，StarRocks用Bitmap索引+Colocate Join，P99延迟<120ms；Doris同场景P99达380ms。
Doris：强在复杂ETL。其INSERT INTO SELECT支持UNION ALL嵌套、LATERAL VIEW，某物流项目用Doris一条SQL完成“轨迹点聚合→停留点识别→仓配路径匹配”，而StarRocks需拆成3步。

决策树：

如果你的场景是“报表即席查询+高并发看板” → StarRocks
如果你的场景是“数据清洗+多层聚合+定时宽表产出” → Doris
如果两者都要 → 用StarRocks做查询层，Doris做ETL层，通过Routine Load同步

血泪教训：曾在一个实时风控项目中强行用Doris支撑5000QPS的规则查询，结果因BE节点GC频繁，延迟毛刺达2.3秒，导致误拦截订单。换StarRocks后稳定在85ms内。

5.4 可视化层陷阱：Tableau/Power BI的“自动聚合”如何偷走你的数据

BI工具默认开启“Aggregate Measures”，当你拖入revenue字段，它自动加SUM()。问题在于：

若事实表已预聚合（如L2层月度汇总），再SUM()会虚高100%
若度量是半可加性（如库存），SUM()直接错误

破解方案：在数据源层显式声明聚合规则

StarRocks：建VIEW时用CREATE VIEW sales_view AS SELECT ...，并在BI连接时勾选“Disable auto-aggregation”
Power BI：在“建模”选项卡中，右键度量值 → “属性” → 设置“Default summarization”为“Don’t summarize”
Tableau：在数据源页面，右键字段 → “Default Properties” → “Aggregation” → 选择“None”

我们要求所有BI看板上线前，必须提供《聚合规则说明书》，列出每个字段的原始类型（可加/半可加/不可加）和BI中设置的聚合方式，签字存档。

6. 常见问题与排查技巧实录：那些让资深工程师熬夜的诡异Bug

6.1 问题1：“同样的SQL，昨天跑得快，今天慢10倍”——元数据缓存污染

现象：某聚合SQL昨日执行42秒，今日突增至480秒，EXPLAIN显示执行计划未变，但Shuffle Read从2.1GB涨到24GB。

排查路径：

检查SHOW TABLE STATS，发现fact_sales表的numRows从1.2亿变为12亿（明显错误）
追溯：上游ETL任务失败，但ANALYZE TABLE命令仍被执行，用错误的采样率更新了统计信息
修复：COMPUTE STATS fact_sales强制全量统计，耗时18分钟，恢复后查询43秒

避坑技巧：在ETL脚本末尾加校验：SELECT COUNT(*) FROM fact_sales与SHOW TABLE STATS对比，偏差>5%则告警并跳过ANALYZE。

6.2 问题2：“GROUP BY结果少了17行”——NULL值在分组中的隐形消失

现象：维度表有120个地区，但GROUP BY region后只有103行，缺失的17个全是region=NULL。

根因：SQL标准规定NULL不等于NULL，因此GROUP BY时所有NULL被归为一组，但某些引擎（如旧版Presto）默认filter NULL。

三步定位：

SELECT COUNT(*), COUNT(region) FROM fact_sales→ 若两数不等，证明有NULL
SELECT region, COUNT(*) FROM fact_sales GROUP BY region→ 查看是否有<NULL>行
SELECT * FROM fact_sales WHERE region IS NULL LIMIT 5→ 检查NULL的业务含义

终极方案：在维度表中用代理键-1表示Unknown，事实表强制NOT NULL约束，从源头消灭NULL。

6.3 问题3：“环比计算结果是负数，但业务说不可能”——时间窗口错位

现象：计算“5月销量环比4月”，结果为-92%，但业务确认5月活动力度更大。

诊断：检查时间字段类型。发现sale_date是STRING类型（'2024-05-01'），而LAG()函数按字典序排序，'2024-04-30'排在'2024-05-01'之后，导致LAG取到的是4月30日而非4月31日（不存在），返回NULL，计算式NULL / value = NULL，前端显示为0或负数。

修复：