- 建模理论:星型模型和雪花模型的区别，优缺点
- 刚刚说的规范化中的”规范“是什么意思
- 你觉得目前常用的数仓体系下星型模型和雪花模型哪个更合适?
- 雪花模型适用的场景?
- 事实表分哪几种类型?
- 讲一下在AI猎头项目里具体做什么?项目做什么?你做了什么?
- 数据域是怎么划分的?
- 层是怎么划分的?分类标准是什么?
- DWM与DWS划分的边界是什么?
- 最终业务用的时候只会用DMS吗?DWM表会用到吗?
- app统计表粒度:uid+页面+date
- 数据监控、数据质量主要做什么?
- 实习之后对成长有哪些变化，有哪些提升、哪些不足?
- 效率低的点，卡在了哪里
1. 建模理论：星型模型和雪花模型的区别、优缺点
考察知识点
- 两种模型的核心结构差异（维度表层级、关联方式）
- 数据冗余、查询效率与维护成本的权衡逻辑
- 模型选型与业务场景的匹配性
参考回答
星型模型和雪花模型是数据仓库维度建模的两种核心方式，核心区别在于维度表的规范化程度，具体差异及优缺点如下：
对比维度 | 星型模型（Star Schema） | 雪花模型（Snowflake Schema） |
核心结构 | 事实表位于中心，直接连接多个扁平维度表（维度表无进一步拆分） | 事实表连接的维度表被进一步规范化拆分（形成多层级子维度表，如“地域维度表”拆分为“国家表-省份表-城市表”） |
数据冗余 | 高（维度表中可能重复存储属性，如“城市”表同时存“省份”“国家”信息） | 低（通过规范化拆分，属性仅存储在最细分子维度表，避免重复） |
查询效率 | 高（仅需事实表与维度表直接关联，join次数少，适合聚合查询） | 低（需跨多层级维度表join，如查“城市订单”需关联“订单表→城市表→省份表→国家表”） |
维护成本 | 低（维度属性变更仅需修改单张维度表，如“城市名称修改”仅改“城市表”） | 高（维度变更需同步维护多级子表，如“省份归属国家调整”需改“省份表”和关联逻辑） |
理解难度 | 低（结构扁平，业务用户易理解“事实表+直接维度”的关联关系） | 高（多层级维度需理清父子表依赖，非技术人员难掌握） |
优缺点总结
模型 | 优点 | 缺点 |
星型模型 | 1. 查询速度快，适配OLAP分析场景（报表、BI）；2. 结构简单，易开发与维护；3. 业务用户易理解 | 1. 数据冗余高，浪费存储（现代存储成本低，影响可忽略）；2. 维度属性变更可能导致多处修改（如“国家名称变更”需更新所有包含该字段的维度表） |
雪花模型 | 1. 数据冗余低，符合规范化设计；2. 维度属性变更更灵活（如“城市归属省份调整”仅改子表） | 1. 查询复杂度高，join次数多，分析效率低；2. 维护成本高（子表层级越多，依赖关系越复杂）；3. 业务用户理解难度大 |
补充注意要点
- 核心区分“维度表是否拆分”：星型模型的维度表是“大而全”的扁平表，雪花模型是“小而专”的多层级表；
- 避免绝对化选型：两种模型可混合使用（如核心维度用星型，次要复杂维度用雪花），而非非此即彼；
- 结合存储与查询权衡：现代数仓更倾向星型模型，因存储成本远低于查询效率损失（分析场景对响应速度敏感）。
2. 规范化中的“规范”是什么意思？
考察知识点
- 数据规范化的核心目标（减少冗余、保证一致性）
- 规范化的核心规则（范式定义）
- 规范化与数仓建模的关系（反范式的合理性）
参考回答
数据规范化中的“规范”，指通过对数据表结构进行合理拆分与重组，遵循“范式（Normal Form）”规则，减少数据冗余和数据异常（插入/更新/删除异常）的设计标准，核心是让数据存储“有序、无冗余、易维护”。
（1）“规范”的核心目标
- 消除冗余：避免同一数据在多张表或同一张表中重复存储（如“用户手机号”仅在“用户表”存储，其他表通过关联获取）；
- 避免异常：
- 插入异常：无需为不存在的属性插入数据（如“订单表”不存“用户地址”，避免新增订单时必须填写用户地址）；
- 更新异常：修改数据时仅需改一处（如“用户手机号变更”仅改“用户表”，无需改所有关联的“订单表”“支付表”）；
- 删除异常：删除某条数据时不丢失其他有用信息（如删除“无订单的用户”，不会删除其他用户的订单数据）。
（2）“规范”的核心规则（范式）
通常指关系型数据库的前3级范式（3NF），是“规范”的具体落地标准：
- 1NF（第一范式）：字段原子性，不可再分（如“地址”拆分为“省份、城市、街道”，而非存储为“北京市朝阳区XX街”）；
- 2NF（第二范式）：在1NF基础上，非主键字段完全依赖主键（消除“部分依赖”，如“订单详情表”主键为“订单ID+商品ID”，“商品名称”仅依赖“商品ID”，需拆分到“商品表”）；
- 3NF（第三范式）：在2NF基础上，消除非主键字段对主键的“传递依赖”（如“订单表”主键为“订单ID”，“用户所属省份”依赖“用户ID”，需拆分到“用户表”，订单表仅存“用户ID”）。
（3）规范化与数仓的关系
- 业务数据库（OLTP）：严格遵循规范化（3NF为主），保证交易数据的一致性和低冗余；
- 数据仓库（OLAP）：常采用“反规范化”（如星型模型的冗余维度表），牺牲部分规范化以提升查询效率（减少join次数），因数仓以“读为主”，效率优先于存储成本。
补充注意要点
- “规范”不是越严格越好：过度规范化（如4NF、5NF）会导致表结构碎片化，增加查询join次数，反而降低效率；
- 数仓中的“反规范化”是对“规范”的灵活调整：核心是平衡“查询效率”与“维护成本”，而非完全抛弃规范化原则；
- 结合实例理解：如“订单表”存“用户ID”而非“用户姓名”，就是遵循3NF的“规范”设计，避免传递依赖。
3. 常用数仓体系下星型模型和雪花模型哪个更合适？
考察知识点
- 数仓的核心需求（分析效率、易用性、维护成本）
- 两种模型与数仓需求的匹配度
- 行业主流选型及原因
参考回答
在当前主流数仓体系（如Hive、ClickHouse、Doris等OLAP场景）中，星型模型更合适，核心原因是数仓的核心需求是“高效支持分析查询、降低业务使用门槛”，星型模型的特性与这些需求高度契合：
（1）数仓的核心需求决定模型选型
- 分析效率优先：数仓主要用于生成报表、BI分析、多维钻取（如“按地域+时间+商品品类分析销售额”），需要频繁进行“事实表+维度表”的聚合查询。星型模型仅需1-2次join（事实表直接关联维度表），查询速度比雪花模型（3-4次join）快3-5倍，尤其在TB/PB级数据场景下，效率差异更为明显。
- 业务用户易用性：数仓的使用者多为运营、产品等非技术人员，他们通过BI工具（如Tableau、Superset）自助分析。星型模型的扁平结构（“订单表→用户表/商品表/时间表”）易理解，用户无需关注复杂的子维度层级；而雪花模型的多层级关联（如“订单表→城市表→省份表→国家表”）会增加分析难度，甚至导致查询错误。
- 维护成本可控：数仓数据以“批量写入、低频更新”为主（如每日全量/增量同步），星型模型的冗余数据对存储成本影响极小（现代云存储成本已降至GB/几分钱），但维护成本远低于雪花模型（无需管理多级子维度表的依赖关系）。
（2）雪花模型的适用边界
仅在以下特殊场景可考虑雪花模型：
- 维度属性极其复杂且频繁变更（如“组织架构维度”包含“公司-部门-小组-岗位”，层级多且调整频繁，拆分后便于单独维护）；
- 存储资源极其有限（如早期本地部署数仓，存储成本高，需严格控制冗余）；
- 需兼容业务数据库的规范化结构（如数仓直接同步业务库的规范化表，避免二次加工）。
（3）行业主流实践
头部企业（阿里、美团、字节）的数仓建模均以星型模型为主，仅对极少数复杂维度采用“星型+雪花混合”模式（如核心维度用星型，次要复杂维度用雪花）。例如，美团外卖数仓中，“订单事实表”直接关联“用户/商家/时间/品类”等扁平维度表，仅“地域维度”因包含“国家-省份-城市-区县”四级，拆分为2级子表（城市表关联区县表），本质仍是简化版雪花模型。
补充注意要点
- 选型核心是“以业务需求为导向”：数仓的核心价值是“支撑高效分析”，而非追求理论上的“规范化完美”；
- 避免绝对化：不排斥雪花模型，而是根据维度复杂度灵活选择，核心维度用星型，次要复杂维度用雪花；
- 结合工具特性：ClickHouse、Doris等OLAP引擎对宽表（星型模型的维度表）查询优化更好，进一步放大星型模型的效率优势。
4. 雪花模型适用的场景？
考察知识点
- 雪花模型的核心优势（低冗余、易维护复杂维度）
- 与业务场景的匹配逻辑（维度复杂度、存储约束、维护需求）
参考回答
雪花模型因“低冗余、维度层级化”的特性，仅适用于维度结构复杂、变更频繁，且对存储成本敏感或需严格规范化的场景，具体如下：
（1）维度属性层级多且频繁变更的场景
当核心维度包含多层级父子关系，且层级或属性值频繁调整时，雪花模型的“分层维护”优势显著：
- 典型案例：企业组织架构维度（包含“集团-子公司-部门-小组-岗位”5级），若采用星型模型，需在“组织架构维度表”中存储所有层级属性，当某子公司拆分部门时，需全表更新相关记录；而雪花模型拆分为“集团表-子公司表-部门表-小组表-岗位表”，仅需修改“部门表”，其他层级不受影响。
- 适用领域：大型集团企业的人力分析数仓、政府机构的层级化管理数仓（如“省-市-县-乡-村”地域维度）。
（2）存储资源受限，需严格控制冗余的场景
在存储成本极高或资源有限的环境中（如早期本地部署数仓、边缘计算节点），雪花模型的低冗余特性更具优势：
- 典型案例：某偏远地区政务数仓，服务器存储仅50TB，需存储近10年的人口、教育、医疗等多维数据。若采用星型模型，“地域维度”的冗余数据可能占用20%存储；而雪花模型通过规范化拆分，可节省15%存储，满足数据存储需求。
- 注意：该场景随云存储成本下降已逐渐减少，仅适用于特殊资源约束环境。
（3）需直接兼容业务数据库规范化结构的场景
当数仓采用“轻量建模”策略，直接同步业务数据库（OLTP）的表结构，避免二次加工时，若业务库已严格遵循规范化（3NF+），数仓会自然形成雪花模型：
- 典型案例：某电商企业数仓初期为快速上线，直接同步MySQL业务库的表（“订单表→用户表→地址表”，地址表拆分为“省份表-城市表-街道表”），未做反规范化处理，形成雪花模型。好处是减少建模工作量，数据同步链路简单；缺点是查询需多表join，效率较低。
- 适用场景：数仓建设初期、业务需求简单、无需复杂分析的场景。
（4）维度属性存在多值或多对多关系的场景
当维度存在多值属性（如“商品维度”的“标签”可能有“生鲜、促销、爆款”多个值）或多对多关系（如“用户维度”与“兴趣维度”为多对多），雪花模型可通过“桥接表”灵活处理：
- 典型案例：用户兴趣分析数仓，“用户表”通过桥接表“用户-兴趣关联表”关联“兴趣表”（兴趣表拆分为“兴趣大类表-兴趣小类表”），形成雪花结构。既避免了星型模型中“用户表”存储多值标签导致的冗余，又便于单独维护兴趣维度的层级关系。
补充注意要点
- 雪花模型是“小众场景选型”：多数数仓场景仍以星型模型为主，雪花模型仅在上述特殊场景中体现价值；
- 避免为“规范化而规范化”：若维度层级少（≤2级）或变更不频繁，强行拆分维度表会增加查询复杂度，得不偿失；
- 可与星型模型混合使用：核心分析维度用星型，上述特殊维度用雪花，平衡效率与维护成本。
5. 事实表分哪几种类型？
考察知识点
- 事实表的核心分类依据（业务过程、粒度、更新方式）
- 不同类型事实表的应用场景与数据特性
- 事实表设计与业务需求的匹配逻辑
参考回答
事实表是数据仓库中存储“业务过程度量值”（如销售额、订单量、点击量）的核心表，根据业务过程的类型、数据粒度和更新方式，可分为4种核心类型：
类型 | 核心定义 | 数据特性 | 典型应用场景 |
事务事实表 | 记录单次业务事件的明细数据（如一笔订单、一次点击、一次支付） | 1. 粒度细（每条记录对应一个事务）；2. 数据插入后不更新；3. 数据量极大（日均千万/亿级） | 订单明细、用户行为日志、支付交易记录 |
周期快照事实表 | 按固定时间间隔（如每日/每周/每月）记录业务过程的“状态快照” | 1. 粒度为“时间间隔+实体”（如“每日-用户-活跃状态”）；2. 数据定期覆盖更新；3. 数据量中等 | 每日用户活跃表、每周商品库存快照、每月门店销售额汇总 |
累积快照事实表 | 记录跨多个时间周期的业务过程从开始到结束的全生命周期状态（如订单从创建到支付、发货、签收） | 1. 粒度为“业务过程实例”（如“一笔订单”）；2. 数据需多次更新（如订单状态变更时更新）；3. 包含多个时间戳字段（创建时间、支付时间、发货时间） | 订单全生命周期跟踪表、用户转化漏斗表（注册→登录→下单） |
聚合事实表 | 基于前三种事实表预聚合生成的汇总数据（如按“天+地区+商品品类”聚合的销售额） | 1. 粒度粗（高于原始事实表）；2. 数据定期全量/增量更新；3. 直接支撑报表查询 | 每日地区商品销售额表、实时GMV监控表、用户留存率汇总表 |
实例说明
- 事务事实表：
dwd_order_detail（订单明细），每条记录对应一笔订单的明细（order_id、user_id、amount、create_time），仅插入不更新，日均1500万条； - 周期快照事实表：
dws_user_active_day（每日用户活跃），按“user_id+date”粒度记录用户当日是否活跃（is_active），每日全量覆盖前一天数据；
This post is for subscribers on the 网站会员 and 成为小万的高级会员 tiers only
Subscribe NowAlready have an account? Sign In
