2025/05/31 by XILEJUN & Deepseek 2025-07-25 修改，补充《数据分析通识》中的内容
前几日在于阿里瓴羊的产品经理沟通后，发现大家对维度和度量的理解依然受到数据中台的深刻影响。在我看来，其实是维度度量的语境不够清晰。 尝试用 AI 整理一下，后期有机会完整整理发布。
一、基础概念与父子关系类比
1.1 字段的原始状态
在原始数据表中，所有字段都处于"未定义"状态。例如订单表：
此时sales只是数字列，region只是文本列，没有维度/度量的区分。
1.2 分析问题赋予身份
当提出具体问题如"各区域销售额是多少？"时，通过SQL查询：
SELECT region AS 区域, SUM(sales) AS 销售额
FROM orders
GROUP BY region;类比理解： 就像"父亲"身份需要"孩子"存在才能确立，维度/度量需要分析问题才能获得身份。
二、多层聚合中的角色转换
2.1 嵌套聚合案例
计算"各区域销售额占比"需要两次聚合：
SELECT region, region_sales, region_sales/total_sales*100 AS percentFROM (SELECT region,SUM(sales) AS region_sales,SUM(SUM(sales)) OVER() AS total_salesFROM ordersGROUP BY region) AS temp;2.2 身份转换三阶段
三、物化中间表的实践与局限
-- 创建物化表CREATE TABLE region_summary ASSELECT region, SUM(sales) AS region_salesFROM orders GROUP BY region;-- 基于物化表计算SELECT region, region_sales,region_sales/(SELECT SUM(region_sales) FROM region_summary) AS percentFROM region_summary;9.5.1 为什么指标必须在模型之上
假设一个这样的业务场景，一家零售超市在全市四大区域分别有多家门店，每天为数万客户提供各类母婴用品。为了提高公司领导访问经营报告的效率，IT 部门决定把领导当问的几个问题转化为数据仓库的“视图”（view），并每天凌晨6点钟完成一次全量提取作业。对应“视图”如下：
表9- 高度聚合的统计报表示例：“各年月的区域品类销售表”
年 │ 月 │ 区域 │ 品类 │ 数量 │ 销售额 │ 毛利率
2025 │ 9 │ 东区 │ 奶粉 │ 400 │ 80010 │ 20%
2025 │ 9 │ 东区 │ 尿裤 │ 200 │ 20010 │ 15%
2025 │ 9 │ 东区 │ 日用品 │ 300 │ 3010 │ 35%
2025 │ 9 │ 东区 │ 服装 │ 500 │ 50010 │ 40%
…… │ …… │ …… │ …… │ …… │ …… │ ……
需要特别注意的是，“物化表”中“数量”“销售额”和“毛利率”仅仅是和年、月一样的数值了，物化的是每一行优秀的聚合值，失去了“聚合”的过程。
笔者把“逻辑视图”的“物化”称之为实质意义上的“退化”！它从逻辑表退化为了物理表，其中的逻辑的、聚合的“度量”退化为表示特定业务意义的“计量属性”，退化为物理意义上的数值。就像失去了投资价值的房地产仅仅是一堆石块，失去了梦想的年轻人如同是一株芦苇。正因为此，本书第8章8.4小节认为，物化的“分析聚合表”也是特殊的事实表。
退化的后果是结果遮挡了细节、失去了灵活性；就像晒成鱼干的鱼儿失去了生的气息。
1）“退化”遮挡了业务的细节
以上面的“各年月的区域品类销售表”为例，当数据提取发生之后，数据表的粒度就止步于“年月、区域、品类”，不能回答任何更细节的问题，比如为什么奶粉9月份销售贡献大幅下滑？为什么日用品的毛利率大幅波动？为什么东区的毛利率贡献持续抵御南区？
2）“退化”让度量失去了灵活性
更严重的问题是，“退化”导致哪些没有可加性（addictive）的“逻辑指标”失去了灵活性。比如，领导希望基于“各年月的区域品类销售表”计算“各年月各地区的总体毛利率”，原本逻辑的毛利率字段（聚合判断）此时失去了适应任何问题的兼容特征，不管是算术平均还是相加都不能获得正确答案；而只能回退到“毛利率”的计算逻辑，倒推计算出“毛利额”而后加权计算。
既然如此，为什么不让逻辑的“毛利率”字段独立于物化表之外呢？
这就是指标落在模型之上，而非模型之中的价值和必要性。
举例……
真正的逻辑指标，对所有问题都有适应能力，就像人适应任何一个环境都能生存；
……
No comments yet