数据核心专题面试专项

适用对象：数据开发、数仓、实时计算、数据平台、湖仓一体、分析型后端、数据治理相关面试。

阅读方式：先背“通用答题框架”，再刷“专题高频题”，最后用“对比选型”和“场景设计”做压轴训练。

版本参考：本文按 2025-08 的主流技术线整理；涉及版本号的内容以官方最新稳定版/最新文档页为准，补丁级差异以发行说明为准。

0. 通用答题框架

面试里遇到数据题，最稳的答法不是“背定义”，而是先给结论，再讲为什么，再落到方案和代价。

1. 先给一句话结论：这个问题的核心矛盾是什么，推荐什么方案。
2. 再讲原理：数据怎么流、状态怎么存、语义怎么保、性能怎么提。
3. 再讲工程化：分层、幂等、监控、回滚、容灾、成本控制。
4. 再讲取舍：为什么不用别的方案，边界在哪里，坑在哪里。
5. 最后补一句面试加分点：口径统一、可回放、可恢复、可治理。

高频答题模板

• 基础版：定义 + 场景 + 一个常见实现。
• 进阶版：再补流程、组件协同、性能和一致性。
• 加分版：再补边界条件、降级策略、监控指标和故障恢复。

1. 版本与趋势速查

这部分不是为了背版本号本身，而是为了知道“行业现在主流怎么选”。

版本趋势怎么说

• 湖仓一体的主流方向不是“单一引擎统治”，而是“开放表格式 + 多引擎计算 + 对象存储底座”。
• 实时数仓的主流方向不是“纯 Lambda 双链路”，而是“统一口径 + 单一事实层 + 流批协同”。
• 事务和一致性问题的主流方向不是“强行全局强一致”，而是“局部强一致 + 全链路幂等 + 可重放 + 可补偿”。

2. 数据仓库专题（★★★★★）

2.1 数仓分层设计：ODS -> DWD -> DWS -> ADS

高频指数：★★★★★。这是数据仓库面试的地基题，面试官最爱追问“为什么要分层”和“每层负责什么”。

一句话结论： 分层的本质是把“采集、清洗、建模、聚合、应用”解耦，让数据口径统一、复用能力更强、链路更稳定、变更影响更小。

1
2
3
4
5
6
7
8

flowchart LR
    A["数据源<br/>业务库/日志/埋点/第三方"] --> B["ODS<br/>原始数据层"]
    B --> C["DWD<br/>明细清洗层"]
    C --> D["DWS<br/>主题汇总层"]
    D --> E["ADS<br/>应用服务层"]
    C --> F["特征/宽表/明细服务"]
    D --> G["指标/主题分析"]
    E --> H["报表/看板/策略/接口"]

基础版：

• ODS 负责原始数据落地，尽量保持原貌，便于追溯和重放。
• DWD 负责清洗、去重、统一编码、统一主键、统一时间语义。
• DWS 负责按主题沉淀公共指标和宽表，减少重复加工。
• ADS 负责直接面向业务场景输出结果，例如报表、接口、画像、风控特征。

进阶版：

• 分层不是教条，核心是“谁负责数据质量，谁负责公共复用，谁负责最后消费”。
• DWD 要尽量做成“可复用的明细事实层”，避免把业务逻辑写死在报表里。
• DWS 适合做高频公共指标、复合维度宽表、主题域汇总，不适合塞太多一次性逻辑。
• ADS 应尽量轻，重点是输出快、口径稳、变更小。

加分版：

• 可以把 ODS 再细分为贴源层、标准原始层、历史归档层，分别承担回放、合规、追踪。
• 可以把 DWD 做成事实表 + 维表快照 + 统一字典层，减少下游重复 join。
• 可以将 DWS 与语义层绑定，让指标定义和计算逻辑可版本化。

易错点：

• ODS 不是垃圾堆，不是所有脏数据都堆进去后再说。
• DWD 不是“大杂烩清洗层”，不能把所有业务规则都塞进来。
• DWS 不是“什么都汇总一下”，它要围绕主题域和公共复用来设计。

2.2 建模方法：范式建模 vs 维度建模

一句话结论： 范式建模更强调消除冗余和更新一致性，维度建模更强调分析易用和查询性能；数仓里常见做法是“底层范式化、服务层维度化”。

基础版：

• 范式建模适合 OLTP 或需要强更新一致性的场景。
• 维度建模适合分析型场景，典型是事实表 + 维度表。
• 事实表表达“发生了什么”，维度表表达“围绕什么看”。

进阶版：

• 维度建模里要先识别业务过程，再定义粒度，再确定事实和维度。
• 粒度是最重要的建模起点，粒度不清，后面所有指标都会歪。
• 常见事实表包括事务事实表、周期快照事实表、累积快照事实表。

加分版：

• 数仓常用“核心层偏范式、应用层偏维度”的混合思路。
• 对实时分析场景，可以把维度快照、主键表、宽表和指标表组合起来，减少复杂 join。
• 设计时要考虑变更成本：维表缓慢变化、事实口径调整、历史重算、血缘追踪。

易错点：

• 维度建模不是只做星型模型，雪花模型、混合模型也有用武之地。
• 事实表不是越宽越好，宽表会增加写入成本和维护成本。

2.3 缓慢变化维（SCD）

一句话结论： SCD 的本质是处理“维度属性变了，历史怎么算”的问题，核心是保留业务所需的历史一致性。

基础版：

• SCD1：直接覆盖，不保留历史，适合错误修正或不关心历史的字段。
• SCD2：新增版本行，保留历史，最常见于需要追溯的业务维度。
• SCD3：保留有限历史字段，例如当前值 + 上一个值。

进阶版：

• 处理 SCD2 时通常会有生效时间、失效时间、当前标记、版本号。
• 维度变更时要明确是“覆盖、追加、还是局部版本化”。
• 大部分分析场景最需要的是“按事实发生时的维度快照”。

加分版：

• 维度慢变不一定非要全量重写，可以通过增量变更日志、CDC、变更维表来实现。
• 对实时数仓，SCD2 要特别关注乱序、重复和迟到数据。

易错点：

• 不要把 SCD2 简化成“加个时间字段就行”，版本切换逻辑才是关键。
• 不要在事实表里直接硬编码维度属性，否则后期变更会很痛。

2.4 数据生命周期管理

基础版：

• 生命周期管理解决的是“数据存多久、放哪、何时归档、何时删除”。
• 常见分级是热数据、温数据、冷数据、归档数据。

进阶版：

• 热数据通常放在低延迟存储或查询引擎，服务实时查询和近线分析。
• 冷数据可以迁移到对象存储或低成本存储，保留审计和回放能力。
• 生命周期策略要和合规要求、业务回溯期限、成本预算绑定。

加分版：

• 生命周期不是单纯 TTL，通常还要配合分区裁剪、冷热分层、自动压缩、自动清理。
• 重要表要保留恢复窗口，避免误删后完全无法找回。

2.5 数据质量保障

核心目标： 让数据“可用、可信、可追踪、可恢复”。

基础版：

• 质量维度常见包括完整性、准确性、一致性、唯一性、及时性、合法性。
• 常见规则有非空、唯一、范围、枚举、关联关系、数量阈值、同比环比阈值。

进阶版：

• 质量体系要分层：采集校验、ETL 校验、入仓校验、出仓校验、消费校验。
• 质量告警要能区分“数据波动”与“链路故障”，避免噪音过多。
• 质量问题要能定位到字段、批次、分区、血缘和责任人。

加分版：

• 大型平台应把质量规则做成配置化、版本化、可回放。
• 最有效的质量治理往往不是“事后报警”，而是“事前约束 + 过程校验 + 末端审计”。

易错点：

• 只做 SQL 校验不够，采集语义、时间语义、主键语义同样重要。
• 质量规则不能太多太乱，否则告警会失真。

2.6 元数据管理

核心目标： 解决“这张表是谁生成的、从哪来、被谁用、出了问题找谁”的问题。

基础版：

• 元数据分技术元数据和业务元数据。
• 技术元数据包括库表结构、分区、字段类型、任务依赖、作业参数。
• 业务元数据包括指标口径、主题定义、责任人、使用场景。

进阶版：

• 元数据系统最好能和血缘、权限、质量、资产目录联动。
• 有了血缘，才能快速定位某个指标受哪些上游变更影响。
• 有了资产目录，才能让数据像“产品”一样被搜索和使用。

加分版：

• 面试里可以强调“指标定义可版本化，血缘可追踪，口径可回放”。
• 元数据系统不仅是管理工具，也是治理中台的神经系统。

2.7 离线数仓 vs 实时数仓

一句话结论： 离线数仓重吞吐和全量分析，实时数仓重低延迟和增量更新；真正难的是两者口径统一。

基础版：

• 离线数仓适合 T+1、T+0.5、日级报表、历史分析。
• 实时数仓适合分钟级、秒级看板、风控、监控、在线特征。

进阶版：

• 离线链路一般以批处理为主，重算能力强，成本相对低。
• 实时链路一般以流处理为主，强调低延迟、状态一致性、持续更新。
• 两者最终最好共享统一指标定义、统一维表、统一主题模型。

加分版：

• 现代架构里常见做法是“实时负责新鲜度，离线负责准确性和回补”。
• 口径统一的关键不是“两个链路算出一样的 SQL”，而是“同一套语义层和维表版本”。

2.8 湖仓一体设计

一句话结论： 湖仓一体的本质是把数据湖的低成本、开放性，和数仓的治理、性能、语义统一起来。

1
2
3
4
5
6

flowchart TB
    A["数据源<br/>DB/日志/IoT/第三方"] --> B["采集层<br/>Kafka / CDC / Batch"]
    B --> C["湖仓存储层<br/>Iceberg / Paimon / Hudi + Object Storage"]
    C --> D["计算层<br/>Spark / Flink / Trino / ClickHouse"]
    C --> E["治理层<br/>Catalog / 元数据 / 权限 / 质量 / 血缘"]
    D --> F["服务层<br/>BI / API / 特征 / 搜索 / 风控"]

基础版：

• 湖仓一体要同时满足开放格式、统一治理、跨引擎读写、历史回溯。
• 核心不是“把湖变成仓”，而是“让湖具备仓的能力”。

进阶版：

• Iceberg 更像开放标准表格式，重点在多引擎一致访问和隐藏分区。
• Paimon 更偏实时湖仓和主键表场景，适合 CDC、增量、流式写入。
• Hudi 更强调 upsert、增量拉取和表服务能力，适合有历史沉淀的实时更新场景。

加分版：

• 设计湖仓平台时，要把 Catalog、Schema 演进、权限、质量、生命周期一起考虑。
• 现代方案通常不会只押一个引擎，而是“存储层统一、计算层多引擎、服务层按场景分发”。

易错点：

• 湖仓一体不是“把表放到对象存储上就完事了”。
• 如果没有治理层，开放格式只会把混乱放大。

3. 数据一致性与语义保障专题（★★★★★）

3.1 消息语义：At-Most-Once / At-Least-Once / Exactly-Once

一句话结论： 消息语义本质是“会不会丢、会不会重、能不能逻辑只生效一次”。

基础版：

• At-Most-Once：最多处理一次，可能丢，不会重复。
• At-Least-Once：至少处理一次，不会丢，可能重复。
• Exactly-Once：逻辑上只生效一次，通常要靠状态、事务或幂等共同实现。

进阶版：

• 工程里常见的是“源头至少一次 + 末端幂等/事务 + 状态一致性”。
• 真正的端到端 Exactly-Once 比单点 Exactly-Once 更难，因为源、流、存储、下游 API 都可能重复。

加分版：

• 不要把“组件内部 Exactly-Once”误认为“整个系统 Exactly-Once”。
• 面试里可以直接说：业务上最稳的方案通常是“允许重复、但不允许错账；允许延迟、但不允许丢失”。

3.2 幂等设计

基础版：

• 幂等就是同一请求重复执行多次，结果和执行一次一致。
• 常见手段有业务唯一键、请求 ID、版本号、状态机、去重表。

进阶版：

• 写入幂等常见于 upsert、覆盖写、唯一索引、插入前查重。
• 消息幂等要结合消费位点、业务主键、事件版本、窗口状态来设计。

加分版：

• 只靠“先查再写”不安全，因为并发下会有竞态，必须借助原子约束或事务。
• 高并发场景里，幂等通常要和“乐观锁、唯一约束、版本控制、幂等表 TTL”一起用。

3.3 事务写入与两阶段提交

1
2
3
4
5
6
7
8
9

sequenceDiagram
    participant C as 计算引擎
    participant S as 目标存储
    participant M as Checkpoint/Coordinator
    C->>S: prepare/预写入
    C->>M: checkpoint barrier
    M-->>C: checkpoint 成功
    C->>S: commit/提交
    S-->>C: ack

基础版：

• 两阶段提交分 prepare 和 commit。
• prepare 阶段先把数据写成可提交状态，commit 阶段再正式生效。

进阶版：

• 2PC 的好处是保证跨阶段一致性，坏处是对延迟和故障恢复有要求。
• 流处理里常用“checkpoint + 预提交 + 事务提交”实现端到端一致性。

加分版：

• 2PC 不是银弹，锁持有时间长、协调器故障、长事务都会影响吞吐。
• 工程上要尽量让事务短、提交快、失败可重试、结果可幂等。

3.4 跨系统一致性

核心问题： 一个业务动作同时影响数据库、消息队列、搜索引擎、缓存和数仓时，怎么避免双写不一致。

基础版：

• 常见策略有本地事务 + 事务消息、Outbox、CDC、补偿任务。
• 先落主库，再通过 binlog/CDC 推送到下游，通常比多点同时写更稳。

进阶版：

• 如果一定要双写，必须有幂等键和补偿逻辑。
• 对最终一致的链路，要设计“可重放、可修复、可对账”。

加分版：

• 面试里可以区分“强一致”与“业务一致”。
• 大部分数据平台追求的是业务一致，而不是分布式数据库那种全局强一致。

3.5 数据去重方案

基础版：

• 去重常见于按业务主键、事件 ID、订单号、用户行为 ID 去重。
• 方式包括 DISTINCT、窗口函数、状态去重、唯一键、去重表、Bloom Filter。

进阶版：

• 批处理去重适合全量或大窗口，实时去重适合状态 + TTL。
• 迟到数据会让“窗口内去重”变复杂，需要 watermark 和允许迟到策略。

加分版：

• 真正稳的方案通常不是单点去重，而是“源头唯一键 + 中间状态去重 + 末端幂等”。
• 不要把去重和去重后的更新语义混为一谈，尤其是在 upsert 场景中。

易错点：

• 仅靠 SELECT DISTINCT 不能解决乱序、迟到和重复消费。
• 仅靠缓存去重不能承受重启、扩容和状态恢复。

4. 数据倾斜专题（★★★★★）

4.1 倾斜为什么会出现

一句话结论： 倾斜不是“某个组件坏了”，而是数据分布、Key 设计、算子策略和业务热点叠加的结果。

常见原因包括：

• 热点 Key：某几个用户、商品、地区、设备过于集中。
• join 倾斜：维表/事实表某些 Key 命中次数异常高。
• 聚合倾斜：group by key 分布极不均匀。
• 时间倾斜：某个时间窗口流量暴涨，某些分区爆满。
• 文件/分区倾斜：分区设计不合理，导致少数分区超大。
• 热点写入：RowKey 单调递增或分片键设计差。

4.2 怎么识别倾斜

基础版：

• 看任务耗时是否长尾明显。
• 看单个 task 的 shuffle read/write 是否远高于平均值。

进阶版：

• Spark 看某些 task runtime、spill、shuffle bytes 是否异常。
• Flink 看 subtask busy/backpressure、checkpoint 延迟、state size 是否偏斜。
• Hive 看 reducer 数量是否少而重，或者个别 reducer 特别慢。

加分版：

• 识别倾斜时不能只看 CPU，要同时看 IO、网络、内存、状态和磁盘 spill。
• 如果一个任务只有一个分区慢，通常不是“机器慢”，而是“数据不均”。

4.3 各组件中的不同表现

Hive：

• 常见表现是某几个 reducer 特别慢，整个 SQL 被尾部拖住。
• 解决通常是 map join、skew join、分桶、预聚合、开启 skew 处理。

Spark：

• 常见表现是少数 partition 特别大，导致长尾 task。
• 可用 AQE、skew join、broadcast join、repartition by range、salting。

Flink：

• 常见表现是某几个 key group 的状态和吞吐过高。
• 需要从 key 设计、算子并行度、局部聚合、状态拆分、异步下沉解决。

HBase：

• 常见表现是少数 region 热点，写入和读取都打爆同一台 RegionServer。
• 关键在 RowKey 设计、预分裂、盐值、反转时间戳、负载均衡。

ClickHouse：

• 常见表现是某些 shard、某些分区、某些聚合阶段特别慢。
• 常用策略是更合理的 shard key、两阶段聚合、物化视图预聚合、避免超大单分区。

4.4 通用解决方案

基础版：

• 加盐：给热点 Key 扩散成多个子 Key。
• 预聚合：先在局部做一次聚合，再做全局聚合。
• 广播：小表 broadcast，避免大 shuffle join。

进阶版：

• 拆分热点 Key：把一个热点 Key 拆成多个逻辑子桶。
• 两阶段处理：先分散计算，再汇总结果。
• 分区重设计：按更均匀的维度切分数据。

加分版：

• 不要只想着“调参数”，更重要的是把业务 Key 设计好。
• 最好的倾斜治理是“从模型上避免热点”，而不是“事后补救”。

4.5 组件专属方案

• Hive：map join、skew join、bucket map join、开启倾斜优化。
• Spark：AQE、skew join、broadcast join、salting、repartitionByRange。
• Flink：key 设计优化、局部聚合、热 key 拆分、异步外部存储、调整并行度。
• HBase：预分裂、散列前缀、反转时间戳、region 手工干预。
• ClickHouse：合理 shard key、避免超大分区、预聚合、分层物化视图。

4.6 设计层面如何规避

核心思路：

• 避免把“高频热点”设计成单点 Key。
• 避免用单调递增字段直接做主分片键。
• 避免把所有流量压到一个窗口、一个分区、一个任务上。

加分点：

• 设计时就要评估 Key 分布、QPS 热点、时间热点、状态规模。
• 任何“看起来很自然”的业务键，都可能在规模放大后变成热点键。

5. 存储与计算优化专题（★★★★★）

5.1 存储格式选型

一句话结论： 列式适合分析，行式适合写入和点查，混合存储适合同时兼顾写和读。

• Parquet：通用列式，压缩和扫描性能好，OLAP 场景最常见。
• ORC：Hive 生态里很常见，列式和统计信息支持好。
• Avro：更适合行式交换和 Schema 演进，不适合重分析。
• 行式：适合事务写入、消息记录、逐条读写。

面试怎么说：

• 只要是大宽表、聚合分析、范围扫描，优先考虑列式。
• 只要是高频单行写、点查、事务更新，优先考虑行式或行列混合。

5.2 压缩策略

基础版：

• Snappy：速度快，压缩率一般，适合实时和通用场景。
• ZSTD：压缩率和速度都不错，越来越常见。
• Gzip：压缩率高，但 CPU 开销大，不适合高吞吐在线链路。

进阶版：

• 压缩不是越强越好，要看 CPU、IO、网络和查询延迟的整体平衡。
• 列式文件通常配合字典编码、RLE、Delta、Bit-packing 等编码方式。

5.3 分区 / 分桶 / 分片设计

分区：

• 适合做大范围裁剪，常见按日期、小时、地区、业务域。
• 分区字段要低到中等基数，避免爆炸式分区。

分桶 / 分片：

• 适合解决 join 和并行度问题。
• 常按用户 ID、订单 ID、设备 ID、商户 ID 等稳定键来做 hash。

加分版：

• 分区负责“少扫”，分桶负责“好并行、好 join”。
• 真正成熟的表设计会同时考虑查询裁剪、数据分布和写入代价。

5.4 冷热数据分层

基础版：

• 热数据：最近数据，访问频繁，放低延迟存储。
• 冷数据：历史数据，少访问，放低成本存储。

进阶版：

• 热冷分层通常和生命周期、归档、压缩、清理联动。
• 如果业务有回放和审计要求，冷数据不能直接删掉，只能迁移。

5.5 小文件治理

为什么会有小文件：

• 流式写入频繁滚动。
• 分区过细。
• 任务并发过高、单次写入量太小。

治理手段：

• 合并写入批次，调大滚动阈值。
• 后台 compaction / merge。
• 降低过度并行，按分区聚合后再落盘。
• 通过 table service、异步合并、定期压缩解决。

易错点：

• 小文件治理不是只靠离线合并，写入侧就要控制文件生成策略。

5.6 计算引擎选型

• Spark：批处理、ETL、宽表加工、SQL 分析、离线重算。
• Flink：低延迟流处理、状态计算、实时聚合、事件驱动。
• Hive：传统离线 SQL、重资产 Hadoop 生态、兼容性场景。
• ClickHouse：高并发 OLAP、明细检索、聚合查询、实时报表。
• Trino / Presto：联邦查询、多源 SQL 统一入口。

5.7 并行度设计

基础版：

• 并行度不是越大越好，太小吃不满资源，太大增加调度和 shuffle 开销。

进阶版：

• 并行度要结合 source 分片数、shuffle key 分布、sink 承载能力、状态大小来定。
• 流式任务要考虑 checkpoint、backpressure 和 state backend 能力。

5.8 内存管理

核心关注点：

• 执行内存、存储内存、状态内存、堆外内存、spill、GC。

面试回答：

• 内存优化不是单纯“加机器”，而是减少 shuffle、减少宽行、减少对象数、减少序列化开销。

5.9 序列化优化

基础版：

• 避免 Java 原生序列化。
• 优先用 Avro、Protobuf、Kryo 等更高效的序列化方式。

进阶版：

• 序列化优化和 schema 设计、字段裁剪、网络传输、状态存储都有关。
• 线上性能差的时候，往往不是 SQL 慢，而是对象创建和序列化太重。

6. 实时与离线架构专题（★★★★★）

6.1 离线架构流程

1
2
3
4
5
6
7

flowchart LR
    A["业务库/日志/埋点"] --> B["采集<br/>CDC/ETL/Batch"]
    B --> C["ODS"]
    C --> D["DWD"]
    D --> E["DWS"]
    E --> F["ADS"]
    F --> G["BI/报表/画像/特征/导出"]

离线链路特点：

• 适合全量、回补、历史分析、复杂 join、大宽表构建。
• 优点是吞吐高、成本相对可控、逻辑复杂度容易收敛。
• 缺点是延迟较高，不适合秒级业务。

6.2 实时架构流程

1
2
3
4
5
6

flowchart LR
    A["数据源"] --> B["Kafka / Pulsar"]
    B --> C["Flink / Streaming"]
    C --> D["实时湖仓 / OLAP / KV / Search"]
    D --> E["实时看板 / 风控 / 推荐 / 告警"]
    C --> F["维表服务 / 配置中心 / 特征服务"]

实时链路特点：

• 核心是低延迟、可恢复、可重放、可观测。
• 一般需要关注 watermark、checkpoint、状态大小、消费堆积和下游写入能力。

6.3 流批一体架构

一句话结论： 流批一体不是“一个任务同时跑所有逻辑”，而是“同一套数据模型、同一套口径、流批共同服务”。

加分回答：

• 实时负责新鲜度，离线负责准确性和回补。
• 两条链路共享指标定义、维表版本、质量规则和元数据。
• 真正难的是“同口径”，不是“同 SQL”。

6.4 Lambda 架构 vs Kappa 架构

1
2
3
4
5
6
7
8

flowchart TB
    A["Lambda"] --> B["Batch Layer<br/>全量准确"]
    A --> C["Speed Layer<br/>实时增量"]
    B --> D["Serving Layer"]
    C --> D
    E["Kappa"] --> F["Unified Log / Stream"]
    F --> G["Streaming Compute"]
    G --> H["Serving / Lakehouse"]

Lambda：

• 优点：批流分离，准确性和实时性都有兜底。
• 缺点：双链路维护成本高，口径容易不一致。

Kappa：

• 优点：逻辑更统一，开发运维成本更低。
• 缺点：对日志回放、状态恢复、流处理能力要求更高。

面试结论：

• 现在大多数新平台更偏 Kappa 思想或“流批统一”的演进方案。
• 只在强历史重算、批处理很重、组织能力不足时，Lambda 仍然有现实价值。

6.5 数据流转链路、口径统一、延迟保障

口径统一怎么做：

• 指标中心化定义。
• 维表版本化管理。
• 统一时间语义和业务日历。
• 统一过滤条件和去重规则。

延迟保障怎么做：

• 减少大 shuffle、热点 key、复杂 UDF。
• 使用预聚合、局部聚合、异步 I/O。
• 合理设置并行度、checkpoint 间隔、batch size、sink flush 策略。

6.6 高可用设计

关键点：

• 消息层要有副本、ISR、消费组重平衡和重放能力。
• 计算层要有 checkpoint/savepoint、leader 选举、failover。
• 存储层要有副本、快照、元数据备份和恢复演练。
• 服务层要有熔断、降级、限流和只读兜底。

7. 集群与运维专题（★★★★）

7.1 集群高可用方案

基础版：

• 主从切换、双副本、多副本、心跳检测、故障转移。

进阶版：

• NameNode / ResourceManager / JobManager / Metadata Service 这类核心节点都要做主备。
• 数据层要优先考虑副本、检查点、快照和重放。

加分版：

• 真正的 HA 不是“挂了能切”，而是“切了后语义还对、数据还在、业务还能稳住”。

7.2 扩容缩容

• 扩容前先看资源瓶颈：CPU、内存、IO、网络、状态、磁盘。
• 扩容后要重新平衡分片、分区、region、任务并行度。
• 缩容要先迁移热点数据和状态，避免直接摘机器导致雪崩。

7.3 监控体系

至少要看四层：

• 基础设施：CPU、内存、磁盘、网络、GC。
• 引擎层：checkpoint、lag、shuffle、spill、watermark、task 长尾。
• 数据层：行数、分区数、迟到率、重复率、质量规则。
• 业务层：指标波动、看板延迟、风控误报率、接口 SLA。

7.4 备份恢复

• 配置要备份。
• 元数据要备份。
• 核心表要有快照和恢复演练。
• 恢复要验证口径、版本和权限。

7.5 容灾设计

基础版：

• 同机房高可用解决的是“单点故障”。
• 异地容灾解决的是“机房级故障”。

进阶版：

• 要区分 RPO 和 RTO。
• 容灾方案常见有主备、双活、异步复制、只读热备。

7.6 权限控制、版本升级、故障自愈

• 权限控制要做 RBAC、最小权限、审计。
• 版本升级要看兼容矩阵、先灰度、再全量、可回滚。
• 故障自愈要有健康检查、自动重启、任务迁移、异常隔离和告警联动。

8. 高频对比选型面试专项

8.1 Hadoop vs Spark vs Flink

面试结论： Hadoop 更像“底座”，Spark 更像“通用计算引擎”，Flink 更像“实时状态计算引擎”。

8.2 Hive vs ClickHouse vs Spark SQL

面试结论： Hive 偏离线，ClickHouse 偏查询服务，Spark SQL 偏计算加工。

8.3 HBase vs Cassandra vs MongoDB

面试结论： HBase 更适合“按 RowKey 精准查和写”，Cassandra 更适合“高可用高写入”，MongoDB 更适合“文档与灵活 Schema”。

8.4 Spark Streaming vs Flink vs Kafka Streams

面试结论： 新项目一般优先 Flink；Kafka Streams 适合贴近业务服务；Spark Streaming 现在更多是历史兼容。

8.5 Elasticsearch vs Solr vs ClickHouse

面试结论： 搜索选 ES/Solr，分析选 ClickHouse；如果一个系统想两头都占，通常需要明确主次。

8.6 Iceberg vs Paimon vs Hudi

选型话术：

• 如果要多引擎统一和标准化，优先 Iceberg。
• 如果要实时 CDC、主键表、Flink 生态，优先 Paimon。
• 如果已有 Hudi 生态或更强调 upsert 和表服务，可以选 Hudi。

8.7 Lambda vs Kappa

面试结论： 新平台大多更偏 Kappa 思想，但在复杂历史重算和组织分工不成熟的环境里，Lambda 仍然能落地。

8.8 行存 vs 列存 vs 行列混合

8.9 批处理 vs 流处理 vs 流批一体

9. 综合场景设计面试专项

9.1 设计亿级用户行为分析平台（实时 + 离线）

目标： 同时支持秒级看板、日级报表、用户画像、推荐特征和历史回放。

推荐架构：

• 采集层：埋点 SDK、日志采集、CDC。
• 消息层：Kafka 作为统一事件总线。
• 实时层：Flink 做实时清洗、聚合、特征生成。
• 离线层：Spark 做重算、补数、历史宽表构建。
• 存储层：Iceberg / Paimon / ClickHouse 组合。

关键设计：

• 统一事件 ID、用户 ID、时间语义。
• 实时负责新鲜度，离线负责准确性和重放。
• 画像和特征要可回溯、可版本化、可补数。

常见追问：

• 如何处理埋点重复和乱序。
• 如何保证实时和离线口径一致。
• 如何做热点用户和高峰流量治理。

9.2 设计实时风控与反欺诈系统

目标： 低延迟地识别可疑交易、可疑登录、异常设备和高风险行为。

推荐架构：

• Kafka 接入交易事件、设备事件、登录事件。
• Flink 做规则流、特征流、状态匹配和窗口聚合。
• 实时特征写入 Redis / HBase / Paimon / Online Feature Store。
• 决策层把规则评分、模型评分、黑白名单、历史画像融合。

关键设计：

• 规则引擎和模型评分要分层，不要把所有逻辑塞一个 SQL。
• 状态要设计 TTL，避免无界增长。
• 需要支持低延迟查询、快速回滚和人工审核。

常见追问：

• 如何防重复告警。
• 如何处理迟到事件。
• 如何做规则版本切换和灰度发布。

9.3 设计企业级湖仓一体数据平台

目标： 统一存储、统一治理、统一元数据、统一多引擎访问。

推荐架构：

• 存储层：对象存储 + Iceberg/Paimon/Hudi。
• 计算层：Spark + Flink + Trino + ClickHouse。
• 治理层：Catalog、权限、血缘、质量、生命周期。
• 服务层：BI、API、特征服务、数据共享。

关键设计：

• 统一 Catalog 和命名空间。
• Schema 演进、分区演进、版本回溯都要支持。
• 读写分离、多引擎并发访问要考虑锁、元数据一致性和提交协议。

常见追问：

• 为什么选 Iceberg / Paimon / Hudi。
• 如何支持增量消费。
• 如何做表级权限和审计。

9.4 设计海量日志存储与检索分析系统

目标： 支持日志接入、检索、聚合、问题排查、可观测分析。

推荐架构：

• 接入层：Agent / Log Shipper。
• 消息层：Kafka。
• 存储层：对象存储 + ClickHouse + Elasticsearch 组合。
• 查询层：全文检索用 ES/Solr，聚合分析用 ClickHouse。

关键设计：

• 日志要标准化字段，至少包含 trace_id、service、level、timestamp、host、env。
• 热日志放近线系统，冷日志归档到湖。
• 检索和分析分工明确，不要强求一个引擎全做。

9.5 设计高并发订单 / 交易数据存储与处理架构

目标： 保证写入不丢、订单状态可追踪、查询低延迟、账实一致。

推荐架构：

• 交易主库负责强一致写入。
• CDC 推送到 Kafka。
• Flink 处理状态流、对账流、指标流。
• HBase / Cassandra / Kafka + Lakehouse 负责高并发查询和分析侧扩展。

关键设计：

• 订单号、流水号、状态机必须设计唯一键和版本号。
• 对账和补偿链路要独立于主交易链路。
• 幂等是底线，重复消息不能重复扣款。

9.6 设计物联网海量设备数据实时处理平台

目标： 接入海量设备上报，支持状态监控、告警、轨迹分析和设备画像。

推荐架构：

• 设备 -> MQ -> Flink -> 实时存储 + 湖仓。
• 设备维表、区域维表、协议维表独立管理。
• 终端状态和告警结果写入 KV / OLAP / 搜索引擎。

关键设计：

• 设备 ID 是天然热点候选，要防倾斜。
• 需要处理离线设备、断线重连、乱序上报和批量补报。
• 状态过期和设备生命周期要关联。

9.7 解决高并发写入 + 海量存储 + 低延迟查询

推荐思路：

• 写入层用 Kafka / CDC 做缓冲。
• 存储层用分层架构：热层 OLAP/KV，冷层湖仓。
• 查询层按场景分流：明细走 OLAP 或搜索，历史走湖，点查走 KV。

关键点：

• 不要让一个系统同时承担所有负载。
• 热点写入要通过分片、哈希、预聚合和异步合并拆掉。

9.8 设计数据中台的统一存储与计算层架构

推荐答案：

• 存储统一：对象存储 + 开放表格式。
• 计算统一：批流统一的执行引擎组合。
• 语义统一：指标中心、维表中心、血缘中心。
• 治理统一：权限、质量、审计、生命周期。

加分点：

• 数据中台不是“做一个大仓库”，而是“把数据能力产品化”。
• 最重要的是减少重复加工和重复口径。

9.9 设计跨集群 / 跨机房的数据同步与容灾方案

推荐架构：

• 源集群通过 CDC / Mirror / Replication 进入中转层。
• 中转层保留可重放日志和校验信息。
• 目标集群按延迟等级做异步复制或准实时同步。

关键设计：

• 要明确 RPO / RTO。
• 关键链路要支持回放和对账。
• 需要预案：切流、回切、双写冲突、版本回滚。

9.10 设计数据质量与数据治理体系方案

推荐回答：

• 先有标准：指标口径、数据字典、血缘、分层规范。
• 再有规则：完整性、准确性、时效性、唯一性、一致性。
• 再有闭环：发现、告警、定位、修复、复盘、知识沉淀。

加分点：

• 治理不是一次性项目，而是持续运营。
• 最好的治理结果是“问题越来越少，口径越来越统一，使用越来越简单”。

10. 面试速背清单

10.1 一句话定论

• 数仓分层的核心是解耦、复用和统一口径。
• 维度建模适合分析，范式建模适合一致性。
• SCD 解决的是历史怎么保留的问题。
• Exactly-Once 是逻辑语义，不是魔法。
• 幂等是高并发数据系统的底线。
• 倾斜的本质是分布不均，不是机器不够快。
• 列存适合分析，行存适合写入，混合存储适合混合负载。
• 实时链路追求低延迟，离线链路追求可重算和全量准确。
• 湖仓一体的关键是开放格式 + 多引擎 + 治理。

10.2 常见追问准备

• 为什么不用一个表直接给所有人查。
• 为什么不用双写而要走 CDC。
• 为什么实时和离线会有口径差。
• 为什么热点 key 会拖垮整条链路。
• 为什么某些场景要选 Iceberg，某些场景要选 Paimon。

11. 官方版本参考

以下是本文版本线和趋势判断时参考的官方页面，适合你后续继续查最新变化：

• Spark：downloads
• Flink：downloads
• Hadoop：releases
• Kafka：downloads
• Iceberg：latest docs
• Paimon：1.4 stable docs
• Hudi：releases
• ClickHouse：changelog
• HBase：downloads
• Cassandra：download
• Solr：downloads
• MongoDB：release notes
• Elasticsearch：downloads

12. 复习建议

如果你要把这份手册真正背下来，最有效的方法不是一页页看，而是按题型刷：

1. 先把“数据仓库专题”和“实时一致性专题”背熟。
2. 再把“数据倾斜”和“存储优化”刷成条件反射。
3. 再用“对比选型”训练自己的结论表达。
4. 最后用“综合场景设计”练架构完整度和取舍能力。

真正的大厂面试，通常不是看你会不会背定义，而是看你能不能在约束下做出稳定、可解释、可运维的系统设计。

__END__