海量数据常见面试问题及详细解答

使用方法

每道题都按 4 层复习：

1. 小白解释：先让自己真正理解。
2. 专业回答：面试时直接讲。
3. 原理补充：面试官追问时展开。
4. 常见坑：体现工程经验。

1. 什么是海量数据处理？

小白解释

海量数据处理就是数据太多，单机内存、单机磁盘、单个数据库或单个程序已经处理不过来，需要把数据切成很多份，放到多台机器上并行存储和计算。

专业回答

海量数据处理不是单纯"数据量大"，而是数据规模、写入速度、计算复杂度、查询并发、时效性和治理复杂度同时上升后的系统工程。

典型链路包括数据采集、消息缓冲、分布式存储、批处理、流处理、交互式查询、任务调度、数据质量、血缘治理和监控告警。

核心思想是分而治之，通过分区、并行、压缩、索引、预聚合、状态管理和容错机制，把单机无法承受的问题拆到分布式系统里解决。

原理补充

海量数据系统通常依赖四个基本能力：

1. 横向扩展：增加机器提升吞吐和容量。
2. 数据分区：把数据按 key、时间、业务维度切分。
3. 并行计算：多个任务同时处理不同分区。
4. 容错恢复：机器失败后能从副本、日志或 Checkpoint 恢复。

常见坑

数据量大不一定要上大数据平台。先看问题是写入瓶颈、查询瓶颈、计算瓶颈、存储瓶颈还是治理瓶颈。

2. 海量数据系统和普通 Java 后端系统有什么区别？

小白解释

普通后端更像"一个用户请求来了，我快速返回结果"。海量数据更像"每天来了几十亿条记录，我要稳定地收进来、算出来、查出来，而且失败后还能恢复"。

专业回答

Java 后端系统通常关注请求级低延迟、事务一致性、接口可用性和业务逻辑封装。

海量数据系统更关注吞吐、端到端延迟、分区并行、数据重放、批流计算、状态一致性、数据倾斜、存储成本、查询性能和数据治理。

两者底层都是分布式系统，但性能指标和设计重点不同。

原理补充

后端系统的关键指标：

1. RT。
2. QPS。
3. 错误率。
4. 可用性。

海量数据系统的关键指标：

1. 每秒写入条数。
2. 每秒处理事件数。
3. 数据端到端延迟。
4. 任务成功率。
5. Checkpoint 时长。
6. 查询 P95 延迟。
7. 存储压缩比。
8. 数据质量通过率。

3. Kafka 为什么适合做海量数据入口？

小白解释

Kafka 像一个高吞吐的"数据中转站"。上游系统把数据先写进去，下游系统慢慢消费。即使下游暂时处理不过来，数据也不会马上丢。

专业回答

Kafka 适合做海量数据入口，主要因为它是基于分区日志的分布式消息系统，具备高吞吐、可扩展、持久化、可回放和消费组并行消费能力。

Producer 可以批量写入多个 Partition，Broker 顺序追加日志，Consumer Group 可以按分区并行消费，Offset 记录消费进度。它既能削峰填谷，也能解耦上下游系统。

原理补充

Kafka 的关键设计：

1. Topic 是逻辑主题。
2. Partition 是并行和顺序性的基本单位。
3. 每个 Partition 内部是有序追加日志。
4. Consumer Group 内一个 Partition 同一时刻通常由一个 Consumer 消费。
5. Offset 表示消费位置。
6. 副本和 ISR 提供可靠性。
7. 批量发送、页缓存、顺序写提升吞吐。

常见坑

1. Partition 数不是越多越好，太多会增加元数据、文件句柄和 Rebalance 成本。
2. Kafka 只能保证单个 Partition 内有序，不能天然保证全局有序。
3. 重复消费是常见现象，下游必须做幂等。
4. 消息堆积要看生产速度、消费速度、分区数、消费者并行度和下游写入能力。

4. 如何设计 Kafka Topic 的分区数？

小白解释

分区数决定可以有多少消费者并行干活。分区少，并行度不够；分区太多，管理成本变高。

专业回答

分区数要结合目标吞吐、消费者并行度、消息顺序性、未来扩展和集群资源来设计。

如果业务要求同一个用户的事件有序，可以按 userId 作为 key，让同一用户落到同一分区。如果追求吞吐，可以增加分区数，但要评估 Broker 文件句柄、Controller 元数据、Consumer Rebalance 和小分区带来的运维成本。

原理补充

常见估算方式：

分区数 >= 目标吞吐 / 单分区稳定吞吐
分区数 >= 最大消费者并行度

但最终要压测验证，因为吞吐受消息大小、压缩方式、ack、磁盘、网络、Broker 数量影响。

5. Kafka 如何保证消息不丢？

小白解释

要让消息不丢，需要生产者确认写入成功，Kafka 多副本保存，消费者处理完再提交进度。

专业回答

Kafka 防止消息丢失需要从 Producer、Broker、Consumer 三端一起设计。

Producer 侧使用 acks=all、合理重试、幂等生产者。

Broker 侧设置副本数、最小 ISR、数据刷盘和监控。

Consumer 侧关闭自动提交或谨慎使用自动提交，确保业务处理成功后再提交 Offset。

原理补充

核心不是"Kafka 一个参数保证不丢"，而是端到端语义：

1. 写入端确认。
2. Broker 副本可靠。
3. 消费端处理成功。
4. Sink 写入幂等。
5. Offset 提交时机正确。

6. 什么是 Flink 的 Watermark？

小白解释

Watermark 是 Flink 判断"某个时间点以前的数据基本到齐了"的水位线。

例如窗口统计 10:00 到 10:05 的订单，但网络可能导致 10:03 的订单晚到。Watermark 就是告诉系统："我认为 10:05 之前的数据差不多到了，可以触发计算了。"

专业回答

Watermark 是事件时间语义下推进计算进度的机制，用来处理乱序数据和迟到数据。

Flink 通过 Watermark 判断窗口是否可以触发。当 Watermark 超过窗口结束时间，窗口计算可以执行。允许迟到时间可以让部分晚到数据继续修正结果。

原理补充

时间语义有三类：

1. Event Time：事件真实发生时间。
2. Ingestion Time：进入系统时间。
3. Processing Time：机器处理时间。

海量实时系统常用 Event Time，因为业务关心事件真实发生时间，而不是机器什么时候看到它。

常见坑

Watermark 设置太激进，会导致迟到数据变多。

Watermark 设置太保守，会导致窗口迟迟不触发，端到端延迟升高。

7. Flink 的 Checkpoint 是什么？

小白解释

Checkpoint 就像游戏存档。程序运行一段时间后，把当前处理到哪里、状态是什么保存下来。如果机器挂了，就从最近一次存档恢复。

专业回答

Checkpoint 是 Flink 实现故障恢复和状态一致性的核心机制。

Flink 会周期性地对算子状态和输入位置做一致性快照。任务失败后，作业从最近成功的 Checkpoint 恢复状态，并从对应的 source offset 继续消费。

原理补充

Checkpoint 能支持 Exactly Once 的前提是：

1. Source 可重放，比如 Kafka。
2. Flink 状态能持久化。
3. Sink 支持事务提交或幂等写入。

如果 Sink 不支持事务或幂等，即使 Flink 内部状态 Exactly Once，最终外部结果也可能重复。

8. Exactly Once 是不是绝对只处理一次？

小白解释

不是物理上只执行一次，而是最终结果看起来像只执行了一次。

专业回答

Exactly Once 通常指端到端的结果一致性语义，而不是每条数据在物理执行过程中绝不重试。

在分布式系统中，失败重试很常见。Exactly Once 的关键是通过可重放 Source、一致性状态快照、事务 Sink 或幂等 Sink，让最终结果不多不少。

常见坑

面试中不要说"Flink 天然保证端到端 Exactly Once"。

正确说法是：

Flink 内部状态可以通过 Checkpoint 实现 Exactly Once，但端到端还取决于 Source 和 Sink。
如果 Source 可重放、Sink 支持两阶段提交或幂等写入，才能实现端到端 Exactly Once。

9. Spark 为什么会有 Shuffle？

小白解释

当数据需要按新的规则重新分组时，就要把不同机器上的数据重新搬运，比如按用户统计订单金额，就要把同一个用户的数据放到一起。

专业回答

Shuffle 是分布式计算中按 key 重新分区和跨节点传输数据的过程。

在 Spark 中，groupByKey、reduceByKey、join、distinct、orderBy 等操作通常会触发 Shuffle。Shuffle 会带来网络传输、磁盘落盘、序列化和内存压力，是 Spark 性能优化的重点。

原理补充

窄依赖不需要大量跨节点数据移动。

宽依赖需要上游多个分区的数据重新分发到下游多个分区，因此触发 Shuffle。

常见坑

1. 能用 reduceByKey 就不要随便用 groupByKey。
2. 大表 Join 大表要重点关注倾斜。
3. Shuffle 分区数过少会导致单任务压力大，过多会导致任务调度开销大。

10. 什么是数据倾斜？怎么解决？

小白解释

数据倾斜就是大家一起干活，但某个人分到的活特别多，导致所有人都要等他。

专业回答

数据倾斜是指在分布式计算中，某些 key 或分区的数据量远大于其他分区，导致少数任务运行时间极长，拖慢整体作业。

解决思路包括识别倾斜 key、过滤异常 key、加盐打散、两阶段聚合、广播 Join、拆分热点 key、调整分区策略和优化数据模型。

原理补充

常见方案：

1. 聚合倾斜：对热点 key 加随机前缀，先局部聚合，再去掉前缀二次聚合。
2. Join 倾斜：小表广播，大表避免 Shuffle。
3. 热点 key：单独拆出来特殊处理。
4. 数据模型：提前预聚合或改分区键。

面试表达

数据倾斜不能只靠调大资源解决。我的处理顺序是先用执行计划和任务耗时定位倾斜分区，再看倾斜 key 分布，然后按场景选择加盐、两阶段聚合、广播 Join、热点拆分或模型调整。

11. 数据湖、数据仓库、湖仓一体有什么区别？

小白解释

数据湖像大仓库，什么数据都能先放进去。

数据仓库像整理好的货架，结构清晰，方便分析。

湖仓一体是既能低成本保存大量原始数据，又能像数仓一样管理表、事务和查询。

专业回答

数据湖强调低成本、开放格式和原始数据沉淀，但早期数据湖容易出现元数据混乱、质量不可控和事务能力不足。

数据仓库强调结构化建模、查询性能和数据质量，但成本较高，扩展灵活性较弱。

湖仓一体通过 Iceberg、Delta Lake、Hudi 等表格式，在对象存储或 HDFS 之上提供 ACID、快照、Schema 演进、分区演进和 Time Travel，让数据湖具备接近数仓的管理能力。

12. Iceberg、Delta Lake、Hudi 怎么选？

小白解释

它们都想把数据湖里的文件管理成"可靠的数据表"，只是侧重点不同。

专业回答

Iceberg 更强调开放表格式、隐藏分区、Schema 演进、分区演进和多引擎兼容，适合开放湖仓和大规模分析表。

Delta Lake 强调事务日志、ACID、Time Travel 和与 Spark 生态结合，适合 Spark 或 Databricks 生态较强的团队。

Hudi 强调 Upsert、Delete、增量拉取和近实时写入，适合 CDC、频繁更新和增量处理场景。

面试表达

我不会简单说谁更好，而是看场景。
如果强调开放生态、多引擎读写和大规模表演进，我倾向 Iceberg。
如果团队 Spark 生态强，追求事务日志和 Time Travel，Delta Lake 很顺。
如果是 CDC、Upsert、近实时入湖和增量消费，Hudi 的能力更匹配。

13. 为什么 MySQL 不适合做海量 OLAP？

小白解释

MySQL 更适合查一条或少量业务记录。海量 OLAP 经常要扫很多列、很多行，做分组统计和聚合，MySQL 会很吃力。

专业回答

MySQL 是典型 OLTP 数据库，适合高并发点查、事务更新和业务系统读写。

海量 OLAP 查询通常需要扫描大量数据、列式读取、向量化执行、分布式并行、预聚合和物化视图。ClickHouse、Doris、StarRocks 这类 OLAP 引擎更适合。

原理补充

OLTP 关注：

1. 行存。
2. 事务。
3. 点查。
4. 高频更新。

OLAP 关注：

1. 列存。
2. 批量扫描。
3. 聚合分析。
4. MPP 并行。
5. 压缩和索引。

14. ClickHouse 为什么查询快？

小白解释

ClickHouse 把同一列的数据放在一起，查询只读需要的列；并且它会压缩、排序、跳过不需要的数据块，还能用多核并行计算。

专业回答

ClickHouse 的性能来自列式存储、MergeTree 表引擎、稀疏主键索引、数据跳过索引、压缩、向量化执行和并行计算。

它特别适合追加写、多维聚合、明细宽表分析和低延迟报表查询。

常见坑

1. ClickHouse 不适合高频小事务更新。
2. 主键不是传统数据库的唯一约束。
3. 排序键设计会直接影响查询性能。
4. 小批量频繁写入会造成过多小 Part，影响合并和查询。

15. 什么是 MPP？

小白解释

MPP 就是很多机器一起算一个查询，每台机器算一部分，最后汇总结果。

专业回答

MPP 是 Massively Parallel Processing，大规模并行处理。

在 OLAP 系统中，一个 SQL 会被拆成多个执行片段，下发到多个节点并行扫描、过滤、聚合、Join，最后汇总返回。Doris、StarRocks、Trino 等都使用 MPP 思想。

原理补充

MPP 查询性能依赖：

1. 数据分布是否合理。
2. 谓词下推是否有效。
3. Join 顺序是否合理。
4. 是否能减少网络 Shuffle。
5. 是否能用物化视图或预聚合。

16. 海量数据链路如何做数据质量？

小白解释

数据质量就是保证数据没有少、没有重复、字段合法、口径一致、延迟可控。

专业回答

数据质量要覆盖采集、传输、计算、存储和查询全链路。

常见措施包括 Schema 校验、非空校验、枚举值校验、主键唯一性、数据量波动检测、延迟检测、对账、血缘追踪、异常隔离、告警和补数机制。

面试表达

我会把数据质量作为平台能力，而不是每个任务各自写一套校验。核心指标包括完整性、准确性、一致性、及时性和唯一性。异常数据要能隔离、告警、追踪和重放。

17. 海量数据系统如何做成本优化？

小白解释

数据越多，机器和存储越贵。成本优化就是用更少资源完成同样的计算和查询。

专业回答

成本优化可以从存储、计算、查询、调度和治理五个方面做。

存储侧做冷热分层、压缩、生命周期管理、小文件合并。

计算侧做资源队列、动态资源、增量计算、任务合并、避免重复计算。

查询侧做分区裁剪、列裁剪、物化视图、预聚合、缓存。

调度侧做错峰执行、SLA 分级和失败重试策略。

治理侧清理无主任务、无用表、重复指标和低价值数据。

18. 研发经理如何管理海量数据团队？

小白解释

不只是安排人写任务，还要让数据链路稳定、任务可监控、指标口径统一、问题能追责、成本可控制。

专业回答

我会按平台能力管理团队：

1. 数据接入标准化。
2. 计算任务模板化。
3. 指标口径资产化。
4. 调度和补数流程化。
5. 质量校验平台化。
6. 监控告警统一化。
7. 成本和资源透明化。

研发经理要能把一次性项目沉淀成长期可复用的数据平台能力。

19. 如果实时任务延迟突然升高，你怎么排查？

专业回答

我会按链路分层排查：

1. 先看 Kafka 是否堆积，生产速率是否突增。
2. 再看 Flink 是否反压，哪个算子耗时最高。
3. 看 Checkpoint 是否变慢或失败。
4. 看状态大小是否膨胀，RocksDB 是否压力过大。
5. 看 Sink 是否写入变慢，比如 OLAP、数据库、对象存储。
6. 看是否有数据倾斜，某些 key 或分区流量异常。
7. 看集群资源，CPU、内存、网络、磁盘是否瓶颈。

面试加分点

最后补一句：

排查后我会补监控，不只修一次问题。比如补充 Kafka Lag、Flink Backpressure、Checkpoint Duration、Watermark Lag、Sink QPS、失败率和端到端延迟看板。

20. 你如何从 0 到 1 建设海量数据平台？

专业回答

我会分阶段建设。

第一阶段先打通链路：埋点或业务日志进入 Kafka，经 Flink 或 Spark 清洗，落湖仓或 OLAP，能支撑基础报表。

第二阶段做稳定性：补齐监控、告警、重试、死信、回放、补数、幂等和权限。

第三阶段做治理：统一指标口径、数据质量、血缘、元数据、数据分层和生命周期。

第四阶段做平台化：沉淀数据接入模板、任务开发模板、实时指标模板、离线数仓规范和查询服务规范。

第五阶段做成本和效率：资源队列、冷热分层、物化视图、预聚合、任务合并和自动化运维。

海量数据常见面试问题及详细解答

使用方法

每道题都按 4 层复习：

1. 小白解释：先让自己真正理解。
2. 专业回答：面试时直接讲。
3. 原理补充：面试官追问时展开。
4. 常见坑：体现工程经验。

1. 什么是海量数据处理？

小白解释

海量数据处理就是数据太多，单机内存、单机磁盘、单个数据库或单个程序已经处理不过来，需要把数据切成很多份，放到多台机器上并行存储和计算。

专业回答

海量数据处理不是单纯"数据量大"，而是数据规模、写入速度、计算复杂度、查询并发、时效性和治理复杂度同时上升后的系统工程。

典型链路包括数据采集、消息缓冲、分布式存储、批处理、流处理、交互式查询、任务调度、数据质量、血缘治理和监控告警。

核心思想是分而治之，通过分区、并行、压缩、索引、预聚合、状态管理和容错机制，把单机无法承受的问题拆到分布式系统里解决。

原理补充

海量数据系统通常依赖四个基本能力：

1. 横向扩展：增加机器提升吞吐和容量。
2. 数据分区：把数据按 key、时间、业务维度切分。
3. 并行计算：多个任务同时处理不同分区。
4. 容错恢复：机器失败后能从副本、日志或 Checkpoint 恢复。

常见坑

数据量大不一定要上大数据平台。先看问题是写入瓶颈、查询瓶颈、计算瓶颈、存储瓶颈还是治理瓶颈。

2. 海量数据系统和普通 Java 后端系统有什么区别？

小白解释

普通后端更像"一个用户请求来了，我快速返回结果"。海量数据更像"每天来了几十亿条记录，我要稳定地收进来、算出来、查出来，而且失败后还能恢复"。

专业回答

Java 后端系统通常关注请求级低延迟、事务一致性、接口可用性和业务逻辑封装。

海量数据系统更关注吞吐、端到端延迟、分区并行、数据重放、批流计算、状态一致性、数据倾斜、存储成本、查询性能和数据治理。

两者底层都是分布式系统，但性能指标和设计重点不同。

原理补充

后端系统的关键指标：

1. RT。
2. QPS。
3. 错误率。
4. 可用性。

海量数据系统的关键指标：

1. 每秒写入条数。
2. 每秒处理事件数。
3. 数据端到端延迟。
4. 任务成功率。
5. Checkpoint 时长。
6. 查询 P95 延迟。
7. 存储压缩比。
8. 数据质量通过率。

3. Kafka 为什么适合做海量数据入口？

小白解释

Kafka 像一个高吞吐的"数据中转站"。上游系统把数据先写进去，下游系统慢慢消费。即使下游暂时处理不过来，数据也不会马上丢。

专业回答

Kafka 适合做海量数据入口，主要因为它是基于分区日志的分布式消息系统，具备高吞吐、可扩展、持久化、可回放和消费组并行消费能力。

Producer 可以批量写入多个 Partition，Broker 顺序追加日志，Consumer Group 可以按分区并行消费，Offset 记录消费进度。它既能削峰填谷，也能解耦上下游系统。

原理补充

Kafka 的关键设计：

1. Topic 是逻辑主题。
2. Partition 是并行和顺序性的基本单位。
3. 每个 Partition 内部是有序追加日志。
4. Consumer Group 内一个 Partition 同一时刻通常由一个 Consumer 消费。
5. Offset 表示消费位置。
6. 副本和 ISR 提供可靠性。
7. 批量发送、页缓存、顺序写提升吞吐。

常见坑

1. Partition 数不是越多越好，太多会增加元数据、文件句柄和 Rebalance 成本。
2. Kafka 只能保证单个 Partition 内有序，不能天然保证全局有序。
3. 重复消费是常见现象，下游必须做幂等。
4. 消息堆积要看生产速度、消费速度、分区数、消费者并行度和下游写入能力。

4. 如何设计 Kafka Topic 的分区数？

小白解释

分区数决定可以有多少消费者并行干活。分区少，并行度不够；分区太多，管理成本变高。

专业回答

分区数要结合目标吞吐、消费者并行度、消息顺序性、未来扩展和集群资源来设计。

如果业务要求同一个用户的事件有序，可以按 userId 作为 key，让同一用户落到同一分区。如果追求吞吐，可以增加分区数，但要评估 Broker 文件句柄、Controller 元数据、Consumer Rebalance 和小分区带来的运维成本。

原理补充

常见估算方式：

分区数 >= 目标吞吐 / 单分区稳定吞吐
分区数 >= 最大消费者并行度

但最终要压测验证，因为吞吐受消息大小、压缩方式、ack、磁盘、网络、Broker 数量影响。

5. Kafka 如何保证消息不丢？

小白解释

要让消息不丢，需要生产者确认写入成功，Kafka 多副本保存，消费者处理完再提交进度。

专业回答

Kafka 防止消息丢失需要从 Producer、Broker、Consumer 三端一起设计。

Producer 侧使用 acks=all、合理重试、幂等生产者。

Broker 侧设置副本数、最小 ISR、数据刷盘和监控。

Consumer 侧关闭自动提交或谨慎使用自动提交，确保业务处理成功后再提交 Offset。

原理补充

核心不是"Kafka 一个参数保证不丢"，而是端到端语义：

1. 写入端确认。
2. Broker 副本可靠。
3. 消费端处理成功。
4. Sink 写入幂等。
5. Offset 提交时机正确。

6. 什么是 Flink 的 Watermark？

小白解释

Watermark 是 Flink 判断"某个时间点以前的数据基本到齐了"的水位线。

例如窗口统计 10:00 到 10:05 的订单，但网络可能导致 10:03 的订单晚到。Watermark 就是告诉系统："我认为 10:05 之前的数据差不多到了，可以触发计算了。"

专业回答

Watermark 是事件时间语义下推进计算进度的机制，用来处理乱序数据和迟到数据。

Flink 通过 Watermark 判断窗口是否可以触发。当 Watermark 超过窗口结束时间，窗口计算可以执行。允许迟到时间可以让部分晚到数据继续修正结果。

原理补充

时间语义有三类：

1. Event Time：事件真实发生时间。
2. Ingestion Time：进入系统时间。
3. Processing Time：机器处理时间。

海量实时系统常用 Event Time，因为业务关心事件真实发生时间，而不是机器什么时候看到它。

常见坑

Watermark 设置太激进，会导致迟到数据变多。

Watermark 设置太保守，会导致窗口迟迟不触发，端到端延迟升高。

7. Flink 的 Checkpoint 是什么？

小白解释

Checkpoint 就像游戏存档。程序运行一段时间后，把当前处理到哪里、状态是什么保存下来。如果机器挂了，就从最近一次存档恢复。

专业回答

Checkpoint 是 Flink 实现故障恢复和状态一致性的核心机制。

Flink 会周期性地对算子状态和输入位置做一致性快照。任务失败后，作业从最近成功的 Checkpoint 恢复状态，并从对应的 source offset 继续消费。

原理补充

Checkpoint 能支持 Exactly Once 的前提是：

1. Source 可重放，比如 Kafka。
2. Flink 状态能持久化。
3. Sink 支持事务提交或幂等写入。

如果 Sink 不支持事务或幂等，即使 Flink 内部状态 Exactly Once，最终外部结果也可能重复。

8. Exactly Once 是不是绝对只处理一次？

小白解释

不是物理上只执行一次，而是最终结果看起来像只执行了一次。

专业回答

Exactly Once 通常指端到端的结果一致性语义，而不是每条数据在物理执行过程中绝不重试。

在分布式系统中，失败重试很常见。Exactly Once 的关键是通过可重放 Source、一致性状态快照、事务 Sink 或幂等 Sink，让最终结果不多不少。

常见坑

面试中不要说"Flink 天然保证端到端 Exactly Once"。

正确说法是：

Flink 内部状态可以通过 Checkpoint 实现 Exactly Once，但端到端还取决于 Source 和 Sink。
如果 Source 可重放、Sink 支持两阶段提交或幂等写入，才能实现端到端 Exactly Once。

9. Spark 为什么会有 Shuffle？

小白解释

当数据需要按新的规则重新分组时，就要把不同机器上的数据重新搬运，比如按用户统计订单金额，就要把同一个用户的数据放到一起。

专业回答

Shuffle 是分布式计算中按 key 重新分区和跨节点传输数据的过程。

在 Spark 中，groupByKey、reduceByKey、join、distinct、orderBy 等操作通常会触发 Shuffle。Shuffle 会带来网络传输、磁盘落盘、序列化和内存压力，是 Spark 性能优化的重点。

原理补充

窄依赖不需要大量跨节点数据移动。

宽依赖需要上游多个分区的数据重新分发到下游多个分区，因此触发 Shuffle。

常见坑

1. 能用 reduceByKey 就不要随便用 groupByKey。
2. 大表 Join 大表要重点关注倾斜。
3. Shuffle 分区数过少会导致单任务压力大，过多会导致任务调度开销大。

10. 什么是数据倾斜？怎么解决？

小白解释

数据倾斜就是大家一起干活，但某个人分到的活特别多，导致所有人都要等他。

专业回答

数据倾斜是指在分布式计算中，某些 key 或分区的数据量远大于其他分区，导致少数任务运行时间极长，拖慢整体作业。

解决思路包括识别倾斜 key、过滤异常 key、加盐打散、两阶段聚合、广播 Join、拆分热点 key、调整分区策略和优化数据模型。

原理补充

常见方案：

1. 聚合倾斜：对热点 key 加随机前缀，先局部聚合，再去掉前缀二次聚合。
2. Join 倾斜：小表广播，大表避免 Shuffle。
3. 热点 key：单独拆出来特殊处理。
4. 数据模型：提前预聚合或改分区键。

面试表达

数据倾斜不能只靠调大资源解决。我的处理顺序是先用执行计划和任务耗时定位倾斜分区，再看倾斜 key 分布，然后按场景选择加盐、两阶段聚合、广播 Join、热点拆分或模型调整。

11. 数据湖、数据仓库、湖仓一体有什么区别？

小白解释

数据湖像大仓库，什么数据都能先放进去。

数据仓库像整理好的货架，结构清晰，方便分析。

湖仓一体是既能低成本保存大量原始数据，又能像数仓一样管理表、事务和查询。

专业回答

数据湖强调低成本、开放格式和原始数据沉淀，但早期数据湖容易出现元数据混乱、质量不可控和事务能力不足。

数据仓库强调结构化建模、查询性能和数据质量，但成本较高，扩展灵活性较弱。

湖仓一体通过 Iceberg、Delta Lake、Hudi 等表格式，在对象存储或 HDFS 之上提供 ACID、快照、Schema 演进、分区演进和 Time Travel，让数据湖具备接近数仓的管理能力。

12. Iceberg、Delta Lake、Hudi 怎么选？

小白解释

它们都想把数据湖里的文件管理成"可靠的数据表"，只是侧重点不同。

专业回答

Iceberg 更强调开放表格式、隐藏分区、Schema 演进、分区演进和多引擎兼容，适合开放湖仓和大规模分析表。

Delta Lake 强调事务日志、ACID、Time Travel 和与 Spark 生态结合，适合 Spark 或 Databricks 生态较强的团队。

Hudi 强调 Upsert、Delete、增量拉取和近实时写入，适合 CDC、频繁更新和增量处理场景。

面试表达

我不会简单说谁更好，而是看场景。
如果强调开放生态、多引擎读写和大规模表演进，我倾向 Iceberg。
如果团队 Spark 生态强，追求事务日志和 Time Travel，Delta Lake 很顺。
如果是 CDC、Upsert、近实时入湖和增量消费，Hudi 的能力更匹配。

13. 为什么 MySQL 不适合做海量 OLAP？

小白解释

MySQL 更适合查一条或少量业务记录。海量 OLAP 经常要扫很多列、很多行，做分组统计和聚合，MySQL 会很吃力。

专业回答

MySQL 是典型 OLTP 数据库，适合高并发点查、事务更新和业务系统读写。

海量 OLAP 查询通常需要扫描大量数据、列式读取、向量化执行、分布式并行、预聚合和物化视图。ClickHouse、Doris、StarRocks 这类 OLAP 引擎更适合。

原理补充

OLTP 关注：

1. 行存。
2. 事务。
3. 点查。
4. 高频更新。

OLAP 关注：

1. 列存。
2. 批量扫描。
3. 聚合分析。
4. MPP 并行。
5. 压缩和索引。

14. ClickHouse 为什么查询快？

小白解释

ClickHouse 把同一列的数据放在一起，查询只读需要的列；并且它会压缩、排序、跳过不需要的数据块，还能用多核并行计算。

专业回答

ClickHouse 的性能来自列式存储、MergeTree 表引擎、稀疏主键索引、数据跳过索引、压缩、向量化执行和并行计算。

它特别适合追加写、多维聚合、明细宽表分析和低延迟报表查询。

常见坑

1. ClickHouse 不适合高频小事务更新。
2. 主键不是传统数据库的唯一约束。
3. 排序键设计会直接影响查询性能。
4. 小批量频繁写入会造成过多小 Part，影响合并和查询。

15. 什么是 MPP？

小白解释

MPP 就是很多机器一起算一个查询，每台机器算一部分，最后汇总结果。

专业回答

MPP 是 Massively Parallel Processing，大规模并行处理。

在 OLAP 系统中，一个 SQL 会被拆成多个执行片段，下发到多个节点并行扫描、过滤、聚合、Join，最后汇总返回。Doris、StarRocks、Trino 等都使用 MPP 思想。

原理补充

MPP 查询性能依赖：

1. 数据分布是否合理。
2. 谓词下推是否有效。
3. Join 顺序是否合理。
4. 是否能减少网络 Shuffle。
5. 是否能用物化视图或预聚合。

16. 海量数据链路如何做数据质量？

小白解释

数据质量就是保证数据没有少、没有重复、字段合法、口径一致、延迟可控。

专业回答

数据质量要覆盖采集、传输、计算、存储和查询全链路。

常见措施包括 Schema 校验、非空校验、枚举值校验、主键唯一性、数据量波动检测、延迟检测、对账、血缘追踪、异常隔离、告警和补数机制。

面试表达

我会把数据质量作为平台能力，而不是每个任务各自写一套校验。核心指标包括完整性、准确性、一致性、及时性和唯一性。异常数据要能隔离、告警、追踪和重放。

17. 海量数据系统如何做成本优化？

小白解释

数据越多，机器和存储越贵。成本优化就是用更少资源完成同样的计算和查询。

专业回答

成本优化可以从存储、计算、查询、调度和治理五个方面做。

存储侧做冷热分层、压缩、生命周期管理、小文件合并。

计算侧做资源队列、动态资源、增量计算、任务合并、避免重复计算。

查询侧做分区裁剪、列裁剪、物化视图、预聚合、缓存。

调度侧做错峰执行、SLA 分级和失败重试策略。

治理侧清理无主任务、无用表、重复指标和低价值数据。

18. 研发经理如何管理海量数据团队？

小白解释

不只是安排人写任务，还要让数据链路稳定、任务可监控、指标口径统一、问题能追责、成本可控制。

专业回答

我会按平台能力管理团队：

1. 数据接入标准化。
2. 计算任务模板化。
3. 指标口径资产化。
4. 调度和补数流程化。
5. 质量校验平台化。
6. 监控告警统一化。
7. 成本和资源透明化。

研发经理要能把一次性项目沉淀成长期可复用的数据平台能力。

19. 如果实时任务延迟突然升高，你怎么排查？

专业回答

我会按链路分层排查：

1. 先看 Kafka 是否堆积，生产速率是否突增。
2. 再看 Flink 是否反压，哪个算子耗时最高。
3. 看 Checkpoint 是否变慢或失败。
4. 看状态大小是否膨胀，RocksDB 是否压力过大。
5. 看 Sink 是否写入变慢，比如 OLAP、数据库、对象存储。
6. 看是否有数据倾斜，某些 key 或分区流量异常。
7. 看集群资源，CPU、内存、网络、磁盘是否瓶颈。

面试加分点

最后补一句：

排查后我会补监控，不只修一次问题。比如补充 Kafka Lag、Flink Backpressure、Checkpoint Duration、Watermark Lag、Sink QPS、失败率和端到端延迟看板。

20. 你如何从 0 到 1 建设海量数据平台？

专业回答

我会分阶段建设。

第一阶段先打通链路：埋点或业务日志进入 Kafka，经 Flink 或 Spark 清洗，落湖仓或 OLAP，能支撑基础报表。

第二阶段做稳定性：补齐监控、告警、重试、死信、回放、补数、幂等和权限。

第三阶段做治理：统一指标口径、数据质量、血缘、元数据、数据分层和生命周期。

第四阶段做平台化：沉淀数据接入模板、任务开发模板、实时指标模板、离线数仓规范和查询服务规范。

第五阶段做成本和效率：资源队列、冷热分层、物化视图、预聚合、任务合并和自动化运维。