多维聚合不是简单GROUP BY：数据变形术揭秘 1. 这不是简单的“加总求平均”——多维聚合中的数据变形术到底在干什么你有没有遇到过这样的场景销售报表里要同时按“地区产品线季度”三个维度看营收但原始数据只有一张扁平的交易流水表或者做用户行为分析时需要把千万级日志按“设备类型×访问时段×页面路径”交叉分组再计算每个组合的跳出率和平均停留时长这时候Excel 的数据透视表点几下就出结果但真要写代码实现很多人卡在第一步——不是不会写GROUP BY而是根本没想清楚当维度从1个变成3个、5个甚至动态嵌套时“聚合”这件事本身已经悄然升级为一场精密的数据结构手术。这就是“Part 20: Data Manipulation in Multi-Dimensional Aggregation”真正要解决的问题。它不讲基础的SUM()或COUNT()而是聚焦在多维聚合过程中数据如何被切割、重组、填充、对齐、降维与再投影——这些操作决定了最终报表能否支撑业务决策而不是仅仅生成一堆数字堆砌的表格。我带团队做过7个行业客户的BI系统落地发现83%的数据口径争议根源不在SQL写错而在于多维聚合时对“空维度组合是否保留”“时间窗口如何对齐”“层级间聚合顺序是否可交换”这些底层逻辑的理解偏差。这篇文章会带你一层层剥开这些黑箱为什么Pandas的pivot_table默认不补零而crosstab会为什么Spark SQL里GROUPING SETS比嵌套UNION ALL快3倍以上当你在Tableau里拖拽一个“年-季度-月”层级钻取时背后实际发生的到底是ROLLUP还是CUBE所有答案都藏在多维聚合的数据变形逻辑里。适合正在写复杂报表SQL的分析师、用Python做商业分析的工程师、以及需要理解BI工具底层机制的产品经理——只要你每天和“按X、Y、Z分组汇总”打交道这篇就是你的实操手册。2. 多维聚合的本质从“单刀直入”到“空间切片”的范式转移2.1 为什么二维思维在多维场景下必然失效先看一个典型反例。假设你有这样一张销售明细表regionproductquarteramount华东手机Q1120华东手机Q2150华北笔记本Q180如果只按region聚合得到的是两个标量值华东270、华北80。这是典型的“一维切片”数据被压缩成一条直线。但当你增加product维度问题立刻出现华东笔记本、华北手机这些组合在原始数据中根本不存在它们该显示为NULL、0还是直接从结果集中消失这个选择不是技术问题而是业务语义问题——如果报表用于考核区域经理空组合必须显式标注为0表示“未完成目标”如果用于市场部分析新品渗透率空组合则应剔除避免误导“该区域无此产品”。我在某电商公司做GMV归因时就踩过这个坑财务要求所有“国家×品类”组合必须存在哪怕金额为0否则无法匹配预算系统而算法团队只要真实成交组合空值会污染模型特征。最终我们不得不在ETL层拆成两条链路。这就是二维思维的致命缺陷它把聚合看作“对行做运算”而多维聚合本质是在N维立方体Cube上定义子空间并计算其度量值。每个维度都是一个坐标轴region是X轴华东/华北/华南product是Y轴手机/笔记本/平板quarter是Z轴Q1/Q2/Q3/Q4。原始数据只是散落在这个立方体中的若干点而聚合操作是在指定子空间比如“所有X-Y平面”或“某个X-Y-Z顶点”上进行数值积分。理解这一点才能明白为什么GROUP BY region, product和GROUP BY product, region结果完全相同坐标轴顺序不影响空间结构但GROUP BY region WITH ROLLUP却会额外生成“华东小计”“华北小计”“总计”三层切片——它不是简单地多算一遍而是主动扩展了查询覆盖的空间范围。2.2 多维聚合的四大核心变形操作及其物理意义在N维空间中一次聚合请求实际触发四种底层数据变形每种都对应明确的数学操作和业务含义空间裁剪Space Pruning这是最常被忽略的隐形步骤。当你写WHERE region IN (华东,华北) AND quarter Q1数据库并非先全量聚合再过滤而是在聚合前就将立方体裁剪为仅包含华东/华北×所有产品×Q1的子立方体。这直接影响性能如果原始数据有100个地区裁剪后只需处理2个地区的数据。但要注意某些OLAP引擎如Doris支持预聚合物化视图此时裁剪可能发生在物化层而非原始表导致WHERE条件无法下推。实测过ClickHouse的场景对10亿行订单表按region,product聚合后加WHERE region华东耗时1.2秒但若先建好region_product_agg物化视图同样查询只要0.3秒——因为裁剪直接作用于已压缩的聚合结果。维度对齐Dimension Alignment当多个数据源参与聚合时维度值必须严格对齐。例如用户表有device_type: iOS,Android,Web而埋点日志里是os: ios,android,windows。如果直接JOIN后GROUP BY device_type, os会生成6个组合其中iOS-windows这种无效组合会拉低准确率。正确做法是在聚合前用映射字典统一维度值。我们给某金融APP做渠道归因时市场部给的渠道名是“微信公众号”运营后台存的是“wechat_official_account”第三方SDK返回的是“weixin_mp”。最后用一个标准化字典在ETL层强制转换才让“渠道×新客来源”聚合结果可信。这里的关键洞察是维度对齐不是数据清洗的附属品而是多维聚合的前置契约。空值填充Null Imputation空组合的处理直接决定报表可用性。SQL标准提供了GROUPING()函数识别ROLLUP产生的空值但业务层面需要更精细控制。比如零售业要求“所有门店×所有SKU组合必须存在”但全量补零会导致TB级中间表。我们的解法是用GENERATE_SERIES生成维度笛卡尔积再LEFT JOIN聚合结果。PostgreSQL示例SELECT s.store_id, s.sku_id, COALESCE(t.sales, 0) as sales FROM (SELECT store_id, sku_id FROM stores CROSS JOIN skus) s LEFT JOIN (SELECT store_id, sku_id, SUM(amount) as sales FROM sales WHERE date 2024-01-01 GROUP BY store_id, sku_id) t ON s.store_id t.store_id AND s.sku_id t.sku_id;这比FULL OUTER JOIN更可控且能配合分区表优化。空间折叠Space Folding这是多维聚合最反直觉的操作。当你执行GROUP BY region, product WITH CUBE引擎实际构建的是所有可能的子空间组合(region,product)、(region)、(product)、()。注意最后一个空括号代表“全集”即总计。但CUBE和ROLLUP的区别在于ROLLUP (a,b,c)只生成(a,b,c)、(a,b)、(a)、()四层而CUBE生成全部8种组合2³。在某车企客户项目中他们用CUBE分析“车型×配置×颜色”结果生成了2000个组合其中90%是零销量比如“Model Y×19寸轮毂×荧光绿”报表加载慢且干扰决策。后来改用GROUPING SETS ((车型),(配置),(颜色))只保留单维度分析效率提升5倍。这说明空间折叠不是越多越好必须匹配业务分析粒度。提示多维聚合的性能瓶颈往往不在计算本身而在空间爆炸。一个含5个维度、各维度基数为100的表CUBE会产生100⁵10¹⁰个组合。生产环境务必用EXPLAIN ANALYZE确认执行计划是否走索引扫描而非全表哈希。3. 实战拆解从原始日志到可钻取报表的七步变形链3.1 场景设定某在线教育平台的完课率分析需求业务方提出需求“我要看每个学科Math/English下不同年级G1-G12的学生在每周周一至周日的课程完课率且能下钻到具体教师”。原始数据是Kafka实时流入的course_events表关键字段包括user_id用户IDsubject学科枚举值grade_level年级字符串teacher_id教师IDevent_type事件类型start/finishevent_time事件时间timestamp目标报表需支持① 按subject × grade_level × week_day查看完课率② 点击某个学科可下钻到该学科下所有教师的完课率③ 周一至周日必须按自然顺序排列非字母序这个需求表面是“三维度聚合”实则暗含五个技术关卡时间维度标准化、空组合补全、比率计算陷阱、层级下钻机制、排序稳定性。下面用Flink SQL PostgreSQL组合方案完整演示七步变形链。3.2 步骤1时间维度原子化——把时间戳掰成可聚合的零件原始event_time是2024-03-15 14:22:33但业务要的是“周一至周日”不是具体日期。直接用EXTRACT(DOW FROM event_time)会得到0-6周日到周六而业务要求周一为1、周日为7。这里有两个坑坑1时区陷阱。Kafka消息用UTC时间但业务统计需中国时区UTC8。若直接AT TIME ZONE UTC会把北京时间14:00当成UTC 06:00导致周一事件算成周日。坑2DOW定义差异。PostgreSQL默认周日0但ISO标准周一1。解决方案用TO_CHAR(event_time AT TIME ZONE Asia/Shanghai, ID)ID格式符强制返回ISO周编号1-7。验证2024-03-15 14:22:33周五→5完美匹配。这步变形后新增week_day字段值域为{1,2,3,4,5,6,7}。3.3 步骤2事件配对——从离散事件到可度量的会话完课率完课人数/开课人数但原始数据是单事件流。必须先将start和finish事件配对成会话session。难点在于同一用户同一天可能上多节课需区分会话finish事件可能丢失不能简单COUNT(finish)/COUNT(start)我们采用基于事件时间窗口的会话重建-- Flink SQL 创建临时视图 CREATE VIEW sessionized AS SELECT user_id, subject, grade_level, teacher_id, week_day, -- 以start事件为基准向后找120分钟内的finish事件 CASE WHEN COUNT(CASE WHEN event_typefinish THEN 1 END) 0 THEN 1 ELSE 0 END as is_completed, COUNT(*) as total_events FROM ( SELECT *, -- 为每个start事件分配会话ID同一用户学科120分钟窗口内首个start FIRST_VALUE(event_time) OVER ( PARTITION BY user_id, subject ORDER BY event_time RANGE BETWEEN INTERVAL 0 SECOND AND INTERVAL 120 MINUTE FOLLOWING ) as session_start FROM course_events WHERE event_type IN (start,finish) ) t GROUP BY user_id, subject, grade_level, teacher_id, week_day, session_start;这步将原始事件流转化为会话粒度is_completed标记会话是否完成。注意RANGE BETWEEN确保时间窗口精确避免ROWS BETWEEN因事件乱序导致配对错误。3.4 步骤3维度标准化——让业务术语和数据字段严丝合缝业务方说“年级G1-G12”但数据里有Grade 1、g1、一年级三种写法。若直接聚合G1和Grade 1会被视为不同维度值。我们建立标准化映射表grade_mappingraw_gradestandard_gradesort_orderGrade 1G11g1G11一年级G11.........在聚合前LEFT JOIN此表用standard_grade替代原始grade_level。关键技巧sort_order字段用于后续按自然顺序排序G1,G2,...,G12避免字符串排序导致G10排在G2前。3.5 步骤4构建维度立方体——用笛卡尔积锚定所有合法组合业务要求“每个学科×每个年级×每周七天”必须存在即使某天无数据也要显示0。但全量笛卡尔积3学科×12年级×7天252组合远小于数据量可接受。创建维度表dim_cubeCREATE TABLE dim_cube AS SELECT s.subject, g.standard_grade, w.week_day FROM (VALUES (Math),(English),(Science)) s(subject) CROSS JOIN (SELECT DISTINCT standard_grade, sort_order FROM grade_mapping) g CROSS JOIN (VALUES (1),(2),(3),(4),(5),(6),(7)) w(week_day) ORDER BY s.subject, g.sort_order, w.week_day;这步生成252行“骨架”后续所有聚合结果都将以此为基准LEFT JOIN确保空组合不丢失。3.6 步骤5安全比率计算——避开除零和精度陷阱完课率计算看似简单SUM(is_completed)/COUNT(*)。但这里有三个致命风险风险1COUNT(*)包含未配对的finish事件。若某会话只有start无finishis_completed0但COUNT(*)1导致分母虚高。风险2整数除法截断。SUM(is_completed)和COUNT(*)都是整数5/100而非0.5。风险3NULL传播。若某组合无数据SUM/COUNT返回NULL而非0。终极方案SELECT c.subject, c.standard_grade, c.week_day, ROUND( COALESCE(SUM(s.is_completed), 0)::DECIMAL / NULLIF(COUNT(*), 0), 4 ) as completion_rate, COALESCE(SUM(s.is_completed), 0) as completed_count, COUNT(*) as started_count FROM dim_cube c LEFT JOIN sessionized s ON c.subject s.subject AND c.standard_grade s.standard_grade AND c.week_day s.week_day GROUP BY c.subject, c.standard_grade, c.week_day ORDER BY c.subject, (SELECT sort_order FROM grade_mapping WHERE standard_grade c.standard_grade), c.week_day;COALESCE(SUM(),0)确保分子为0而非NULLNULLIF(COUNT(*),0)使分母为0时返回NULL避免除零错误::DECIMAL强制转为小数类型ROUND(...,4)保留4位小数ORDER BY中嵌套子查询用sort_order保证年级自然序3.7 步骤6下钻机制实现——用GROUPING SETS替代硬编码层级业务要求点击学科可下钻到教师这意味着同一SQL需输出两层聚合层级1subject × grade_level × week_day主报表层级2subject × teacher_id下钻视图若用UNION ALL拼接需两次扫描数据。更优解是GROUPING SETSSELECT subject, CASE WHEN GROUPING(teacher_id) 0 THEN teacher_id ELSE NULL END as teacher_id, CASE WHEN GROUPING(grade_level) 0 THEN grade_level ELSE NULL END as grade_level, CASE WHEN GROUPING(week_day) 0 THEN week_day ELSE NULL END as week_day, SUM(is_completed) as completed, COUNT(*) as started, GROUPING(teacher_id) as is_subject_level, GROUPING(grade_level) as is_teacher_level FROM sessionized GROUP BY GROUPING SETS ( (subject, grade_level, week_day), -- 主报表维度 (subject, teacher_id) -- 下钻维度 );GROUPING()函数返回1表示该列在当前分组中被折叠即NULL值由GROUPING SETS生成非原始数据NULL。前端根据is_subject_level和is_teacher_level标志位判断当前行属于哪一层级实现无缝下钻。实测在千万级数据上GROUPING SETS比双UNION ALL快2.3倍且内存占用降低40%。3.8 步骤7结果交付——用物化视图固化聚合结果实时计算虽灵活但报表查询延迟不可控。我们采用T1物化视图策略每日凌晨2点用上述SQL生成completion_report_mv对subject,grade_level,week_day建复合索引设置autovacuum参数避免大表膨胀关键经验物化视图刷新时用CREATE TABLE AS新建表再ALTER TABLE ... RENAME TO原子切换避免锁表影响报表服务。某次大促期间我们通过此方案将报表首屏加载从8秒降至0.9秒。注意多维聚合的物化不是简单缓存而是空间预计算。dim_cube的252行骨架必须随业务变化动态更新——当新增学科“Art”时需同步刷新dim_cube和物化视图否则新学科数据永远不显示。4. 工具选型深度对比不同场景下谁才是真正的多维聚合王者4.1 OLAP引擎三巨头Doris、ClickHouse、StarRocks的核心差异点面对海量数据的多维聚合选型不是看谁跑得快而是看谁的空间计算模型最贴合业务语义。我们对比三个主流引擎在关键场景的表现能力维度Apache DorisClickHouseStarRocks空组合补全支持FULL OUTER JOINARRAY JOIN生成笛卡尔积语法直观需arrayJoingroupArray模拟代码冗长原生CUBE/ROLLUP但空值需手动COALESCE动态维度Bitmap列高效支持IN查询千万级维度值过滤100msLowCardinality优化枚举但动态新增维度需重导数据Colocate Join保证分桶一致跨维度关联稳定比率计算SUM/MAX等聚合函数自动处理NULLDIVIDE函数防除零必须用if(x0,NULL,y/x)易遗漏SAFE_DIVIDE内置函数一行解决除零实时性Mini-batch流式导入端到端延迟≈2分钟ReplacingMergeTree需手动OPTIMIZE延迟不稳定Primary Key模型实时更新延迟1秒学习成本MySQL协议兼容SQL几乎零迁移成本自研SQL方言WITH子句嵌套深易出错兼容MySQL但高级特性需适配实战选型建议传统企业报表如银行月报选Doris。它的FULL OUTER JOIN对空组合处理最符合财务人员思维“缺什么补什么”逻辑清晰DBA维护成本最低。广告归因分析高基数、低延迟选StarRocks。某信息流平台实测10亿行曝光日志按campaign×ad_group×creative三维度聚合StarRocks耗时1.8秒Doris 3.2秒ClickHouse 4.7秒。关键在StarRocks的Runtime Filter能提前剪枝90%无关分区。IoT设备监控超高基数维度选ClickHouse。当设备ID达亿级时Doris的Bitmap内存暴涨而ClickHouse的LowCardinality(String)将字符串维度压缩至1/5内存且uniqCombined去重函数精度达99.99%。实测陷阱ClickHouse的GROUP BY默认不排序ORDER BY需显式声明。某次我们漏写ORDER BY subject,grade_level导致前端渲染时年级乱序被业务方投诉“数据不准”。记住ClickHouse的聚合结果顺序是未定义的必须加ORDER BY。4.2 Python生态Pandas vs Polars的多维聚合哲学差异当数据量在GB级Python仍是主力工具。但Pandas和Polars对多维聚合的设计哲学截然不同Pandas的“矩阵思维”pivot_table是其多维聚合核心本质是构建二维矩阵行×列值填入度量。优势在于fill_value0一键补零marginsTrue自动生成小计aggfunc{sales:sum,count:count}支持多度量与Matplotlib无缝集成df.plot()直接出热力图但致命短板内存不可控。pivot_table会先生成完整矩阵再聚合100万行数据按100×100维度透视内存峰值达8GB。我们曾因此导致Jupyter内核崩溃。Polars的“流式管道思维”group_by().agg()是其核心不预分配空间逐块处理# Polars内存恒定≈数据大小×2 result df.group_by([subject,grade_level,week_day]).agg([ pl.col(is_completed).sum().alias(completed), pl.col(is_completed).count().alias(started) ]).with_columns([ (pl.col(completed) / pl.col(started)).round(4).alias(rate) ])内存占用稳定100万行仅需1.2GBlazy()模式支持查询优化自动合并filter和group_by但空组合补全需手动join维度表不如Pandas便捷选型口诀数据100MB要快速出图 → Pandas数据1GB要稳定跑批 → Polars需要交互式探索 → Pandas datatable内存优化版4.3 BI工具底层揭秘Tableau/Power BI/Tableau的聚合真相很多分析师以为拖拽字段就万事大吉其实BI工具在发送SQL前已做大量预处理Tableau默认启用Aggregate Measures将SUM([Sales])下推到数据库。但若开启Analysis Aggregate Measures它会在内存中二次聚合导致结果与数据库直查不一致。某次我们发现Tableau报表比DB查询高5%根源在此。Power BIDAX的SUMMARIZE函数本质是GROUP BY但CALCULATE会动态修改筛选上下文。计算“华东手机Q1占比”时CALCULATE(SUM(Sales), ALL(region))会清除地区筛选而ALL(region,product)会清除地区和产品筛选——少写一个维度结果天壤之别。Superset开源方案GROUPING SETS支持完善但需手动配置Ad-hoc Filter对空组合处理弱于商业工具。避坑指南在BI工具中开启“查看生成的SQL”功能确认聚合是否下推对关键指标用数据库直查结果与BI报表比对误差0.1%立即排查禁用BI工具的客户端聚合如Tableau的Aggregate Measures所有计算在服务端完成5. 常见问题与排查技巧实录那些让资深工程师也挠头的多维聚合陷阱5.1 问题1聚合结果与Excel透视表不一致但SQL语法完全正确现象数据库查出华东,手机,Q1销售额为120万Excel透视表显示118万差额2万。排查路径检查数据源时间范围Excel连接的是sales_2024_q1视图而SQL查的是sales表。发现视图有WHERE statusconfirmed而原始表含pending状态订单。验证维度值标准化Excel中“华东”包含“上海”“江苏”“浙江”而SQL中region字段只有“华东”字符串。原来业务方要求按省级粒度聚合但开发误用了大区字段。确认空值处理逻辑Excel透视表默认忽略NULL而SQL用COALESCE(amount,0)。某笔订单amountNULLExcel不计入SQL计入为0导致计数差异。根治方案建立《维度字典》文档明确定义每个维度的业务含义、取值范围、数据来源表在ETL层添加数据质量校验SELECT region, COUNT(*) FROM sales GROUP BY region HAVING COUNT(*) 1000检测异常稀疏维度所有BI报表必须标注数据源版本和更新时间戳5.2 问题2GROUP BY后数据量暴增查询超时现象对1亿行订单表按user_id,product_id,category聚合结果返回2亿行远超预期。原因分析user_id有1000万唯一值product_id有50万category有100个理论最大组合5万亿但实际2亿说明存在严重数据质量问题。抽样检查发现product_id字段含大量NULL、undefined、 等脏数据被当作合法值参与组合。解决步骤清洗维度值UPDATE sales SET product_id NULL WHERE TRIM(product_id) IN (NULL,undefined,) OR LENGTH(TRIM(product_id))0;添加约束ALTER TABLE sales ADD CONSTRAINT chk_product_id CHECK (product_id IS NOT NULL AND LENGTH(TRIM(product_id))0);监控维度基数每日运行SELECT COUNT(DISTINCT product_id) FROM sales基数值突变20%触发告警。经验心得维度基数是多维聚合的“血压计”。我们给某物流客户部署后发现driver_id基数日增10万追查发现是司机APP未做登录态校验每次启动生成新ID。修复后聚合耗时从15分钟降至42秒。5.3 问题3ROLLUP结果中出现重复小计行现象SELECT region, product, SUM(amount) FROM sales GROUP BY region, product WITH ROLLUP返回regionproductsum华东手机120华东NULL270NULLNULL350NULL手机180根源WITH ROLLUP按GROUP BY顺序生成小计(region,product)的ROLLUP只产生(region)和()两层NULL,手机是非法组合。此现象表明数据中存在regionNULL的脏记录导致GROUP BY将NULL视为独立值。验证SQLSELECT COUNT(*) FROM sales WHERE region IS NULL; -- 返回127条修复方案立即清理DELETE FROM sales WHERE region IS NULL;长期防护在应用层拦截region为空的插入请求替代方案用GROUPING SETS ((region,product),(region),())明确指定小计层级避免隐式生成5.4 问题4多维聚合结果在不同数据库间不一致现象同一SQL在PostgreSQL和MySQL中执行GROUP BY region, product结果行数相同但SUM(amount)值相差0.03%。深度排查浮点数精度PostgreSQL的NUMERIC和MySQL的DECIMAL默认精度不同。PostgreSQLNUMERIC无精度限制MySQLDECIMAL(10,2)强制截断。NULL处理MySQL的SUM()跳过NULLPostgreSQL同理但COUNT(*)在MySQL中不计NULL行PostgreSQL中计数一致。字符集排序region字段在MySQL用utf8mb4_unicode_ciPostgreSQL用en_US.UTF-8导致GROUP BY分组键哈希值不同。统一方案所有金额字段用DECIMAL(18,2)显式声明精度字符串维度用COLLATE C强制二进制排序消除区域设置影响在ETL层用MD5(CONCAT(region,|,product))生成一致性哈希键作为分组依据5.5 问题5实时聚合延迟飙升但CPU/内存正常现象Flink作业处理延迟从1秒升至300秒TaskManager资源使用率30%。排查发现Watermark生成停滞event_time最大值卡在10分钟前检查Kafkacourse_eventsTopic的__consumer_offsets分区有积压根本原因某教师ID为teacher_123|backup竖线|被Kafka消费者误解析为分隔符导致反序列化失败消息堆积根治措施所有维度值在生产环境强制URL编码URLEncoder.encode(teacher_id, UTF-8)Kafka消费者添加DeserializationSchema校验失败消息转入DLQ Topic监控numRecordsInPerSec和numRecordsOutPerSec差值1000/秒触发告警实操心得多维聚合的稳定性70%取决于数据质量30%取决于技术选型。我们给某在线医疗平台做架构评审时发现他们花200万买StarRocks集群却没预算做数据清洗。最后用dbt搭建轻量级数据质量层成本不到5万将聚合错误率从12%降至0.3%。记住再强的引擎也救不了脏数据。6. 终极实践用一个真实案例贯穿所有关键技术点6.1 案例背景跨境电商“全球购”的库存周转分析业务痛点全球12个仓库2000个SKU每日入库/出库/调拨事件超500万条运营要“按仓库×国家×品类”看库存周转天数且支持下钻到具体SKU财务要求所有组合必须存在空仓显示为0但空SKU不补避免虚假库存数据表结构inventory_eventswarehouse_id, country, category, sku_id, event_type(in,out,move), qty, event_timesku_mastersku_id, category, weight_kg, volume_l主数据表6.2 六步落地全流程已在生产环境稳定运行18个月步骤1构建安全维度立方体-- 只补全仓库×国家×品类不补SKU业务规则 CREATE TABLE dim_inventory_cube AS SELECT w.warehouse_id, w.country, c.category FROM warehouses w CROSS JOIN (SELECT DISTINCT category FROM sku_master) c;步骤2事件归一化处理-- 将出入库事件统一为“净库存变化” CREATE VIEW inventory_net AS SELECT warehouse_id, country, category, SUM(CASE WHEN event_typein THEN qty WHEN event