考察点
这道题出自阿里数仓实习一面，是数仓方法论的核心概念题。面试官想确认三件事：你知道维度建模的基本构件（事实表、维度表、业务过程、粒度）；你能讲清星型和雪花的结构差异及各自代价；最重要的是选型时你有工程判断——现代 MPP 和列存时代为什么星型基本一边倒。追问常往"维度退化是什么"、"缓慢变化维怎么处理"、"事实表有哪几种类型"走，这些是维度建模的连环题。
参考答案
维度建模的基本构件
Kimball 维度建模把数据组织成事实表和维度表两类。事实表记录业务过程的度量：一行代表一个可度量的业务事件（一笔订单明细、一次支付），由外键（指向维度）和度量值（金额、数量，要求可加或半可加）组成。维度表描述"谁在什么时间什么地点对什么对象做了什么"里的名词：用户维、商品维、时间维、地区维，特点是行少列多、描述性属性丰富。
建模的标准四步要背得出更要用得上：选业务过程（下单还是支付，一个过程一张事实表）、声明粒度（一行是什么——"订单明细行"这个声明决定了整张表的一切）、确认维度（这个粒度下有哪些描述上下文）、确认事实（这个粒度下有哪些度量）。粒度声明是最容易被跳过去的一步，而下游所有问题（重复计数、口径打架）八成是粒度没声明清楚造成的。
星型模型
事实表居中，维度表直接挂在事实表上，一层关联，形状像星星。比如订单事实表直连用户维、商品维、时间维、商家维。特点是维度反规范化：商品的类目信息（三级类目、二级类目、一级类目名称）全部打平冗余在商品维一张表里，哪怕大量重复。
优点直接对应查询体验：join 只有一层，SQL 简单，优化器容易做对，查询快；维度属性全在一张表，分析师不用理解表间关系。代价是存储冗余（类目名称在百万商品行里重复存储）和更新放大（一级类目改名要更新整张商品维表）。
雪花模型
在星型基础上把维度表继续规范化：商品维只存类目 id，单独抽出一级类目维、二级类目维表，像雪花一样向外延伸。这是数据库三范式思路在数仓里的体现。
优点是存储省（重复的属性只存一份）、维度维护一致性好（类目改名只改一行）。缺点是查询要 join 多层，SQL 复杂、性能差，且分析语义变模糊——分析师要知道类目是拆出去的才能取到类目名称。
怎么选：现代实践是星型优先
给结论：默认星型，局部场景雪花化。理由有三层。
第一，雪花省的存储在今天不值钱。维度表本身不大（商品维百万行级，类目维表撑死几千行，省下的重复存储以 GB 计），而列存编码（字典编码）对重复字符串的压缩已经极好，星型冗余的实际存储代价远小于直觉。用几 GB 存储换所有查询少两层 join，账算得过来。
第二，join 成本是真成本。不管 Hive/Spark 还是 ClickHouse/Doris，多层 join 的执行计划出错概率、 shuffle 开销都显著高于单层的。尤其 ClickHouse 这类引擎官方就建议大宽表、慎用 join，雪花模型在上面是自找麻烦。
第三，一致性维护有替代方案。雪花模型解决的"类目改名一致性问题"，工程上用全量重刷维度表（维表小，每天全量覆盖即可）就能解决，犯不上为此拆表。
什么时候雪花合理？维度本身巨大且层级属性高频变化时：比如地址维（省市区详细节点几十万行且行政调整频繁）、组织架构维，把这些"子维度"拆出去，主维表保持瘦，变更只影响小表。另一个折中是"星座模型"——多个事实表共享同一批一致性维度，这是企业级数仓的常态，阿里总线矩阵落地的就是这个形态。
连环概念：面试官大概率接着问
维度退化：把订单号、支付流水号这种"除了本身没任何属性"的维度直接留在事实表里当字段，不建维度表——建一张只有一行的维度表没有意义。这是星型模型的标准实践。
缓慢变化维（SCD）：维度属性会变（用户等级、商家状态），三种处理：类型一直接覆盖（不关心历史，如修正错别字）、类型二加拉链/快照（关心历史，分析"当时的等级"必须用它）、类型三加旧值列（只关心最近一次变化）。数仓里拉链表是类型二的主流实现。
事实表三种类型：事务事实表（一行一个事件，最常用）、周期快照事实表（每天一行记录账户余额这类状态存量）、累积快照事实表（一行跟踪一个订单从下单到收货的全生命周期，多个时间字段逐步回填）。三种粒度不同，混用是新手高发错误。
可能的追问
- 星型模型维度冗余导致维度属性更新怎么办？维表按天全量重刷覆盖（维度变化频率低、表不大）；需要历史视角的场景用拉链表记录变化，而不是靠雪花拆分。
- 宽表和星型模型什么关系？宽表是把常用维度属性退化进事实表的极端星型——连那层 join 都省了，用存储和回刷成本换查询性能，DWS 层大量采用。
- 度量"半可加"是什么意思？举例？只能按部分维度相加的度量：库存可以按商品加、不能按时间加（今天的库存+昨天的库存没意义），余额同理；建模时要标注可加性，防止分析师错误聚合。