上一篇：OLTP vs OLAP：数据仓库中两种核心处理模式的对比分析
推荐阅读：实时数仓 vs 离线数仓：2025年企业如何选择？
1. 介绍下数据仓库
数据仓库(Data Warehouse, DW)是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。主要特点包括：
面向主题：围绕企业核心主题(如客户、产品、销售等)组织数据 集成性：将分散在各个业务系统中的数据整合到一起，消除不一致性 非易失性：数据一旦进入数据仓库就不会被随意修改或删除 时变性：记录数据随时间变化的历史信息
2. 数仓的基本原理
数据仓库的基本原理包括：
数据抽取：从各种业务系统抽取数据 数据清洗：处理脏数据，保证数据质量 数据转换：将数据转换为统一的格式和标准 数据加载：将处理后的数据加载到数据仓库中 数据存储：按照特定模型组织存储数据 数据服务：为报表、分析等应用提供数据支持
3. 数仓架构
常见的数据仓库架构：
3.1 传统三层架构
数据源层：业务系统、日志、外部数据等 数据仓库层： ODS(操作数据存储)：原始数据层 DW(数据仓库)：整合后的数据 DM(数据集市)：面向特定主题或部门的数据子集 应用层：报表、分析、数据挖掘等应用
3.2 现代大数据架构
数据湖 + 数据仓库的混合架构 Lambda架构(批流结合) Kappa架构(全流式处理)
4. 数据仓库分层(层级划分)，每层做什么?分层的好处?
4.1 常见分层
ODS(Operation Data Store)层：
原始数据层，保留源系统数据原貌 主要做数据备份和轻度清洗 DWD(Data Warehouse Detail)层：
明细数据层，对ODS数据进行清洗转换 保持与ODS相同粒度，但数据结构更规范 DWS(Data Warehouse Summary)层：
汇总数据层，基于DWD轻度汇总 面向分析主题，形成宽表 ADS(Application Data Store)层：
应用数据层，高度聚合的结果数据 直接面向报表、分析等应用
4.2 分层的好处
清晰数据结构：每层有明确职责 减少重复开发：下层可为上层复用 简化复杂问题：分步骤处理数据 统一数据口径：保证数据一致性 便于维护管理：问题定位和修复更容易
5. 数据分层是根据什么?
数据分层主要基于：
数据抽象程度：从原始数据→明细数据→汇总数据→应用数据 数据处理阶段：采集→清洗→转换→聚合→应用 数据使用场景：不同层次服务于不同分析需求 数据生命周期：不同层次保留不同时间范围的数据 数据访问频率：热数据、温数据、冷数据的分层存储
6. 数仓分层的原则与思路
6.1 分层原则
高内聚低耦合：层内数据高度相关，层间依赖最小化 逐层加工：数据从下层向上层流动，避免跨层引用 公共下沉：公共维度、指标下沉到下层 成本与性能平衡：平衡存储成本与查询性能 数据一致性：保证各层数据口径一致
6.2 分层思路
业务过程驱动：按照业务流程划分层次 数据粒度驱动：从细粒度到粗粒度分层 数据流向驱动：按照数据加工流程分层 使用场景驱动：根据不同应用需求分层
7. 数仓建模常用的模型有哪些?区别、优缺点?
7.1 常用模型
星型模型：
一个事实表+多个维度表 维度表非规范化，直接关联事实表 雪花模型：
维度表进一步规范化 维度表可以关联其他维度表 星座模型：
多个事实表共享维度表 事实表之间通过共享维度关联
7.2 区别与优缺点
8. 星型模型和雪花模型的区别?应用场景?优劣对比
8.1 主要区别
维度表规范化程度：
星型：维度表非规范化(扁平结构) 雪花：维度表规范化(层级结构) 表间关系：
星型：维度表只关联事实表 雪花：维度表可以关联其他维度表 查询复杂度：
星型：查询简单，连接少 雪花：查询复杂，需要多表连接
8.2 应用场景
星型模型：
数据量相对较小 查询性能要求高 维度变化不频繁 如销售分析系统 雪花模型：
数据量大，存储成本敏感 维度层次复杂 维度变化频繁 如大型电商数据仓库
8.3 优劣对比
9. 数仓建模有哪些方式?
9.1 主要建模方法
范式建模(Inmon方法)：
自上而下设计 先建立企业级数据模型 3NF或更高范式 适合大型企业级数据仓库 维度建模(Kimball方法)：
自下而上设计 以事实表和维度表为核心 星型或雪花模型 适合部门级数据集市 Data Vault建模：
中心表(Hub)+链接表(Link)+卫星表(Satellite) 适合数据集成和变化频繁的场景 对ETL容错性强 Anchor建模：
高度标准化的扩展模型 由锚点(Anchor)、属性(Attribute)和连接(Knot)组成 适合极度变化的业务环境
10. 数仓建模的流程?
10.1 典型建模流程
需求分析：
理解业务需求 确定分析主题和KPI 概念模型设计：
识别关键业务实体 定义实体间关系 逻辑模型设计：
选择建模方法(范式/维度等) 设计事实表和维度表 定义粒度和维度层次 物理模型设计：
表结构设计 分区、索引策略 存储和性能优化 模型评审与优化：
与业务人员确认 性能测试和调优 模型实施与维护：
ETL开发 模型版本管理 持续优化
11. 维度建模的步骤，如何确定这些维度的
11.1 维度建模步骤
选择业务过程：
确定要建模的业务流程(如销售、库存等) 声明粒度：
明确事实表的每一行代表什么(如每笔订单、每天汇总等) 确定维度：
找出描述业务过程的维度(如时间、产品、客户等) 确定事实：
识别可度量的业务事实(如销售额、数量等) 模型设计：
设计星型或雪花模型 定义维度属性和层次
11.2 维度确定方法
业务访谈：与业务人员讨论分析需求 报表分析：分析现有报表的维度 源系统分析：研究源系统的数据字典 头脑风暴：列出可能影响业务的所有角度 维度检查：使用标准维度列表(时间、地点等)检查完整性
12. 维度建模和范式建模区别
13. 维度表和事实表的区别?
14. 什么是ER模型?
ER模型(Entity-Relationship Model，实体-关系模型)是一种用于描述现实世界概念结构的数据模型，由Peter Chen于1976年提出。
14.1 主要组件
实体(Entity)：现实世界中可区分的对象(如学生、课程) 属性(Attribute)：实体的特征(如学生的学号、姓名) 关系(Relationship)：实体间的联系(如"选课"关系)
14.2 表示方法
矩形表示实体 椭圆表示属性 菱形表示关系 连线表示关联
14.3 在数仓中的应用
主要用于操作型系统的数据库设计 范式建模的基础 与维度建模形成对比
15. OLAP、OLTP解释(区别)三范式是什么，举些例子
15.1 OLTP vs OLAP
15.2 三范式(3NF)
第一范式(1NF)：
每个字段都是原子的，不可再分 示例：将"地址"拆分为省、市、详细地址 第二范式(2NF)：
满足1NF，且非主键字段完全依赖于主键 示例：订单明细表中，产品名称应依赖产品ID而非订单ID 第三范式(3NF)：
满足2NF，且消除传递依赖 示例：学生表中不应包含系主任(应通过系ID关联)
16. 维度设计过程，事实设计过程
16.1 维度设计过程
选择维度：
基于业务过程确定分析维度 确定主维度和子维度：
识别维度层次关系 确定维度属性：
选择有分析意义的属性 缓慢变化维度策略：
确定如何处理维度变化(类型1/2/3) 维度表设计：
设计表结构和关系 维度一致性处理：
确保跨事实表的维度一致
16.2 事实设计过程
选择业务过程：
确定要分析的业务活动 确定粒度：
定义事实表的详细程度 识别维度：
确定与事实相关的维度 识别事实：
选择可度量的业务指标 确定事实类型：
可加性(可加/半可加/不可加) 设计事实表：
设计表结构和关系
17. 维度设计中有整合和拆分，有哪些方法，并详细说明
17.1 维度整合方法
统一维度表：
将相似维度合并为一个表 如将多个系统的客户表合并 一致性维度：
在不同事实表间使用相同维度 如日期维度跨多个事实表 维度桥接表：
处理多对多关系 如产品与产品类别的关系 微型维度：
将频繁变化的属性拆分 如客户信用等级
17.2 维度拆分方法
水平拆分：
按属性分组拆分 如将客户表拆为基础信息和扩展信息 垂直拆分：
按访问频率拆分 如将热属性和冷属性分开 缓慢变化维度拆分：
按变化频率拆分 如将稳定属性和易变属性分开 层次拆分：
按层次结构拆分 如时间维度的年、季、月
18. 事实表设计分几种，每一种都是如何在业务中使用
18.1 事实表类型
事务事实表：
记录业务过程的最细粒度事件 如每笔订单、每次点击 用于详细分析业务过程 周期快照事实表：
定期记录业务状态 如每日账户余额、月末库存 用于趋势分析和状态监控 累积快照事实表：
记录有生命周期的业务流程 如订单从创建到完成的各阶段 用于流程分析和时效统计 无事实事实表：
只记录事件发生，无度量值 如学生选课记录 用于关联分析和覆盖率统计
19. 单事务事实表、多事务事实表区别与作用
19.1 单事务事实表
特点：
只记录单一类型业务事件 如订单创建事实表 优点：
结构简单 易于理解和使用 缺点：
分析跨事件流程需要多表关联 适用场景：
单一业务过程分析 如销售分析、库存变动
19.2 多事务事实表
特点：
记录多种相关业务事件 如订单创建、支付、发货 优点：
便于分析业务流程 减少表间关联 缺点：
设计复杂 可能存在空值 适用场景：
业务流程分析 如订单全生命周期分析
20. 说下一致性维度、一致性事实、总线矩阵
20.1 一致性维度
定义：
在不同事实表中具有相同含义的维度 如日期维度在所有事实表中保持一致 作用：
保证跨主题分析的一致性 便于数据集成和钻取
20.2 一致性事实
定义：
在不同地方计算的相同指标保持一致 如销售额在不同报表中计算方式相同 作用：
避免指标歧义 保证决策依据一致
20.3 总线矩阵
定义：
矩阵形式展示业务过程与维度的关系 行是业务过程，列是维度 作用：
数据仓库设计的蓝图 识别共享维度 保证模型一致性
21. 从ODS层到DW层的ETL，做了哪些工作?
21.1 主要工作内容
数据抽取：
从ODS抽取需要的数据 增量或全量抽取 数据清洗：
处理脏数据(空值、异常值等) 数据标准化(格式、编码等) 数据转换：
字段映射和计算 业务规则转换 数据粒度转换 维度处理：
生成代理键 处理缓慢变化维度 事实处理：
度量值计算 数据聚合(如需要) 数据加载：
加载到目标表 处理历史数据 质量控制：
数据校验 错误处理
22. 数据仓库与(传统)数据库的区别?
23. 数据质量是怎么保证的，有哪些方法保证
23.1 数据质量保证方法
数据标准制定：
定义字段命名、格式、值域等标准 数据验证规则：
设置字段级、记录级、跨表验证规则 ETL过程控制：
在ETL各环节设置检查点 数据清洗：
处理缺失值、异常值、重复数据等 数据血缘追踪：
记录数据来源和转换过程 数据质量监控：
定期检查数据质量指标 数据治理：
建立数据质量管理流程和责任
24. 怎么衡量数仓的数据质量，有哪些指标
24.1 数据质量指标
完整性：
缺失值比例 记录完整率 准确性：
数据错误率 与真实值偏差 一致性：
跨系统数据一致率 指标计算一致率 及时性：
数据延迟时间 刷新频率达标率 唯一性：
重复记录比例 主键唯一率 有效性：
符合业务规则比例 值域合规率
25. 增量表、全量表和拉链表
25.1 增量表
定义：只记录新增和变化的数据 特点： 数据量小 处理效率高 需要记录增量标识 适用场景：数据量大、变化频繁的表
25.2 全量表
定义：每天保留完整数据快照 特点： 数据完整 存储成本高 使用简单 适用场景：数据量小、变化频繁的表
25.3 拉链表
定义：记录数据历史变化的表，通过有效日期标记 特点： 节省存储 能追溯历史 查询稍复杂 适用场景：需要保存历史变化的维度表
25.4 对比
文章转载自陈乔数据观止，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
