第3章 高频面试问题与回答框架（二）：维度建模与事实表设计

• 是否掌握维度建模基础概念
• 能否用结构化方式对比两种表
• 是否理解两者如何协作形成星型模型

1. 定义先行：事实表 = 业务事件的度量记录；维度表 = 业务属性的描述集合
2. 核心对比：用途（度量 vs 描述）、结构（外键+度量 vs 主键+属性）、变化频率（快速增长 vs 缓慢变化）
3. 协作示例：订单事实表通过外键关联时间/用户/商品维度表

“事实表存储业务事件的量化度量，每行含维度外键与数值指标，行数多且增长快；维度表存储业务属性描述，行数少且变化缓慢。两者通过外键关联形成星型模型。例如订单事实表关联时间、用户、商品维度表，支撑多维度聚合分析。”

• 退化维度是什么？ — 维度属性退化到事实表中，如订单编号既是事实又是维度键
• 什么情况用雪花型？ — 维度表层次深且需要规范化，如产品类别多级分层

❌ 不要只背诵概念，要结合实际场景对比；❌ 避免混淆事实表的度量值与维度表的属性字段；❌ 切忌说“维度表不重要”，两者同等关键。

• 是否完整掌握三种事实表类型
• 能否根据业务场景做出合理选型
• 是否理解各类型的设计代价与收益

1. 列举类型：事务事实表、周期快照事实表、累积快照事实表
2. 特点对比：粒度（原子事件 vs 周期状态 vs 流程进度）、更新方式（增量追加 vs 覆盖更新 vs 多次更新）
3. 选择依据：过程分析用事务，状态分析用快照，长流程跟踪用累积

“事务事实表记录每笔订单事件，粒度最细，支持过程下钻；周期快照事实表按天记录库存状态，适合周期性度量；累积快照事实表跟踪订单全流程进度。选型关键看业务需求：分析单笔行为用事务，监控周期状态用快照，跟踪长流程用累积。”

• 累积快照事实表如何应对多次更新？ — 设计多个日期字段记录里程碑，覆盖更新进度
• 周期快照事实表的存储如何优化？ — 按周期分区+增量合并+历史归档

❌ 不要只列举类型说不出选择场景；❌ 避免在同一事实表中混用多种粒度；❌ 切忌忽略业务周期特性盲目选型。

• 是否掌握粒度设计的方法论
• 能否在业务需求与存储成本间权衡
• 是否理解粒度对下游分析的影响

1. 定义粒度：一行事实记录的业务含义
2. 确定方法：从业务过程出发，识别最细业务事件（如“订单行项目”）
3. 权衡因素：分析需求 vs 存储成本，优先满足最细粒度场景，再考虑聚合

“粒度定义了一行记录代表什么业务事件。以电商交易为例，最细粒度为‘订单行项目’，即每个商品在每个订单中的交易记录。确定粒度从业务过程出发，优先满足最细粒度的分析需求（如按商品SKU下钻），再通过聚合表平衡存储与性能。”

• 如何平衡粒度与查询性能？ — 原子表+聚合表分层，查询路由到合适粒度
• 粒度选择错误如何修正？ — 重建事实表+数据回填+下游任务适配

❌ 不要选择过粗粒度导致无法下钻分析；❌ 避免过细粒度造成存储爆炸；❌ 切忌脱离业务场景空谈粒度，始终以业务事件为锚点。