多维聚合实战：从GROUP BY到立方体思维的数据操作

1. 项目概述：多维聚合中的数据操作，远不止GROUP BY那么简单

“Part 20: Data Manipulation in Multi-Dimensional Aggregation”这个标题乍看像教科书某章编号，但实际踩中了数据分析和商业智能工程中最常被低估、最易出错、也最具业务价值的一环——当数据不再是一张二维表格，而是按时间、地域、产品线、客户分层、渠道来源等多个维度交织展开时，我们到底该怎么“动”它？不是简单加总，不是机械切片，而是有策略地重塑、有逻辑地折叠、有边界地填充、有依据地推演。我带过七支不同行业的数据团队，从零售的千万级门店日销流水，到SaaS企业的百万用户行为埋点，再到制造业的设备传感器时序集群，所有项目在进入深度分析阶段后，无一例外卡在“多维聚合后的再加工”这一步。很多人以为写完GROUP BY region, product_category, month就结束了，结果发现：同比环比算不准，Top N排名跨维度失效，空缺维度无法自动补零，层级汇总与明细下钻对不上……这些不是SQL语法错误，而是对多维数据空间结构理解的断层。本篇不讲基础聚合函数，不列枯燥的窗口函数语法表，而是还原一个真实场景——某快消品牌要分析Q3华东区新品上市效果，原始数据含12个维度（省、市、区、渠道类型、门店等级、SKU、包装规格、促销档期、会员等级、新老客标识、下单时段、支付方式），需产出5类交叉报表+3种动态钻取路径+1套异常值标记规则。我会带你从零开始，拆解每一步“操作”的底层意图、技术选型依据、参数设计逻辑，以及那些只有在凌晨三点调试报表时才会咬牙记下的实操陷阱。

2. 多维聚合的本质：从表格思维到立方体思维的范式转换

2.1 为什么传统SQL思维在这里会失效？

很多工程师习惯把多维聚合理解为“多字段GROUP BY”，这是最危险的认知偏差。举个具体例子：你要统计“各城市各品类的月度销售额”，直觉写法是：

SELECT city, category, month, SUM(sales) FROM sales_fact GROUP BY city, category, month;

表面看没问题，但一旦业务方提出：“请补全所有城市×品类×月份的组合，即使某组合没有销售记录也要显示0”，问题就来了。GROUP BY天然只返回有数据的组合，而“补全”本质是构建一个笛卡尔积基底空间，再将事实数据映射上去。这不是聚合操作，而是空间定义 + 数据投射。我在某电商项目中就因此返工三次：第一次用LEFT JOIN生成全量组合，但城市列表来自维表，品类列表来自另一张维表，JOIN逻辑写错导致组合爆炸；第二次改用GENERATE_SERIES配合CROSS JOIN，但PostgreSQL版本不支持高维生成；第三次才意识到，该用OLAP引擎内置的FULL OUTER JOIN语义或预计算的维度骨架表。关键点在于：多维聚合的第一步不是写SELECT，而是明确定义维度域（Dimension Domain）——每个维度有哪些合法取值、取值间是否存在层级关系（如省→市→区）、是否允许空值、是否需要强制补全。这直接决定后续所有操作的可行性。

2.2 多维数据空间的三个核心结构特征

真正理解多维操作，必须掌握以下三个结构性特征，它们决定了你选择什么工具、怎么设计模型、甚至如何向业务解释结果：

1. 稀疏性（Sparsity）：现实世界中，绝大多数维度组合是空的。10个维度，每个维度平均100个取值，理论组合数是10^20，而实际有数据的可能不到百万分之一。处理稀疏性不是靠暴力填充，而是通过稀疏矩阵存储（如Apache Kylin的Cube Segment）或延迟物化（如Doris的Rollup Table）来规避无效计算。

2. 层级性（Hierarchy）：维度不是扁平列表，而是树状结构。例如“时间”维度包含年→季度→月→周→日，“地理”维度包含国家→省→市→区→门店。多维操作的核心能力之一是上卷（Roll-up）与下钻（Drill-down），但实现方式差异巨大：在星型模型中靠JOIN维表实现，在雪花模型中需多层JOIN，在OLAP Cube中则由元数据定义层级关系自动处理。我在做某银行风控报表时，因未在维度表中明确定义“客户等级”的层级（VIP→金卡→普卡→潜在客户），导致“按等级汇总逾期率”时，系统把“潜在客户”错误归入“普卡”分支，偏差达37%。

3. 正交性（Orthogonality）：理想情况下，各维度相互独立，组合无业务约束。但现实中存在强耦合，例如“促销档期”只适用于“KA渠道”，“会员等级”只对“已注册用户”有效。忽略正交性会导致非法组合污染结果。解决方案不是硬编码过滤，而是建立维度约束规则引擎——在ETL阶段标记合法组合，或在查询层用CASE WHEN动态屏蔽。某母婴品牌曾因未处理“渠道×促销”耦合，将线下门店的满减活动错误计入线上直播GMV，引发高层质疑。

提示：判断一个项目是否真正需要多维聚合能力，就看业务需求里是否频繁出现“任意组合筛选”“动态层级切换”“跨维度对比”等表述。如果只是固定几个报表，用宽表+索引更高效；一旦需求变得灵活，就必须切换到立方体思维。

2.3 工具链选型的底层逻辑：不是越新越好，而是匹配数据密度与查询模式

面对多维聚合，工程师常陷入工具崇拜：看到别人用Doris就上Doris，听说ClickHouse快就堆ClickHouse。但实际选型必须回归两个硬指标：数据稀疏度和查询QPS模式。我整理了四类典型场景的决策树：

选型不是技术比武，而是成本-效率权衡。某教育SaaS公司曾花三个月迁移至ClickHouse，结果发现80%查询集中在“学校×年级×学科”三个固定维度，最终用MySQL分区表+覆盖索引，性能提升2倍，运维成本降为零。

3. 核心操作详解：五类高频多维操作的技术实现与避坑指南

3.1 空维度补全（Dimensional Scaffolding）：让“没有数据”也变成有效信息

业务最常提的需求：“把所有城市都列出来，没卖货的显示0”。但“补全”不是目的，而是手段——目的是让下游计算（如同比、占比）有稳定分母。真正的难点在于：补全的范围必须可配置、可验证、可追溯。我见过太多团队用硬编码城市列表，结果行政区划调整后报表崩盘。

实操方案（以PostgreSQL为例）：

第一步：构建维度骨架表（Dimension Scaffold）

-- 创建城市维度骨架（含行政层级与状态） CREATE TABLE dim_city_scaffold AS SELECT city_code, city_name, province_code, province_name, is_active, -- 是否当前有效 valid_from, -- 生效日期 valid_to -- 失效日期 FROM dim_city WHERE is_active = true AND valid_to >= CURRENT_DATE; -- 创建时间维度骨架（按业务需求生成） CREATE TABLE dim_month_scaffold AS SELECT TO_CHAR(d, 'YYYY-MM')::TEXT as month_id, d::DATE as month_start, (d + INTERVAL '1 month' - INTERVAL '1 day')::DATE as month_end FROM GENERATE_SERIES( '2023-01-01'::DATE, '2024-12-01'::DATE, '1 month' ) AS d;

第二步：用CROSS JOIN生成全量组合，再LEFT JOIN事实表

WITH full_combination AS ( SELECT s.city_code, s.city_name, m.month_id, m.month_start FROM dim_city_scaffold s CROSS JOIN dim_month_scaffold m WHERE s.city_code IN ('SH', 'NJ', 'HZ', 'SU') -- 限定业务关注城市 ) SELECT fc.city_name, fc.month_id, COALESCE(f.sales_amount, 0) as sales_amount, COALESCE(f.order_count, 0) as order_count FROM full_combination fc LEFT JOIN fact_sales_monthly f ON fc.city_code = f.city_code AND fc.month_id = f.month_id;

关键参数设计逻辑：

• CROSS JOIN范围必须受业务约束（如WHERE s.city_code IN (...)），否则1000个城市×100个月=10万行，尚可接受；若放开到全国地级市×10年，则超亿级，必须引入分区裁剪。
• COALESCE不能简单写COALESCE(f.sales_amount, 0)，需结合业务含义：退货金额为负，应设为GREATEST(COALESCE(f.sales_amount, 0), 0)避免负值干扰。

注意：补全不是万能药。某物流项目曾要求“补全所有司机×线路×日期”，但司机每日跑线路是动态调度的，强行补全会产生大量虚假0值，误导运力分析。此时应改用“最近7天活跃司机×线路”作为基底，更符合业务实际。

3.2 动态Top N截断（Dynamic Top-N with Ties）：别让“第10名”成为业务黑洞

“查各城市销量Top 10门店”看似简单，但LIMIT 10会丢失并列情况。更致命的是：业务真正需要的常是“Top 10及并列者”，或“Top 10占全市销量80%以上的城市”。这要求操作具备上下文感知能力。

实操方案（窗口函数进阶用法）：

WITH city_store_rank AS ( SELECT city_code, store_id, sales_amount, -- RANK()处理并列，DENSE_RANK()更紧凑，ROW_NUMBER()严格唯一 RANK() OVER (PARTITION BY city_code ORDER BY sales_amount DESC) as rank_num, -- 计算累计占比，用于动态阈值 SUM(sales_amount) OVER ( PARTITION BY city_code ORDER BY sales_amount DESC ROWS UNBOUNDED PRECEDING ) * 1.0 / SUM(sales_amount) OVER (PARTITION BY city_code) as cum_pct FROM fact_store_daily WHERE dt BETWEEN '2023-09-01' AND '2023-09-30' ), top_n_filter AS ( SELECT city_code, store_id, sales_amount, rank_num, cum_pct, -- 动态阈值：取Top 10或累计占比≥80%，取更宽松者 CASE WHEN rank_num <= 10 THEN 'fixed_top10' WHEN cum_pct >= 0.8 THEN 'pct_threshold' ELSE 'excluded' END as filter_flag FROM city_store_rank ) SELECT * FROM top_n_filter WHERE filter_flag != 'excluded';

为什么不用ROW_NUMBER()？
ROW_NUMBER()给并列值分配不同序号，导致“第10名”实际可能是第12家店，业务无法接受。RANK()保留并列，但需额外处理“第10名有3家并列，是否全取？”——这就是filter_flag的设计意义：用业务规则而非技术规则决策。

实操心得：

• 在某连锁餐饮项目中，我们发现单纯Top 10掩盖了“长尾效应”：上海前10店占全市65%，但杭州前10仅占32%。于是增加cum_pct字段，让业务方自主滑动阈值，报表交互性大幅提升。
• ROWS UNBOUNDED PRECEDING必须显式声明，否则某些数据库（如旧版MySQL）默认RANGE语义，对相同销售额会错误聚合。

3.3 跨维度比率计算（Cross-Dimensional Ratio）：分母陷阱比想象中更深

“华东区新品A的市占率”——这句话隐含三重维度：地理（华东）、时间（Q3）、产品（新品A）。但市占率=新品A销量 / 华东区所有新品销量。问题来了：分母的“所有新品”是否包含同属华东但未上市新品？是否包含已退市新品？比率计算的本质是定义分母的维度上下文。

实操方案（用CTE明确分母范围）：

WITH numerator AS ( -- 分子：华东区Q3上市的新品A销量 SELECT SUM(sales_amount) as num_value FROM fact_sales f JOIN dim_product p ON f.product_id = p.product_id JOIN dim_region r ON f.region_id = r.region_id WHERE r.region_name = '华东' AND p.is_new_launch = true AND p.product_name = '新品A' AND f.month_id BETWEEN '2023-07' AND '2023-09' ), denominator AS ( -- 分母：华东区Q3所有在售新品销量（排除退市、未上市） SELECT SUM(sales_amount) as den_value FROM fact_sales f JOIN dim_product p ON f.product_id = p.product_id JOIN dim_region r ON f.region_id = r.region_id WHERE r.region_name = '华东' AND p.is_new_launch = true AND p.status = 'on_sale' -- 关键！限定“在售”状态 AND f.month_id BETWEEN '2023-07' AND '2023-09' ) SELECT n.num_value * 1.0 / NULLIF(d.den_value, 0) as market_share_pct FROM numerator n, denominator d;

关键设计点解析：

• NULLIF(d.den_value, 0)防止除零错误，但更重要的是：分母为0时，业务需知道是“无数据”还是“计算逻辑错误”。我们在生产环境增加告警：当den_value = 0且num_value > 0时触发，说明分子分母定义冲突。
• p.status = 'on_sale'是业务规则，不是技术假设。某次上线前，产品团队未同步“新品B因质检暂停销售”，导致分母错误包含B，市占率虚高22%。

提示：所有比率类指标必须配套“分母构成明细”报表。我在某车企项目中，坚持为每个KPI提供下钻页，点击市占率数字即可查看“分母包含哪些车型、哪些区域、哪些时间”，业务方信任度显著提升。

3.4 层级上卷与下钻（Hierarchical Roll-up/Drill-down）：让“省→市”不只是JOIN

多维分析的灵魂在于自由切换粒度。但GROUP BY province和GROUP BY province, city之间不是简单增减字段，而是维度层级的导航。问题在于：不同数据库对层级的支持差异极大。

实操方案（以Doris为例，展示原生层级能力）：

首先在建模阶段定义维度层级：

-- 创建物化视图，定义地理层级 CREATE MATERIALIZED VIEW mv_sales_geo_hierarchy AS SELECT province, city, district, SUM(sales_amount) as total_sales, COUNT(DISTINCT order_id) as order_cnt FROM fact_sales GROUP BY province, city, district PROPERTIES( "force_external_table_query_rewrite" = "true" );

查询时利用Doris的智能路由：

-- 自动匹配mv_sales_geo_hierarchy，无需指定GROUP BY SELECT province, SUM(total_sales) FROM mv_sales_geo_hierarchy GROUP BY province; -- 下钻到城市级，同样走同一MV SELECT province, city, SUM(total_sales) FROM mv_sales_geo_hierarchy GROUP BY province, city;

对比传统方案（MySQL）的缺陷：

• 需为每个粒度建单独汇总表（agg_province,agg_city,agg_district），ETL维护成本翻倍。
• 下钻时需JOIN维表获取上级信息，如查“上海销量”需JOIN dim_city ON c.city_id = d.city_id，而Doris直接在MV中存储province字段，减少JOIN。

实操心得：

• 层级定义必须与业务术语一致。某零售项目将“商圈”定义为district，但业务方口头说“片区”，导致报表命名混乱。我们强制要求：所有维度字段名=业务词典词条名。
• 上卷时警惕“重复计算”。某次将“门店级”数据上卷到“城市级”，因部分门店归属多个商圈，未去重导致城市销量虚高。解决方案：在事实表中增加city_id冗余字段，确保上卷路径唯一。

3.5 异常值标记与归因（Anomaly Flagging & Attribution）：从“发现异常”到“定位根因”

多维聚合的终极价值不是呈现数据，而是驱动决策。“华东区Q3销量下降15%”是结果，业务需要的是“为什么下降？是上海跌了还是南京跌了？是高端线跌了还是入门款跌了？是新客少了还是复购低了？”。这要求操作具备多维归因能力。

实操方案（Shapley值简化版，适配SQL）：

WITH base_metrics AS ( SELECT '2023-Q3' as period, SUM(sales_amount) as sales_total, COUNT(DISTINCT user_id) as user_cnt, AVG(order_amount) as avg_order FROM fact_sales WHERE month_id BETWEEN '2023-07' AND '2023-09' ), comp_metrics AS ( SELECT '2022-Q3' as period, SUM(sales_amount) as sales_total, COUNT(DISTINCT user_id) as user_cnt, AVG(order_amount) as avg_order FROM fact_sales WHERE month_id BETWEEN '2022-07' AND '2022-09' ), delta_calc AS ( SELECT b.period as curr_period, c.period as prev_period, b.sales_total - c.sales_total as sales_delta, b.user_cnt - c.user_cnt as user_delta, b.avg_order - c.avg_order as avg_order_delta FROM base_metrics b, comp_metrics c ), -- 简化归因：按各维度贡献比例分配总变化 attribution AS ( SELECT 'user_cnt' as dimension, (user_delta * avg_order) / NULLIF(sales_delta, 0) as contribution_pct FROM delta_calc UNION ALL SELECT 'avg_order' as dimension, (avg_order_delta * user_cnt) / NULLIF(sales_delta, 0) as contribution_pct FROM delta_calc, base_metrics ) SELECT * FROM attribution;

为什么不用机器学习归因？
Shapley值虽精准，但需完整特征矩阵和训练周期。在BI场景中，业务可解释性优先于数学严谨性。上述简化公式ΔSales ≈ ΔUsers × AvgOrder + Users × ΔAvgOrder，业务方一眼看懂：销量变化=新客变化带来的影响 + 客单价变化带来的影响。

实操心得：

• 归因必须绑定维度。某次分析发现“新客减少”是主因，但未下钻到“新客减少发生在哪些城市”，导致市场部无法精准投放。我们在归因结果后强制追加TOP 3 city by user_delta子查询。
• 设置归因阈值。当某维度贡献<5%，标记为“次要因素”，避免业务方过度解读噪音。

4. 实操全流程：从原始日志到多维分析报表的7步落地

4.1 步骤1：维度建模审计（Dimensional Modeling Audit）

在写任何聚合SQL前，必须完成维度建模审计。这不是文档工作，而是技术动作。我用一张检查表驱动：

关键动作：所有检查必须自动化为ETL前置校验脚本，失败则阻断任务。我在某金融项目中，将此检查嵌入Airflow DAG，每次调度前运行，拦截了87%的数据质量问题。

4.2 步骤2：稀疏度探查与基底设计（Sparsity Profiling）

运行以下探查SQL，决定补全策略：

-- 计算各维度组合的实际填充率 WITH combo_stats AS ( SELECT COUNT(*) as total_combos, COUNT(DISTINCT CONCAT(city_code, '|', category_id, '|', month_id)) as filled_combos FROM fact_sales ) SELECT filled_combos * 1.0 / total_combos as sparsity_ratio, CASE WHEN filled_combos * 1.0 / total_combos < 0.001 THEN 'Highly Sparse: Use OLAP Cube' WHEN filled_combos * 1.0 / total_combos < 0.01 THEN 'Moderate: Use Materialized View' ELSE 'Dense: Use Indexed Fact Table' END as recommendation FROM combo_stats;

经验技巧：

• 对高稀疏数据，绝不尝试CROSS JOIN全量补全。某次处理10维数据，理论组合10^15，我们改用“采样+插值”：先对高频组合（占80%流量）全量补全，低频组合用最近邻插值估算。
• 稀疏度会随时间变化。每月运行一次探查，动态调整策略。

4.3 步骤3：维度骨架生成（Scaffold Generation）

基于审计结果，生成维度骨架：

# 使用Python脚本动态生成（非SQL硬编码） # 输入：维度配置文件 dimensions.yaml # 输出：dim_city_scaffold.sql, dim_month_scaffold.sql 等 python generate_scaffold.py --config dimensions.yaml --output sql/

dimensions.yaml示例：

city: source_table: dim_city filters: ["is_active = true", "valid_to >= current_date"] fields: ["city_code", "city_name", "province_code"] month: type: "date_series" start: "2023-01-01" end: "2025-12-01" interval: "1 month" fields: ["month_id", "month_start", "month_end"]

为什么不用纯SQL生成？
因为业务规则会变：某次行政区划调整，需新增“直辖市下属区”层级，纯SQL需人工修改所有CROSS JOIN，而YAML配置只需更新fields，脚本自动生成。

4.4 步骤4：多维聚合SQL编写（Multi-Dimensional Aggregation SQL）

遵循“原子化+可组合”原则：

-- 原子化：每个CTE只做一件事 WITH sales_base AS ( -- 基础过滤与清洗 SELECT city_code, category_id, month_id, GREATEST(sales_amount, 0) as sales_amount -- 清洗负值 FROM fact_sales WHERE sales_amount IS NOT NULL ), sales_scaffolded AS ( -- 补全 SELECT s.city_code, s.category_id, s.month_id, COALESCE(b.sales_amount, 0) as sales_amount FROM dim_city_scaffold s CROSS JOIN dim_category_scaffold c CROSS JOIN dim_month_scaffold m LEFT JOIN sales_base b ON s.city_code = b.city_code AND c.category_id = b.category_id AND m.month_id = b.month_id ), sales_analyzed AS ( -- 分析计算 SELECT city_code, category_id, month_id, sales_amount, LAG(sales_amount, 1) OVER ( PARTITION BY city_code, category_id ORDER BY month_id ) as last_month_sales FROM sales_scaffolded ) -- 最终输出：只在此处定义业务逻辑 SELECT city_code, category_id, month_id, sales_amount, (sales_amount - last_month_sales) * 1.0 / NULLIF(last_month_sales, 0) as mom_growth_rate FROM sales_analyzed;

关键纪律：

• CTE命名体现意图（sales_base,sales_scaffolded），而非技术动作（t1,t2）。
• 所有计算放在最后CTE，前面只做数据准备。

4.5 步骤5：性能压测与索引优化（Performance Benchmarking）

对核心查询进行三轮压测：

1. 冷启动压测：清空缓存后首次执行，观察是否OOM或超时。
2. 热缓存压测：重复执行10次，取P95耗时，确认稳定性。
3. 并发压测：模拟50并发，观察CPU/IO瓶颈。

索引优化口诀：

• WHERE字段必建索引（如month_id,city_code）
• GROUP BY字段按顺序建联合索引（INDEX idx_geo_time (city_code, category_id, month_id)）
• 高基数维度（如user_id）不单独建索引，改用分区

某次优化中，为fact_sales表增加(city_code, month_id)联合索引，Q3查询从23s降至0.8s。

4.6 步骤6：结果验证与业务对齐（Result Validation）

验证不是比数字，而是比逻辑：

独家技巧：在报表前端增加“验证开关”，点击即显示该单元格的底层SQL和原始数据行，业务方自查时信任感倍增。

4.7 步骤7：监控告警与迭代闭环（Monitoring & Iteration）

上线后必须监控：

• 数据新鲜度：SELECT MAX(month_id) FROM agg_city_month，若超过24小时未更新则告警
• 空值率突增：SELECT COUNT(*) FILTER (WHERE sales_amount = 0) * 1.0 / COUNT(*) FROM agg_city_month，若>30%触发调查
• 查询失败率：Prometheus采集Presto/Doris查询失败日志，>5%告警

迭代闭环机制：
每周收集团队反馈，分类为：

• Bug类（如计算错误）：24小时内修复
• 体验类（如加载慢）：放入下月优化排期
• 需求类（如新增维度）：评估后纳入季度规划

某电商项目通过此机制，6个月内将多维报表平均响应时间从8.2s降至1.4s，业务方使用率提升300%。

5. 常见问题与排查技巧实录：那些凌晨三点教会我的事

5.1 问题1：补全后数据量爆炸，查询直接超时

现象：补全脚本运行后，full_combination表达千万级，LEFT JOIN事实表后查询超时。

排查思路：

1. 先查EXPLAIN ANALYZE，确认是否走索引。若显示Seq Scan on fact_sales，说明缺少city_code, month_id联合索引。
2. 检查CROSS JOIN范围。用SELECT COUNT(*) FROM dim_city_scaffold确认城市数，若超500，需业务确认是否真需全部。
3. 查事实表数据分布：SELECT COUNT(*) FROM fact_sales WHERE city_code IN (SELECT city_code FROM dim_city_scaffold)，若为0，说明维度表与事实表ID不匹配。

根本解决：

• 业务侧：与PM确认“华东区”是否真指所有地级市，还是仅核心12城。
• 技术侧：改用IN子查询替代CROSS JOIN，让数据库优化器选择Nested Loop：

  SELECT s.city_code, m.month_id, COALESCE(f.sales_amount, 0) FROM dim_city_scaffold s CROSS JOIN dim_month_scaffold m LEFT JOIN fact_sales f ON f.city_code = s.city_code AND f.month_id = m.month_id AND s.city_code IN ('SH','NJ','HZ') -- 限定范围

5.2 问题2：Top N结果跨维度不一致，业务方质疑数据质量

现象：“各城市Top 10门店”总和为120家，但“全国Top 10门店”中只有5家在城市Top 10中出现。

原因分析：

• RANK()在不同PARTITION BY下独立排序，不存在全局序号。
• 业务混淆了“局部最优”与“全局最优”。

解决方案：
提供双视角报表：

• 局部视角：各城市内排名，用于城市经理考核
• 全局视角：全国统一排名，用于总部资源调配
• 交叉透视：新增“是否进入城市Top 10”布尔列，让业务方自主筛选

代码实现：

WITH global_rank AS ( SELECT store_id, RANK() OVER (ORDER BY SUM(sales_amount) DESC) as global_rank_num FROM fact_sales GROUP BY store_id ), city_rank AS ( SELECT city_code, store_id, RANK() OVER (PARTITION BY city_code ORDER BY SUM(sales_amount) DESC) as city_rank_num FROM fact_sales GROUP BY city_code, store_id ) SELECT c.city_code, c.store_id, c.city_rank_num, g.global_rank_num, CASE WHEN g.global_rank_num <= 10 THEN 'Yes' ELSE 'No' END as in_global_top10 FROM city_rank c LEFT JOIN global_rank g ON c.store_id = g.store_id;

5.3 问题3：同比计算结果为NULL，但业务坚称有数据

现象：LAG(sales_amount, 12) OVER (...)返回NULL，但业务说去年同月有销售。

排查步骤：

1. 检查时间维度骨架是否覆盖去年：SELECT MIN(month_id), MAX(month_id) FROM dim_month_scaffold
2. 检查事实表是否有去年数据：SELECT COUNT(*) FROM fact_sales WHERE month_id = '2022-09'
3. 检查PARTITION BY字段是否包含影响排序的维度：若PARTITION BY city_code, category_id，但去年该城市无此品类，则LAG为NULL。

终极解决：
改用FIRST_VALUE+RANGE窗口，强制取时间上最近的有效值：

FIRST_VALUE(sales_amount) OVER ( PARTITION BY city_code, category_id ORDER BY month_id RANGE BETWEEN INTERVAL '11 months' PRECEDING AND INTERVAL '11 months' PRECEDING ) as last_year_sales

5.4 问题4：多维报表加载缓慢，前端白屏超10秒

现象：BI工具