4. 数据模型设计面试高频题：维度建模、事实表设计、缓慢变化维、总线矩阵
数据模型设计是实时数仓的根基。面试官重点考察你能否平衡查询性能、ETL复杂度和业务可扩展性。本章梳理核心概念与高频追问，帮你掌握维度建模的沟通语言。
常规问答卡片
面试问题：在实时数仓中，如何设计一个交易订单的事实表？你会选择哪种事实表类型？
面试官考察点：① 是否理解事实表粒度、可加性与半可加性；② 能否区分事务事实表、周期快照和累积快照；③ 实时场景下对延迟和精确性的权衡。
回答框架：先定业务过程与粒度 → 选择事实表类型 → 设计度量（可加/半可加） → 加入退化维度 → 考虑实时更新窗口。
简短示例回答：
“以订单支付成功为业务过程，粒度设为单笔订单。采用事务事实表，包含金额、积分等可加度量，将订单状态、支付渠道退化为维度字段。实时场景下用去重主键防重复，窗口保留30分钟应对迟到数据。”
可能追问：① 如果某度量需要随时间按状态变化（如订单退款），怎么设计？② 实时快照表与事务表如何配合？③ 如何保证实时与离线数据一致性？
面试问题：用户信息维度表（如收货地址、会员等级）的缓慢变化维如何设计？实时场景下有什么不同？
面试官考察点：① SCD1/2/3的适用场景；② 实时数仓中历史拉链表与流处理的结合；③ 对业务“多变”属性的理解。
回答框架：评估业务变更频率与保留历史需求 → 若只需当前地址选SCD1（覆盖） → 需全历史选SCD2（拉链） → 实时场景用版本号+有效时间戳 → 避免频繁全量重刷。
简短示例回答：
“会员等级变更频繁但需历史分析，采用SCD2拉链表。实时流中收到变更事件后更新当前版本有效期，同时在宽表中冗余等级字段。每天凌晨用离线任务补齐拉链合并，控制查询复杂度。”
可能追问：① SCD2拉链表在实时流中如何保证并发正确性？② 如果维度表数据量超过亿级，拉链表的性能瓶颈？③ 是否能用业务时间戳代替数据库时间戳？
面试问题：请解释什么是总线矩阵，在实时数仓项目中如何落地？
面试官考察点：① 对维度建模方法论的整体理解；② 能否说清一致性维度与数据域的映射；③ 实时场景下总线矩阵的维护方式。
回答框架：定义：总线矩阵是维度与业务过程的交叉表 → 帮助协调多个业务域使用共享维度 → 落地步骤：梳理数据域 → 识别一致性维度 → 建立维度主数据 → 每个事实表引用公共维度 → 实时场景通过维度维度中间层统一更新。
简短示例回答：
“在电商数仓中，总线矩阵列出订单、用户、商品、支付、物流5个业务域。将用户、商品、时间定义为核心一致性维度，每个事实表只保留维度代理键。实时层通过Kafka同步维度变更，保证所有实时OLAP查询共用同一份维度宽表。”
可能追问：① 如果两个业务域对“商品”分类层级不同，如何处理？② 总线矩阵与数据集市的区别？③ 实时场景下维度数据延迟如何处理？
项目案例模板
项目名称：实时用户价值分层 & 交易风控维度模型
业务背景：电商平台需要实时计算用户生命价值（LTV），并基于用户历史行为进行实时风控拦截。原有离线模型延迟4小时，风控窗口过长。
规模指标：用户数 1.2亿，日均订单量 2000万，实时维度表 15张，事实表每日增量 300GB，实时OLAP查询 P99 1.5s。
技术栈：Kafka（事件总线）+ Flink（实时ETL + 维度关联）+ Hologres/ClickHouse（OLAP）+ Redis（维度缓存）+ DataHub（元数据中心）。
核心难点：① 用户等级每小时更新，实时拉链表合并性能瓶颈；② 订单事实表需要同时关联用户、商品、物流三个维度的最新快照；③ 总线矩阵中不同业务域对“商品分类”维度的粒度不一致。
面试高频追问：
- 问：实时拉链表如何避免状态膨胀？
答：采用增量T+1全量快照+实时流变更 delta 进行版本管理，状态只保留当日活跃用户的拉链区域，历史关闭版本下推到离线存储。 - 问：如何保证订单与维度数据的最终一致性？
答：Flink使用 watermark+allowedLateness 处理乱序，维度表通过 CDC 流实时同步并用 Redis 做关联缓存，丢数据时通过离线补偿任务修复。 - 问：总线矩阵中“分类维度”冲突怎么解决？
答：定义统一的“类目树”独立维度表，业务域通过 leaf_category_id 关联，每个业务域可根据自己需求做聚合，保持一致性的同时保留灵活性。
可迁移回答话术：
- “首先根据业务过程梳理总线矩阵，确保所有业务域共享统一维度主数据；事实表设计时优先保证粒度唯一且可加，对于实时场景增加version字段支持维度更新；缓慢变化维采用全量快照+增量变更的方式，用Redis做热缓存，冷数据走离线拉链。”