[toc]

数据仓库离线 + 实时全级别面试宝典（含详细答案）

第一部分 0-1 年（应届生 / 入门级）面试题 + 详细答案

岗位定位 & 考察重点

面向应届生、转行入门、0-1 年基础开发，核心考察基础概念理解、基础 SQL 能力、组件基本使用，不深挖高阶原理，重点判断是否具备数仓入门能力、能否承担基础开发任务。

模块 1 数仓基础理论

1. 【高频考点】简述数据仓库的定义、四大核心特性，以及和业务数据库的核心区别

答案：

定义：数据仓库是面向主题、集成、相对稳定、随时间变化的数据集合，核心目标是为企业管理决策、数据分析提供支撑，不参与线上业务交易。
四大特性：

① 面向主题：按业务主题（如用户、订单、商品、交易）组织数据，而非按业务流程组织；

② 集成性：整合多个异构业务系统（MySQL 业务库、用户日志、第三方接口）的数据，经过清洗、转换后统一标准存储；

③ 稳定性（非易失性）：数据以追加写入为主，极少做更新、删除操作，永久保留历史数据；

④ 时变性：数据自带时间维度，可追溯不同时间节点的状态，支撑趋势分析、历史对比。

与业务数据库的核心区别：

表格

维度	业务数据库（MySQL 等）	数据仓库
核心场景	OLTP 联机事务处理，支撑线上业务	OLAP 联机分析处理，支撑决策分析
操作特点	高频增删改查，短事务	批量读写，极少更新，复杂聚合查询
数据量级	在线业务数据，量级可控	全量历史数据，TB/PB 级海量存储
设计目标	保证事务一致性、高并发响应	保证查询效率、数据整合能力、分析灵活性

2. 【高频考点】数据仓库标准分层架构（ODS/DWD/DWS/DIM/ADS），每层的作用是什么？

答案：

数仓分层的核心目的是解耦、复用、便于问题排查、减少重复计算，行业通用 5 层架构如下：

ODS 层（Operational Data Store，原始数据层）：贴源层，直接对接业务源数据，数据结构和源系统保持完全一致，不做深度清洗转换，仅做数据落地，用于数据备份、原始数据回溯，是数仓的数据入口。
DWD 层（Data Warehouse Detail，明细数据层）：对 ODS 层数据做清洗、脱敏、去重、关联、拆分，去除脏数据、异常值、空值，构建标准化的明细数据，是数仓的核心基础层，保证数据的准确性、一致性。
DIM 层（Dimension，公共维度层）：独立存储全公司通用的维度数据，比如用户维度、商品维度、地区维度、时间维度，统一维度口径，解决跨业务线维度不一致的问题，离线、实时数仓可共用。
DWS 层（Data Warehouse Service，汇总数据层）：基于 DWD 明细数据，按业务主题做轻度聚合，生成面向分析的公共宽表（如用户日行为宽表、商品日销售宽表），减少上层指标的重复计算，提升查询效率。
ADS 层（Application Data Store，应用数据层）：面向具体的业务报表、产品需求、数据分析场景，做最终的指标聚合计算，直接对外提供数据服务，是数仓的最终输出层。

3. 什么是维度建模？星型模型和雪花模型的区别是什么？

答案：

维度建模是数据仓库主流的建模方式，核心是围绕业务过程构建事实表，围绕分析视角构建维度表，通过事实表和维度表的关联，支撑灵活的多维分析，核心是 “事实 + 维度” 的设计思想。
星型模型 vs 雪花模型：
1. 星型模型：1 张事实表直接关联多张维度表，维度表不再做层级拆分，结构像星星。优点是结构简单、关联层级少、查询性能高、维护简单，是企业数仓的首选模型；缺点是维度数据有少量冗余。
2. 雪花模型：维度表继续做规范化拆分，比如商品维度拆分为商品基础表、品类表、品牌表，结构像雪花。优点是数据冗余少；缺点是关联层级多、查询性能差、维护复杂，仅适合维度数据量极大、对冗余要求极高的场景。

4. 什么是缓慢变化维（SCD）？常见的处理方式有哪些？

答案：

缓慢变化维：指维度表中的数据会随着时间缓慢变化，比如用户的收货地址、商品的分类、员工的部门，这类维度称为缓慢变化维，核心是处理维度变化时，如何保留历史数据、保证分析的准确性。
常见处理方式：
1. SCD1（直接覆盖）：用新值直接覆盖旧值，不保留历史数据，实现最简单，适合无需追溯历史的非核心维度。
2. SCD2（新增行记录）：维度变化时，新增一行数据，通过start_date（生效时间）、end_date（失效时间）、is_current（是否当前生效）标记数据的生命周期，保留全量历史数据，是企业生产最常用的方案。
3. SCD3（新增字段）：新增字段保存维度的新旧值，仅保留最近一次的历史，适合维度变化频率极低、仅需对比新旧值的场景。

模块 2 SQL 基础与实战

1. 【高频考点】SQL 中`row_number()`、`rank()`、`dense_rank()`的区别，以及适用场景

答案：

三个都是窗口排序函数，核心区别是排序后序号的生成规则不同：

**row_number()**：连续不重复排序，即使值相同，序号也会依次递增，不会出现重复序号。比如 1、2、3、4，适合取 TopN、去重、行号标记。
**rank()**：跳跃排序，值相同序号相同，后续序号会跳跃。比如 1、1、3、4，适合统计排名（如考试名次，并列第一后直接是第三名）。
**dense_rank()**：连续排序，值相同序号相同，后续序号连续不跳跃。比如 1、1、2、3，适合统计层级排名（如薪资等级，并列第一后还是第二名）。

答案：

sql

-- 按用户、日期分组统计登录次数
SELECT
  user_id,
  DATE(login_time) AS login_date,
  COUNT(*) AS login_times
FROM user_login
GROUP BY user_id, DATE(login_time)
ORDER BY login_date, user_id;

3. 如何用 SQL 实现两张表的左连接，以及左连接、内连接、右连接、全连接的区别

答案：

左连接 SQL 示例（用户表左连订单表，查询所有用户及其订单）：

sql

SELECT
  a.user_id, a.user_name, b.order_id, b.order_amount
FROM user_info a
LEFT JOIN order_info b
ON a.user_id = b.user_id;

四种连接的核心区别：
1. 内连接（INNER JOIN）：只返回两张表中匹配条件一致的数据，不匹配的直接过滤。
2. 左连接（LEFT JOIN）：以左表为基准，返回左表所有数据，右表匹配不到的字段补 NULL。
3. 右连接（RIGHT JOIN）：以右表为基准，返回右表所有数据，左表匹配不到的字段补 NULL。
4. 全连接（FULL JOIN）：返回两张表的所有数据，匹配不到的字段补 NULL。

模块 3 离线数仓基础

1. 【高频考点】Hive 是什么？Hive 和 MySQL 的核心区别是什么？

答案：

Hive 是基于 Hadoop 的数仓工具，它将结构化的数据文件映射为一张表，提供类 SQL 的 HQL 查询能力，底层将 SQL 转换为 MapReduce/Spark 任务执行，用于处理海量离线数据。
与 MySQL 的核心区别：

表格

维度	Hive	MySQL
底层存储	HDFS 分布式文件系统	本地磁盘 / 服务器磁盘
执行引擎	MapReduce/Spark/Tez	数据库原生执行引擎
适用场景	海量数据离线分析、OLAP	线上业务交易、OLTP
数据操作	批量写入，极少更新删除	高频增删改查
延迟	高延迟，分钟 / 小时级	低延迟，毫秒级

2. Hive 内部表和外部表的区别，分别适用什么场景？

答案：

内部表（管理表）：Hive 完全管理表的元数据和实际数据，删除表时，会同时删除元数据和 HDFS 上的实际数据。适合数仓内部的中间层表（DWD/DWS），不会被外部系统共享使用。
外部表：Hive 只管理元数据，实际数据存储路径由用户指定，删除表时，仅删除元数据，不会删除 HDFS 上的实际数据。适合对接外部数据源、ODS 层贴源表、需要多系统共享的数据，避免误删表导致数据丢失。

3. Hive 分区表是什么？为什么要使用分区表？

答案：

分区表是 Hive 的一种优化手段，将表的数据按照指定的字段（如日期、地区）划分为多个子目录，每个子目录对应一个分区。
使用分区表的核心原因：避免全表扫描，提升查询效率。查询时可以通过WHERE语句过滤分区，只扫描需要的分区数据，不用扫描全表，大幅减少查询的数据量，尤其适合海量数据按时间维度查询的场景。

模块 4 实时数仓基础

1. 【高频考点】Kafka 的核心架构组件有哪些？分别有什么作用？

答案：

Kafka 是分布式的消息队列，核心用于实时数据的接入、缓存、流转，核心架构组件如下：

Producer（生产者）：负责向 Kafka 发送消息的客户端，比如日志采集程序、业务数据同步程序。
Broker：Kafka 的服务器节点，一个 Kafka 集群由多个 Broker 组成，负责存储消息、处理客户端的读写请求。
Topic（主题）：消息的分类，生产者发送消息到指定 Topic，消费者从指定 Topic 消费消息，实现消息的隔离。
Partition（分区）：Topic 的物理分片，一个 Topic 可以分为多个 Partition，每个 Partition 是一个有序的队列，是 Kafka 高并发、水平扩展的核心，消息存储在 Partition 中。
Replica（副本）：Partition 的备份，每个 Partition 可以设置多个副本，分为 Leader 副本和 Follower 副本，Leader 负责读写，Follower 负责同步数据，保证数据不丢失、集群高可用。
Consumer（消费者）：负责从 Kafka 拉取并消费消息的客户端，比如 Flink 实时计算程序。
Consumer Group（消费者组）：多个消费者组成一个消费者组，同一个 Topic 的一个分区，只能被同一个消费者组中的一个消费者消费，保证消息不重复消费，同时实现消费的负载均衡。

2. 【高频考点】Flink 是什么？对比 Spark Streaming，为什么 Flink 更适合实时数仓？

答案：

Flink 是一款分布式的流处理引擎，支持流处理和批处理，核心特性是低延迟、高吞吐、精准一次语义，是实时数仓的核心计算引擎。
对比 Spark Streaming 更适合实时数仓的核心原因：
1. 计算模型不同：Spark Streaming 是微批处理，把流数据切分成一个个小批次处理，最低延迟百毫秒级；Flink 是真正的原生流处理，每条数据都触发计算，延迟可达毫秒级，实时性更强。
2. 事件时间支持更完善：Flink 原生支持事件时间语义，通过 Watermark 机制完美解决数据乱序、迟到问题；Spark Streaming 对事件时间的支持较弱，处理乱序数据成本高。
3. 状态管理更强大：Flink 提供了完善的状态管理、状态后端、Checkpoint 机制，支持超大状态的持久化和故障恢复，适合实时数仓的长时间窗口计算、指标累计；Spark Streaming 的状态管理能力较弱。
4. 语义保证更可靠：Flink 基于 Checkpoint + 两阶段提交，轻松实现端到端的 Exactly-Once（精准一次）语义；Spark Streaming 很难实现端到端的精准一次，容易出现数据重复或丢失。

3. Flink 的时间语义有哪几种？分别是什么含义？

答案：

Flink 提供了 3 种时间语义，适配不同的实时计算场景：

处理时间（Processing Time）：数据被 Flink 算子处理时的系统时间，实现最简单，无需处理数据乱序，延迟最低，但精度最低，适合对时间精度要求不高的简单实时统计。
摄入时间（Ingestion Time）：数据进入 Flink Source 时的时间，介于处理时间和事件时间之间，兼顾一定的性能和精度，不会受下游算子处理延迟的影响。
事件时间（Event Time）：数据本身自带的业务发生时间，是最准确、最常用的时间语义，完全符合业务逻辑，不受数据传输、处理延迟的影响，但需要配合 Watermark 机制处理数据乱序、迟到问题，是实时数仓的首选时间语义。

4. 什么是 Watermark（水位线）？它的核心作用是什么？

答案：

Watermark 是 Flink 中用于标记事件时间进度的机制，本质是一个时间戳，代表 “该时间戳之前的所有数据都已经到达，不会再有更早的数据了”。
核心作用：
1. 处理实时数据的乱序问题：实时数据因为网络传输、系统延迟，会出现数据先发生、后到达的乱序情况，Watermark 可以设定允许的延迟时间，等待乱序数据到达后再触发窗口计算。
2. 触发窗口计算：基于事件时间的窗口，需要通过 Watermark 判断是否达到窗口的结束时间，从而触发窗口的计算，避免无限期等待迟到数据。

模块 5 简单场景题

1. 统计用户的日活（DAU），你会怎么设计？

答案：

数据来源：用户登录日志、用户行为日志，核心字段是 user_id、event_time。
口径定义：DAU 是当日有过活跃行为的去重用户数，核心是用户去重。
离线实现：按日期分区，对 user_id 做 distinct 去重，或先 group by user_id 再 count，每日 T+1 计算前一天的 DAU。
实时实现：用 Flink 按天滚动窗口，基于事件时间 + Watermark 处理乱序，用 Bitmap 或 HyperLogLog 做用户去重，实时输出 DAU 指标。

2. 数仓开发中，遇到脏数据怎么处理？

答案：

分阶段处理，核心是 “事前拦截、事中清洗、事后监控”：

事前：ODS 层接入时，做基础的格式校验，拦截完全不符合格式的脏数据，写入异常数据备份表。
事中：DWD 层做深度清洗，对空值、异常值、格式错误的数据，根据业务规则处理：比如非核心字段空值填充默认值，核心字段空值直接过滤；异常值（如金额为负）过滤或标记；重复数据去重。
事后：配置数据质量监控，监控数据量波动、空值率、异常值占比，出现脏数据超标时及时告警，回溯处理。

第二部分 1-3 年（初级开发级）面试题 + 详细答案

岗位定位 & 考察重点

面向 1-3 年数仓开发，核心考察实战开发能力、常见生产问题解决、SQL 优化、组件核心原理，要求能独立完成数仓模块开发、解决日常任务故障、做基础的性能优化，重点判断实战经验是否扎实。

模块 1 数仓建模进阶

1. 【高频考点】完整的数仓建模流程是什么？从需求到落地需要考虑哪些关键点？

答案：

完整的数仓建模流程分为 6 步，全程围绕业务需求展开：

业务需求调研与分析：对接业务方、数据分析人员，明确核心业务过程、分析维度、指标口径，梳理业务总线矩阵，明确主题域、业务过程、维度、指标。
概念模型设计：基于业务调研结果，划分主题域（如用户域、交易域、流量域、商品域），明确每个主题域的核心业务过程，设计高层级的实体关系。
逻辑模型设计：基于维度建模思想，为每个业务过程设计事实表和维度表，明确事实表的粒度、度量值，维度表的属性，定义表之间的关联关系，统一指标口径。
物理模型设计：将逻辑模型落地为具体的表结构，设计表的存储引擎、分区策略、分桶策略、字段类型、压缩格式，适配底层存储引擎（Hive/ClickHouse）的特性。
模型落地与验证：开发 ETL/ELT 任务，实现数据从源系统到数仓各层的流转，验证数据的准确性、一致性，核对指标结果是否符合业务预期。
模型迭代与运维：根据业务需求的变化，迭代优化模型，配置数据质量监控、任务调度，保障模型稳定运行。

落地核心关键点：

粒度设计：事实表的粒度要统一，避免一张表包含多种粒度的数据；
维度一致性：全公司共用统一的维度，避免同一维度在不同表中口径不一致；
数据复用：公共逻辑下沉到中间层，避免上层重复计算；
扩展性：模型设计要预留扩展空间，适配业务的快速迭代；
性能平衡：适度冗余提升查询性能，避免过度规范化导致的关联过多。

2. 事实表有哪几种类型？分别适用什么场景？

答案：

维度建模中，事实表分为 3 种核心类型，适配不同的业务场景：

事务型事实表：以业务事务为粒度，每行数据对应一个业务事件，比如订单创建事件、支付事件、用户点击事件。特点是增量同步，数据只追加不修改，适合记录单次业务行为、统计事件发生的频次、度量值，是数仓中最常用的事实表。
周期型快照事实表：以固定的时间周期为粒度，记录业务实体在周期结束时的状态，比如用户日资产快照、商品日库存快照。特点是全量同步，保留每个周期的快照数据，适合统计状态类、累计类指标，比如每日用户余额、每日库存数量。
累积型快照事实表：以业务流程的完整生命周期为粒度，记录一个业务流程从开始到结束的多个关键节点的状态和时间，比如订单全生命周期事实表，记录订单创建、支付、发货、签收、完成的各个时间节点。特点是数据会随着业务流程的推进不断更新，适合分析业务流程的流转效率、各个节点的耗时。

3. 数据仓库中，数据一致性怎么保证？

答案：

数据一致性是数仓的核心，分为维度一致性、指标一致性、数据时序一致性，核心保证方案如下：

维度一致性保证

：
- 建设统一的公共 DIM 维度层，全公司所有业务线、所有数仓任务共用同一套维度数据，避免重复开发维度表；
- 维度的编码、命名、属性统一规范，比如地区编码、商品分类编码全公司统一；
- 缓慢变化维的处理方式统一，保证历史数据追溯的一致性。

指标一致性保证

：
- 建设统一的指标体系，明确原子指标、派生指标、复合指标的定义，统一口径，比如 “支付金额” 的定义全公司统一，避免不同报表同一指标结果不同；
- 指标计算逻辑下沉到 DWS 层，上层 ADS 层直接复用，避免每个报表重复开发计算逻辑；
- 离线和实时数仓共用同一套指标口径，同一指标的计算规则、维度、过滤条件完全一致。

数据时序一致性保证

：
- 离线数仓按统一的时间切片调度，同一批次的任务使用同一个业务时间窗口的数据，避免部分任务用了最新数据、部分任务用了旧数据；
- 实时数仓通过 Watermark 统一事件时间进度，保证多流关联、窗口计算的时间一致性；
- 定期做离线和实时指标的对账校验，及时发现并修正数据不一致的问题。

模块 2 Hive SQL 优化与实战

1. 【高频考点】Hive 数据倾斜的根本原因是什么？有哪些常见场景？对应的解决方案是什么？

答案：

根本原因：Shuffle 阶段，相同 Key 的数据被分发到同一个 ReduceTask 中处理，出现部分 Key 对应的数据量远大于其他 Key，导致少数 ReduceTask 运行时间极长，整个任务等待这几个 ReduceTask 完成，出现任务卡顿、超时。
常见场景及解决方案：
1. 场景 1：空值 / NULL 值、异常值过多导致倾斜

 原因：关联 / 聚合时，大量 NULL 值被分到同一个 Reduce 中处理。



 解决方案：① 过滤掉不需要的 NULL 值；② 给 NULL 值赋值随机字符串，打散到不同的 Reduce 中，不影响关联结果。

场景 2：大小表 Join 导致倾斜

 原因：大表和小表关联时，普通的 Reduce Join 会发生 Shuffle，小表的热点 Key 集中在少数 Reduce 中。



 解决方案：开启 MapJoin，将小表全量加载到内存中，在 Map 端完成关联，完全避免 Shuffle，从根源上解决倾斜。Hive 中通过

 1
set hive.auto.convert.join=true;


 开启自动 MapJoin。

场景 3：大表与大表 Join，Key 分布极度不均

 原因：部分热点 Key（比如大商家、头部用户）对应的数据量极大，集中在少数 Reduce 中。



 解决方案：

 加盐打散 + 二次聚合

 。第一步，给倾斜的 Key 加上随机前缀，打散到多个 Reduce 中做局部聚合；第二步，去掉随机前缀，做全局聚合，完成最终计算。

场景 4：Count (Distinct) 导致倾斜

 原因：Count (Distinct) 会把所有数据分发到同一个 Reduce 中去重，数据量大时必然倾斜。



 解决方案：先按去重字段 Group By 做局部去重，再在外层做 Count 统计，将压力分散到多个 Reduce 中。示例 SQL：

 sql











 1
2
3
4
-- 优化前
SELECT COUNT(DISTINCT user_id) FROM user_behavior;
-- 优化后
SELECT COUNT(*) FROM (SELECT user_id FROM user_behavior GROUP BY user_id) t;

场景 5：Group By 聚合时 Key 分布不均

 原因：分组字段的某些值数据量极大，导致 Reduce 倾斜。



 解决方案：开启 Map 端聚合，

 1
set hive.map.aggr=true;


 ，在 Map 端先做局部聚合，减少 Shuffle 到 Reduce 端的数据量；同时开启倾斜优化参数

 1
set hive.groupby.skewindata=true;


 ，自动开启两阶段聚合。

2. 【高频考点】Hive SQL 的通用优化手段有哪些？

答案：

从 SQL 写法、参数配置、表设计三个维度，覆盖全链路优化：

一、表设计层面优化

合理使用分区表 + 分桶表：按高频查询字段（如日期）做分区，避免全表扫描；对大表的关联字段做分桶，优化 Join 查询和抽样查询。
选择合适的文件格式和压缩算法：生产环境优先使用 ORC/Parquet 列式存储格式，配合 Snappy 压缩，大幅减少存储空间，提升查询效率，避免使用 TextFile 行式存储。
适度冗余设计：常用的维度属性冗余到宽表中，减少查询时的多表关联。

二、SQL 写法层面优化

分区裁剪 + 列裁剪：查询时必须带分区条件，只查询需要的分区；避免使用SELECT *，只查询需要的字段，减少扫描的数据量。
避免笛卡尔积：严禁不带关联条件的 Join，笛卡尔积会导致数据量爆炸，任务完全无法执行。
大表关联优化：优先使用 MapJoin 处理大小表关联；大表关联时，提前过滤数据，减少参与关联的数据量。
优化子查询：避免多层嵌套子查询，优先使用 JOIN 代替 IN/EXISTS，Hive 对 JOIN 的优化更好。
控制动态分区：开启动态分区时，严格控制分区数量，避免生成过多小文件；设置hive.exec.dynamic.partition.mode=nonstrict时，必须有一个静态分区。

三、参数配置层面优化

开启 CBO 优化器：set hive.cbo.enable=true;，CBO 会自动优化 SQL 的执行计划，选择最优的 Join 顺序、关联方式。
合并小文件：Map 端合并小文件set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;；Reduce 端合并小文件set hive.merge.mapfiles=true;set hive.merge.mapredfiles=true;，减少 MapTask 数量，降低 NameNode 压力。
调整并行度：合理设置 MapTask 和 ReduceTask 的数量，MapTask 数量由输入文件的大小和数量决定，ReduceTask 数量通过set mapreduce.job.reduces=xxx;设置，避免并行度过低导致任务慢，或并行度过高导致集群资源争抢。
开启数据倾斜优化参数：如hive.groupby.skewindata=true、hive.optimize.skewjoin=true，自动处理倾斜场景。

3. Hive 中 order by、sort by、distribute by、cluster by 的区别是什么？

答案：

四个都是 Hive 中的排序语句，核心区别是排序的范围、是否发生 Shuffle、是否保证全局有序：

order by：全局排序，所有数据都会分发到同一个 ReduceTask 中排序，输出的结果是完全全局有序的。缺点是数据量大时，单个 Reduce 压力极大，任务运行极慢，甚至超时，生产环境慎用，必须配合 limit 使用。
sort by：局部排序，只保证每个 ReduceTask 内部的数据有序，不保证全局有序。优点是不会强制所有数据到一个 Reduce，并行度高，适合需要先局部排序、再后续处理的场景。
distribute by：数据分发规则，控制 Map 端的数据按指定字段哈希分发到对应的 ReduceTask 中，本身不负责排序，通常和 sort by 配合使用，先按指定字段分发，再在 Reduce 内排序。比如按 user_id 分发，保证同一个 user_id 的数据分到同一个 Reduce 中。
cluster by：相当于distribute by + sort by，当 distribute by 和 sort by 的字段完全相同时，可以用 cluster by 简写，既保证相同字段的数据分到同一个 Reduce，又保证 Reduce 内部按该字段有序。缺点是只能升序排序，不能指定排序规则。

模块 3 Spark 离线开发与优化

1. Spark 的核心架构组件有哪些？RDD 的五大特性是什么？

答案：

一、Spark 核心架构组件

Driver：驱动程序，负责执行用户编写的 main 方法，提交 Spark 作业，解析作业生成 DAG，分配 Task 到 Executor 执行，协调作业的运行。
Executor：执行器，运行在 Worker 节点上的进程，负责执行 Driver 分配的 Task，存储 RDD 的缓存数据，每个应用程序都有自己独立的 Executor。
Master：Standalone 模式下的主节点，负责管理整个集群的资源，接收 Driver 的作业提交，分配资源给 Worker，监控 Worker 和 Driver 的状态。
Worker：Standalone 模式下的从节点，负责管理本节点的资源，启动 Executor，向 Master 上报本节点的资源状态。
Application：用户编写的 Spark 应用程序，包含一个 Driver 和多个 Executor。
Task：Spark 作业的最小执行单元，一个 Stage 包含多个 Task，每个 Task 对应一个 RDD 分区，在 Executor 中执行。

二、RDD 的五大特性

RDD（弹性分布式数据集）是 Spark 最核心的抽象，代表一个不可变、可分区、可并行计算的数据集，五大特性如下：

一系列的分区（Partitions）：RDD 由多个分区组成，分区是 Spark 计算的最小单元，每个分区对应一个 Task，分区的数量决定了并行度。
一个计算每个分区的函数：每个 RDD 都有一个 compute 函数，用于计算每个分区的数据，基于父 RDD 的分区数据计算当前 RDD 的分区。
RDD 之间的依赖关系：每个 RDD 都记录了它的父 RDD，也就是依赖关系，分为宽依赖和窄依赖，是 DAG 划分、容错的核心。
分区器（Partitioner）：对于 Key-Value 类型的 RDD，可以指定分区器，控制数据按 Key 的哈希分发到对应的分区，常用的有 HashPartitioner 和 RangePartitioner。
优先位置列表：每个分区都有一个优先位置列表，记录了该分区数据所在的节点，Spark 会优先将 Task 调度到数据所在的节点执行，实现 “数据不动代码动”，减少网络传输，提升计算效率。

2. Spark 的宽窄依赖是什么？Stage 是如何划分的？

答案：

一、宽窄依赖

RDD 的依赖关系分为宽依赖和窄依赖，核心区别是是否发生 Shuffle：

窄依赖：父 RDD 的一个分区，只对应子 RDD 的一个分区，也就是一对一 / 多对一的关系，不会发生 Shuffle，数据不需要在节点之间传输。比如 map、filter、flatMap 等算子产生的都是窄依赖。优点是可以流水线执行，容错成本低，一个分区数据丢失只需要重新计算对应的父分区即可。
宽依赖：父 RDD 的一个分区，对应子 RDD 的多个分区，也就是一对多的关系，会发生 Shuffle，数据需要在节点之间重新分发。比如 groupByKey、reduceByKey、join 等算子产生的都是宽依赖。缺点是必须等待父 RDD 的所有分区计算完成，才能开始 Shuffle，容错成本高，一个分区丢失需要重新计算所有父分区。

二、Stage 划分原理

Spark 的作业会被解析为一个 DAG（有向无环图），DAG 会根据宽依赖划分为多个 Stage，划分规则如下：

从后往前回溯：从最后一个 RDD（最终输出的 RDD）开始，向前回溯它的父 RDD，判断依赖关系。
遇到宽依赖就拆分：遇到宽依赖时，就从这里断开，划分一个新的 Stage，宽依赖的 Shuffle 过程就是两个 Stage 的边界。
窄依赖合并到同一个 Stage：窄依赖的 RDD 会被合并到同一个 Stage 中，实现流水线执行。
Stage 数量 = 宽依赖的数量 + 1：每个 Stage 内部都是一系列的窄依赖算子，对应一组并行执行的 Task，Task 的数量等于 Stage 中最后一个 RDD 的分区数。

3. 【高频考点】Spark 任务的通用优化方案有哪些？

答案：

从资源调优、算子优化、Shuffle 优化、数据倾斜优化、代码优化五个维度覆盖：

一、资源调优

资源调优是 Spark 优化的基础，核心是合理分配资源，最大化利用集群资源：

Executor 配置：合理设置 Executor 的数量、每个 Executor 的 Core 数、内存大小。通常每个 Executor 分配 2-5 个 Core，避免 Core 过多导致的线程竞争；内存分为执行内存和存储内存，生产环境通常设置spark.memory.fraction=0.7，提升执行内存占比。
并行度设置：设置合理的任务并行度，通常并行度设置为集群总 Core 数的 2-3 倍，避免并行度过低导致资源闲置，或并行度过高导致任务调度开销大。通过spark.default.parallelism（RDD）和spark.sql.shuffle.partitions（Spark SQL）设置。
Driver 配置：对于需要拉取大量结果到 Driver 的任务，合理设置 Driver 的内存，避免 Driver OOM。

二、算子优化

避免使用低效算子：优先使用 reduceByKey、aggregateByKey 代替 groupByKey，因为前两者会在 Map 端做预聚合，减少 Shuffle 的数据量；避免使用笛卡尔积算子。
复用 RDD 与持久化：对于多次使用的 RDD，调用 cache () 或 persist () 方法持久化，避免重复计算。根据数据量大小选择持久化级别，数据量小用 MEMORY_ONLY，数据量大用 MEMORY_AND_DISK，避免 OOM。
Map 端预聚合：聚合类算子开启 Map 端预聚合，减少 Shuffle 到 Reduce 端的数据量。
小文件合并：对于输入的大量小文件，使用 wholeTextFiles 读取，或开启小文件合并，减少 MapTask 数量。

三、Shuffle 优化

Shuffle 是 Spark 任务性能的瓶颈，核心是减少 Shuffle 的数据量、降低 Shuffle 的开销：

减少 Shuffle 次数：优化代码逻辑，尽量合并算子，减少不必要的 Shuffle 操作，比如多次 groupByKey 合并为一次。
调整 Shuffle 参数：增大 Shuffle 的缓冲区大小spark.shuffle.file.buffer，减少溢写磁盘的次数；开启 Shuffle 压缩spark.shuffle.compress=true，减少网络传输的数据量。
优化 Shuffle 分区数：合理设置spark.sql.shuffle.partitions，默认 200，数据量大时调大，避免单个分区数据量过大导致的 OOM。

四、数据倾斜优化

和 Hive 倾斜优化思路一致，核心是打散热点 Key：

预处理过滤异常 Key、空值，避免热点 Key 集中；
广播小表，使用 Broadcast Join 代替普通 Join，避免 Shuffle；
对热点 Key 加盐打散，分两阶段聚合 / 关联；
拆分热点 Key，单独处理后再合并结果。

五、代码与数据优化

避免在算子中创建大量对象：比如在 map 算子中循环创建对象，尽量将对象创建移到算子外面，减少 GC 压力。
使用高性能的数据结构：比如用 Array 代替 List，用基本类型代替包装类型，减少内存占用。
提前过滤数据：在算子执行前，尽量过滤掉不需要的数据，减少参与计算的数据量。
使用 Kryo 序列化：开启 Kryo 序列化spark.serializer=org.apache.spark.serializer.KryoSerializer，比 Java 序列化速度更快、占用内存更小。

模块 4 Flink/Kafka 实战开发

1. 【高频考点】Kafka 如何保证消息不丢失、不重复消费、有序性？

答案：

一、保证消息不丢失

从 Producer、Broker、Consumer 三个端分别保证：

Producer 端

：
- 设置acks=all（或 - 1）：只有当消息被 Leader 副本和所有 ISR 中的 Follower 副本都成功写入后，才认为消息发送成功，避免 Leader 宕机导致消息丢失。
- 设置retries重试次数：网络波动时，Producer 自动重试发送消息，避免临时故障导致的消息发送失败。
- 开启幂等性：enable.idempotence=true，避免重试导致的消息重复，同时保证消息发送的可靠性。

Broker 端

：
- 设置合理的副本数：每个 Topic 的分区副本数≥2，保证单节点宕机时，副本中有完整的消息数据。
- 关闭 unclean.leader.election.enable：禁止非 ISR 中的副本被选举为 Leader，避免数据丢失。
- 合理设置刷盘策略：虽然 Kafka 依赖副本机制保证可靠性，不是强制刷盘，但可以调整刷盘参数，减少宕机时的数据丢失风险。

Consumer 端

：
- 关闭自动提交 Offset，使用手动提交 Offset：enable.auto.commit=false，只有当消息被完全处理完成后，再手动提交 Offset，避免先提交 Offset 后业务处理失败，导致消息丢失。

二、保证消息不重复消费

根本原因：消息已经处理完成，但 Offset 没有提交成功，导致 Consumer 重启后重新消费同一条消息；或 Producer 重试发送，导致 Broker 中存在重复消息。
解决方案：

业务端实现幂等性

，这是最可靠的方案。比如：
- 基于消息的唯一主键，写入数据库时做去重，存在则更新，不存在则插入；
- 基于 Redis 的 setnx 做去重标记，处理过的消息记录唯一 ID，避免重复处理；
- Flink 中开启 Exactly-Once 语义，基于 Checkpoint 和两阶段提交，保证消息仅处理一次。

三、保证消息有序性

Kafka 的有序性保证：单 Partition 内，消息是严格有序的，同一个 Partition 中的消息，按发送顺序存储，消费时按存储顺序消费；但多个 Partition 之间，无法保证全局有序。
实现方案：
- 如果需要全局有序：将 Topic 的分区数设置为 1，同时消费者组中只有一个消费者，牺牲并发度保证全局有序。
- 如果只需要局部有序：比如同一个用户的消息需要有序，将消息按 user_id 哈希发送到同一个 Partition 中，保证同一个 user_id 的消息在同一个 Partition 内，实现局部有序，这是生产环境最常用的方案。

注意事项：Producer 端必须关闭重试，或开启幂等性，否则重试可能导致消息乱序。

2. 【高频考点】Flink 的状态管理是什么？状态后端有哪几种？如何选型？

答案：

一、Flink 状态管理

Flink 的状态，指的是算子在计算过程中，需要保存的中间数据、历史数据，比如窗口中的数据、聚合的中间结果、用户的累计指标、Kafka 的消费 Offset 等，是 Flink 实现有状态计算、故障恢复、窗口计算的核心。

Flink 的状态分为两大类：

Keyed State（键控状态）：基于 KeyedStream 的状态，和 Key 绑定，每个 Key 对应一个独立的状态，比如按 user_id 分组后的用户累计消费金额。常用的类型有 ValueState、ListState、MapState、ReducingState、AggregatingState。
Operator State（算子状态）：和算子实例绑定，一个算子实例对应一个状态，和 Key 无关，最常用的场景是 Kafka Source 的消费 Offset 管理。

同时，Flink 提供了完整的状态生命周期管理，包括状态的持久化、TTL 过期清理、故障恢复、扩容时的状态重分布，保证状态的可靠性和一致性。

二、状态后端类型及选型

状态后端负责管理 Flink 状态的存储、访问、持久化，Flink 提供了 3 种核心的状态后端，选型如下：

表格

状态后端	存储方式	优点	缺点	适用场景
MemoryStateBackend	状态存储在 TaskManager 的内存中，Checkpoint 存储在 JobManager 的内存中	速度极快，开发测试简单，无磁盘 IO	可靠性极差，状态过大会导致 OOM，JobManager 宕机就会丢失状态	本地开发测试、无状态的简单任务、状态极小的短任务
FsStateBackend	运行时状态存储在 TaskManager 的内存中，Checkpoint 持久化到远程文件系统（HDFS/S3）	读写速度快，可靠性高，支持超大 Checkpoint，配置简单	状态过大时，会占用 TaskManager 大量内存，导致 OOM	生产环境中小状态的任务、短窗口计算、状态大小在 GB 级以内的任务
RocksDBStateBackend	运行时状态存储在 TaskManager 本地的 RocksDB 数据库中（磁盘），Checkpoint 持久化到远程文件系统	支持超大状态（TB 级），不会占用 TaskManager 的堆内存，减少 GC 压力，可靠性高	读写速度比内存级慢，有磁盘 IO 开销	生产环境首选，尤其适合大状态任务、长窗口计算、7*24 小时运行的实时数仓任务、状态大小在 10GB 以上的任务

生产环境选型建议：

测试环境：优先使用 MemoryStateBackend，简单快捷；
生产环境：绝大多数场景优先使用 RocksDBStateBackend，尤其是实时数仓的窗口聚合、维表关联、累计指标计算等有状态任务；只有状态极小、无窗口的简单清洗任务，可以使用 FsStateBackend。

3. Flink 反压是什么？如何排查和解决反压问题？

答案：

一、反压的定义

Flink 的反压，指的是下游算子的处理速度跟不上上游算子的发送速度，导致下游算子的输入缓冲区被占满，进而向上游算子反馈压力，上游算子的输出缓冲区也被占满，最终导致 Source 算子停止读取数据，整个任务的处理速度被最慢的算子限制，出现数据堆积、延迟升高的问题。

简单来说，反压就是下游处理不过来，向上游反馈压力，导致整个任务流速下降。

二、反压问题排查

第一步：通过 Flink WebUI 定位反压源头

打开 Flink WebUI 的 Back Pressure 页面，查看各个算子的反压状态：

状态为 HIGH：代表该算子处于高反压状态，是反压的上游节点；
状态为 OK：代表该算子无反压，通常是反压的下游瓶颈节点。

 反压的传播规律是：

 从下游瓶颈节点，向上游传播

 ，所以 WebUI 中最下游的 OK 状态算子，就是反压的瓶颈源头。

第二步：分析瓶颈算子的具体原因

定位到瓶颈算子后，从以下几个维度排查：

查看算子的并行度：是否并行度过低，导致处理能力不足；
查看 TaskManager 的 GC 日志：是否频繁 Full GC，导致线程暂停，处理速度下降；
查看算子的业务逻辑：是否有复杂的计算、频繁的外部系统调用（如数据库查询），导致单条数据处理耗时过长；
查看数据分布：是否存在数据倾斜，少数 SubTask 处理了绝大多数数据，导致该 SubTask 成为瓶颈；
查看外部系统：Sink 算子是否因为下游数据库（ClickHouse/MySQL）写入性能不足，导致写入缓慢；
查看 Checkpoint：是否 Checkpoint 过于频繁、状态过大，导致 TaskManager 频繁做快照，占用计算资源。

三、反压问题解决方案

针对不同的瓶颈原因，对应解决方案如下：

算子处理能力不足：提升瓶颈算子的并行度，增加处理线程，提升整体处理能力；注意并行度不能超过 Kafka 的分区数（Source 算子）。
数据倾斜导致的反压：对倾斜的 Key 加盐打散，分散到多个 SubTask 中处理；过滤掉异常的热点 Key，单独处理。
算子逻辑复杂导致的反压：优化算子逻辑，避免在算子中做频繁的外部系统调用，改为批量查询；预加载维表数据到内存中，避免每条数据都查询数据库；简化复杂的计算逻辑。
Sink 写入缓慢导致的反压：优化写入方式，改为批量写入，控制批次大小；对下游数据库做扩容、索引优化，提升写入性能；限流写入，避免压垮下游数据库。
GC 频繁导致的反压：优化 TaskManager 的内存配置，调整堆内存大小；优化代码，避免频繁创建大量对象；对于大状态任务，切换为 RocksDBStateBackend，减少堆内存占用。
状态过大导致的反压：给状态设置 TTL，自动清理过期的状态数据，减少状态大小；优化状态存储，只保留必要的字段，避免状态冗余。

4. Flink Exactly-Once（精准一次）语义的实现原理是什么？

答案：

Flink 的 Exactly-Once 语义，指的是每条数据只会被精确处理一次，即使任务发生故障重启，也不会出现数据重复处理、也不会出现数据丢失，最终的计算结果和数据只处理一次完全一致。

Flink 的 Exactly-Once 语义分为两个层面：引擎内部的 Exactly-Once、端到端的 Exactly-Once，实现原理如下：

一、引擎内部的 Exactly-Once：基于 Checkpoint 机制

Checkpoint 是 Flink 实现容错和精准一次的核心，本质是定时对所有算子的状态做一个全局快照，持久化到远程存储中，任务故障重启时，从最新的 Checkpoint 恢复状态，保证数据只处理一次。

Checkpoint 的执行流程：

JobManager 触发 Checkpoint，向所有 Source 算子发送 Checkpoint Barrier（屏障），Barrier 是一个特殊的标记，代表该 Barrier 之前的所有数据都已经处理完成。
Source 算子收到 Barrier 后，停止数据处理，将自己的状态（如 Kafka Offset）持久化到 Checkpoint 存储中，然后向 JobManager 确认 Checkpoint 完成，再将 Barrier 发送给下游算子。
下游算子收到所有上游通道的 Barrier 后（Barrier 对齐），停止处理数据，将自己的状态持久化到 Checkpoint 存储中，向 JobManager 确认，再将 Barrier 继续向下游发送。
当所有 Sink 算子都完成 Checkpoint，向 JobManager 确认后，本次 Checkpoint 全局完成。
任务故障重启时，所有算子都从最新的 Checkpoint 中恢复状态，Source 从记录的 Offset 重新消费数据，保证数据只处理一次，不会重复也不会丢失。

二、端到端的 Exactly-Once：基于两阶段提交（2PC）

Checkpoint 只能保证 Flink 引擎内部的 Exactly-Once，要实现端到端（从 Source 到 Sink）的 Exactly-Once，还需要 Sink 端支持事务，Flink 通过两阶段提交（2PC） 实现，核心是在 Checkpoint 的过程中，实现 Sink 端的事务提交和回滚。

两阶段提交的执行流程：

预提交阶段（Pre-Commit）：当算子收到 Barrier，完成状态快照后，Sink 算子会开启一个事务，将本次 Checkpoint 周期内的所有数据预写入外部系统，但不提交事务，数据对外不可见；同时将事务信息持久化到 Checkpoint 中。
提交阶段（Commit）：当 JobManager 收到所有算子的 Checkpoint 完成确认，标记本次 Checkpoint 全局完成后，会向所有算子发送 Checkpoint 完成的通知，Sink 算子收到通知后，正式提交之前预提交的事务，数据对外可见，完成最终写入。
异常回滚：如果 Checkpoint 过程中发生故障，任务重启后，会从最新的完成的 Checkpoint 恢复，未提交的事务会直接回滚，保证数据不会重复写入，最终实现端到端的 Exactly-Once。

注意事项：要实现端到端的 Exactly-Once，外部 Sink 系统必须支持事务，比如 Kafka、JDBC 数据库、支持事务的 ClickHouse；对于不支持事务的系统，只能通过幂等写入实现最终的 Exactly-Once。

模块 5 生产常见问题解决

1. 离线任务运行超时、执行缓慢，如何排查和优化？

答案：

按照 “从易到难、从外到内” 的思路排查，分为 4 步：

第一步：排查外部环境问题
- 查看集群资源是否充足：是否有其他任务占用了大量资源，导致当前任务分配不到足够的资源，出现等待；
- 查看集群是否有故障：DataNode/NodeManager 是否宕机、磁盘是否满了、网络是否有波动，导致任务执行缓慢。

第二步：查看任务执行计划，定位瓶颈阶段
- 查看 Hive/Spark 的执行计划，定位是 Map 阶段慢，还是 Reduce 阶段慢；
- 如果是 Map 阶段慢：大概率是输入的小文件过多，导致 MapTask 数量极多，调度开销大；或输入数据量过大，没有做分区裁剪，全表扫描；
- 如果是 Reduce 阶段慢：大概率是数据倾斜，少数 ReduceTask 运行时间极长；或 Reduce 数量设置不合理，并行度过低。

第三步：针对性优化
- 小文件过多：开启小文件合并，调整 MapTask 数量，合并输入的小文件；
- 全表扫描：优化 SQL，加上分区条件，实现分区裁剪，只扫描需要的分区；
- 数据倾斜：按照之前的倾斜优化方案，针对性处理；
- 并行度不合理：调整 ReduceTask 数量 / Spark 的 shuffle 分区数，提升并行度；
- 复杂查询优化：开启 MapJoin、CBO 优化器，优化多表关联顺序，减少 Shuffle 次数。

第四步：长期优化
- 表设计优化：合理分区、分桶，使用列式存储和压缩；
- 模型优化：提前聚合数据，将公共计算逻辑下沉到 DWS 层，避免 ADS 层重复计算；
- 调度优化：错峰运行大任务，避免资源争抢。

2. 数仓数据质量出现问题，比如指标结果不对，如何排查溯源？

答案：

按照 “从结果到源头、从上到下” 的思路，全链路排查，分为 5 步：

第一步：确认指标口径，排除业务理解错误
- 先和业务方确认指标的口径定义、统计维度、过滤条件、时间范围，确认是否是口径理解错误、SQL 过滤条件写错导致的结果不对。

第二步：从 ADS 层向上溯源，定位问题层级
- 从最终的 ADS 层指标表开始，向上核对每一层的数据：
  1. 核对 ADS 层的计算逻辑是否正确，聚合条件、过滤条件是否符合口径；
  2. 核对 DWS 层的汇总数据是否正确，和 DWD 层的明细数据核对，确认聚合逻辑是否有误；
  3. 核对 DWD 层的明细数据是否正确，和 ODS 层的源数据核对，确认清洗、关联逻辑是否有误；
  4. 核对 ODS 层的源数据是否正确，和业务源系统的数据核对，确认数据同步是否完整、是否有丢失。

第三步：定位具体问题原因

常见的问题原因分类：

口径问题：指标口径理解错误，过滤条件、统计维度错误；
数据同步问题：ODS 层数据同步不完整、增量同步漏数据、源系统数据变更未同步；
数据清洗问题：DWD 层过滤掉了有效数据、关联条件错误导致数据丢失、空值处理不当；
数据倾斜问题：聚合时倾斜导致部分数据未被计算，结果偏小；
维度关联问题：维度表数据更新不及时，关联不到维度数据，导致指标错误；
时间范围问题：时间条件写错，统计的时间范围不对。

第四步：修复问题，重跑数据
- 定位到具体问题后，修复对应的 SQL 逻辑、同步任务；
- 按数据流向，从问题层级开始，向下重跑所有相关的任务，保证全链路数据一致。

第五步：长效防控
- 配置数据质量监控规则，比如指标波动监控、数据量监控、非空校验、关联一致性校验，出现问题及时告警；
- 完善指标口径文档，统一管理，避免口径理解错误；
- 上线前做数据校验，核对测试环境和生产环境的结果，避免上线后出现问题。

模块 6 综合场景题

1. 设计一套电商场景的离线 + 实时数仓架构，覆盖从数据采集到指标输出的全流程

答案：

整体架构分为 5 层，离线和实时共用一套维度体系、指标口径，实现流批一体，全流程如下：

1. 数据采集层

业务数据：电商的订单、支付、用户、商品等 MySQL 业务库数据，通过 Canal 监听 Binlog，实时同步到 Kafka，同时离线同步到 Hive ODS 层；
行为数据：用户 APP / 网页的点击、浏览、加购等行为日志，通过 Flume 采集，实时写入 Kafka，同时落盘到 HDFS，进入 Hive ODS 层；
第三方数据：物流、支付等第三方接口数据，通过 DataX 离线同步到 Hive ODS 层，同时同步到 Kafka 供实时使用。

2. 数据存储层

离线存储：HDFS 作为底层存储，Hive 构建数仓表，存储 ODS/DWD/DWS/DIM 各层数据；
实时存储：Kafka 作为实时数仓的存储介质，存储 ODS/DWD/DWS 各层的实时数据；
维度存储：MySQL/HBase 存储公共维度数据，离线和实时共用；
指标存储：ClickHouse 存储最终的 ADS 层指标数据，支撑实时大屏、离线报表的多维查询。

3. 离线数仓分层计算

ODS 层：贴源存储，和源系统结构一致，按天分区；
DWD 层：数据清洗、脱敏、去重、维度关联，构建事务型事实表，比如订单明细事实表、支付明细事实表、用户行为明细事实表；
DIM 层：公共维度层，用户维度、商品维度、地区维度、时间维度，采用 SCD2 处理缓慢变化维，离线和实时共用；
DWS 层：按主题轻度聚合，构建日粒度的汇总宽表，比如用户日行为宽表、商品日销售宽表、店铺日经营宽表；
ADS 层：面向业务需求，计算最终的业务指标，比如 GMV、订单量、转化率、复购率、DAU，供报表系统使用。
调度：通过 DolphinScheduler/Airflow 做任务调度，配置任务依赖，每日 T+1 定时执行。

4. 实时数仓分层计算

基于 Flink 流处理引擎，和离线数仓分层逻辑一致，口径统一：

ODS 层：消费 Kafka 中的原始数据，做简单的格式转换；
DWD 层：实时数据清洗、脱敏、去重，和离线 DWD 层的清洗规则完全一致，关联维度数据，输出标准化的实时明细数据到 Kafka；
DWS 层：基于 DWD 层的明细数据，按主题做轻度聚合，比如分钟级的商品销售汇总、用户行为汇总，输出到 Kafka；
ADS 层：基于 DWS 层的数据，计算最终的实时指标，比如实时 GMV、实时订单量、实时 DAU，写入 ClickHouse，供实时大屏、实时监控使用。

5. 数据服务与运维层

数据服务：统一的指标查询接口，对外提供离线和实时指标查询，屏蔽底层存储差异；
数据质量：配置全链路数据质量监控，监控数据完整性、准确性、一致性、及时性；
监控告警：监控任务运行状态、数据延迟、集群资源，出现异常及时告警；
数据对账：每日 T+1，用离线指标核对实时指标，修正实时数据的偏差，保证最终一致性。

2. 实时计算 UV（日活），如何解决数据乱序、重复计算、精准去重的问题？

答案：

UV 的核心难点是用户去重、乱序数据处理、保证精准性，分低延迟近似方案和精准方案，生产环境根据业务需求选型，具体实现如下：

一、基础方案设计

数据来源：用户行为日志，核心字段 user_id、event_time（事件发生时间）；
时间语义：采用事件时间语义，完全符合业务口径，配合 Watermark 处理数据乱序；
窗口设计：采用自然日的滚动窗口，比如每日 0 点到 24 点的滚动窗口，符合日活的统计口径。

二、核心问题解决方案

数据乱序问题解决

配置 Watermark，设置合理的允许乱序时间，比如Watermark for event_time as event_time - INTERVAL '30' SECOND，允许数据最多迟到 30 秒；
开启窗口延迟关闭，设置allowedLateness(Time.hours(2))，允许窗口关闭后，2 小时内的迟到数据仍然可以进入窗口参与计算，更新 UV 结果；
超过延迟时间的极端迟到数据，写入侧输出流，每日 T+1 用离线数据做最终修正，保证 UV 结果的最终准确性。

重复计算问题解决

开启 Flink 的 Checkpoint 机制，设置合理的 Checkpoint 间隔（比如 1 分钟），实现引擎内部的 Exactly-Once 语义，避免任务重启导致的重复计算；
对每条行为数据设置唯一的事件 ID，基于事件 ID 做去重，避免同一条数据被多次消费导致的重复统计；
Sink 端采用幂等写入，比如基于日期 + user_id 的唯一键，写入 ClickHouse 时采用 ReplacingMergeTree 引擎，重复数据会自动去重，保证最终结果不重复。

精准去重问题解决

分两种方案，适配不同的业务场景：

方案 1：精准去重方案（适合小流量、要求 100% 精准的场景）

基于 Keyed State 实现：按日期 + user_id 分组，用 ValueState 存储用户是否已经被统计过的标记，每条数据到来时，先判断 State 中是否有该用户的标记，没有则计数 + 1，同时更新 State，有则跳过，实现精准去重。
优点：100% 精准，结果完全准确；
缺点：用户量极大时（比如千万 / 亿级日活），状态会非常大，对 StateBackend 压力大。

方案 2：近似去重方案（适合大流量、低延迟、允许微小误差的场景）

基于 HyperLogLog（HLL）实现：Flink SQL 内置了 HLL 函数，APPROX_COUNT_DISTINCT(user_id)，基于概率算法实现去重，误差率在 0.1% 左右。
优点：占用内存极小，即使亿级用户，也只需要很小的状态，计算速度极快，延迟低；
缺点：有微小的误差，不是 100% 精准。

方案 3：混合方案（生产环境首选）

实时计算：用 HLL 做近似去重，保证低延迟，给业务方提供实时参考；
离线修正：每日 T+1，用离线数仓的精准 UV 结果，修正前一天的实时 UV 数据，保证最终结果的精准性。

三、最终落地 SQL 示例（Flink SQL）

sql

-- 1. 创建源表，读取用户行为日志
CREATE TABLE user_behavior_source (
  user_id STRING,
  event_time TIMESTAMP(3),
  WATERMARK FOR event_time AS event_time - INTERVAL '30' SECOND
) WITH (
  'connector' = 'kafka',
  'topic' = 'user_behavior',
  'properties.bootstrap.servers' = 'xxx',
  'properties.group.id' = 'uv_calc',
  'format' = 'json'
);

-- 2. 创建结果表，写入ClickHouse
CREATE TABLE realtime_uv_sink (
  stat_date STRING,
  uv BIGINT,
  update_time TIMESTAMP,
  PRIMARY KEY (stat_date) NOT ENFORCED
) WITH (
  'connector' = 'clickhouse',
  'url' = 'xxx',
  'table-name' = 'realtime_dau',
  'username' = 'xxx',
  'password' = 'xxx'
);

-- 3. 实时计算每日UV，近似去重方案
INSERT INTO realtime_uv_sink
SELECT
  DATE_FORMAT(event_time, 'yyyy-MM-dd') AS stat_date,
  APPROX_COUNT_DISTINCT(user_id) AS uv,
  NOW() AS update_time
FROM user_behavior_source
GROUP BY DATE_FORMAT(event_time, 'yyyy-MM-dd');

第三部分 3-5 年（高级开发级）面试题 + 详细答案

岗位定位 & 考察重点

面向 3-5 年高级数仓开发，核心考察数仓架构设计能力、高阶优化能力、复杂生产问题排查、全链路方案设计，要求能主导数仓从 0 到 1 搭建、解决 PB 级海量数据的性能问题、设计高可用的实时数仓架构，重点判断架构思维和复杂问题解决能力。

模块 1 数仓架构设计高阶

1. 【高频考点】设计一套 PB 级海量数据下的离线 + 实时一体化数仓架构，说明技术选型、分层设计、数据流转、核心难点解决方案

答案：

一、架构设计总览

整体采用流批一体 + 湖仓一体的架构，解决 PB 级海量数据下的存储成本、计算性能、口径一致性、扩展性问题，实现一份数据、一套口径、两种计算模式，技术栈选型如下：

数据采集：Flink CDC、Flume、DataX
数据湖存储：HDFS + Apache Hudi（核心，实现流批一体存储）
计算引擎：Flink（流 + 批统一计算）、Spark（离线批量计算）
消息队列：Kafka（实时数据缓存、流转）
OLAP 引擎：ClickHouse（实时多维查询）、Doris（离线报表分析）
调度系统：Apache DolphinScheduler
元数据管理：Atlas + 自研元数据平台
数据质量：Apache Griffin + 自研质量监控平台

二、分层设计与数据流转

整体分层和传统数仓一致，但基于数据湖实现流批一体，离线和实时共用同一份存储、同一套模型，避免数据冗余和口径不一致，分层如下：

ODS 层（贴源层）

存储：基于 Hudi 的 Copy On Write 表，按天分区，直接对接源系统数据；
数据流转：业务库 MySQL 数据通过 Flink CDC 实时同步到 Kafka，再通过 Flink 写入 Hudi ODS 层；日志数据通过 Flume 采集到 Kafka，同时落盘到 Hudi ODS 层；离线批量数据通过 DataX 同步到 Hudi ODS 层；
核心能力：支持增量读取、快照读取，实时任务可以消费增量数据，离线任务可以读取全量快照，实现一份数据流批共用。

DWD 层（明细层）

存储：基于 Hudi 的 Merge On Read 表，按业务主题 + 天分区，支持实时更新；
数据流转：Flink 消费 ODS 层的增量数据，做清洗、脱敏、去重、维度关联、结构化处理，和离线清洗规则完全一致，实时写入 Hudi DWD 层；离线批量补数任务，通过 Spark 读取 Hudi ODS 层，执行相同的清洗逻辑，写入 DWD 层；
核心能力：明细数据实时更新，离线和实时任务都可以直接读取 DWD 层的明细数据，无需重复开发清洗逻辑。

DIM 层（公共维度层）

存储：基于 Hudi 的 Merge On Read 表，支持行级更新，同时同步一份到 Redis/HBase，供实时维表关联使用；
数据流转：维度数据通过 Flink CDC 实时同步，采用 SCD2 处理缓慢变化维，实时更新 Hudi 维度表，同时同步更新缓存；离线和实时任务共用同一套维度数据，保证维度一致性。

DWS 层（汇总层）

存储：分为实时轻度汇总和离线全量汇总，实时汇总数据存储在 Kafka+ClickHouse，离线汇总数据存储在 Hudi；
数据流转：Flink 消费 DWD 层的增量数据，按主题做分钟级轻度聚合，写入 ClickHouse，供实时指标查询；Spark 每日 T+1 读取 DWD 层全量数据，做日粒度的深度聚合，写入 Hudi DWS 层，供离线报表使用；两者的聚合口径、维度完全一致。

ADS 层（应用层）

存储：实时指标存储在 ClickHouse，离线报表数据存储在 Doris；
数据流转：基于 DWS 层的数据，计算最终的业务指标，统一指标口径，对外提供数据服务；每日 T+1 用离线指标核对实时指标，修正实时数据的偏差。

三、核心难点与解决方案

PB 级数据存储成本与性能平衡
- 解决方案：冷热数据分离，热数据（近 3 个月）存储在 SSD，冷数据（3 个月以上）存储在低成本的机械硬盘，同时采用高压缩比的列式存储；Hudi 表定时合并小文件、清理过期版本，减少存储占用；数据生命周期管理，自动归档超过保留期的数据。

流批口径一致性保证
- 解决方案：统一数据模型，离线和实时共用 ODS/DWD/DIM 层数据；统一计算逻辑，清洗、聚合、指标计算的逻辑封装成 Flink SQL/Spark SQL 的公共模板，离线和实时共用同一套模板；建设自动对账系统，每日 T+1 自动对比离线和实时指标，出现差异及时告警。

海量数据查询性能优化
- 解决方案：Hudi 表合理设计分区、分桶，设置数据排序键，提升查询效率；ADS 层指标预聚合，避免即席查询时的海量数据计算；ClickHouse/Doris 合理设计分片、副本、物化视图，优化索引，提升多维查询性能。

数据湖小文件问题
- 解决方案：Hudi 内置的小文件自动合并机制，定时执行 Clustering 操作，合并小文件；Flink 写入时调整批次大小，减少文件生成数量；离线任务定时清理过期的快照文件、日志文件。

高可用与容灾保障
- 解决方案：Kafka、HDFS、Flink、ClickHouse 都采用集群部署，多副本机制；Flink 开启 Checkpoint，任务故障自动重启恢复；数据跨机房备份，避免单机房故障导致的数据丢失；核心任务双集群备容，大促期间扩容集群资源。

四、架构优势

流批一体：一份数据、一套口径，避免数据冗余和口径不一致，减少一半的开发工作量；
弹性扩展：基于分布式架构，存储和计算可以独立水平扩展，适配 PB 级数据的增长；
低成本：基于数据湖架构，减少数据搬迁，冷热分离降低存储成本；
高实时性：数据从产生到可查询，延迟在秒级，同时支持 T+1 的离线分析；
可维护性：分层清晰，逻辑复用，便于问题排查和模型迭代。

2. 多业务线、多租户场景下，数仓如何设计？如何平衡公共数据复用与业务线数据独立？

答案：

多业务线、多租户数仓设计的核心原则是公共层统一、应用层隔离、资源隔离、权限管控，既保证全公司数据的一致性、复用性，又满足各业务线的个性化需求，避免数据孤岛，具体设计方案如下：

一、整体架构设计：三层架构体系

整体分为公共层、业务线中间层、业务线应用层，实现 “高内聚、低耦合”，从上到下，通用性递减，个性化递增。

第一层：企业级公共层（全公司统一）

这一层是全公司所有业务线共用的，是数仓的核心，保证数据口径、维度、模型的统一，避免数据孤岛，分为：

统一 ODS 层：全公司所有业务系统的源数据，统一接入到企业级 ODS 层，按业务系统划分库，统一数据同步规范，避免各业务线重复同步源数据；
统一 DIM 层：建设企业级统一维度中心，比如用户维度、商品维度、地区维度、组织维度、时间维度，全公司所有业务线共用，统一维度编码、属性、缓慢变化维处理方式，解决维度不一致的核心问题；
公共 DWD 层：建设企业级核心业务过程的明细数据，比如交易、支付、用户、流量等全公司通用的业务过程，统一清洗规则、统一数据标准，所有业务线都可以直接复用，无需重复开发；
公共 DWS 层：建设企业级通用的轻度汇总宽表，比如用户全行为宽表、商品全渠道销售宽表，覆盖全公司通用的分析维度，各业务线可以直接基于公共宽表计算自己的指标，避免重复聚合。

第二层：业务线中间层（各业务线独立）

这一层是各业务线基于公共层，扩展的自己的业务模型，实现业务线的个性化需求，同时和其他业务线隔离，分为：

业务线专属 DWD 层：对于业务线独有的业务过程，比如直播业务的打赏明细、电商业务的物流明细，在业务线专属 DWD 层建设，复用公共层的维度和清洗规范；
业务线专属 DWS 层：基于公共 DWS 层和业务线专属 DWD 层，建设业务线个性化的汇总宽表，比如直播业务的主播日经营宽表，满足业务线的高频分析需求。

第三层：业务线应用层（各业务线完全独立）

这一层是各业务线面向自己的业务报表、产品需求、数据分析场景，建设的 ADS 层指标表，完全独立，各业务线之间互不影响，只依赖本业务线的中间层和企业级公共层。

二、核心隔离方案

数据隔离

库表隔离：企业级公共层统一在一个库中，各业务线的中间层、应用层，独立建库，库名按业务线命名，比如dwd_live、ads_ecommerce，避免表名冲突，实现数据隔离；
分区隔离：对于共享的公共表，通过业务线标识分区，实现数据隔离，各业务线只能读取自己业务线的分区数据；
租户隔离：对于多租户场景，比如 ToB 业务的商家数据，在表中增加租户 ID 字段，所有查询都必须带租户 ID 过滤，同时通过行级权限控制，保证租户之间的数据完全隔离，无法互相访问。

资源隔离

计算资源隔离：YARN 集群按业务线划分独立的资源队列，给每个业务线分配固定的 CPU、内存资源，核心公共任务使用独立的高优先级队列，避免业务线之间的资源争抢；
存储资源隔离：HDFS 按业务线划分独立的存储目录，设置存储配额，监控各业务线的存储占用；
集群资源隔离：对于核心业务线，使用独立的 Kafka 集群、ClickHouse 集群，避免非核心业务影响核心业务的稳定性。

权限隔离

基于 RBAC（角色 - based 访问控制）模型，建设统一的权限体系：
1. 公共层数据：全公司所有开发都有读权限，只有数仓架构组有写权限，避免随意修改公共模型；
2. 业务线数据：只有对应业务线的开发有读写权限，其他业务线无权限，实现业务线之间的权限隔离；
3. 多租户数据：只有对应租户的账号能访问该租户的数据，行级权限控制，杜绝跨租户数据访问；
4. 敏感数据：对手机号、身份证等敏感字段做脱敏处理，只有授权的账号能查看明文数据。

三、公共数据复用与业务独立的平衡方案

明确模型边界，制定严格的开发规范

制定数仓建模规范，明确哪些模型应该放在公共层，哪些应该放在业务线层：全公司通用、多业务线共用的业务过程、维度、指标，必须放在公共层，统一建设；业务线独有的、个性化的内容，放在业务线专属层，避免公共层过度膨胀。
公共层模型的变更，必须经过架构组评审，评估对各业务线的影响，保证模型的稳定性，避免随意变更导致业务线任务故障。

公共逻辑下沉，避免重复开发

建设统一的函数库、UDF 库，全公司共用，比如常用的日期函数、脱敏函数、金额计算函数，避免各业务线重复开发；
建设统一的指标体系，定义原子指标、派生指标，公共指标统一在公共 DWS 层计算，各业务线直接复用，避免同一指标在不同业务线重复计算、口径不一致。

数据血缘与元数据管理，提升复用性

建设全链路数据血缘平台，展示所有表的依赖关系、上下游影响，让业务线开发能快速找到可复用的公共模型，避免重复建设；
建设统一的元数据平台，完善表、字段、指标的文档说明，明确口径、用途，让业务线能快速理解和复用公共数据。

建立合理的需求响应机制

对于公共层的需求，由架构组统一评估、统一开发，保证公共层的通用性和稳定性；
对于业务线的个性化需求，由业务线开发自行在业务线层实现，架构组提供规范指导，不限制业务线的个性化迭代，平衡公共层的稳定性和业务线的灵活性。

3. 湖仓一体（LakeHouse）在企业级数仓中的落地方案，对比传统数仓的优势，以及落地过程中的核心坑点与解决方案

答案：

一、湖仓一体的核心定义

湖仓一体是一种结合了数据湖和数据仓库优势的新型架构，在低成本的数据湖存储之上，构建数据仓库的 ACID 事务、数据管理、高性能分析能力，实现一份数据同时支持流处理、批处理、交互式分析、机器学习，避免传统架构中数据湖和数据仓库之间的数据冗余、搬迁、口径不一致问题。

二、对比传统数仓的核心优势

表格

维度	传统数仓（Lambda 架构）	湖仓一体架构
存储成本	数仓存储成本高，数据湖和数仓两份数据，冗余度高	基于低成本的对象存储 / HDFS，一份数据，无冗余，存储成本降低 50% 以上
数据实时性	离线数仓 T+1 更新，实时和离线两套链路，开发成本高	流批一体，数据实时写入，实时可查询，一套链路覆盖流和批，开发成本低
数据格式	数仓有固定的存储格式，支持的计算引擎有限	开放的存储格式（Parquet/ORC），支持 Spark/Flink/Trino 等多种引擎，灵活性高
事务支持	传统数仓支持事务，但数据湖不支持	基于 Hudi/Iceberg/Delta Lake，在数据湖上实现 ACID 事务，支持行级更新、删除
扩展性	存储和计算耦合，扩展成本高	存储和计算完全分离，可独立水平扩展，适配海量数据增长
数据支持	主要支持结构化数据	支持结构化、半结构化、非结构化数据，覆盖更多分析场景

三、企业级落地方案

基于HDFS + Apache Hudi + Flink + Spark构建企业级湖仓一体架构，落地分为 5 个阶段：

第一阶段：架构规划与技术选型

核心组件选型：
1. 表格式：Apache Hudi，国内社区成熟，完美支持 Flink 流批一体，适合实时更新场景；
2. 计算引擎：Flink（流处理 + 批处理统一引擎）、Spark（离线批量计算、机器学习）；
3. 存储层：HDFS（海量存储）+ 对象存储（冷数据归档）；
4. 元数据管理：Hive Metastore + Atlas，兼容现有数仓的元数据体系；
5. 即席查询：Trino/Doris，对接 Hudi 表，提供高性能交互式查询。

规范制定：制定表设计规范、数据写入规范、分区策略、小文件治理规范、权限管控规范，避免后续架构混乱。

第二阶段：试点落地，验证架构可行性

选择非核心的业务线试点，比如用户行为分析场景，从 ODS 层到 ADS 层，全链路基于 Hudi 构建湖仓一体模型；
验证核心能力：Flink CDC 实时写入 Hudi、增量读取、批读快照、ACID 事务、小文件合并、查询性能；
对比传统架构，验证开发效率、存储成本、实时性的提升，总结落地经验，优化规范。

第三阶段：架构推广，核心业务迁移

先迁移公共层：将企业级 ODS、DIM、公共 DWD 层迁移到 Hudi，实现流批一体的公共数据层，统一数据入口；
再迁移业务线层：各业务线基于公共层，逐步将业务模型迁移到湖仓一体架构，下线传统的 Lambda 架构链路；
建设配套工具：适配现有的调度系统、数据质量平台、数据血缘平台，对接 Hudi 表，保证迁移后运维体系的完整性。

第四阶段：性能优化与体系完善

存储优化：合理设计 Hudi 表的分区、分桶、索引，优化查询性能；冷热数据分离，降低存储成本；
写入优化：调整 Flink 写入参数，优化批次大小，定时执行 Clustering/Compaction 操作，合并小文件；
完善数据治理体系：建设湖仓一体的元数据管理、数据质量、权限管控、生命周期管理体系。

第五阶段：全场景覆盖，架构升级

覆盖更多场景：将机器学习、交互式分析、实时数仓全部迁移到湖仓一体架构，实现一份数据支撑全场景分析；
架构升级：基于存算分离架构，实现计算资源的弹性扩缩容，适配业务的峰值需求。

四、落地过程中的核心坑点与解决方案

坑点 1：小文件爆炸，导致查询性能急剧下降

原因：Flink 实时写入 Hudi，每条 Checkpoint 都会生成新的数据文件，长时间运行后，小文件数量达到几十万甚至上百万，NameNode 压力极大，查询性能下降 90% 以上。
解决方案：
1. 调整写入参数：增大 Checkpoint 间隔，调大写入批次大小，减少文件生成数量；
2. 开启 Hudi 自动小文件合并：配置hoodie.parquet.small.file.limit、hoodie.compact.inline.max.delta.commits，开启 inline compaction，自动合并小文件；
3. 定时离线合并：每日低峰期，通过 Spark 任务执行 Clustering 操作，对历史分区的小文件做全量合并，优化查询性能；
4. 清理过期提交：设置hoodie.cleaner.commits.retained，自动清理过期的 commit 和文件，减少文件数量。

坑点 2：写入和查询冲突，导致查询超时、写入失败

原因：Compaction/Clustering 操作会占用大量的 IO 和 CPU 资源，和实时写入、在线查询争抢资源，导致写入延迟升高、查询超时。
解决方案：
1. 资源隔离：Compaction/Clustering 任务使用独立的资源队列，和实时写入、在线查询隔离，避免资源争抢；
2. 错峰执行：重量级的合并操作，放在业务低峰期（比如凌晨）执行，避免影响白天的业务；
3. 异步执行：关闭 inline compaction，使用异步 compaction，不阻塞实时写入；
4. 读写分离：查询使用快照读，不锁定文件，避免和写入操作冲突。

坑点 3：历史数据回溯、补数成本极高

原因：Hudi 表保留了大量的历史版本，回溯历史数据时，需要合并大量的 delta 文件，性能极差；全量重跑历史数据时，会生成大量的小文件，同时影响实时写入。
解决方案：
1. 合理设置分区策略：按天分区，历史补数只重跑对应的分区，不影响全表；
2. 批量补数优化：使用 Spark 批量写入 Hudi，采用 Bulk Insert 模式，避免生成大量小文件；
3. 时间旅行优化：定期对历史分区做 Compaction，生成合并后的快照文件，提升历史回溯性能；
4. 增量补数：基于 Flink CDC 的增量数据，只补跑变化的数据，避免全量重跑。

坑点 4：现有工具链适配成本高

原因：传统数仓的调度系统、数据质量工具、血缘工具，都是基于 Hive 表开发的，对 Hudi 表的适配性差，导致迁移后运维工具不可用。
解决方案：
1. 优先选择社区成熟的组件：Hudi 完美兼容 Hive Metastore，现有的 Hive 工具可以直接适配；
2. 轻量改造：对现有的工具做轻量改造，支持 Hudi 表的增量读取、快照读取；
3. 补充自研工具：针对 Hudi 的特性，自研小文件治理、Compaction 调度、数据质量校验工具，完善工具链。

坑点 5：团队学习成本高，规范落地难

原因：湖仓一体是新型架构，团队对 Hudi 的原理、最佳实践不熟悉，容易写出性能极差的表，导致架构混乱。
解决方案：
1. 制定严格的开发规范，明确表类型选型（COW/MOR）、分区策略、索引设计、写入参数的最佳实践；
2. 组织培训和分享，通过试点项目总结经验，输出最佳实践文档；
3. 建设低代码平台，封装 Hudi 的核心能力，开发人员只需要关注业务逻辑，平台自动生成符合规范的代码，降低学习成本。

模块 2 离线数仓高阶优化

1. PB 级大表 Join、大表聚合的深度优化方案，从模型、存储、计算、架构全链路优化

答案：

PB 级大表 Join 和聚合的核心痛点是数据量极大、Shuffle 开销极高、数据倾斜严重、任务运行时间超长甚至 OOM，优化必须从全链路入手，而不是只优化 SQL 写法，具体方案如下：

一、模型层优化：从根源减少大表 Join 和聚合的开销

模型优化是最高效的优化，从根源上避免大表的频繁关联和全量聚合，是优化的第一优先级。

宽表预关联，避免多表频繁 Join
- 基于维度建模，将常用的维度属性、关联字段，提前冗余到 DWD 层的明细宽表中，比如订单明细宽表中，提前关联用户维度、商品维度、店铺维度的常用属性，上层查询时直接读取宽表，无需再做多个大表的 Join。
- 适用场景：多个大表的固定关联逻辑，上层查询频繁使用，提前关联一次，多次复用，避免每次查询都做 Join。

分层聚合，避免全量数据单次聚合
- 采用 “分层聚合” 的思路，将大聚合拆分为多层轻度聚合，比如：先按小时聚合，再基于小时聚合结果按天聚合，最后按月聚合，而不是直接基于 PB 级的明细数据做月聚合。
- 核心优势：每次聚合的数据量指数级下降，减少 Shuffle 的数据量，同时聚合结果可以复用，避免重复计算。

合理设计粒度，避免过度明细
- 根据业务的分析需求，合理设计事实表的粒度，不需要过度明细，比如业务只需要小时级的统计，就不需要存储秒级的明细数据，大幅减少表的数据量，降低 Join 和聚合的开销。

数据分域，避免跨主题大表 Join
- 按主题域划分模型，尽量避免跨主题域的大表 Join，比如用户行为域和交易域的大表 Join，提前将两个域的关联指标汇总到 DWS 层的用户宽表中，上层直接查询宽表，避免两个 PB 级大表的直接 Join。

二、存储层优化：减少扫描的数据量，提升 IO 效率

存储层优化的核心是让查询只扫描需要的数据，减少磁盘 IO 和网络传输，为后续的计算减负。

分区裁剪 + 分桶优化，避免全表扫描
- 分区设计：按高频查询的时间字段（天 / 小时）做一级分区，按地区、业务线等字段做二级分区，查询时必须带分区条件，只扫描需要的分区，PB 级的表，分区裁剪后可能只需要扫描 GB 级的数据。
- 分桶设计：对大表的 Join 字段、分组字段做分桶，设置合理的分桶数，比如按 user_id 分桶，Join 时只需要对相同分桶的数据做关联，不需要全表 Shuffle，大幅减少 Join 的数据量，也就是 Bucket Map Join。

列式存储 + 高压缩比，减少 IO 开销
- 必须使用 ORC/Parquet 列式存储格式，列式存储只需要扫描查询需要的字段，不需要扫描全表所有字段，比如查询 10 个字段，列式存储只需要读取这 10 个字段的数据，而行式存储需要读取整行数据，IO 开销降低 90% 以上。
- 配合 Snappy/ZSTD 高压缩算法，减少数据的存储空间，同时降低磁盘 IO 和网络传输的开销，PB 级数据压缩后，存储空间可以减少 70% 以上。

数据排序 + 索引优化，提升过滤效率
- 对表的高频过滤字段、Join 字段做排序，比如按 user_id、event_time 排序，排序后的数据可以使用谓词下推，快速定位需要的数据，避免全表扫描。
- 对于 ORC/Parquet 格式，开启布隆过滤器，对高频过滤的唯一键字段（如 order_id、user_id）构建布隆索引，大幅提升等值查询的过滤效率。

冷热数据分离，减少热数据扫描范围
- 对大表做冷热分离，热数据（近 3 个月）存储在 SSD，冷数据（3 个月以上）归档到低成本存储，查询时只扫描热数据分区，避免扫描全量历史数据；对于超过保留期的数据，自动清理，减少表的数据量。

三、计算层优化：降低 Shuffle 开销，解决数据倾斜

计算层优化的核心是减少 Shuffle 的数据量，解决数据倾斜，提升并行计算效率。

Join 类型选型优化
- 大小表 Join：必须使用 Broadcast Join（广播 Join），将小表全量广播到所有 Executor 的内存中，在 Map 端完成 Join，完全避免 Shuffle，这是大小表 Join 的最优解。注意：小表不是绝对的大小，只要能放进内存，就可以使用广播 Join，Spark 中可以通过spark.sql.autoBroadcastJoinThreshold调整阈值。
- 大表大表 Join：优先使用 Bucket Map Join，两个表按相同的 Join 字段分桶，分桶数相同，Join 时只需要对相同分桶的数据做关联，不需要全表 Shuffle，大幅减少 Shuffle 的数据量。
- 倾斜大表 Join：使用加盐打散 + 分阶段 Join，对倾斜的 Key 加上随机前缀，打散到多个 Task 中做局部 Join，再去掉前缀做全局 Join，解决数据倾斜问题。

聚合优化，减少 Shuffle 数据量
- Map 端预聚合：开启 Map 端预聚合，在 Map 端先做局部聚合，减少 Shuffle 到 Reduce 端的数据量，比如 group by、count、sum 等聚合算子，Map 端预聚合可以将数据量降低几个数量级。
- 两阶段聚合：对于数据倾斜的聚合，先给 Key 加上随机前缀，做第一阶段局部聚合，再去掉前缀做第二阶段全局聚合，将倾斜的压力分散到多个 Task 中。
- 避免 Count (Distinct)：对于大基数的去重统计，避免使用 Count (Distinct)，改为先 Group By 去重，再 Count，或者使用 HyperLogLog 近似去重，减少单 Task 的压力。

Shuffle 优化，降低 Shuffle 开销
- 调整 Shuffle 分区数：PB 级数据的 Shuffle，默认的 200 个分区完全不够，需要根据数据量调整spark.sql.shuffle.partitions，通常按每个分区处理 1GB 数据设置，避免单个分区数据量过大导致的 OOM。
- 优化 Shuffle 参数：增大 Shuffle 缓冲区spark.shuffle.file.buffer，减少溢写磁盘的次数；开启 Shuffle 压缩spark.shuffle.compress=true，减少网络传输的数据量；使用高效的 Shuffle 管理器，比如 SortShuffleManager。
- 减少 Shuffle 次数：优化 SQL 逻辑，合并多个 Shuffle 算子，比如多次 group by 合并为一次，多个 Join 按最优顺序执行，减少不必要的 Shuffle。

数据倾斜专项优化
- 预处理过滤：提前过滤掉空值、异常值、热点 Key，比如大促期间的测试订单、机器人流量，这些数据会导致严重的倾斜，提前过滤掉。
- 热点 Key 拆分：对于少数几个热点 Key，比如头部商家、大 V 用户，单独拆分出来处理，先做单独的聚合 / Join，再和其他数据合并，避免热点 Key 影响整个任务。
- 动态倾斜检测：开启 Spark 的动态倾斜检测参数，比如spark.sql.adaptive.enabled=true、spark.sql.adaptive.skewJoin.enabled=true，自适应执行引擎会自动检测倾斜的分区，拆分倾斜分区，分散到多个 Task 中处理，这是 Spark 3.0 + 的核心特性，生产环境必须开启。

四、架构层优化：提升集群资源利用率，避免资源瓶颈

资源调优，最大化利用集群资源
- 合理配置 Executor 参数：PB 级计算任务，需要配置足够的资源，比如每个 Executor 分配 4-8 个 Core，16-32GB 内存，Executor 数量根据集群总资源设置，保证任务有足够的计算资源。
- 调整内存比例：增大执行内存的占比，spark.memory.fraction=0.7-0.8，因为大表 Join 和聚合需要大量的执行内存做 Shuffle 和排序，避免内存不足导致的溢写磁盘。
- 开启动态资源分配：spark.dynamicAllocation.enabled=true，任务根据需要动态申请和释放资源，提升集群资源的利用率。

计算引擎选型优化
- 对于超大规模的离线计算，优先使用 Spark 3.0 + 版本，自适应执行引擎、动态分区裁剪、动态倾斜优化等特性，对大表计算的优化提升极大；
- 对于固定的 T+1 批量计算，可以使用 Flink 的批处理模式，流批统一，复用实时的计算逻辑，同时 Flink 的批处理性能在大规模数据集上有优势。

任务调度优化
- 错峰调度：大表计算的重量级任务，放在业务低峰期执行，避免和其他任务争抢资源；
- 分级调度：核心任务优先调度，分配更多的资源，非核心任务错峰执行；
- 拆分大任务：将一个超大的任务，拆分为多个小任务，按分区并行执行，避免单个任务占用整个集群的资源，同时降低任务失败的重试成本。

预计算与缓存优化
- 对于频繁使用的大表中间结果，提前预计算，持久化到 HDFS，避免每次查询都重新计算；
- 对于任务中多次使用的 RDD/DataFrame，使用 cache ()/persist () 持久化到内存或磁盘，避免重复计算；
- 对于热点维度表，全量缓存到内存中，加速大表 Join。

模块 3 实时数仓高阶难题

1. Flink TB 级超大状态优化方案，解决状态膨胀、状态恢复缓慢、Checkpoint 超时失败问题

答案：

Flink 超大状态（TB 级）的核心痛点是状态持续膨胀、Checkpoint 超时失败、任务重启状态恢复极慢、TaskManager 频繁 OOM，这类问题通常出现在长窗口计算、海量 Key 的去重、实时用户画像、维表关联等场景，优化方案从状态设计、状态后端、Checkpoint 优化、运维配置四个维度入手，全链路优化：

一、状态设计优化：从根源减少状态大小，避免状态膨胀

状态设计优化是最核心的优化，从根源上控制状态的大小，避免无效状态的存储，是所有优化的前提。

严格控制状态生命周期，开启 TTL 自动清理过期状态

这是解决状态膨胀最有效的手段，给所有 Keyed State 设置合理的 TTL（生存时间），自动清理过期的状态数据，避免状态无限增长。
配置示例：

java

 运行









 1
2
3
4
5
6
7
StateTtlConfig ttlConfig = StateTtlConfig
  .newBuilder(Time.days(7)) // 状态保留7天
  .setUpdateType(StateTtlConfig.UpdateType.OnCreateAndWrite) // 创建和写入时更新过期时间
  .setStateVisibility(StateTtlConfig.StateVisibility.NeverReturnExpired) // 不返回过期数据
  .build();
ValueStateDescriptor<Long> descriptor = new ValueStateDescriptor<>("user_count", Long.class);
descriptor.enableTimeToLive(ttlConfig);

场景适配：
1. 日活 UV 计算：TTL 设置为 1 天 + 窗口延迟时间，每日窗口结束后，状态自动清理；
2. 7 天用户留存计算：TTL 设置为 7 天，超过 7 天的用户状态自动清理；
3. 实时去重：TTL 设置为数据的最大乱序延迟时间，避免永久保留去重标记。

注意：Flink SQL 中可以通过table.exec.state.ttl参数给 SQL 任务设置全局状态 TTL，生产环境必须开启，禁止无 TTL 的状态。

状态瘦身，只存储必要的字段，减少状态冗余

避免在状态中存储全量数据，只存储计算必须的关键字段，比如用户去重场景，只需要存储 user_id，不需要存储用户的所有行为数据；聚合计算场景，只存储聚合的中间结果，不需要存储全量明细数据。
优化数据结构：使用紧凑的数据结构，比如用数组代替 List，用基本类型代替包装类型，用固定长度的字段代替变长字符串，减少状态的序列化后的大小。
数据压缩：对状态中的大字段，提前做压缩后再存储，比如 JSON 字符串用 GZIP 压缩后再存入状态，减少状态占用的存储空间。

优化 Key 粒度，避免 Key 数量爆炸

合理设计 Key 的粒度，避免过细的 Key 导致 Key 数量爆炸，比如按分钟 + user_id + 商品_id 做 Key，单日 Key 数量可能达到百亿级，状态会急剧膨胀；优化为按小时 + user_id + 商品_id 做 Key，Key 数量减少 60 倍，状态大小大幅降低。
拆分大状态任务：将一个包含超多 Key 的大任务，拆分为多个小任务，每个任务处理一部分业务数据，分散状态压力，比如按业务线拆分，每个业务线一个独立的 Flink 任务，避免单个任务的状态达到 TB 级。

避免无效的状态使用，选择更优的计算方案

对于超大规模的去重场景，比如亿级 UV 计算，避免用 Keyed State 存储每个用户的标记，改为使用 HyperLogLog/Bitmap 等概率数据结构，状态大小可以从几十 GB 降低到几 MB，完全解决状态膨胀问题。
对于长窗口的聚合计算，避免用滚动窗口存储全量窗口数据，改为增量聚合，只存储聚合的中间结果，比如 sum、count、max/min，不需要存储窗口内的所有明细数据，状态大小可以降低 99%。
对于大维表关联场景，避免用 MapState 全量缓存维表数据，改为使用 LRU 缓存热数据，或用 HBase/Redis 异步查询冷数据，避免维表全量加载到状态中，导致状态膨胀。

二、状态后端选型与优化：适配超大状态场景

状态后端决定了状态的存储方式、读写性能、容错能力，对于 TB 级超大状态，必须选择正确的状态后端，并做针对性优化。

必须使用 RocksDBStateBackend

对于超大状态，绝对禁止使用 MemoryStateBackend 和 FsStateBackend，这两个都是内存级状态后端，状态全部存在 TaskManager 的堆内存中，TB 级状态会直接导致 OOM，GC 频繁。
RocksDBStateBackend 将状态存储在 TaskManager 本地的 RocksDB 数据库（磁盘）中，只有热数据缓存在内存中，支持 TB 级的超大状态，不会占用堆内存，大幅减少 GC 压力，是超大状态场景的唯一选择。

RocksDB 核心参数优化

RocksDB 的性能直接决定了状态的读写性能，针对超大状态场景，核心优化参数如下：

开启增量 Checkpoint：state.backend.incremental=true，开启后，每次 Checkpoint 只上传和上一次 Checkpoint 相比变化的增量数据，而不是全量状态，TB 级状态的 Checkpoint 时间可以从小时级降到分钟级，彻底解决 Checkpoint 超时问题，生产环境必须开启。
调整 RocksDB 的内存配置：默认的 RocksDB 内存配置过小，超大状态场景需要调大，比如state.backend.rocksdb.memory.managed=true开启托管内存，state.backend.rocksdb.memory.write-buffer-ratio=0.5调大写缓冲区比例，减少磁盘溢写次数，提升写入性能。
优化列族配置：给不同的状态设置独立的列族，调整 Block 大小，state.backend.rocksdb.block.blocksize=32KB，对于大状态，调大 Block 大小，减少索引开销；开启布隆过滤器，state.backend.rocksdb.filter.enabled=true，提升状态查询性能。
开启压缩：state.backend.rocksdb.compression.type=LZ4_COMPRESSION，开启 LZ4 压缩，减少状态占用的磁盘空间，同时减少磁盘 IO 开销，对于 TB 级状态，压缩比可以达到 5:1 以上。
使用 SSD 磁盘：RocksDB 是磁盘型数据库，超大状态场景必须使用 SSD 磁盘，避免机械硬盘的 IO 瓶颈，读写性能可以提升 10 倍以上。

本地状态恢复优化

开启本地恢复：state.backend.local-recovery=true，开启后，Checkpoint 时会在本地磁盘保留一份状态副本，任务重启时，优先从本地磁盘恢复状态，不需要从远程 HDFS 下载全量 TB 级状态，恢复时间可以从小时级降到分钟级，彻底解决状态恢复缓慢的问题。
注意：需要保证 TaskManager 的本地磁盘有足够的存储空间，存放状态副本。

三、Checkpoint 机制优化：解决 Checkpoint 超时、失败问题

Checkpoint 是 Flink 状态容错的核心，超大状态场景下，Checkpoint 很容易出现超时、失败、对齐耗时过长的问题，需要针对性优化。

调整 Checkpoint 间隔和超时时间

合理设置 Checkpoint 间隔：超大状态场景，避免 Checkpoint 过于频繁，比如设置为 5-10 分钟，给 Checkpoint 足够的执行时间，避免上一次 Checkpoint 还没完成，下一次就开始了，导致任务压力过大。
调大 Checkpoint 超时时间：execution.checkpointing.timeout=30min，默认的 10 分钟对于 TB 级状态完全不够，需要调大到 30 分钟甚至 1 小时，避免 Checkpoint 超时失败。
设置最大并发 Checkpoint 数：execution.checkpointing.max-concurrent-checkpoints=1，同一时间只允许一个 Checkpoint 执行，避免多个 Checkpoint 争抢资源，导致任务性能下降。

优化 Barrier 对齐，解决对齐耗时过长问题

对于 Exactly-Once 语义，Barrier 对齐是 Checkpoint 耗时的主要来源，尤其是多流关联的任务，上游通道多，Barrier 对齐耗时极长。
优化方案：
1. 开启 Unaligned Checkpoint（非对齐 Checkpoint）：execution.checkpointing.unaligned.enabled=true，非对齐 Checkpoint 不需要等待所有上游的 Barrier 都到达，就可以开始快照，大幅减少 Barrier 对齐的耗时，尤其适合反压场景下的超大状态任务，生产环境必须开启。
2. 调整 Barrier 对齐超时时间：execution.checkpointing.aligned-checkpoint-timeout=30s，如果 30 秒内没有完成对齐，自动切换为非对齐 Checkpoint，兼顾性能和资源占用。

Checkpoint 存储优化

使用高吞吐的分布式存储：Checkpoint 必须存储在 HDFS 等分布式文件系统中，禁止使用本地存储，同时保证 HDFS 集群有足够的带宽和 IO 性能，避免 Checkpoint 写入超时。
开启 Checkpoint 压缩：execution.checkpointing.compression.enabled=true，压缩 Checkpoint 数据，减少写入 HDFS 的数据量，提升写入速度。
合理设置 Checkpoint 保留数量：state.checkpoints.num-retained=3，只保留最近 3 个成功的 Checkpoint，避免占用过多的 HDFS 存储空间。

开启 Changelog 机制，加速 Checkpoint

Flink 1.15 + 版本，开启 Changelog 机制：execution.checkpointing.changelog.enabled=true，开启后，状态的变更会先写入持久化的 Changelog 中，Checkpoint 不需要等待 RocksDB 的刷盘，Checkpoint 的周期可以缩短到秒级，同时任务故障恢复时，从 Changelog 恢复，速度更快。
适用场景：超大状态任务，对 Checkpoint 耗时要求高，需要快速故障恢复的场景。

四、运维与任务配置优化：保障任务长期稳定运行

TaskManager 内存配置优化

对于 RocksDBStateBackend，需要调大 TaskManager 的堆外内存，因为 RocksDB 使用堆外内存，taskmanager.memory.managed.fraction=0.4-0.6，给 RocksDB 分配足够的托管内存，避免堆外内存不足导致的 OOM。
合理设置 TaskManager 的槽位数：避免单个 TaskManager 的槽位数过多，导致多个子任务共享一个 RocksDB 实例，争抢资源，通常单个 TaskManager 设置 2-4 个槽位。

状态扩容重分布优化

任务扩容时，状态会在多个 TaskManager 之间重分布，TB 级状态的重分布耗时极长，优化方案：
1. 使用 Key Group 范围优化：Flink 的 Key Group 是状态重分布的最小单元，合理设置max-parallelism，避免 Key Group 数量过多或过少，通常设置为并行度的 2 倍，且是 2 的整数次幂。
2. 开启本地状态恢复，扩容时尽量复用本地的状态副本，减少跨节点的数据传输。

状态监控与告警

搭建状态监控体系，监控核心指标：状态大小、Checkpoint 成功率、Checkpoint 耗时、Barrier 对齐时间、RocksDB 读写延迟、TaskManager GC 频率。
配置告警规则：状态持续膨胀、Checkpoint 连续失败、Checkpoint 耗时超过阈值、RocksDB 读写延迟过高时，及时告警，提前介入优化，避免任务故障。

定期状态备份与清理

定期对 Checkpoint 和 Savepoint 做备份，避免 HDFS 故障导致状态丢失；
任务重启时，从 Savepoint 恢复，清理过期的状态数据，优化状态结构；
对于长期运行的任务，定期做全量 Savepoint，重启任务，优化 RocksDB 的状态存储，减少磁盘碎片，提升读写性能。

第四部分 5 年以上（专家 / 架构师级）面试题 + 详细答案

岗位定位 & 考察重点

面向 5 年以上数仓专家 / 架构师，核心考察企业级架构顶层设计、数据治理体系搭建、技术选型决策、团队管理、成本与性能平衡、行业级解决方案设计，要求能主导企业级数仓体系从 0 到 1 建设、解决跨部门的企业级数据问题、制定数据战略、带领团队落地，重点判断架构思维、行业视野、管理能力。

模块 1 企业级数仓架构顶层设计

1. 如何设计一套支撑企业数字化转型的企业级数仓架构？从战略、架构、落地、治理全流程说明

答案：

企业级数仓建设的核心目标不是单纯的技术落地，而是支撑企业的数字化转型，用数据驱动业务决策、业务创新、降本增效，必须从企业战略出发，自上而下设计，而不是单纯的技术堆砌，全流程设计分为 6 个阶段：

一、第一阶段：对齐企业战略，明确数仓建设的核心目标

企业级数仓建设的第一步，不是技术选型，而是对齐企业的战略目标，明确数仓的定位和价值，避免为了建数仓而建数仓。

对齐企业战略

：
- 深入理解企业的发展战略，比如是营收增长、成本控制、用户运营、产品创新，还是供应链优化，数仓的建设必须围绕企业的核心战略展开，为战略落地提供数据支撑。
- 比如企业的核心战略是 “用户精细化运营”，那么数仓建设的核心就是用户域数据的整合、用户画像体系建设、用户行为分析能力搭建。

明确核心业务诉求

：
- 对齐各业务线、管理层的核心诉求，明确数仓需要解决的核心业务痛点，比如 “各部门数据口径不一致，报表打架”、“数据滞后，无法做实时决策”、“数据孤岛，无法做跨业务线分析”。

制定建设规划

：
- 制定分阶段的建设目标，比如：
  1. 第一阶段：统一数据底座，解决数据孤岛和口径不一致问题；
  2. 第二阶段：完善分析能力，支撑业务精细化运营；
  3. 第三阶段：数据赋能业务，实现数据驱动的业务创新；
  4. 第四阶段：建设数据资产体系，实现数据资产化。

组建跨部门团队

：
- 成立数据委员会，由业务高管牵头，IT、数据、各业务线负责人参与，对齐目标，协调资源，解决跨部门的协作问题，避免数仓建设成为数据部门的单打独斗。

二、第二阶段：企业级数据架构顶层设计

基于企业战略和业务诉求，设计企业级数据架构，整体采用流批一体 + 湖仓一体的云原生架构，实现 “数据一体化、分析一体化、服务一体化”，架构分为 5 层：

数据接入层：统一数据门户
- 建设企业级统一的数据接入平台，规范数据接入标准，覆盖企业内所有的数据源：业务系统数据库、IoT 设备数据、日志数据、第三方合作数据、线下 Excel 数据，实现 “应接尽接”，统一数据入口，解决数据孤岛问题。
- 技术选型：Flink CDC（实时数据接入）、DataX（离线批量接入）、Flume（日志接入）、Kafka（实时数据缓存）。

数据存储层：湖仓一体统一存储底座
- 基于云原生对象存储 + Hudi/Iceberg 构建企业级数据湖，实现一份数据支持流处理、批处理、交互式分析、机器学习全场景，避免数据冗余和搬迁。
- 采用分层存储策略：热数据（近 3 个月）存储在高性能 SSD，温数据（3 个月 - 1 年）存储在标准对象存储，冷数据（1 年以上）存储在低成本归档存储，平衡性能和成本。

数据模型层：企业级统一数据模型
- 采用 “总线矩阵 + 维度建模” 的思想，建设企业级统一数据模型，分为：
  1. 贴源层（ODS）：统一接入的源数据，按业务系统划分，保留原始数据；
  2. 公共层：企业级统一的维度层（DIM）和明细层（DWD），按主题域划分（用户域、交易域、商品域、供应链域、财务域等），统一数据标准、统一维度、统一清洗规则，是企业数据的核心资产；
  3. 汇总层（DWS）：面向分析场景的轻度汇总层，建设企业级通用的指标宽表，实现指标复用；
  4. 应用层（ADS）：面向各业务线的个性化报表、产品需求，建设应用指标表。

核心原则：公共数据统一建设，个性化数据独立建设，保证全公司数据口径一致，同时满足各业务线的个性化需求。

计算与分析层：统一分析引擎
- 建设统一的计算引擎平台，适配不同的分析场景：
  1. 实时计算：Flink，支撑实时数仓、实时大屏、实时预警；
  2. 离线计算：Spark/Flink 批处理，支撑 T+1 报表、批量数据处理；
  3. 交互式分析：Trino/Doris，支撑自助分析、即席查询；
  4. 人工智能：Spark ML/Flink ML，支撑用户画像、推荐系统、预测分析。

数据服务层：统一数据出口
- 建设企业级统一数据服务平台，封装统一的 API 接口，对外提供数据查询、指标服务、数据推送能力，所有业务系统、报表系统、产品都通过统一的平台获取数据，避免数据出口混乱，保证数据的一致性和安全性。

三、第三阶段：企业级指标体系与数据标准建设

企业级数仓的核心是数据的一致性，必须先制定统一的数据标准和指标体系，再落地模型，避免 “先乱后治”。

建设企业级统一数据标准
- 制定全公司统一的数据标准，包括：
  1. 命名规范：表名、字段名、指标名的统一命名规范；
  2. 数据类型规范：统一字段的数据类型、长度、格式；
  3. 编码规范：统一维度编码，比如地区编码、商品分类编码、组织架构编码；
  4. 数据质量规范：统一数据质量校验规则，比如非空校验、值域校验、一致性校验。

所有数据模型的建设，必须严格遵守数据标准，从源头保证数据的一致性。

建设企业级统一指标体系
- 基于原子指标、派生指标、复合指标的三层模型，建设全公司统一的指标体系：
  1. 原子指标：不可拆分的基础指标，比如支付金额、订单数量、用户登录次数，明确指标的业务含义、计算逻辑、统计粒度；
  2. 派生指标：原子指标 + 维度 + 统计周期，比如 “近 7 天华东地区的支付金额”；
  3. 复合指标：基于原子指标和派生指标计算的组合指标，比如转化率、复购率、客单价。

指标体系由数据委员会统一审批、统一管理，所有指标必须在指标体系中注册，明确口径，避免 “一个指标，多个口径，多个结果” 的问题，彻底解决报表打架的痛点。

四、第四阶段：架构落地与迭代优化

企业级数仓建设不是一蹴而就的，必须采用 “试点先行、快速迭代、逐步推广” 的落地策略，避免大而全的项目导致的周期长、落地难、效果差。

试点先行，验证价值
- 选择企业核心的、痛点明确的业务场景做试点，比如核心的交易报表、用户运营分析，快速落地端到端的解决方案，在 3 个月内产出业务价值，获得业务方和管理层的认可，为后续推广争取资源。

逐步推广，完善体系
- 试点成功后，按主题域逐步推广，先建设核心的交易域、用户域，再扩展到供应链、财务、人力等主题域，逐步完善企业级数据模型。
- 同步建设配套的工具平台：数据开发平台、调度平台、数据质量平台、元数据平台、数据服务平台，提升开发效率，保障数仓稳定运行。

业务赋能，价值落地
- 数仓建设的核心是业务价值，必须将数据能力赋能给业务方，比如建设自助分析平台，让业务人员可以自己取数、自己分析，不需要依赖数据部门；建设数据产品，比如用户画像平台、经营分析平台、供应链优化平台，直接支撑业务决策。
- 建立数据价值评估体系，量化数仓建设带来的业务收益，比如提升了运营效率、降低了成本、带来了营收增长，持续获得管理层和业务方的支持。

持续迭代，架构升级
- 随着业务的发展和技术的迭代，持续优化架构，比如从传统的 Lambda 架构升级到流批一体架构，从传统数仓升级到湖仓一体架构，从本地部署升级到云原生架构，保持架构的先进性和扩展性。

五、第五阶段：企业级数据治理体系建设

企业级数仓建设的长期稳定运行，必须配套完善的数据治理体系，实现数据资产的全生命周期管理，避免 “建起来，乱下去”。

建立数据治理组织架构
- 成立数据治理委员会，由企业高管牵头，明确数据治理的责任部门和责任人，每个业务域设置数据 Owner，负责本业务域的数据质量、数据安全、数据标准落地，实现 “谁生产，谁负责”。

建设全链路数据治理能力
- 元数据管理：建设企业级元数据平台，管理所有表、字段、指标的元数据，完善业务文档，实现数据可查、可懂。
- 数据血缘管理：建设全链路数据血缘，实现数据从源头到应用的全链路追踪，支持影响面分析、故障溯源。
- 数据质量管理：建设全链路数据质量监控平台，配置数据质量规则，实现事前拦截、事中监控、事后告警，保障数据的准确性、完整性、一致性。
- 数据安全管理：建设统一的权限管控体系、数据脱敏体系、数据分级分类体系，保障数据安全，符合等保、数据安全法的要求。
- 数据生命周期管理：制定数据的生命周期管理策略，自动归档、清理过期数据，降低存储成本，提升查询性能。

建立数据治理制度与流程
- 制定数据治理的管理制度、流程规范、考核标准，将数据治理纳入各部门的绩效考核，推动数据治理的落地执行，让数据治理成为常态化的工作，而不是一次性的项目。

六、第六阶段：数据资产化与数据文化建设

企业级数仓建设的最终目标，是将数据变成企业的核心资产，建设数据驱动的企业文化，支撑企业的长期数字化转型。

建设数据资产体系
- 对企业的数据资产进行盘点、评估、定价，建立数据资产目录，明确数据资产的价值、归属、使用范围，实现数据资产的可管理、可运营、可交易。

推动数据文化建设
- 开展数据培训，提升全公司员工的数据素养，让业务人员懂数据、用数据；
- 树立数据驱动的标杆案例，推广数据驱动的业务成果，让数据成为企业决策的基础；
- 建立数据驱动的绩效考核体系，将数据指标纳入各部门的考核，推动全员用数据说话、用数据决策、用数据管理、用数据创新。

探索数据创新应用
- 基于企业的数据资产，探索数据创新应用，比如智能推荐、智能风控、供应链智能优化、销量预测，用数据驱动业务创新，为企业创造新的营收增长点，实现从 “业务数据化” 到 “数据业务化” 的升级。

2. 流批一体架构在企业级的落地方法论，对比 Lambda 架构，如何解决落地过程中的业务适配、技术门槛、历史兼容问题？

答案：

一、流批一体的核心定义与企业级价值

流批一体是指用同一套引擎、同一套 SQL、同一套模型，同时处理流数据和批数据，彻底解决传统 Lambda 架构的两套链路、两套代码、口径不一致、开发维护成本高的核心痛点。

对比 Lambda 架构，核心优势如下：

表格

维度	Lambda 架构	流批一体架构
开发成本	实时、离线两套链路、两套代码，开发成本翻倍	一套链路、一套代码，开发成本降低 50% 以上
口径一致性	实时、离线两套逻辑，极易出现口径不一致，报表打架	同一套逻辑，天然保证口径一致，彻底解决报表打架问题
维护成本	两套链路需要同时维护，故障排查复杂，运维成本高	一套链路，维护成本大幅降低，问题排查简单
实时性	离线链路 T+1 更新，实时链路秒级更新	全链路实时更新，数据从产生到可查询延迟在秒级
学习成本	需要同时掌握批处理和流处理两套技术栈，学习成本高	一套技术栈，学习成本低，开发人员只需要掌握一套 API/SQL

二、企业级流批一体落地方法论

流批一体在企业级落地，不能只关注技术，必须从业务、技术、组织、工具四个维度同步推进，采用 “六步落地法”，确保落地成功：

第一步：业务调研与场景适配，明确落地边界

流批一体不是万能的，不是所有场景都适合，必须先调研业务场景，明确哪些场景适合流批一体，哪些场景需要保留传统架构，避免为了技术而技术。

场景分类与适配

表格

场景类型	业务特点	是否适合流批一体	落地优先级
实时 + 离线双链路指标	同一指标，既需要实时大屏展示，又需要 T+1 离线报表，比如 GMV、DAU、订单量	高度适合，核心场景	P0 最高
增量数据 ETL	业务数据实时同步，需要做清洗、转换、关联，同时支撑实时和离线分析	高度适合	P0
固定周期的批量报表	仅需要 T+1 离线报表，无实时需求，比如月度财务报表、年度经营分析	可适配，非核心	P2 低
超大规模历史数据回溯	全量历史数据重跑、批量数据处理，无实时需求	可适配，需要优化	P1 中
机器学习模型训练	海量数据批量训练，无实时需求	不适合，保留传统架构	不落地

明确落地目标
- 核心目标：解决业务痛点，比如口径不一致、开发效率低、数据实时性差，而不是单纯的技术升级；
- 量化目标：比如开发效率提升 50%、指标口径不一致问题清零、数据实时性从 T+1 提升到秒级。

第二步：技术选型与架构设计，适配企业级需求

基于业务场景，选择成熟的、适合企业现状的技术栈，设计企业级流批一体架构，避免盲目追求新技术。

核心技术栈选型

企业级流批一体的核心是

计算引擎 + 表格式

的组合，主流选型方案如下：

表格

方案	核心组件	优势	适用企业
方案 1	Flink + Hudi	国内社区最成熟，完美支持流批一体读写，Flink 同时支持流和批，Hudi 支持 ACID、增量读写、快照读取	国内绝大多数企业，尤其是有强实时需求的企业
方案 2	Spark + Iceberg	Spark 批处理能力极强，Iceberg 对 Spark 的适配性最好，对批处理场景优化更好	以离线批处理为主，实时需求较少的企业
方案 3	Flink + Doris	Doris 是流批一体的 OLAP 引擎，支持实时写入、批量分析，一站式解决存储和计算	中小规模企业，不想维护复杂的大数据组件，一站式落地

选型核心原则：优先选择社区成熟、国内案例多、符合企业现有技术栈的方案，降低落地风险和学习成本。

企业级架构设计

整体架构分为 4 层，实现 “数据入口统一、模型统一、计算统一、服务统一”：

统一数据接入层：用 Flink CDC 统一接入业务库的增量数据，写入 Kafka 和数据湖，实现一套数据同时支撑流和批处理，避免重复同步。
统一存储层：基于数据湖（Hudi/Iceberg）构建统一存储，ODS/DWD/DIM 层全量存储在数据湖中，实时任务写入增量数据，离线任务读取全量快照，实现一份数据流批共用。
统一计算层：基于 Flink/Spark 构建统一计算引擎，实时计算和离线批量计算使用同一套 SQL 逻辑，封装成公共模板，保证口径完全一致。
统一服务层：基于 OLAP 引擎构建统一数据服务，同时支撑实时指标查询和离线报表分析，对外提供统一的指标接口。

第三步：规范制定与能力建设，降低落地门槛

流批一体落地的最大障碍之一是团队的学习成本和技术门槛，必须提前制定规范，建设配套工具，降低落地门槛。

制定全流程开发规范
- 表设计规范：明确流批一体表的类型选型、分区策略、索引设计、TTL 设置；
- SQL 开发规范：统一流批一体 SQL 的写法，避免使用流批不兼容的语法；
- 数据模型规范：明确分层设计、维度建模规范，保证流批模型统一；
- 运维规范：明确 Checkpoint 配置、状态管理、任务监控、故障恢复规范。

建设配套工具平台，封装底层技术细节
- 低代码数据开发平台：封装流批一体的核心能力，开发人员只需要关注业务逻辑，平台自动生成符合规范的 Flink/Spark SQL，自动配置资源、Checkpoint、监控，降低开发人员的学习成本。
- 统一调度平台：同时支持实时任务的运维和离线任务的调度，实现流批任务的统一运维。
- 统一数据质量平台：同时支持实时数据质量监控和离线数据质量校验，实现全链路数据质量保障。
- 统一元数据平台：统一管理流批一体的表、字段、指标元数据，展示全链路数据血缘，实现流批元数据的统一管理。

团队培训与能力建设
- 组织系统化的培训，从原理、最佳实践、实战案例三个维度，提升团队的流批一体技术能力；
- 建立技术攻坚小组，解决落地过程中的技术难题，输出最佳实践文档；
- 建立代码评审机制，保证开发的代码符合规范，避免技术债务。

第四步：试点先行，快速验证，小步快跑

企业级落地绝对不能搞大而全的一次性切换，必须采用 “试点先行、小步快跑、快速迭代” 的策略，降低落地风险，快速验证业务价值。

选择核心试点场景
- 优先选择 P0 级的核心场景，比如 “实时 + 离线双链路的 GMV 指标”，这类场景业务痛点明确，流批一体的价值最明显，容易快速落地，获得业务方的认可。
- 试点场景的范围要可控，避免范围过大导致周期长、落地难，目标是 3 个月内完成端到端的落地，产出业务价值。

试点落地与对比验证
- 试点落地过程中，保留原有的 Lambda 架构链路，新的流批一体链路和原有链路并行运行，做结果对比验证，确保新链路的指标结果和原有链路一致，甚至更准确，验证口径一致性。
- 同时对比开发效率、维护成本、实时性的提升，量化流批一体的价值。

总结经验，优化规范
- 试点落地完成后，总结落地过程中的经验和坑点，优化开发规范、工具平台、最佳实践，为后续的全量推广打下基础。

第五步：分阶段推广，平滑迁移，兼容历史

试点成功后，分阶段、分业务域逐步推广流批一体架构，同时做好历史架构的兼容，避免业务中断。

分阶段推广计划
- 第一阶段：推广所有 P0 级的实时 + 离线双链路场景，替换原有的 Lambda 架构；
- 第二阶段：推广增量 ETL 场景，将 ODS/DWD 层全部迁移到流批一体架构，实现统一的数据底座；
- 第三阶段：推广离线批量报表场景，将 T+1 的离线任务迁移到流批一体架构，实现全链路统一；
- 第四阶段：拓展更多场景，比如自助分析、数据科学、机器学习，实现一份数据支撑全场景。

平滑迁移方案
- 采用 “并行运行、灰度切换” 的迁移策略：新的流批一体链路和原有链路并行运行，结果对比验证无误后，先灰度切换少量业务，再全量切换，最后下线原有链路，避免业务中断。
- 对于历史数据，采用批量迁移的方式，将历史数据一次性写入数据湖，保证历史数据和实时数据的连续性，支持历史回溯分析。

历史架构兼容
- 对于暂时无法迁移的场景，保留原有的架构，通过数据湖实现数据互通，流批一体架构可以读取原有架构的数据，原有架构也可以读取流批一体的数据，实现平滑过渡，避免一刀切。
- 对于现有的报表系统、数据产品，不需要做改造，通过统一的数据服务层对接新的流批一体架构，对上层业务完全透明，降低迁移成本。

第六步：体系完善，长效运营

流批一体架构落地后，需要建设完善的运维、治理、运营体系，保障架构的长期稳定运行，持续释放业务价值。

全链路监控与运维体系
- 建设流批一体的全链路监控平台，监控任务运行状态、数据延迟、资源使用率、数据质量，配置告警规则，出现异常及时通知，保障任务 7*24 小时稳定运行。
- 建立标准化的故障排查、应急响应、故障恢复流程，提升运维效率。

数据治理体系适配
- 将流批一体架构纳入企业现有的数据治理体系，完善元数据管理、数据血缘、数据质量、数据安全、生命周期管理，实现流批数据的统一治理。

持续优化与价值运营
- 持续优化架构性能，降低资源成本，提升开发效率；
- 持续拓展流批一体的应用场景，赋能更多业务线，量化业务价值，推动企业的数字化转型。

三、落地过程中的核心痛点与解决方案

痛点 1：业务场景适配难，不知道哪些场景该用流批一体
- 解决方案：
  1. 建立场景适配评估模型，从 “实时需求、口径一致性要求、开发维护成本” 三个维度评估场景的适配度；
  2. 优先落地痛点明确、价值清晰的场景，不追求全场景覆盖；
  3. 对于不适合的场景，保留原有架构，不强行落地流批一体，避免适得其反。

痛点 2：团队技术门槛高，学习成本大，落地难
- 解决方案：
  1. 优先选择符合团队现有技术栈的方案，比如团队熟悉 Flink，就选择 Flink+Hudi 的方案，降低学习成本；
  2. 建设低代码开发平台，封装底层技术细节，开发人员只需要写 SQL，不需要关注底层的 Checkpoint、状态管理等复杂配置；
  3. 系统化的培训 + 试点项目实战，快速提升团队能力，输出最佳实践文档，让团队有章可循。

痛点 3：历史架构兼容难，迁移成本高，业务中断风险大
- 解决方案：
  1. 采用 “并行运行、灰度切换” 的迁移策略，新老链路并行运行，验证无误后再切换，绝对不搞一刀切；
  2. 建设统一的数据服务层，对上层业务系统屏蔽底层架构的变化，上层业务不需要做任何改造，就能切换到新的架构，大幅降低迁移成本；
  3. 分阶段迁移，先迁移非核心场景，积累经验后再迁移核心场景，降低业务风险。

痛点 4：流批一体的性能问题，尤其是批量历史数据处理性能不如传统批处理
- 解决方案：
  1. 针对批量场景优化参数配置，比如 Flink 批处理模式，调整并行度、内存配置、Shuffle 参数，提升批量处理性能；
  2. 优化数据湖表的设计，合理分区、分桶、索引，合并小文件，提升批量读取性能；
  3. 对于超大规模的历史数据回溯，采用 Spark 批处理，和 Flink 流处理配合，发挥各自的优势，不追求用一个引擎解决所有问题。

痛点 5：数据治理体系不兼容，原有治理工具无法适配流批一体架构
- 解决方案：
  1. 优先选择和现有治理工具兼容的组件，比如 Hudi/Iceberg 都兼容 Hive Metastore，现有的元数据、数据质量工具可以直接适配；
  2. 对现有治理工具做轻量改造，支持流批一体的增量数据、实时数据监控；
  3. 补充自研工具，针对流批一体的特性，建设专门的治理能力，比如实时数据血缘、实时数据质量监控。

附加部分面试通用工具包

1. 各经验级别项目自我介绍模板

0-1 年应届生 / 入门级

面试官您好，我是 XX，有 XX 年数仓开发经验，主要参与了 XX 公司的离线数仓建设项目。我的核心工作是基于 Hive 进行数仓分层开发，编写 SQL 完成数据清洗、指标计算，配合调度工具完成任务上线，同时参与了基础的实时数据采集和 Flink 实时任务开发。在项目中，我掌握了数仓基础建模、Hive SQL 优化、Kafka 和 Flink 的基础使用，解决了数据倾斜、小文件等常见问题，具备独立完成数仓基础模块开发的能力。

1-3 年初级开发级

面试官您好，我是 XX，有 XX 年数仓开发经验，全程参与了 XX 公司离线 + 实时数仓的搭建与迭代。我负责的核心工作包括：业务需求调研、数仓分层建模、Hive/Spark 离线任务开发、Flink 实时任务开发、SQL 性能优化、生产问题排查。主导了用户行为分析、交易指标统计等核心模块的建设，解决了生产环境中的数据倾斜、任务超时、Kafka 堆积、Flink 反压等常见问题，同时搭建了基础的数据质量监控体系，保障了数仓任务的稳定运行。具备独立完成数仓全流程开发、解决生产复杂问题的能力。

3-5 年高级开发级

面试官您好，我是 XX，有 XX 年数仓开发经验，主导了 XX 公司从 0 到 1 的离线 + 实时一体化数仓建设。我负责整体数仓架构设计、技术选型、建模规范制定、核心模块开发，同时带领团队完成数仓迭代与运维。在项目中，我设计了基于湖仓一体的流批一体架构，解决了 PB 级海量数据的性能优化、口径一致性、高可用等核心问题，主导了大促期间数仓稳定性保障方案的落地，同时搭建了企业级数据治理体系，实现了数据资产的全生命周期管理。具备数仓架构设计、复杂问题攻坚、团队管理的能力。

5 年以上专家 / 架构师级

面试官您好，我是 XX，有 XX 年大数据和数仓架构经验，负责多家企业的企业级数仓体系从 0 到 1 的规划、设计、落地与运营。我核心聚焦于通过数据架构支撑企业数字化转型，擅长企业级流批一体、湖仓一体架构设计，数据治理体系搭建，数据资产化运营。在过往的项目中，我主导制定了企业级数据战略，设计了支撑多业务线、多租户的企业级数仓架构，解决了跨部门数据孤岛、口径不一致、数据价值无法落地等核心痛点，推动企业从业务数据化到数据业务化的升级，同时带领团队完成了技术体系升级、团队能力建设，具备企业级数据架构顶层设计、跨部门协调、团队管理与数据价值运营的能力。

2. 数仓面试避坑 10 条

不说空话，所有的技术点都要结合自己的项目经历，不要只背理论，面试官一定会追问你在项目中是怎么用的。
不夸大自己的经验，没做过的内容不要说，面试官几个追问就会露馅，诚实比夸大更重要。
遇到不会的问题，直接坦诚说自己没接触过，不要瞎编，同时可以说自己的理解思路，体现自己的学习能力和思考能力。
回答问题要有逻辑，分点说明，先说结论，再说细节，不要东拉西扯，让面试官抓不住重点。
不要贬低之前的公司、团队和技术架构，多从自己的成长、解决的问题出发，体现自己的专业性。
指标口径是数仓面试的核心，所有的指标都要明确口径，比如 DAU，要说明是怎么定义活跃、怎么去重、时间口径是什么，体现自己的严谨性。
性能优化的问题，不要只说调参数，要先说排查思路，再说优化方案，最后说优化效果，比如优化前任务运行多久，优化后多久，体现自己的实战能力。
架构设计的问题，不要只堆技术组件，要先说明业务痛点，再说架构设计的思路，为什么选这个技术栈，解决了什么问题，体现自己的架构思维，而不是技术堆砌。
面试前一定要熟悉自己简历上写的所有项目和技术点，面试官 90% 的问题都会围绕简历展开，不要简历上写了，自己却不熟悉。
反问环节，不要问薪资、加班这种太功利的问题，优先问团队的技术栈、业务方向、这个岗位的核心挑战，体现自己对岗位的兴趣和专业性。

3. 面试反问环节话术模板

0-1 年应届生 / 入门级

请问这个岗位的核心职责是什么，团队对这个岗位的期望是怎样的？
请问团队的技术栈是怎样的，新人入职会有相关的培训和带教吗？
请问团队目前的数仓建设处于什么阶段，接下来的规划是怎样的？

1-3 年初级开发级

请问这个岗位需要负责的核心业务和模块是什么，目前团队面临的最大的技术挑战是什么？
请问团队的数仓架构是怎样的，离线和实时的占比是多少，接下来有架构升级的规划吗？
请问团队的开发流程是怎样的，需求评审、代码评审、上线流程是怎么规范的？

3-5 年高级开发级

请问这个岗位是偏向架构设计，还是偏向业务开发，需要带领团队吗？
请问公司目前的数仓建设处于什么阶段，存在哪些痛点，希望这个岗位的人来解决哪些问题？
请问公司对数据团队的定位是怎样的，是支撑业务，还是驱动业务，未来的发展规划是怎样的？

5 年以上专家 / 架构师级

请问公司目前的数字化转型处于什么阶段，对数据架构的核心诉求是什么？
请问公司目前的数据体系存在哪些核心痛点，希望通过这个岗位的加入，带来哪些改变？
请问公司对数据团队的长期规划是怎样的，在数据资产化、数据驱动业务方面，有怎样的布局？

数据仓库离线 + 实时全级别面试宝典（含详细答案）

第一部分 0-1 年（应届生 / 入门级）面试题 + 详细答案

岗位定位 & 考察重点

模块 1 数仓基础理论

1. 【高频考点】简述数据仓库的定义、四大核心特性，以及和业务数据库的核心区别

2. 【高频考点】数据仓库标准分层架构（ODS/DWD/DWS/DIM/ADS），每层的作用是什么？

3. 什么是维度建模？星型模型和雪花模型的区别是什么？

4. 什么是缓慢变化维（SCD）？常见的处理方式有哪些？

模块 2 SQL 基础与实战

1. 【高频考点】SQL 中row_number()、rank()、dense_rank()的区别，以及适用场景

2. 用 SQL 实现用户每日登录次数统计，表结构：user_login (user_id string, login_time timestamp)

3. 如何用 SQL 实现两张表的左连接，以及左连接、内连接、右连接、全连接的区别

模块 3 离线数仓基础

1. 【高频考点】Hive 是什么？Hive 和 MySQL 的核心区别是什么？

2. Hive 内部表和外部表的区别，分别适用什么场景？

3. Hive 分区表是什么？为什么要使用分区表？

模块 4 实时数仓基础

1. 【高频考点】Kafka 的核心架构组件有哪些？分别有什么作用？

2. 【高频考点】Flink 是什么？对比 Spark Streaming，为什么 Flink 更适合实时数仓？

3. Flink 的时间语义有哪几种？分别是什么含义？

4. 什么是 Watermark（水位线）？它的核心作用是什么？

模块 5 简单场景题

1. 统计用户的日活（DAU），你会怎么设计？

2. 数仓开发中，遇到脏数据怎么处理？

第二部分 1-3 年（初级开发级）面试题 + 详细答案

岗位定位 & 考察重点

模块 1 数仓建模进阶

1. 【高频考点】完整的数仓建模流程是什么？从需求到落地需要考虑哪些关键点？

2. 事实表有哪几种类型？分别适用什么场景？

3. 数据仓库中，数据一致性怎么保证？

模块 2 Hive SQL 优化与实战

1. 【高频考点】Hive 数据倾斜的根本原因是什么？有哪些常见场景？对应的解决方案是什么？

2. 【高频考点】Hive SQL 的通用优化手段有哪些？

一、表设计层面优化

二、SQL 写法层面优化

三、参数配置层面优化

3. Hive 中 order by、sort by、distribute by、cluster by 的区别是什么？

模块 3 Spark 离线开发与优化

1. Spark 的核心架构组件有哪些？RDD 的五大特性是什么？

一、Spark 核心架构组件

二、RDD 的五大特性

2. Spark 的宽窄依赖是什么？Stage 是如何划分的？

一、宽窄依赖

二、Stage 划分原理

3. 【高频考点】Spark 任务的通用优化方案有哪些？

一、资源调优

二、算子优化

三、Shuffle 优化

四、数据倾斜优化

五、代码与数据优化

模块 4 Flink/Kafka 实战开发

1. 【高频考点】Kafka 如何保证消息不丢失、不重复消费、有序性？

一、保证消息不丢失

二、保证消息不重复消费

三、保证消息有序性

2. 【高频考点】Flink 的状态管理是什么？状态后端有哪几种？如何选型？

一、Flink 状态管理

二、状态后端类型及选型

3. Flink 反压是什么？如何排查和解决反压问题？

一、反压的定义

二、反压问题排查

三、反压问题解决方案

4. Flink Exactly-Once（精准一次）语义的实现原理是什么？

一、引擎内部的 Exactly-Once：基于 Checkpoint 机制

二、端到端的 Exactly-Once：基于两阶段提交（2PC）

模块 5 生产常见问题解决

1. 离线任务运行超时、执行缓慢，如何排查和优化？

2. 数仓数据质量出现问题，比如指标结果不对，如何排查溯源？

模块 6 综合场景题

1. 设计一套电商场景的离线 + 实时数仓架构，覆盖从数据采集到指标输出的全流程

1. 数据采集层

2. 数据存储层

3. 离线数仓分层计算

4. 实时数仓分层计算

5. 数据服务与运维层

2. 实时计算 UV（日活），如何解决数据乱序、重复计算、精准去重的问题？

一、基础方案设计

二、核心问题解决方案

方案 1：精准去重方案（适合小流量、要求 100% 精准的场景）

方案 2：近似去重方案（适合大流量、低延迟、允许微小误差的场景）

1. 【高频考点】SQL 中`row_number()`、`rank()`、`dense_rank()`的区别，以及适用场景

附加部分面试通用工具包