数据仓库面试题及答案.docx

数据仓库面试题及答案

一、基础概念类

问：数据仓库和业务数据库（如MySQL）的核心区别是什么？实际工作中怎么判断该用哪种？

答：核心区别在“用途”和“数据特性”：

业务数据库（OLTP）是面向“日常交易”的，比如下单、付款、用户登录，需要支持高频读写（每秒可能几百次操作），数据是实时更新的，表结构按交易场景设计（比如订单表、支付表分开）；

数据仓库（OLAP）是面向“分析决策”的，比如看月度销售趋势、用户留存率，不需要实时读写（一般按天/小时更新），数据是批量导入的，表结构按分析主题设计（比如“销售分析”主题会整合订单、用户、商品数据）。

实际判断：如果是支撑日常业务操作（如用户下单），用业务数据库；如果是做报表、数据分析（如老板看季度营收），用数据仓库。

问：数据仓库为什么要分层？常见的分层逻辑是什么？举个实际例子说明分层的好处。

答：分层是为了“解耦”和“易维护”，避免一层出错全链路故障。常见分层：

ODS层（操作数据存储）：存原始数据，和数据源结构一致，比如从业务库同步过来的订单原始表，不做任何加工，方便回溯；

DW层（数据仓库层）：分DWD（明细层）、DWS（汇总层），DWD做清洗（比如补全空值、过滤无效订单），DWS按主题汇总（比如按“用户”汇总每日消费金额）；

DM层（数据集市层）：面向具体业务场景，比如给运营的“用户留存报表层”、给财务的“月度营收层”。

好处例子：如果运营要改留存率计算逻辑，只需要改DM层脚本，不用动ODS和DW层，避免影响其他依赖DW层的报表（比如销售报表）。

二、建模类

问：星型模型和雪花模型的区别是什么？实际项目中你更倾向选哪种？为什么？

答：核心区别在“维度表是否拆分”：

星型模型：事实表在中间，直接关联多个维度表，维度表不进一步拆分。比如“销售事实表”直接关联“用户维度表”（含用户ID、地区、年龄）、“商品维度表”（含商品ID、类别、品牌）；

雪花模型：维度表会拆分成子维度表，比如“用户维度表”拆成“用户基础表”（用户ID、姓名）和“用户地区表”（用户ID、省份、城市），事实表要通过用户表再关联地区表。

实际倾向星型模型：因为雪花模型关联层级多，查询速度慢（比如查“北京地区商品销量”要关联事实表→用户表→地区表），而且维护复杂（改地区表字段要同步改关联逻辑）；星型模型查询快、结构简单，大部分业务场景（如零售销售分析、用户行为分析）足够用，除非是超复杂的分析场景（如金融风控的多维度交叉分析）才考虑雪花模型。

问：缓慢变化维度（SCD）有哪几种常见类型？分别在什么业务场景下用？

答：主要3种，核心是“如何处理维度属性的变化”：

SCD1（覆盖式）：直接用新值覆盖旧值，不保留历史。场景：维度属性变化后不需要追溯历史，比如用户“手机号”变更，只需要必威体育精装版手机号，旧手机号没用，就用SCD1；

SCD2（新增式）：保留历史记录，通过“版本号”“生效时间”“失效时间”区分。场景：需要追溯历史状态，比如用户“会员等级”变更（普通→VIP），要分析等级变更前后的消费变化，就用SCD2：原记录失效时间设为变更前一天，新增一条记录（版本号+1，生效时间设为变更当天）；

SCD3（新增字段式）：在原表加字段存历史值，比如“当前地址”“历史地址1”。场景：只需要保留最近1-2次变更，且查询简单，比如用户“常用地址”变更，只需要知道现在和上一次的地址，就用SCD3（比SCD2省存储）。

三、ETL与数据质量类

问：ETL过程中遇到“源表数据和目标表数据不一致”（比如源表1000条，目标表只加载990条），你会怎么排查？

答：按“链路顺序”排查，先定位在哪一步丢数据：

查“抽取环节”：先看抽取日志，确认源表是否真的抽了1000条（比如用SQL查抽取临时表：selectcount(*)frometl_temp.order_extract），如果临时表只有990条，说明源表数据本身有问题（比如源表分区缺失）或抽取脚本过滤了数据（比如脚本里多写了wherestatus=1，过滤了无效订单）；

查“转换环节”：如果抽取临时表是1000条，看转换脚本日志，是否有数据清洗逻辑丢了数据（比如转换时过滤了“金额为空”的订单，而源表有10条金额空的记录），此时要确认过滤规则是否合理（比如业务是否允许金额为空的订单进入目标表）；

查“加载环节”：如果转换后的数据是1000条，看加载日志，是否有加载失败（比如目标表主键冲突，导致10条数据插入失败），此时要查主键设计是否合理（比如事实表用“订单ID+子订单ID”做主键，避免冲突