简介这份资源是面向大数据开发、大数据运维、云计算、数据治理及大数据架构师方向求职者的面试题合集覆盖从基础组件到调优实战的完整知识链路适合有一定基础、准备跳槽或系统梳理知识体系的工程师查漏补缺。压缩包内共1个docx文档约491KB按章节组织目录便于按模块检索复习。内容围绕Linux与Shell常用命令、Hadoop端口与集群搭建、HDFS读写流程、MapReduce Shuffle与压缩优化、YARN提交流程及调度器、Zookeeper选举机制、Flume事务与拦截器、Kafka架构与丢数据及幂等性、Hive内外表与窗口函数及数据倾斜、HBase RowKey设计、Sqoop导入导出、Scala语法以及Spark部署模式、宽窄依赖、Shuffle流程、缓存与checkpoint、共享变量和TopN实现等高频考点展开并附有京东等真实调优对比案例。目前已有880人学习可帮助读者快速定位薄弱环节、积累面试答题思路与项目表述素材。1. 一份能当“错题本”用的大数据面试题库到底长什么样面过大数据岗的人大概都有过这种体验简历上写着“熟悉 Hadoop 生态”面试官一句“HDFS 写流程里 DataNode 是怎么选副本的”就能把人问住。问题不在于不会用而在于知识是散的——平时搭集群、跑任务、调参数都能对付一旦被追问底层机制和边界条件脑子里就只剩几个模糊的名词。这份 2023 年整理的大数据面试题库本质上就是把这些散落的知识点按技术栈重新串了一遍从 LinuxShell 一路铺到 Flink 高级、数仓架构、手写代码覆盖大数据开发、大数据运维、云计算和数据治理几个方向。它适合两类人一类是准备跳槽、需要系统过一遍知识面的从业者另一类是刚入行、想搞清楚“面试到底会问什么”的新手。下面我不按目录顺序念而是按“怎么用这份题库”来讲把里面真正值钱的部分拆出来。2. 把题库拆成三条复习线开发、运维、数仓各走各的路这份题库最大的特点是“全”但全也意味着直接从头看到尾效率极低。我的做法是先按岗位方向拆成三条线每条线只挑对应的章节深挖剩下的当字典查。2.1 开发线Spark 和 Flink 是重头戏开发岗的面试Spark 和 Flink 几乎占了半壁江山。题库里 Spark 部分从部署方式、提交参数、架构流程一直问到宽窄依赖、Shuffle 流程、缓存与 checkpoint 的区别颗粒度很细。比如“reduceByKey 与 groupByKey 的区别”这种题背结论没用得能说清楚为什么 reduceByKey 在 map 端会做本地聚合、groupByKey 不会以及这个差异在数据量大时意味着多少网络传输。Flink 部分分成了基础、中级、高级三层这个分层本身就值得参考。基础层问组件栈、Task Slot、并行度中级层问批流一体、分布式快照、Exactly-once高级层问三层图结构、JobManager 和 TaskManager 的角色、计算资源调度。复习的时候可以按这个分层自测基础题答不上来就别急着看高级题先把运行模型搞清楚。题库里还有一块容易被忽略但面试常考的内容——手写代码。冒泡、二分、快排、归并这些基本算法加上手写 Spark WordCount 和十道 HQL 题基本覆盖了笔试环节的常见题型。HQL 那十道题尤其值得动手写一遍因为 SQL 题在面试里往往是“写出来”和“写对”之间差着好几个坑。2.2 运维线Hadoop、Kafka、Flume 的稳定性问题运维方向的重点不在“怎么用”而在“出问题怎么办”。题库里 Hadoop 部分专门列了宕机处理、数据倾斜解决、参数调优、基准测试Kafka 部分有丢不丢数据、ISR 副本同步队列、消息积压处理、幂等性和事务Flume 部分有采集数据会不会丢、FileChannel 优化、HDFS Sink 小文件处理。这些问题的共同点是面试官想听的不是标准答案而是你有没有真在生产环境里处理过。举个例子Kafka 消息积压这道题题库里给的方向是“消费能力不足怎么处理”。实际面试中面试官往往会追问你怎么判断是消费能力不足还是分区数不够扩容消费者有没有上限如果积压是因为某几个分区数据特别多怎么办这些问题没有标准答案但能看出你有没有排查思路。我的建议是复习这类题的时候把题库里的问题当成引子自己往下追问三层把“现象→原因→解决”这条链走通。2.3 数仓线从分层架构到指标口径数仓方向的面试题集中在第 3 章到第 7 章包括数仓分层架构、埋点数据格式、用户行为分析活跃、新增、留存、回流、流失、电商业务表设计、拉链表、同步策略、即席查询以及数据治理、数据中台、数据湖这些偏架构的概念。这部分最容易被低估的是“需求逻辑”那一节。比如“如何分析最近七天内连续三天活跃用户数”看起来是一道 SQL 题实际上考的是你对窗口函数的理解和对业务口径的敏感度。题库里给了思路但真正面试的时候面试官可能会让你现场写 HQL还会追问“如果用户跨天活跃怎么算”“时区怎么处理”。这类题光看不行得动手写。电商运营经验那一章也值得翻一翻。八大类基本指标、五大关键指标、直播指标这些内容在面数据运营或数据产品岗时经常出现。即使面的是纯开发岗能说清楚自己做的指标对应什么业务含义也是加分项。提示三条线不是完全割裂的。开发岗也会问数仓分层运维岗也会问 Spark 任务调优。拆线只是为了确定复习优先级不是让你只学一条线。3. 用“问题→原理→参数→坑”四步法刷题比背答案管用题库里的问题数量不少如果每道题都背答案既记不住也用不上。我的做法是每道题按四步走一遍先看问题本身在问什么再想背后的原理然后落到具体参数或配置最后想一个自己踩过的坑或者见过的故障场景。这样过一遍比读十遍答案都管用。3.1 以 HDFS 写流程为例走一遍四步法题库里 HDFS 读流程和写流程是放在一起的很多人背的时候容易混。用四步法拆一下第一步问题在问什么。面试官问“HDFS 写流程”其实是想知道你对副本机制、Pipeline 传输、ACK 确认这几个概念的理解。第二步原理。客户端先向 NameNode 请求上传文件NameNode 返回可用的 DataNode 列表客户端建立 Pipeline 开始传输数据数据以 Packet 为单位流式传输最后一个 DataNode 写完发 ACK 回传全部完成后客户端通知 NameNode 关闭文件。第三步参数。这里面涉及几个关键参数dfs.replication控制副本数默认 3dfs.client-write-packet-size控制 Packet 大小默认 64KBdfs.datanode.socket.write.timeout控制写超时。这些参数在调优时都可能动。第四步坑。常见的一个坑是如果 Pipeline 中某个 DataNode 写失败客户端会怎么处理答案是会重试并剔除失败的节点同时 NameNode 会重新分配副本。但如果客户端自己超时了可能留下一个处于“正在写入”状态的文件需要手动处理。这个坑在题库的“Hadoop 宕机”那一节有涉及但需要自己串起来。3.2 用表格对比同类问题避免混淆题库里有很多“区别类”问题比如内部表和外部表、reduceByKey 和 groupByKey、repartition 和 coalesce、cache 和 persist、RDD/DataFrame/DataSet。这类问题最适合用表格整理把对比维度固定下来每次遇到新问题就往表格里加一行。对比项reduceByKeygroupByKeymap 端聚合有无网络传输量较小较大内存压力较低较高适用场景聚合类操作优先需要保留全量数据时对比项cachepersist存储级别默认 MEMORY_ONLY可指定多种级别是否可改不可改可改底层调用persist(MEMORY_ONLY)直接调用适用场景简单缓存需要磁盘或序列化时表格不用多每个技术栈整理一两张就够。关键是整理的过程而不是表格本身。3.3 参数类问题要落到具体数值和调整方向题库里参数类问题很多比如 Spark 提交作业参数、Kafka 分区数设定、Hive 动态分区、Hadoop 参数调优。这类问题最忌讳只答“调大一点”或“根据实际情况”。面试官想听的是你知道这个参数控制什么调大调小分别影响什么以及你根据什么来判断该调多少。以 Spark 提交参数为例题库里列了executor-memory、executor-cores、num-executors、driver-memory这些。实际面试中面试官可能会给一个场景一个 Spark 任务有 1TB 数据集群有 10 台机器每台 64GB 内存、16 核你怎么配这时候需要算每个 executor 分多少内存、留多少给系统、并行度怎么设、分区数怎么定。题库里没有给具体计算过程但你可以自己补上。# 一个常见的 Spark 提交配置示例 spark-submit \ --master yarn \ --deploy-mode cluster \ --driver-memory 4g \ --executor-memory 16g \ --executor-cores 4 \ --num-executors 20 \ --conf spark.default.parallelism200 \ --conf spark.sql.shuffle.partitions200 \ --class com.example.MainApp \ app.jar这段配置的逻辑是driver 给 4G 足够管理任务每个 executor 16G 内存、4 核留出内存给系统20 个 executor 总共 80 核对应集群 10 台机器每台 8 核左右并行度设 200 是为了让每个分区数据量适中避免分区过大导致 OOM 或分区过小导致任务调度开销大。实际数值要根据数据量和集群情况调整但思路是这样的。注意参数调优没有万能公式。题库里的参数是参考值不是标准答案。面试时如果能说出“我会先跑基准测试再根据瓶颈调整”比直接报数值更可信。4. 避坑刷题库最容易翻车的五个地方题库类资源最大的风险是“看起来都会一用就废”。下面这五个坑是我自己刷题和带人复习时反复见到的按“现象→原因→解决”写出来供对照。4.1 现象答案背得滚瓜烂熟面试官换个问法就懵原因背的是结论不是推导过程。比如“Hive 内部表和外部表的区别”背了“外部表删表不删数据”但面试官问“那什么时候用外部表”就答不上来了。解决每道题都问自己“为什么会有这个设计”。外部表的存在是因为数仓里原始数据不能被误删所以用外部表管理内部表适合中间结果表删了可以重建。理解了这个换问法也不怕。4.2 现象参数题答了一堆数值面试官追问“为什么”就卡住原因只记了数值没记数值背后的约束。比如 Kafka 分区数背了“一般设 3 到 10 个”但面试官问“如果分区数设多了会怎样”就不知道了。解决每个参数都从“控制什么→调大影响→调小影响→根据什么判断”四个角度过一遍。Kafka 分区数设多了会增加文件句柄和元数据开销还会影响 rebalance 时间设少了消费并行度上不去。判断依据是目标吞吐量和消费者数量。4.3 现象数据倾斜题只会说“加盐”但说不清加盐后怎么处理原因加盐是常见方案但不同场景加盐方式不同。Spark 里加盐后要做两次聚合Hive 里加盐后要处理 join 键Flink 里加盐要考虑 keyBy 后的状态。解决把题库里“数据倾斜”那一章按引擎分开整理。Spark 的解决方案有提高 shuffle 并行度、自定义分区器、加盐、map join 等Hive 有 map join、加盐、调整 reduce 数等Flink 有 local keyBy、加盐、两阶段聚合等。每个方案写清楚适用场景和副作用。4.4 现象手写代码题看着会一写就错原因眼高手低。冒泡排序看着简单但边界条件、循环终止条件、交换逻辑不写一遍就容易错。HQL 题更是如此窗口函数的 frame 范围、join 的条件、group by 的字段差一点结果就不对。解决题库里手写代码那一章每道题都自己在纸上或编辑器里写一遍写完再对照答案。HQL 题最好在 Hive 或 Spark SQL 里跑一遍用测试数据验证结果。4.5 现象项目经验题答得空泛面试官追问细节就露馅原因题库里“项目开发经验”那一章列了很多问题比如“项目开发中遇到哪些问题”“哪张表最费时间”“并发峰值多少”如果没有真实项目经历很容易答得空洞。解决如果没有真实项目可以用题库里的问题反向搭建一个模拟项目。比如选一个电商场景把 ODS、DWD、DWS 层设计一遍把每天跑多少张表、什么时候跑、跑多久这些细节补上。面试时可以说“我参与过一个模拟项目”但要把技术细节说清楚不要编造公司名或项目名。5. 进阶用法把题库变成自己的知识索引题库的终极用法不是刷完就扔而是变成自己的知识索引。我的习惯是每刷完一个技术栈就用思维导图或表格把核心问题、原理、参数、坑整理成一页纸。以后遇到相关问题先翻自己整理的那页纸找不到再回题库查。5.1 用“三层追问法”检验掌握程度每道题问自己三层第一层是什么第二层为什么第三层如果条件变了会怎样。比如 Kafka 的 ISR 副本同步队列第一层ISR 是什么第二层为什么需要 ISR第三层如果 ISR 收缩到只剩 leader 会怎样。能答到第三层基本就稳了。5.2 用“故障场景”串联知识点题库里很多问题可以串成一个故障场景。比如Kafka 消息积压 → 消费者处理慢 → 可能是下游 Hive 写入慢 → Hive 写入慢可能是小文件太多 → 小文件太多可能是 Flume 的 HDFS Sink 没配好。这样串一遍比单独背每道题印象深得多。5.3 用“版本差异”补充边界题库里有些内容涉及版本特性比如 Flink 1.9 的新特性、Spark 的 HashShuffle 和 SortShuffle。面试时如果被问到“你用的是哪个版本”要能说出这个版本和之前版本的关键差异。比如 Spark 1.6 之后 HashShuffle 被弃用SortShuffle 成为默认Flink 1.9 开始批流一体有较大改进。这些版本差异不需要背全但关键节点要知道。5.4 用“反问环节”反向验证题库质量面试最后的反问环节可以问面试官“你们现在用的 Spark 版本是多少”“数仓分层是怎么设计的”“数据质量怎么监控”。这些问题既能帮你判断团队技术栈也能反向验证题库里的内容是否过时。如果面试官说的和题库里差很多说明题库需要更新了。从那以后我每次刷题库都会先问自己一句这道题如果面试官追问三层我能不能接住接不住的就标记出来重点补。希望这份题库能帮你把知识面串起来少走点弯路。本文还有配套的精品资源点击获取
