数仓面试内容

1.简述数仓架构?

一、数据源层

功能：负责提供原始数据。这些数据来源广泛，有结构化的有非结构化的。
特点：数据源层的数据具有多样性、异构性和分布性等特点。

二、ETL层

功能：ETL是Extract（抽取）、Transform（转换）、Load（加载）的缩写，负责将数据从数据源中抽取出来，进行必要的清洗、转换和集成处理，然后加载到数据仓库中。在抽取过程中，需要根据数据源的特点和业务需求，选择合适的抽取方法，确保数据的准确性和完整性；转换过程则包括数据清洗、数据转换和数据集成等操作，以消除数据中的噪声、错误和不一致性，将数据转换为目标存储格式；最后，将处理好的数据加载到数据仓库的事实表。

三、数据仓库层

功能：用于存储和管理经过ETL处理后的数据。它按照主题的方式组织数据，每个主题对应一个或多个业务领域的数据集合，如销售主题、客户主题、产品主题等。数据仓库中的数据通常以事实表和维度表的形式进行存储，事实表包含了与业务相关的度量信息，如销售额、销售量等，维度表则包含了对事实表进行描述的维度信息，如时间、地区、产品类别等，通过这种星型模型或雪花模型的组织方式，能够方便地进行多维分析和查询。
存储：数据仓库可以采用关系型数据库（如Oracle、MySQL、SQL Server等）、列式存储（如HBase、Vertica等）、非关系型数据库（如MongoDB、Cassandra等）或数据湖（如Delta Lake、Apache Hudi等）等多种存储方式，以满足不同用户的需求和业务场景。

四、OLAP层

功能：即联机分析处理层，主要基于数据仓库中的数据进行快速、一致、交互式的分析和查询，为用户提供决策支持。OLAP通过多维数据集市技术，将数据按照多个维度进行建模和存储，使用户能够从不同的角度对数据进行切片、切块、旋转等操作，深入挖掘数据背后的信息和规律。

五、前端应用层

功能：作为数据仓库与用户的交互层，负责将OLAP分析的结果以直观、易懂的方式展示给用户，并提供各种数据分析工具和报表功能，帮助用户更好地理解和使用数据。
特点：前端应用层注重用户体验和交互性，能够根据用户的角色和权限提供个性化的界面和服务，满足不同用户的需求。

2.简述数据仓库架构设计的方法与原则

一、设计方法

需求分析：
- 数据仓库的设计始于对业务需求的深入理解。通过与业务部门沟通，明确他们希望通过数据仓库解决什么问题，如销售趋势分析、客户行为分析等2。
- 收集和整理业务需求，包括数据源、数据类型、报表需求等。
概念模型设计：
- 在需求分析的基础上，设计数据仓库的概念模型。这通常包括确定主题域、维度表、事实表等7。
- 使用工具（如ER图）来描述概念模型，确保模型能够反映业务需求。
逻辑模型设计：
- 将概念模型转化为逻辑模型，确定数据的组织形式、存储结构等。
- 考虑数据粒度、分割、聚合等因素，以优化查询性能和存储效率。
物理模型设计：
- 根据逻辑模型设计物理模型，包括选择合适的存储引擎、索引策略、分区策略等。
- 考虑数据的压缩、编码方式等，以减少存储空间和提高查询性能。
数据集成与ETL设计：
- 设计ETL（Extract, Transform, Load）流程，实现从数据源到数据仓库的数据抽取、转换和加载。
- 确保ETL流程的高效性、可靠性和可扩展性。

二、设计原则

以业务需求为导向：
- 数据仓库的设计必须紧密围绕业务需求展开，确保能够支持业务决策和分析。
数据质量至上：
- 采取有效的数据清洗、验证和纠错措施，以提高数据质量。
分层架构设计：
- 采用分层架构设计数据仓库，将不同层次的功能分离开来，如数据源层、ETL层、数据仓库层和应用层等。
- 提高系统的灵活性和可维护性。
高内聚低耦合：
- 每一层或每一个模块都应该具有明确的功能和职责，内部组件应紧密合作，而不同层或模块之间应尽量减少依赖。
性能优化：
- 合理的索引策略、分区策略以及查询优化等。
- 确保系统能够满足业务需求的查询响应时间和吞吐量要求。

3.增量表、全量表和拉链表的区别

增量表
- 定义：仅存储目标数据集中自上次更新以来发生变化的部分（新增/修改/删除）。
- 特点：体积小、更新效率高，常用于频繁变更的数据（如每日交易流水）。
- 示例：订单系统每天生成的新订单记录表。
全量表
- 定义：存储目标数据集的完整快照，包含全部历史数据。
- 特点：数据冗余度高，但支持完整数据分析；适用于数据量较小或对实时性要求低的场景。
- 示例：每月备份一次的用户基本信息表。
拉链表（SCD Type 2表）
- 定义：通过维护历史版本记录实现维度数据的缓慢变化管理，每条记录包含有效时间区间及前后版本指针。
- 特点：可追溯数据变更历史，支持审计与趋势分析；但结构复杂，查询需关联多版本记录。
- 应用场景：金融风控、客户资料变更跟踪等需要保留历史状态的业务场景。

类型	存储粒度	优势	劣势	典型场景
增量表	差异数据	高效更新，节省存储	依赖基础表重构	日志采集、实时计算
全量表	完整快照	简单易用	存储膨胀严重	小规模数据备份
拉链表	历史版本链	数据可追溯	查询性能损耗	合规审计、BI分析

4.星型模型和雪花模型的区别

1. 星型模型（Star Schema）

结构特点：
- 一个事实表：存储业务过程的核心指标（如销售额、订单量）。
- 多个维度表：围绕事实表的属性表（如时间、产品、客户），维度表直接与事实表关联。
- 非规范化设计：维度表通常不拆分，直接包含所有层级属性（如产品名称、类别、品牌），存在数据冗余。
优点：
- 查询速度快：维度表与事实表直接关联，减少表连接操作。
- 结构简单：易于理解和维护，适合快速开发。
缺点：
- 数据冗余：维度表存储重复信息（如类别名称多次出现），占用更多存储空间。
- 灵活性较低：维度层级固定，难以支持复杂的多层级分析。
应用场景：
- OLAP分析：需要快速响应复杂查询（如销售报表、实时看板）。
- 读多写少：数据更新频率低，以读取和分析为主。
- 业务逻辑简单：维度层级较少，无需频繁扩展。

2. 雪花模型（Snowflake Schema）

结构特点：
- 一个事实表：与星型模型相同。
- 规范化维度表：维度表被拆分为多级子表（如产品表拆分为产品表、类别表、品牌表），形成树状结构。
- 减少冗余：通过外键关联实现规范化，数据存储更紧凑。
优点：
- 节省存储：规范化设计减少数据冗余。
- 灵活性强：支持复杂层级分析（如按品牌→类别→产品逐层下钻）。
缺点：
- 查询性能低：多级表连接增加查询复杂度，影响响应速度。
- 维护成本高：结构复杂，需管理更多表和关系。
应用场景：
- 存储敏感场景：数据量极大，需优化存储成本。
- 复杂维度分析：需要多层级下钻（如金融风控、供应链分析）。
- 写多读少：数据频繁更新（如动态价格调整），规范化减少冗余更新。

维度	星型模型	雪花模型
结构	非规范化，单层维度表	规范化，多层维度表
查询性能	高（表连接少）	低（表连接多）
存储效率	低（冗余多）	高（冗余少）
灵活性	低（维度固定）	高（支持复杂层级）
适用场景	快速分析、简单业务逻辑	复杂分析、存储敏感、频繁更新