简介：这份文档面向大数据开发、运维、云计算、数据治理及架构方向的学习者与求职者，系统梳理面试中高频出现的技术考点，帮助读者在准备跳槽或校招时快速建立知识框架、查漏补缺。内容覆盖Linux与Shell常用命令、Hadoop端口配置与HDFS读写流程、MapReduce Shuffle与YARN提交流程、Zookeeper选举机制、Flume事务与防丢失机制、Kafka架构与分区副本策略、Hive内外表与数据倾斜处理、HBase的RowKey设计、Sqoop数据迁移一致性，以及Scala语法和Spark部署、算子、Shuffle与调优等模块，目录按技术栈分层组织，便于按专题检索复习。资源包共1个docx文件，约491KB，结构紧凑、知识点密集，适合作为面试前的速查手册与项目经验复盘参考。目前已有885人学习，适合希望系统梳理大数据知识体系、对照真实面试题查漏补缺的开发与运维人员。
1. 大数据面试到底在考什么：一份题库背后的知识地图
很多人第一次翻大数据面试题，都会被目录吓一跳：Linux、Hadoop、Zookeeper、Flume、Kafka、Hive、HBase、Sqoop、Scala、Spark、Flink，后面还跟着数仓分层、数据治理、手写 HQL、JVM、Redis、MySQL。乍一看像把半个技术圈塞进了一个文档，其实它考的不是“你会不会背”，而是“你脑子里有没有一张能跑起来的数据流水线地图”。打个比方，大数据岗位就像一个城市的水务系统：Linux 是地基和管道，Hadoop 是水库，Kafka 是加压泵站，Hive 是净水厂，Spark 和 Flink 是调度中心，数仓则是最终送到每家每户的水表读数。面试官问的每一个点，都是在确认你知不知道水从哪来、在哪可能漏、漏了怎么修。这份题库之所以值得搞懂，是因为它把“大数据开发、运维、云计算、数据治理、架构师”几条路共用的底层概念摊开摆在一起，让你先看清全貌，再决定往哪深挖。
2. 为什么大数据岗位绕不开这套技术栈：从数据落地到数据可用
2.1 数据不是存下来就完事：一条链路上的四个角色
大数据系统里，数据要经历“采集、存储、计算、服务”四个阶段，每个阶段都有对应的角色。采集阶段靠 Flume 和 Sqoop，一个负责日志流，一个负责数据库批量搬运；存储阶段靠 HDFS 和 HBase，一个存大文件，一个存随机读写的稀疏数据；计算阶段靠 MapReduce、Spark、Flink，分别对应批处理、内存批处理、流处理；服务阶段靠 Hive 数仓和即席查询引擎，把算好的结果整理成能查的表。面试题里反复出现“HDFS 读流程和写流程”“Kafka 丢不丢数据”“Spark 宽窄依赖”，本质上都是在问：你知不知道数据在这四个阶段之间怎么交接、交接时哪里容易掉链子。理解这条链路，比单独背某个组件的参数更有用，因为真实故障往往发生在两个组件的接缝处，而不是组件内部。
2.2 为什么面试官爱问“数据倾斜”：它是链路上最典型的堵点
数据倾斜是这份题库里出现频率极高的词，Hadoop、Hive、Spark、Flink 四个章节都单独列了“解决数据倾斜方法”。通俗地说，数据倾斜就是本该平均分给十个人干的活，有一个人分到了八成，其他九个人干完等着，整个任务被那一个人拖住。它之所以成为面试必问，是因为它同时考验三件事：你懂不懂分布式计算的分区逻辑，你会不会看任务监控定位热点 key，你有没有实际调过参数或改过代码。题库里从“数据倾斜表现”讲到“定位导致数据倾斜代码”，再到“查看导致数据倾斜的 key 分布情况”，这条线就是在模拟一次真实的排查过程。能把这几个问题串起来回答的人，通常不是背题背出来的，而是真被线上任务拖慢过。
2.3 运维和开发的分界线：同一套组件，问法不一样
这份题库标注适用于开发、运维、云计算、数据治理、架构师几类岗位，但同一组件在不同岗位的考法差别很大。以 Kafka 为例，开发岗更关心“分区分配策略”“幂等性”“事务”“数据重复怎么处理”，因为这些直接影响代码怎么写；运维岗更关心“机器数量”“硬盘大小”“日志保存时间”“监控”“挂掉怎么办”，因为这些决定集群稳不稳。再比如 Hive，开发岗会问“四个 By 区别”“窗口函数”“自定义 UDF”，运维岗更可能问“动态分区底层原理”“字段分隔符为什么用 \t”。看懂这个差别，你就知道刷题时该把精力放在哪：不是每道题都要背，而是先判断自己目标岗位更可能追问哪一层。
3. 容易混淆的几个概念：名字像，考法完全不同
3.1 易混点一：HDFS 和 HBase 都是存储，区别在哪
初学者常把 HDFS 和 HBase 当成“两个数据库”，这是最容易混的地方。HDFS 是文件系统，适合一次写入、多次读取的大文件，比如日志归档；HBase 是建立在 HDFS 之上的列式数据库，适合按 RowKey 随机读写单条记录，比如用户画像的实时查询。混的原因是两者都“存数据”，但访问模式完全相反。区分方法很简单：问自己“我是要扫一遍全量文件，还是要按某个键取一行”，前者选 HDFS，后者选 HBase。面试里如果被问到“RowKey 设计原则”，其实就是在考你有没有理解 HBase 的随机读写特性，RowKey 设计不好，热点全压在一台机器上，跟数据倾斜是一个道理。
3.2 易混点二：Spark 的 cache 和 checkpoint 都叫“存一下”，差别不小
cache 和 persist 是把数据留在内存里，方便下一次复用，但血统关系还在，节点挂了可以重算；checkpoint 是把数据写到可靠存储里，主动切断血统，牺牲一点磁盘换容错。很多人混是因为两者都“让任务变快”，但 cache 解决的是重复计算，checkpoint 解决的是失败恢复。区分时看目的：如果只是同一个 RDD 被多个 action 用到，用 cache；如果任务链特别长、重算代价太高，用 checkpoint。题库里把“缓存机制与 checkpoint 机制的区别与联系”单独列出来，就是因为面试官想确认你不是只会加.cache()，而是知道什么时候不该加。
3.3 易混点三：Hive 内部表和外部表，删表时见真章
内部表删表时，元数据和 HDFS 上的数据一起删；外部表删表时只删元数据，数据还在。混的原因是建表语句看起来几乎一样，只差一个EXTERNAL关键字。区分方法记一句：数据要不要跟着表走。如果是中间计算结果、可以随时重建，用内部表；如果是原始日志、多个部门共用，用外部表，避免误删。面试里追问“你们 ODS 层用什么表”，其实是在确认你有没有数据安全意识，而不是考你背定义。
3.4 易混点四：Spark 的 repartition 和 coalesce，一个必 shuffle 一个可避免
repartition 会走 shuffle，把数据重新均匀打散；coalesce 默认不走 shuffle，只是把分区数减少，适合合并小分区。混的原因是两者都改分区数，但一个可能变慢、一个可能变快。区分时看要不要“打散”：如果分区数据不均、需要重新分布，用 repartition；如果只是分区太多、想合并，用 coalesce。题库里把这两个放在 Spark SQL 章节对比，是因为实际调优时选错一个，任务时间可能差出好几倍。
3.5 易混点五：数据治理和数据中台，不是同一个东西
数据治理关注的是“数据质量、元数据、权限、血缘”，目标是让数据可信、可追溯；数据中台关注的是“把共性数据能力沉淀成服务”，目标是让业务方快速复用。混的原因是两者都常出现在架构图里，听起来都很“大”。区分方法看落点：治理的产出是质量监控规则、血缘图、权限策略；中台的产出是可复用的数据服务接口。题库里把 Atlas 血缘、Griffin 质量监控、数据治理、数据中台、数据湖排在一起，其实是在提醒你：这些词经常被混着说，但面试官一问“你们治理具体做了什么”，答不上细节就露馅。
4. 从题库到能力：怎么用这份资料建立自己的知识框架
4.1 先按链路归类，再按岗位取舍
拿到这份题库，最忌讳从第一页开始逐题背。更有效的做法是先按“采集、存储、计算、服务”四段把章节归类：Flume、Sqoop 归采集；HDFS、HBase、Kafka 归存储和缓冲；MapReduce、Spark、Flink 归计算；Hive、数仓分层、即席查询归服务。归完类你会发现，很多题其实在问同一件事的不同侧面，比如“Kafka 丢不丢数据”和“Flume 采集数据会丢失吗”本质都是问“消息确认机制怎么设计”。然后按目标岗位取舍：开发岗把 Spark、Flink、Hive 的题往深看，运维岗把 Hadoop 集群搭建、Kafka 监控、Flume 内存和 FileChannel 优化往深看，治理岗把 Atlas、Griffin、数仓分层往深看。这样刷题不是线性堆量，而是围绕一条链路补缺口。
4.2 用“手写代码”章节检验理解深度
题库第 8 章列了冒泡排序、二分查找、快排、归并、手写 Spark WordCount、十道手写 HQL，这部分不是让你背代码，而是检验你有没有真正理解执行逻辑。比如手写 WordCount，看起来简单，但面试官会追问“reduceByKey 和 groupByKey 区别”“shuffle 发生在哪一步”，答不上来就说明你只是抄过模板。再比如手写 HQL 里的连续活跃用户问题，考的是窗口函数和日期处理，题库前面 Hive 章节已经铺垫了“窗口函数”“日期处理函数”，前后是呼应的。用这些题反推自己哪块概念没打通，比单纯看目录更有效。
-- 示例：用窗口函数求最近七天内连续三天活跃的用户 SELECT user_id FROM ( SELECT user_id, dt, date_sub(dt, row_number() OVER (PARTITION BY user_id ORDER BY dt)) AS grp FROM user_active WHERE dt >= date_sub(current_date, 7) ) t GROUP BY user_id, grp HAVING count(1) >= 3;这段 SQL 的关键在date_sub(dt, row_number())：如果日期连续，减去行号会得到同一个分组值，再用HAVING count(1) >= 3筛出连续三天。它对应题库里“如何分析最近七天内连续三天活跃用户数”那道题，考的不是语法记忆，而是你能不能把“连续”这个业务描述翻译成分组逻辑。参数上，dt是分区日期字段，row_number()按用户分组、按日期排序，date_sub的第二个参数是行号，三者配合才能把连续区间压成同一个grp。如果换成“连续三周活跃”，思路一样，只是把天换成周、把窗口拉长。
4.3 项目经验题怎么答：用“问题、定位、动作、结果”四段式
题库第 6 章“项目开发经验”列了大量问题，比如“项目开发中遇到哪些问题”“哪张表最费时间，有没有优化”“并发峰值多少”。这类题最怕答成流水账。更稳的结构是四段：先说问题现象，比如某天任务延迟三小时；再说定位过程，比如看 Spark UI 发现某个 stage 数据倾斜；然后说动作，比如给热点 key 加随机前缀再聚合；最后说结果，比如任务时间从三小时降到四十分钟。题库里“调优之前与调优之后性能的详细对比”就是在提示这个结构。注意不要编造具体公司名或项目名，用“某电商数仓项目”“某日志分析系统”这类代称即可，面试官关心的是你的排查思路，不是你待过哪家公司。
5. 什么时候该用这份题库，什么时候别把它当唯一答案
这份题库最适合两类场景。第一类是准备面试前两到四周，用它快速扫一遍知识盲区：先看目录，把完全没听过的词标出来，再按链路归类补概念，最后用“手写代码”和“项目经验”章节做自测。第二类是已经在大数据岗位干了一段时间，想系统梳理自己的知识框架，把平时零散踩过的坑对应到具体组件上，比如你调过 Spark 数据倾斜，就去看题库里“Spark 数据倾斜的解决方案”那一节，对照自己当时的做法，看有没有漏掉更优解。它的价值在于覆盖面广、问题具体，能帮你把“好像懂”变成“说得出细节”。
但它不适合三种用法。第一种是把它当唯一教材逐题背答案，因为面试官稍微换个问法你就接不住，比如题库问“Kafka 分区数怎么定”，面试官可能追问“分区数过多有什么代价”，这需要你理解分区和文件句柄、重平衡之间的关系，而不是背一个数字。第二种是把它当操作手册照着搭集群，题库里虽然有“Hadoop 集群搭建”“Flume 内存”“FileChannel 优化”这类偏实操的点，但版本差异很大，参数名和默认值可能已经变了，真动手还是要看对应版本的官方文档。第三种是拿它应付所有岗位，题库覆盖开发、运维、云计算、治理、架构师，但每类岗位的追问深度不同，运维岗被问到“Spark 血统”的概率远低于开发岗，反过来开发岗被问到“Kafka 机器数量怎么估算”的概率也低于运维岗，按岗位取舍比全量硬啃更省时间。
提示：题库里涉及具体参数的地方，比如“Kafka 的日志保存时间”“Hive 动态分区底层原理”，不同版本行为可能有差异，面试回答时最好补一句“我们当时用的版本是这样，新版本建议以官方文档为准”，既显得严谨，也避免被追问版本细节时翻车。
我自己的习惯是，每次准备面试前先拿这份题库的目录当检查清单，把每个章节标题读一遍，能立刻说出三个关键点的就跳过，说不出来的才翻进去看。有一次我自以为对 Spark Shuffle 很熟，结果被“HashShuffle 与 SortShuffle 的工作流程”问住，才发现自己只记得结论、不记得过程。从那以后我每次梳理知识框架都强制走一遍“目录自检、链路归类、手写验证”这三步，不再靠感觉判断自己会不会。希望这份题库也能帮你把“好像懂”变成“真能讲清楚”。
本文还有配套的精品资源，点击获取
