第三章节：实时数仓建模基础 – 维度建模与事实表设计
面试中，维度建模与事实表设计是考察实时数仓基本功的核心环节。面试官通常通过这类问题判断你是否能平衡“业务分析需求”与“实时技术约束”。本章节帮你把抽象模型拆解成可表达的回答路径，并通过项目模板串联真实落地经验。
3.1 面试问答卡片
❓ 问题一：请描述维度建模中的星型模型和雪花模型，你在实时数仓中更倾向于哪一种？为什么？
| 面试官考察点 | 是否理解两种模型的本质区别；能否结合实时场景（Join代价、宽表冗余、一致性）做出合理选择。 |
| 回答框架 | ① 定义星型、雪花；② 对比冗余、规范化、查询性能；③ 实时场景下优先宽表/星型以减少Join延迟；④ 举例说明。 |
| 示例回答 | “星型模型将维度直接挂载在事实表旁，冗余但查询快；雪花模型对维度做规范化。实时数仓中我倾向星型，因为每次Join对延迟敏感，宽表可以借助Flink维表缓存减少网络开销。例如实时订单宽表直接包含用户标签，比多次维表关联延迟降低约40%。” |
| 可能追问 | 宽表维度变更怎么处理？(拉链表或Lookup维表)；实时场景如何保证维度一致性？(CDC+广播维状态) |
| 避坑提醒 | ❌ 不要只说“星型好”却不解释实时约束；❌ 不要忽略维度变更对宽表的冲击。 |
❓ 问题二：事实表有哪些类型？你如何根据业务选择实时事实表的技术方案？
| 面试官考察点 | 是否掌握事务事实、周期快照、累积快照三种类型；能否与实时计算窗口、状态后端匹配。 |
| 回答框架 | ① 分类（事务/周期快照/累积快照）；② 各自适用场景；③ 实时技术选型（Flink窗口 vs 状态后端 vs 维表关联）；④ 举例说明。 |
| 示例回答 | “事务事实表记录每笔交易，实时用Flink的KeyedProcessFunction做精确一次累积；周期快照如每日库存，用TumblingWindow每24小时输出；累积快照适合订单生命周期，用Flink的CEP或定时器推进。例如实时支付流水用事务表，实时库存用周期快照+Redis状态。” |
| 可能追问 | 累积快照的结束时间怎么确定？(事件时间+超时策略)；如何处理迟到数据？(Watermark+侧输出) |
| 避坑提醒 | ❌ 不要混淆周期快照和累积快照；❌ 避免只背概念，要明确Flink具体算子。 |
❓ 问题三：你怎么定义实时数仓中维度的“一致维度”？为什么重要？
| 面试官考察点 | 是否理解维度一致性（命名、编码、层次）在跨主题分析中的价值；能否处理实时CDC带来的维度漂移。 |
| 回答框架 | ① 一致性定义（主键、属性、层次结构）；② 实时场景下维度变更风险；③ 解决方案（维表统一维护+版本+事件重放）；④ 示例。 |
| 示例回答 | “一致维度指不同事实表共享同一维度的主键、属性和编码规则。例如订单表和退款表共用同一用户维度，若用户部门改名，两个事实表都需要同步更新。实时中我用CDC捕获维度变更，写入Flink广播状态，再在join时用事件时间版本匹配，保证跨流分析不偏差。” |
| 可能追问 | 广播状态数据量大怎么办？(按热度分区+LRU淘汰)；维度版本如何标记？(有效时间区间+Type2 SCD) |
| 避坑提醒 | ❌ 不要只说“用Lookup维表”，要提版本控制和状态管理；❌ 避免忽略维表更新延迟对实时报表的影响。 |
3.2 项目案例：实时订单单仓（维度建模实践）
| 项目名称 | 电商实时订单分析仓（订单宽表 + 买家/商品/时间维度） |
| 业务背景 | 运营需秒级查看订单金额、省份分布、商品品类趋势；分析师需灵活下钻到用户画像。离线T+1无法满足大促场景。 |
| 规模指标 | 日均订单量2亿+；实时入仓峰值QPS 15w；宽表字段120+；维表总记录3000w+。 |
| 技术栈 | Kafka (源) → Flink 1.15 (Process+AsyncIO+Broadcast) → ClickHouse (OLAP) / Redis (维表缓存) / Hudi (近实时层) |
| 核心难点 |
|
| 面试高频追问 |
|
| 可迁移回答话术 | “在XX项目中，我们沿用了Kimball维度建模思想，但针对实时做了三点适配： ① 宽表设计时只冗余高频稳定维度字段（用户等级、商品一级类目），低频变更字段走Lookup； ② 维表变更通过CDC + 广播状态保证所有后续数据一致性； ③ 下钻需求通过ClickHouse物化视图分层聚合，避免实时OLAP引擎查询压力。” 💡 提示：话术中强调“权衡”和“实时定制”，体现工程师思维。 |
📘 学习要点 维度建模是实时数仓的骨架，面试时把 “模型选型”与“实时技术（Join/状态/CDC）” 快速绑定，就能拉开与纯理论应届生的差距。