简介：这份资料面向大数据开发、运维、云计算、数据治理及架构方向的学习者与求职者，系统梳理面试中高频出现的技术考点，帮助读者在准备面试或技能复盘时快速定位知识盲区。内容覆盖Linux与Shell基础、Hadoop生态（HDFS读写流程、MapReduce Shuffle、YARN提交流程与参数调优）、Zookeeper选举机制、Flume事务与防丢失机制、Kafka架构与分区副本策略、Hive内外表与数据倾斜处理、HBase RowKey设计、Sqoop数据迁移，以及Scala语法和Spark部署、算子、Shuffle、缓存与调优等模块，目录按技术栈分层组织，便于按章节检索。资源包共1个docx文档，约491KB，结构紧凑、知识点密集，适合作为面试前的速查手册和日常工作的参考清单。目前已有885人学习，适合需要系统梳理大数据知识体系、查漏补缺的中初级从业者与转岗人员。
1. 大数据面试题到底在考什么：从一份“全家桶”资料说起
第一次翻大数据面试题的人，常有一种逛超市的错觉：货架上从 Linux 命令、Shell 脚本，一路摆到 Hadoop、Kafka、Hive、Spark、Flink，最后还塞进 Java、MySQL、Redis、JVM。看着目录挺全，真到面试现场被问一句“HDFS 写流程讲一下”，脑子却像断网的页面，转半天出不来。这份资料想解决的，正是这种“知识点都见过、串不起来”的尴尬。
通俗地说，大数据面试题不是一堆背诵条目，而是一张岗位能力地图。它把大数据开发、大数据运维、云计算、数据治理、大数据架构师这几类岗位真正会碰到的技术点，按“基础环境—采集传输—存储计算—调度治理—项目落地”的顺序摊开。你翻目录时看到的每一个小节，背后都对应一个真实工作场景：数据从哪来、怎么进来、存在哪、怎么算、算完怎么用、出了问题怎么查。搞懂这张地图，比死记一百道题更有用。
2. 为什么大数据岗位绕不开这套技术栈：一条数据流水线的分工
2.1 从数据产生到出报表：一条流水线需要哪些角色
把大数据系统想成一家餐厅。Linux 和 Shell 是后厨的水电煤，平时不显眼，停了你连火都打不着；Hadoop 的 HDFS 是仓库，MapReduce 和 Yarn 是切菜工和排班经理；Flume 是采购员，负责把外面的食材一车车拉进来；Kafka 是传菜窗口，高峰期先排队再分发；Hive 是菜谱和半成品加工区，把原始食材做成能上桌的菜；HBase 是随手可取的小料台，按编号快速拿；Sqoop 是专门跑银行和仓库之间的搬运工；Spark 和 Flink 则是两套更快的灶台，一个擅长批量出餐，一个擅长现点现做。
这条流水线上任何一环卡住，报表就出不来。面试官问“Flume 采集数据会丢失吗”，不是想听你背配置项，而是想知道你清不清楚采购员半路掉货时，后厨有没有补救机制。问“Kafka 消息积压怎么处理”，本质是问传菜窗口堵了，你是加窗口、加人手，还是让前面少出菜。把每个组件放回流水线的位置，很多看似孤立的问题就有了上下文。
2.2 为什么面试官爱问流程和参数：流程暴露理解深度
拿 HDFS 写流程来说，资料里把它单独列成一节，不是因为它难背，而是因为它能一次性暴露你对副本、机架感知、管道传输、确认机制的理解。你如果能用自己的话讲清楚“客户端先找谁、数据包怎么沿着管道走、中途某个节点挂了怎么办”，说明你不是只见过名词，而是知道数据在集群里怎么活下来。
参数调优也是同理。Hadoop 参数调优、Kafka 参数优化、Spark 提交作业参数，这些内容在目录里反复出现，是因为真实工作中调错一个参数就可能让任务跑成“玄学”。比如小文件太多，NameNode 压力大，你得知道从压缩、合并、调参几个方向下手；数据倾斜导致某个 task 拖到最后，你得能定位是哪个 key 在作怪。面试官问参数，往往是在确认你有没有踩过坑、有没有形成自己的排查顺序。
2.3 数据倾斜为什么反复出现：它是分布式计算的“老熟人”
目录里 Hadoop、Hive、Spark、Flink 四个部分都出现了数据倾斜，这不是编排凑数，而是因为只要做分布式计算，就绕不开它。打个比方，十个人分拣快递，本来每人一车，结果某个小区的包裹全堆到一个人车上，其他人早早收工，这个人干到半夜。数据倾斜就是某个 key 的数据量远超其他 key，把并行计算硬生生拖成单线程。
资料里把数据倾斜的表现、产生原因、解决思路、定位代码、查看 key 分布、Spark 具体方案分成多节，说明它不是一个“背答案”能过关的点。面试时如果你只说“加盐”，对方多半会追问加盐之后怎么聚合、加盐倍数怎么定、哪些场景不适合加盐。能把这些讲清楚，才算真正理解分布式计算里“均匀”两个字有多贵。
3. 这些组件到底各自管什么：把名词放回它该在的位置
3.1 存储与计算：HDFS、Hive、HBase 不是三选一
初学者最容易把 HDFS、Hive、HBase 当成互相替代的存储方案，其实它们分工完全不同。HDFS 是底层文件系统，负责把大文件切成块、多副本存到多台机器上，它不认“表”，只认文件和目录。Hive 建在 HDFS 之上，提供类似 SQL 的查询能力，把 SQL 翻译成 MapReduce 或 Tez、Spark 任务去跑，它更像“给文件加了一层表格视图和查询语言”。HBase 则是另一条路，面向列、按 RowKey 快速随机读写，适合稀疏数据和毫秒级查询。
用图书馆打比方：HDFS 是书库，书按箱子堆着；Hive 是目录卡片和借阅规则，让你能用“作者、书名”这类条件找书，但找的过程可能要翻很多箱子；HBase 是每本书自带索引号，报编号就能直接抽出来。面试里问“内部表和外部表区别”“RowKey 设计原则”，考的就是你知不知道这层分工，而不是把三个名词混成一锅粥。
3.2 采集与传输：Flume 和 Kafka 为什么总被放在一起问
Flume 和 Kafka 都跟“数据流动”有关，但角色不同。Flume 更像定点搬运工，配置好 Source、Channel、Sink，就能把日志从一台机器搬到另一处，它关心的是“采集链路稳不稳、会不会丢”。Kafka 更像一个耐用的传送带和缓冲池，生产者往里写，消费者按自己的节奏读，它关心的是“吞吐、分区、副本、消费位点”。
资料里 Flume 部分问 Put 事务、Take 事务、Channel 选择器、防止数据丢失，Kafka 部分问架构、分区数、副本数、ISR、幂等性、事务、数据重复，这些问题的共同点是：它们都在追问“数据在流动过程中会不会少、会不会重、顺序乱不乱”。把 Flume 当成“进门那一段”，把 Kafka 当成“进门之后的缓冲和分发”，很多概念就不会打架。
3.3 计算引擎：Spark 和 Flink 的边界在哪里
Spark 和 Flink 都能做大数据计算，但资料把它们分开列，说明面试官期待你知道两者的定位差异。Spark 以批处理起家，Spark SQL、DataFrame、DataSet 让结构化数据处理很顺手，Spark Streaming 用微批的方式做流处理；Flink 则从设计上强调流批一体，把流处理当一等公民，窗口、水印、状态、Exactly-once 这些概念在 Flink 部分被反复追问。
通俗地说，Spark 像一列按时刻表发车的货运列车，把一段时间内的货攒起来一起拉，效率高；Flink 像一条持续运转的传送带，货到就处理，更在意事件时间和乱序到达。面试里问“Flink 相比 Spark Streaming 的区别”“Flink 如何保证 Exactly-once”，考的是你有没有理解“微批”和“真流”在容错、延迟、状态管理上的不同取舍。
3.4 调度、协调与治理：Zookeeper、Yarn、Azkaban 各管一摊
Zookeeper 在目录里出现得不算多，但选举机制和常用命令被单独列出，因为它是很多分布式系统的“协调员”，负责选主、配置管理、分布式锁这类脏活累活。Yarn 是资源调度器，决定哪个任务拿多少 CPU 和内存，默认调度器、调度器分类和区别是常考点。Azkaban 则在项目开发经验部分出现，负责工作流定时调度。
这三者容易被混成“调度相关”，其实层次不同：Zookeeper 管协调，Yarn 管集群资源，Azkaban 管任务按依赖关系按时跑。打个比方，Zookeeper 是楼里的对讲机和公告栏，Yarn 是物业分配房间和工位，Azkaban 是每天早上按流程表喊人开工。分清楚这层，面试时就不会把“选举机制”和“调度器分类”答串。
4. 常见误区与易混概念：这些坑不踩一遍很难记住
4.1 误区一：把 Hive 当成数据库
易混点在于 Hive 有表、有字段、能写 SQL，看起来和 MySQL 很像。之所以会混，是因为很多人先学关系型数据库，再接触 Hive，自然把“表”等同于“数据库表”。区分的关键看两点：Hive 的数据存在 HDFS 上，元数据存在关系型数据库里，查询延迟高，不适合事务和频繁更新；它更像数据仓库的查询层，不是在线业务库。面试问“Hive 和数据库比较”，就是在确认你有没有这根弦。
4.2 误区二：以为 Kafka 分区越多越好
分区能提高并行度，所以初学者容易觉得分区数往大了设总没错。混淆的原因是只看到“并行”的好处，没看到分区背后的成本：分区越多，文件句柄、内存、副本同步、故障恢复的负担都上来，生产者和消费者的管理也更复杂。区分方法是回到吞吐目标和集群规模，资料里把“Kafka 分区数”“副本数设定”“多少个 Topic”放在一起，就是提醒你这些参数要一起看，不是单点拍脑袋。
4.3 误区三：把数据倾斜和“数据量大”画等号
数据倾斜的表现是任务慢，很多人第一反应是“数据太多了”，于是加资源。混淆点在于总量大和分布不均是两回事：总量大可以靠加并行度缓解，分布不均加机器也救不了那个热点 key。区分方法是看 task 运行时间和处理记录数是否严重不均，资料里专门列了“查看导致数据倾斜的 key 分布情况”，就是让你先定位再动手，而不是盲目扩容。
4.4 误区四：认为 Exactly-once 就是“绝对不重复”
流处理里常听到 Exactly-once 语义，初学者容易理解成“数据一条都不会重复”。实际上它描述的是一套端到端的处理效果，依赖状态、检查点、幂等写入或事务提交共同保证，不同组件的边界不一样。混淆的原因是把它当成单个开关。区分时要问清楚：是哪一段链路的 Exactly-once，下游存储支持不支持事务或幂等，失败恢复后位点怎么对齐。资料里 Kafka 幂等性、Kafka 事务、Spark Streaming 精准一次消费、Flink 如何保证 Exactly-once 分散在不同章节，正说明它不是一句话能答完的。
4.5 误区五：把宽窄依赖和 Stage 划分当成背诵题
Spark 的宽窄依赖、Stage 划分、task 个数是笔试高频点，很多人背了定义就上场。易混之处在于“窄依赖不 shuffle、宽依赖 shuffle”这句话太顺口，容易忽略 Stage 划分是从后往前推、遇到宽依赖切一刀的细节。区分方法是拿一个具体算子链画一遍：map、filter 是窄依赖，reduceByKey、groupByKey 会触发 shuffle，Stage 边界和 task 数自然就出来了。能画出来，比背十遍定义都稳。
5. 什么时候该用这份资料：边界判断与一个具体场景
这份资料最适合两类人。一类是准备大数据开发、大数据运维、云计算相关岗位面试的人，需要把散落的知识点按岗位地图串起来，尤其是目录里从 Linux、Hadoop 一路覆盖到 Spark、Flink、项目架构、电商指标、手写代码的部分，适合做系统复盘。另一类是在工作中被某个概念卡住、想快速查漏的人，比如刚接手数据仓库，想搞清楚拉链表、同步策略、数仓分层各自解决什么问题，可以按章节跳读。
它不适合什么场景？如果你要找的是某个组件最新版本的官方配置手册，或者想照着一步步搭生产集群，这份资料只能当索引，不能当操作手册。它也不替代真实项目经验：面试里问“项目开发中遇到哪些问题”“哪张表最费时间、有没有优化”，答案得从你自己跑过的任务里长出来，资料给的是提问角度和排查方向。
举个具体例子。假设某开发者去面一个数据开发岗，简历上写了“参与用户行为数据分析”。面试官顺着目录里的用户行为章节问：“最近七天内连续三天活跃用户数怎么分析？”如果只背过“用窗口函数”，很容易卡在连续条件的写法上。比较稳的做法是先说清思路：按用户和日期聚合出活跃天，再用日期减排名得到分组标记，连续日期会落在同一组，最后按用户分组数天数。资料里把“如何分析最近七天内连续三天活跃用户数”单独列出来，价值不在于给一段现成 SQL，而在于提醒你这类需求要拆成“去重、排序、分组、计数”几步。
再比如数据治理和元数据管理部分，目录里提到血缘系统和数据质量监控。面试官问“为什么要做数据质量监控”，如果你只答“保证数据准确”，很容易被追问“监控哪些指标、发现问题怎么定位、和血缘系统什么关系”。这时候可以顺着“指标定义—采集—校验—告警—溯源”的顺序讲，把 Griffin 这类工具放在“校验和告警”环节，把 Atlas 血缘放在“溯源”环节，逻辑就立住了。
我自己的习惯是，每次准备面试前先拿目录当检查表，把每个小节用自己的话讲一遍，讲不顺的地方标出来，再去翻对应章节。有一次讲“Yarn 的 Job 提交流程”讲得磕磕绊绊，回头补了资源调度那几节，才发现之前一直把“提交”和“调度”混着说。从那以后我每次梳理技术点都强制走一遍“先讲流程、再讲参数、最后讲翻车场景”的顺序，比单纯刷题踏实得多。这份资料的价值也在这里：它把问题按真实工作链路摆好，你顺着走一遍，认知就成型了。希望帮到你。
本文还有配套的精品资源，点击获取
