数仓面试高频题及实战答案.docxVIP

数仓面试高频题及实战答案

一、基础理论题（考察核心认知）

问题：请简述数据仓库和数据库的核心区别，结合使用场景说明

答案：核心区别在于设计目标和使用场景：数据库（OLTP）面向业务操作，比如电商下单、银行转账，追求高并发、低延迟、数据一致性，存储的是实时交易数据；数据仓库（OLAP）面向分析决策，比如月度销售报表、用户行为分析，追求高查询效率、数据整合能力，存储的是历史汇总数据。举个例子：电商系统的MySQL是数据库，记录每笔实时订单；而数仓会把订单、用户、商品数据整合，计算近3个月各品类销量，支撑运营决策。

问题：数据仓库分层的目的是什么？常见的分层架构有哪些？

答案：分层核心目的是“解耦、复用、易维护”：①隔离原始数据，避免直接操作业务库影响线上；②中间层沉淀公共逻辑，减少重复开发；③按使用场景分层，方便定位问题和优化。常见分层（从下到上）：ODS层（操作数据存储层）——同步原始业务数据，结构和业务库一致，不做清洗；DWD层（数据明细层）——对ODS层清洗（去重、补缺失值、格式标准化），保留明细数据；DWS层（数据汇总层）——按主题汇总（比如用户、商品），计算轻度聚合指标（如用户近7天下单次数）；ADS层（应用数据层）——面向具体需求，比如报表、dashboard，直接提供可使用的指标数据。

问题：什么是事实表和维度表？两者的设计原则是什么？

答案：事实表是数仓的核心，存储“发生了什么”的量化数据，比如订单表（订单金额、下单时间）、支付表（支付金额、支付方式），特点是数据量大、字段多为数值型、可聚合；维度表是“描述性数据”，回答“谁、何时、何地、如何”，比如用户表（用户ID、姓名、地区）、商品表（商品ID、品类、价格），特点是数据量小、字段多为描述型、可关联事实表。设计原则：事实表按粒度设计（比如订单粒度、明细粒度），避免冗余；维度表尽量丰富维度属性，支持多维度分析，常用缓慢变化维度（SCD）处理维度属性变更（比如SCD1直接覆盖、SCD2新增记录保留历史）。

二、实操技术题（考察落地能力）

问题：ETL过程中，如何处理数据缺失、数据重复、数据不一致的问题？

答案：①数据缺失：先区分“可补”和“不可补”——关键字段（如订单ID、用户ID）缺失直接丢弃；非关键字段（如用户年龄）可通过默认值（0、“未知”）、均值/中位数填充（数值型）、众数填充（字符型），或关联其他表补全（比如通过用户手机号关联补全地区）。②数据重复：按唯一键去重（比如订单ID唯一，保留最早/最新一条）；如果没有唯一键，按核心字段组合去重（比如用户ID+商品ID+下单时间），避免重复计算指标。③数据不一致：比如业务库中订单状态“已支付”但支付表无对应记录，先核对数据来源（是否同步延迟、同步范围不一致），再通过业务规则校验（比如订单状态变更必须有对应的操作日志），不一致数据标记后人工核查，或按“取信度高的来源”处理（比如支付表数据优先于订单表）。

问题：如何设计一个电商数仓的核心主题模型？以“销售主题”为例说明

答案：销售主题核心是“分析销量、销售额、客单价等指标，支持按时间、地区、商品、用户维度拆解”，模型设计如下：①事实表：销售事实表（粒度：订单明细行），字段包括：订单明细ID（主键）、订单ID、用户ID、商品ID、下单时间、支付时间、销售金额、支付金额、优惠金额、数量、地区ID、支付方式ID。②维度表：用户维度表（用户ID、性别、年龄、会员等级、注册时间）、商品维度表（商品ID、品类ID、品牌ID、商品名称、售价、上架时间、所属品类）、时间维度表（日期ID、年、季、月、周、日、是否节假日）、地区维度表（地区ID、省份、城市、区县）、支付方式维度表（支付方式ID、方式名称：微信、支付宝、银行卡）、订单状态维度表（状态ID、状态名称：待支付、已支付、已发货、已完成）。③关联逻辑：销售事实表通过用户ID关联用户维度表，商品ID关联商品维度表，日期ID关联时间维度表，地区ID关联地区维度表，支付方式ID关联支付方式维度表，支持多维度下钻分析（比如“2024年Q3北京地区女性会员购买的TOP10商品品类”）。

问题：数仓查询性能优化的常用方法有哪些？

答案：从“存储、模型、查询”三个层面优化：①存储层面：分区表（按时间分区，比如按天分区，查询时只扫描指定日期分区，减少数据扫描量）、分桶表（按高频关联字段分桶，比如按用户ID分桶，加速join操作）、压缩存储（比如ORC、Parquet格式，比文本格式存储效率高、查询更快）。②模型层面：减少join次数（通过宽表沉淀