简介《2023年史上最全的大数据面试题》面向大数据开发、运维、云计算、数据治理与架构岗位的求职者和进阶学习者围绕面试高频考点与技术盲区提供系统梳理。压缩包内为1个docx文档约491KB按Linux与Shell、Hadoop、Zookeeper、Flume、Kafka、Hive、HBase、Sqoop、Scala、Spark等模块分章组织目录层级清晰便于按技术栈检索。内容既覆盖HDFS读写流程、MapReduce Shuffle、YARN作业提交、Hadoop参数调优与数据倾斜处理也延伸到Kafka丢数据与重复消费、Hive窗口函数与自定义函数、HBase RowKey设计、Sqoop数据一致性以及Spark部署模式、宽窄依赖、核心算子、Shuffle流程和TopN调优等。已有882人学习适合面试前集中复盘、工作中查漏补缺也可作为大数据知识体系的复习提纲。1. 大数据面试到底考什么先把 12 个模块的考点范围理清楚大数据面试从来不是比谁的框架清单长。面试官坐在你对面真正想确认的只有三件事你知不知道数据从产生到进仓的完整链路、遇到异常时能不能定位到具体环节、给你一个场景能不能给出可执行的方案。在这份覆盖开发、运维、云计算、数据治理、架构师方向的题目清单里Linux 与 Shell、Hadoop、Zookeeper、Flume、Kafka、Hive、HBase、Sqoop、Scala、Spark、Spark SQL 与 Streaming、Flink、数据倾斜、项目架构与数仓分层、Java 与 JVM、MySQL 与 Redis加起来十几块内容看着吓人但真题分布其实很不均匀Hadoop 读写流程、MapReduce Shuffle、Spark 宽窄依赖与 Shuffle、Hive 优化与数据倾斜、Kafka 丢不丢数据、Flink 的 exactly-once这几处几乎每场必问。适合谁来准备这份题准备跳槽的开发、从业务线转数据平台的运维、刚接触数仓治理的同学都能按模块拆开练。拿分的逻辑不是背完所有答案而是每个模块至少有一个能画图讲清的流程、一个踩坑案例、一组可调的参数。2. Hadoop 与存储层读写流程、Shuffle、YARN 三处最容易问穿这一层的题有个共同特征面试官不需要你背结论他要你从客户端发起请求讲到数据落盘中间每个角色在干什么。流程讲顺了后面的调优题自然接得上流程讲不顺参数题一问就露馅。2.1 HDFS 读流程与写流程按「谁找谁」的顺序讲写流程最容易讲乱。稳妥的讲法是按客户端、NameNode、DataNode 三段推进客户端先向 NameNode 请求创建文件NameNode 校验权限与目录后返回可写的 DataNode 列表客户端向第一个 DataNode 建立管道由它继续向下游转发形成 pipeline数据以 packet 为单位传输每个 packet 经过的节点都要回 ackack 队列全部确认后才算写完一个包所有块写完后客户端通知 NameNode 关闭文件。读流程反向客户端请求读文件NameNode 返回块所在的 DataNode 列表按距离排序客户端选最近的节点读取读完一个块再取下一个。面试官最爱追问的是「某个 DataNode 中途挂了怎么办」。答法是pipeline 中的节点故障会被上游感知客户端把出错的节点从管道中移除用剩下的节点重建管道继续写同时 NameNode 在后续把该节点上的副本补足。这里能顺带带出副本因子、机架感知、块大小三个参数比单独背定义有用得多。2.2 MapReduce Shuffle 与 Hadoop 调优把阶段拆成可下手的点Shuffle 是 MapReduce 的核心也是大厂笔试的高频区。map 端先写环形缓冲区达到阈值溢写spill到磁盘溢写前按分区加排序多个溢写文件再归并reduce 端拉取属于自己的分区数据做归并排序后交给 reduce 函数。要讲出「溢写阈值、溢写比、combiner、压缩」这几个可调项才算把 Shuffle 讲成了调优题而不是概念题。调优的答法建议分四类说压缩中间结果用 Snappy 或 LZO权衡 CPU 与 IO、小文件合并、调大 split 尺寸、HAR 归档、集群 container 内存与核数配比、JVM 复用、数据倾斜见第 5 章的通用打法。基准测试也常被问到思路是用 TeraSort 之类的标准作业跑不同数据量记录耗时与资源占用作为基线再谈优化前后的对比别只报一个「快了 30%」的数字。# 提交一个带压缩与自定义 reducer 数的作业观察调整前后的耗时差异 hadoop jar wordcount.jar WordCount \ -D mapreduce.job.reduces10 \ -D mapreduce.map.output.compresstrue \ -D mapreduce.map.output.compress.codecorg.apache.hadoop.io.compress.SnappyCodec \ /input /output命令行里的mapreduce.job.reduces决定 reduce 任务数量直接影响输出文件个数和 Shuffle 压力mapreduce.map.output.compress打开 map 输出压缩压缩编解码器要与集群实际安装的库一致否则作业会因找不到 codec 直接失败。这类题的正确姿势是先说改哪个参数、再说观察哪个指标耗时、Shuffle 数据量、GC 时间最后给出对比结论。2.3 YARN 提交流程与调度器三类调度器的取舍要能说清YARN 的提交流程按角色串客户端提交应用到 ResourceManagerRM 分配一个 container 启动 ApplicationMasterAM 向 RM 注册并申请资源RM 把可用 container 分配给 AMAM 再通知 NodeManager 启动具体任务任务运行期间向 AM 汇报进度全部完成后 AM 注销并释放资源。调度器部分要能对比 FIFO、Capacity、Fair 三类FIFO 简单但大作业会饿死小作业Capacity 把队列容量按比例划分适合多团队共享Fair 让运行中的作业动态平分资源适合交互式与批处理混跑。面试官常追问「你们生产用哪个、为什么」这时要把队列规划、资源抢占、小作业响应时间讲进去而不是只背三种调度器的名字。提示流程类题先画草图再开口说不清角色关系时宁可停下来画两笔也别靠语速硬撑。3. 采集与消息层Flume 不丢数据、Kafka 不重复两个承诺怎么兑现采集链路的题考的不是组件会不会用而是上下游出问题时你承诺的数据语义还成不成立。Flume 说自己可靠Kafka 说自己高吞吐还能不丢面试官要的就是你把这句承诺拆成机制。3.1 Flume 的三种组件与两级事务Flume 的结构是 source、channel、sink 三件套source 从数据源读、channel 做缓冲、sink 往下一跳送。真正被追问的是 Put 事务与 Take 事务source 把事件写入 channel 时开启 Put 事务批量写成功后提交、失败则回滚sink 从 channel 取数据时开启 Take 事务取走并成功送达下游后才提交否则回滚让数据留在 channel 中。两级事务加上 channel 的持久化能力才构成「不丢」的说法。内存 channel 快但进程崩溃会丢file channel 靠磁盘换可靠性容量与落盘目录要提前规划防止数据丢失的关键是把 channel 类型、batch size、sink 的失败重试策略一起讲只答「用 file channel」会被继续追。拦截器、channel 选择器、监控器这类题按用途答即可拦截器做过滤与打标选择器把事件路由到不同 channel监控器上报吞吐与堆积指标。3.2 Kafka 丢数据与重复消费三个环节逐一封堵「Kafka 丢不丢数据」是必问题答法按生产者、broker、消费者三段走。生产者侧把acks设为 all、开启重试保证写入所有 ISR 副本才算成功broker 侧靠副本机制与min.insync.replicas保证至少有一个同步副本存活unclean.leader.election关掉可避免落后副本被选为 leader 造成数据截断消费者侧关闭自动提交处理完业务逻辑再手动提交 offset。数据重复的成因是提交 offset 前消费者挂了重启后从旧位点重新消费所以消费端要做幂等用业务主键去重、写库用 upsert、或借助事务消息。Kafka 的幂等性与事务题答到「生产者开启幂等保证单分区单会话不重复、事务跨分区原子写」这一层就够了别硬背实现细节。// 关键消费参数手动提交 关闭自动提交避免处理失败后位点已推进 props.put(enable.auto.commit, false); props.put(isolation.level, read_committed); // 事务消息场景下只读已提交 props.put(max.poll.records, 500); // 单批拉取量防止一次处理过久触发 rebalancemax.poll.records与处理耗时共同决定两次 poll 的间隔超过max.poll.interval.ms就会触发再平衡这是线上「消费着消费着就卡住」的常见原因。回答「消息积压怎么处理」时先判断是消费能力不足还是分区数不够加消费者实例、扩分区、提高单批处理效率三条路要按成本排序说。3.3 分区、副本与 ISR参数背后的容量题分区数决定并行度上限副本数决定可靠性下限ISR 是「跟得上 leader 的副本集合」。分区分配策略有 range、round-robin、sticky 几类消费者组内成员变化会触发再平衡sticky 的价值就是减少分区迁移。容量类问题按公式讲更容易被认可日志保存时间乘以每日写入量得到磁盘占用再乘副本数得到实际需求最后留出余量。机器数量、硬盘大小、topic 数量这些问题本质都是这道算术题的不同问法。4. 数仓与计算层Hive 优化、Spark 依赖、Flink 语义三线并进到了计算层题目开始从「是什么」转向「你怎么做」。Hive 优化和数据倾斜几乎是同一道题的两面Spark 的依赖划分决定 stage 与 task 数量Flink 的状态与快照决定容错能力能否兑现。4.1 Hive 优化与四个 By 的区别Hive 优化按层面答建表层做分区与分桶、用列式存储ORC、Parquet配压缩SQL 层避免全表扫描、小表 join 大表时用 map join、合理控制 reduce 数量参数层调hive.exec.parallel、合并小文件、开启动态分区。四个 By 的区别是送分题也是失分题group by 做分组聚合order by 全局排序只有一个 reducersort by 保证单 reducer 内有序distribute by 按字段把数据分到不同 reducer。组合用法要能举例比如 distribute by 加 sort by 实现分区内排序避免 order by 把数据全压到一个 reducer 上。窗口函数题通常给一个「求连续 N 天活跃」的场景答法是先用日期减行号构造分组标记再按标记聚合计数。动态分区题则要提到底层是按分区字段值在 HDFS 上建目录字段分隔符的坑字段里含制表符导致错列用额外指定分隔符或预处理清洗解决。4.2 Spark 宽窄依赖、stage 划分与两套 Shuffle宽窄依赖的判断标准是父 RDD 的每个分区是否只被子 RDD 的一个分区使用。窄依赖不产生 Shuffle宽依赖会触发 Shuffle 并按它划分 stage遇到宽依赖就切一刀前面的算一个 stage后面的再算一个最后一个 stage 的 task 数由输出分区数决定。两套 Shuffle 的对比要落到文件数量上未优化的 HashShuffle 每个 map task 为每个 reduce task 生成一个文件文件数等于两者乘积优化后通过复用 buffer 减少文件数SortShuffle 让每个 map task 最终只产出一个数据文件加一个索引文件bypass 模式在 reduce 数量较少时跳过排序直接写。被问到 reduceByKey 与 groupByKey 的区别核心是前者在 map 端先做局部聚合网络传输量小后者把同 key 全量拉到一个节点容易倾斜。共享变量题答广播变量把小表广播到每个 executor 避免重复传输和累加器只写不读的计数TopN 题给思路即可每个分区取前 N 再全局合并避免全量排序。4.3 Flink 的窗口、时间与 exactly-onceFlink 的时间分事件时间、摄入时间、处理时间事件时间配 watermark 处理乱序watermark 的本质是「不早于该时间的数据已经到齐」的进度承诺。窗口分滚动、滑动、会话迟到数据靠 allowed lateness 或侧输出兜底。容错这块按链路讲Checkpoint 基于分布式快照在数据流中插入 barrier算子收到 barrier 后把状态快照到持久化存储失败时从最近一次完成的快照恢复。端到端 exactly-once 要靠 source 可重放、状态快照一致、sink 支持事务或幂等三件事同时成立Kafka 连接器正是靠两阶段提交把这三段接起来的。反压题答到「下游处理慢导致上游被限速、通过监控背压指标定位到具体算子」即可。注意状态题不要只答「Flink 有状态后端」要区分内存、文件系统、RocksDB 三类后端在容量与性能上的取舍。5. 易错题与失分点五道看起来会、开口就翻车的题第一道数据倾斜只说「加随机前缀」。错在把手段当答案。倾斜的成因是某个 key 的数据量远超其他 key所以要先定位看任务耗时分布、看 stage 里个别 task 的输入量、采样统计 key 分布。定位之后才谈方案——聚合类倾斜用两阶段聚合先加随机前缀局部聚合再去前缀全局聚合join 类倾斜把小表广播或给大 key 单独抽出来处理空值倾斜先把 null 转成随机值。答完方案一定要补一句「改完要看 task 耗时是否拉平」否则等于没验证。第二道把 Flume 的可靠性和 Kafka 的不丢数据混成一件事。错在没分清组件边界。Flume 的两级事务保证的是「事件在 channel 里不丢」Kafka 的 acks 与副本保证的是「消息在 broker 侧不丢」两段拼起来才构成端到端。面试官追问「从采集到入仓整条链路怎么保证不丢」要按 source 事务、channel 持久化、sink 重试、下游确认逐段说缺一段就被认为没做过完整链路。第三道Spark 的 cache 和 checkpoint 答成同义词。错在没讲血缘。cache 把数据留在内存或磁盘但血缘还在节点挂了可以重算checkpoint 把数据写到可靠存储并切断血缘代价是产生额外 IO适合迭代很长或血缘太深的场景。回答时要带一句「checkpoint 前最好先 persist否则会重算两遍」这是踩过坑才知道的细节。第四道Hive 内部表外部表只答「删表删不删数据」。这个结论对但不够。要补上使用场景外部表适合多部门共享原始数据、防止误删内部表适合中间结果由本团队管理的场景再提 location 的差别与加载数据时的行为差异答案才有厚度。第五道Kafka 消费者加机器就一定变快。错在忽略分区数上限。消费者实例数超过分区数时多出来的实例空转。正确答法是先确认分区数、再判断瓶颈在拉取还是处理必要时扩分区并接受 key 顺序被打乱的代价或者优化单条处理逻辑。6. 答题节奏把「流程 参数 验证」当成固定套路用练到后面会发现大数据面试的绝大多数题都能套进同一个结构先讲清一条链路再指出链路上可调的参数最后说明改完怎么验证。这个套路对流程题、调优题、故障题都成立也是面试官判断「做过还是背过」最直接的依据。举个具体用法。被问到「Hadoop 集群某天突然变慢怎么排查」先走链路客户端提交、RM 分配、AM 申请、NM 起任务、HDFS 读写每一环都可能是瓶颈再逐个看参数container 内存是否不足导致频繁等待、Shuffle 数据量是否暴涨、DataNode 磁盘是否打满、集群是否有节点处于不健康状态最后说验证方式对比作业耗时基线、看监控里各队列的资源使用、检查是否有小文件激增。这样答即使没真正处理过这个故障逻辑也站得住。再比如「设计一个日活千万级的数仓分层」这类架构题同样按三步走ODS 层保留原始数据并确定同步策略全量还是增量、拉链还是快照DWD 层做清洗与维度关联DWS 与 ADS 层按主题聚合出指标参数落在存储格式、压缩方式、分区粒度、表生命周期上验证落在「每天跑多少张表、跑多久、峰值并发多少」这些可量化的回答上。项目经验题最忌讳只报数字不说口径说清「这张表为什么这么分层」比报一个漂亮的耗时更有说服力。题型开场怎么答必须带上的细节常见扣分流程题先画角色关系每个角色的职责与交互顺序只背名词不说顺序调优题先说瓶颈在哪参数名、调整方向、观察指标只报优化比例故障题先说影响面定位手段与回滚方案上来就给结论架构题先说数据流向分层职责与存储选型堆框架不谈取舍我自己的习惯是每次练题都强制走一遍这个三步能不能画出链路、能不能说出三个参数、能不能给出验证方法。三步齐了才开口缺一步就回去补不靠临场发挥。这份题库的价值也在这里——它把 Linux 与 Shell、Hadoop、Zookeeper、Flume、Kafka、Hive、HBase、Sqoop、Scala、Spark、Flink一直到项目架构、数仓分层、手写代码和 Java 基础按模块整理成了可以直接对练的题面配着答题思路过一遍比零散刷面经省时间得多。希望帮到你。本文还有配套的精品资源点击获取