简介：这份资料是面向大数据开发、运维、云计算、数据治理及架构岗位的系统性面试题库，适合准备跳槽或校招的初中高级从业者查漏补缺。内容按技术栈分章组织，覆盖Linux与Shell常用命令、Hadoop端口配置与HDFS读写流程、MapReduce Shuffle与YARN提交流程、Zookeeper选举机制、Flume事务与防丢失机制、Kafka架构与分区副本策略、Hive内外表与窗口函数及数据倾斜处理、HBase的RowKey设计、Sqoop导入导出一致性、Scala语法特性，以及Spark部署模式、宽窄依赖与Stage划分、Shuffle流程、缓存与checkpoint、TopN实现等高频考点，并附有调优前后性能对比等实战经验。资源包共1个docx文件，约491KB，目录层级清晰，便于按模块检索复习。目前已有885人学习，适合作为面试前系统梳理知识体系、对照自查薄弱环节的参考材料。
1. 一份能当“作战地图”用的大数据面试题库，到底长什么样
凌晨一点，某公司数据平台组的工位上，一位做了三年 ETL 的工程师正对着屏幕发愁：简历上写了“熟悉 Spark 调优”，可真被问到“reduceByKey 和 groupByKey 在 Shuffle 阶段到底差在哪、什么场景下前者反而更慢”，脑子里只剩一句模糊的“前者会预聚合”。这不是能力问题，是知识没有成体系地过一遍。这份 2023 年整理的大数据面试题库，覆盖 Linux/Shell、Hadoop、Zookeeper、Flume、Kafka、Hive、HBase、Sqoop、Scala、Spark、Flink，再往下压到数仓分层、电商业务建模、数据治理与数据湖，最后收在 JavaSE、Redis、MySQL、JVM、JUC 这些后端底座上。它解决的不是“背题”，而是把开发、运维、云计算、数据治理、架构师几条线的知识串成一张能自查的地图。适合谁？准备跳槽的大数据开发、刚接手集群的运维、从数仓转实时计算的从业者，以及需要给团队做技术盘点的负责人。
2. 先看骨架：这份题库的模块划分与知识覆盖逻辑
2.1 从组件清单到能力矩阵：14 章不是平铺的
很多人拿到题库第一反应是从第一页背到最后一页，这是最低效的用法。这份资料的章节顺序其实暗含一条能力递进线：第 1 章“项目涉及技术”是组件级知识，从 Linux 命令、Hadoop 端口号一路铺到 Flink 三层图；第 2 章“项目架构”讲数仓概念、框架版本选型、服务器选型、集群规模、人员配置；第 3、4 章落到用户行为数据分析和业务交互数据分析，也就是埋点格式、电商表结构、同步策略、拉链表；第 5 章即席查询数仓；第 6 章项目开发经验，把 Hadoop、Flume、Kafka、Hive、MySQL、Tez、Sqoop、Azkaban、Spark 的线上问题逐条列出；第 7 章电商运营指标；第 8 章手写代码，冒泡、二分、快排、归并、Scala 二叉树、Spark WordCount、10 道 HQL；第 9 到 13 章是 JavaSE、Redis、MySQL、JVM、JUC；第 14 章面试说明。
把它当能力矩阵看，就能按岗位裁剪。大数据开发重点吃第 1 章的 Spark、Hive、Kafka 和第 8 章手写代码；大数据运维重点吃第 1 章的 Hadoop、Flume、Kafka 参数和第 6 章的线上故障；数据治理岗重点吃第 6 章的 Atlas 血缘、Griffin 数据质量、数据中台与数据湖；架构师岗重点吃第 2 章的选型与集群规模、第 4 章的建模、第 6 章的开发经验。云计算方向则要把第 1 章的部署方式、第 2 章的服务器选型结合起来看。
2.2 组件知识的组织方式：每个技术点都带“参数 + 流程 + 故障”三件套
这份资料在组织单个组件时有个很实用的套路，以 Kafka 为例：先给架构，再给压测方法，然后连续追问机器数量、日志保存时间、硬盘大小、分区数、副本数、Topic 数量，接着是丢不丢数据、ISR 副本同步队列、分区分配策略、数据量计算、挂掉怎么办、消息积压怎么处理、幂等性、事务、数据重复、参数优化、高效读写。这一串问题不是随机排的，它对应的是“容量规划 → 可靠性 → 一致性 → 性能”的排查顺序。
我一般会把这个顺序抄成一张检查表，遇到线上 Kafka 问题时按表走。比如消息积压，先看消费能力（消费者数量、单条处理耗时），再看分区数是否够并行，再看是否有消费者频繁 rebalance，最后才怀疑 Broker 磁盘。资料里“Kafka 消息数据积压，消费能力不足怎么处理”这一条，配合“Kafka 分区数”“副本数设定”一起看，才能得出“扩分区还是扩消费者”的结论。
2.3 数仓部分的落地价值：从分层到拉链表
第 3、4 章是这份资料里最容易被低估的部分。数仓分层架构表、埋点行为数据基本格式、电商订单表/订单详情表/商品表/用户表/支付流水表的关键字段、同步策略、关系型数据库范式、数据模型、拉链表，这些内容拼起来就是一套可复用的建模模板。尤其是拉链表，资料里给了概念，但真正落地时要解决“每日增量如何合并进历史链、开链关链的起止时间字段怎么设、迟到数据怎么回补”三个问题。
常见做法是：ODS 层保留原始切片，DWD 层用“start_date + end_date + is_current”三字段维护拉链，每日跑批时先关掉发生变化的旧链（end_date 置为昨日），再插入新链（start_date 为今日，end_date 为 9999-12-31）。这个模式在用户维度、商品维度上都能直接套。资料第 6 章还追问了“ODS 层采用什么压缩方式和存储格式”“DWD 层做了哪些事”“DWS 层做了哪些事”，这三问其实是在逼你把分层职责说清楚，答不上来就说明建模是抄的而不是想过的。
3. 把题库变成可执行的复习计划：按岗位拆解与自测方法
3.1 按岗位生成复习清单：一张表定优先级
直接从头背会陷入“什么都看了、什么都没记住”。我的做法是先按目标岗位给章节打权重，再排时间。下面这张表是我给几个不同方向的朋友排过的优先级，权重按“面试出现频率 × 岗位相关度”粗估，读者可以按自己情况改。
| 目标岗位 | 高优先级章节 | 中优先级章节 | 可后置章节 |
|---|---|---|---|
| 大数据开发 | 第 1 章 Spark/Hive/Kafka、第 8 章手写代码 | 第 3、4 章数仓建模、第 6 章开发经验 | 第 9-13 章后端底座 |
| 大数据运维 | 第 1 章 Hadoop/Flume/Kafka 参数、第 6 章线上故障 | 第 2 章集群规模与选型 | 第 7 章电商运营 |
| 数据治理 | 第 6 章 Atlas/Griffin/数据中台/数据湖 | 第 3、4 章建模与元数据 | 第 8 章手写算法 |
| 大数据架构师 | 第 2 章选型与集群规模、第 4 章建模、第 6 章开发经验 | 第 1 章各组件原理 | 第 9-13 章语法细节 |
| 云计算方向 | 第 1 章部署方式、第 2 章服务器选型、第 6 章数据湖 | 第 1 章 Kafka/Spark | 第 7 章运营指标 |
排完权重后，每天只攻一个组件的“三件套”：原理流程、关键参数、故障处理。比如今天攻 HDFS，就把读流程和写流程画一遍，把副本数、块大小、机架感知相关参数列出来，再把“Hadoop 宕机”这一条想清楚——NameNode 挂了怎么恢复、DataNode 挂了副本怎么补。画不出来就是没懂，别骗自己。
3.2 用“追问链”自测：每个知识点往下追三层
这份资料本身就是一个巨大的追问链，比如 Spark 部分从“有几种部署方式”追到“提交作业参数”，再追到“架构与作业提交流程”，再追到“血统概念”“宽窄依赖与 stage 划分”“transformation 与 action 算子”“会引起 Shuffle 的算子”“两种核心 Shuffle 的工作流程”“reduceByKey 与 groupByKey 的区别”。这条链就是面试官的真实追问路径。
自测方法是：合上资料，从“Spark 作业提交流程”开始讲，讲完后自己问“那 stage 怎么划分”“为什么宽依赖要切 stage”“Shuffle 写磁盘时怎么减少小文件”。能连续答三层不卡壳，这个点才算过。答到第二层卡住，就回到资料对应小节补，补完再重讲一遍。这个方法比反复阅读有效得多，因为它模拟的是输出而不是输入。
3.3 手写代码与 HQL 的练习节奏
第 8 章的手写代码分三块：基本算法（冒泡、二分、快排、归并、Scala 二叉树）、开发代码（手写 Spark WordCount）、手写 HQL 共 10 题。算法部分建议每天手写一道，重点不是背代码而是写边界：二分查找的 mid 溢出、快排的递归终止条件、归并的临时数组拷贝。Spark WordCount 要能默写出 RDD 版本和 DataFrame 版本两种。
HQL 的 10 道题是这份资料里含金量很高的部分，因为数仓面试几乎必考“连续 N 天活跃”“留存”“漏斗”。练习时不要只看答案，先自己写，写完对照，重点看三处：日期函数用得对不对（date_sub、date_add、datediff）、窗口函数的分区与排序字段选得对不对、连续问题的“日期减排名”技巧有没有用上。下面这段是“最近七天内连续三天活跃用户”的常见写法，用日期减排名构造分组标识：
-- 取最近 7 天内，连续 3 天有活跃记录的用户 WITH daily AS ( SELECT DISTINCT user_id, dt FROM dwd_user_active WHERE dt BETWEEN date_sub(current_date, 6) AND current_date ), grp AS ( SELECT user_id, dt, -- 关键技巧：日期减去行号，连续日期的差值恒定 date_sub(dt, rn) AS grp_flag FROM ( SELECT user_id, dt, row_number() OVER (PARTITION BY user_id ORDER BY dt) AS rn FROM daily ) t ) SELECT user_id FROM grp GROUP BY user_id, grp_flag HAVING count(1) >= 3;逻辑说明：第一步去重得到用户每日活跃切片；第二步按用户分组、按日期排序打行号；第三步用date_sub(dt, rn)生成分组标识，连续日期的这个差值相同；第四步按用户和标识分组，计数大于等于 3 即为连续三天。参数上要注意dt的格式必须是yyyy-MM-dd，如果表里是yyyyMMdd字符串，要先from_unixtime(unix_timestamp(dt,'yyyyMMdd'),'yyyy-MM-dd')转一道，否则date_sub会返回 NULL，这是新手最常翻车的地方。
4. 避坑与排查：这份题库用起来最容易踩的五个坑
4.1 把“知道答案”当成“会做项目”
现象：面试时能把 Hive 数据倾斜的解决方案背出七八条，面试官追问“你项目里是哪张表、哪个 key 倾斜、怎么定位的、最后用了哪种方案、效果多少”，立刻哑火。原因：资料第 1.13 节给了“数据倾斜表现、产生原因、解决思路、定位代码、查看 key 分布、Spark 解决方案”一整套，但那是通用方法论，没有绑定具体项目。解决：每看完一个解决方案，强制自己补一个“如果是我手上的表，我会怎么验证”。比如 groupBy 倾斜，先跑SELECT key, count(1) FROM t GROUP BY key ORDER BY 2 DESC LIMIT 20看分布，再决定是加随机前缀还是用 map-side join。资料第 6 章“项目开发中遇到哪些问题”就是让你练这个的，别跳过。
4.2 参数只记名字不记量级
现象：被问“Kafka 分区数怎么定”，答“根据吞吐量定”，再问“你们多少分区、单分区多少吞吐”，答不上来。原因：资料里“Kafka 分区数”“Kafka 数据量计算”“Kafka 的硬盘大小”是连着的，只看单条会断链。解决：记住一组可复用的量级——单分区写入常见在几 MB/s 到十几 MB/s，按目标总吞吐除以单分区吞吐估分区数，再考虑消费者并行度上限就是分区数。硬盘按“每日数据量 × 副本数 × 保留天数 × 压缩比”估。这些数字不必精确，但必须有，否则参数就是玄学。
4.3 数仓分层只背名字不背职责
现象：ODS、DWD、DWS、ADS 说得顺，一问“DWD 层做了哪些事”就只剩“清洗”。原因：资料第 6.2 节明确列了 ODS 压缩与存储格式、DWD 做了哪些事、DWS 做了哪些事，但很多人只扫一眼。解决：把每层的输入、输出、典型操作写下来。DWD 常见做的是清洗、去重、维度退化、脱敏、拉链；DWS 常见做的是按主题宽表聚合、轻度汇总；ADS 才是面向报表的指标层。写不出来就说明分层是背的。
4.4 手写 HQL 忽略数据格式与空值
现象：连续 N 天活跃的 SQL 写对了逻辑，跑出来结果为空。原因：日期字段是字符串且格式不对，或者row_number遇到 NULL 日期导致分组错乱。解决：写之前先DESC 表名看字段类型，先SELECT dt FROM t LIMIT 10看格式，日期统一转成yyyy-MM-dd再参与计算；对 NULL 日期先过滤。这类问题在资料第 8 章不会写出来，但实际手写时必踩。
4.5 把 Flink 和 Spark Streaming 的区别背成口号
现象：能说“Flink 是真正的流处理，Spark Streaming 是微批”，再问“那 Flink 的反压怎么做的、和 Storm 有什么不同、Checkpoint 和 Spark 的 checkpoint 差在哪”，答不深。原因：资料第 1.14、1.15 节把 Flink 基础、中级、高级拆得很细，包括分布式快照、Exactly-once、内存管理、序列化、反压、算子链，但需要按“数据交换 → 容错 → 状态 → 反压”这条线串起来看。解决：先看 1.15.4 分布式快照原理，再看 1.15.5 Exactly-once，再看 1.15.12 反压，三节连读，理解 Barrier 对齐、状态后端、反压传播是一条因果链，而不是三个孤立知识点。
5. 进阶用法：把题库改造成团队知识库与面试评估表
这份资料最值钱的用法不是自己背，而是改造成两样东西：团队知识库的目录骨架，和面试官的评估表。前者解决“新人来了从哪学”，后者解决“面试问得散、评价没标准”。
先说知识库改造。把第 1 章的组件清单直接当目录，每个组件下固定四个小节：核心流程、关键参数、常见故障、我们集群的实际配置。前三个从资料里摘，第四个必须由团队自己填。比如 Kafka 小节下写清楚“我们 6 台 Broker、每台 3 块盘、单分区目标 8MB/s、默认 3 副本、日志保留 7 天”，新人一看就知道参数不是拍脑袋来的。第 6 章的 Atlas 血缘、Griffin 数据质量、数据中台、数据湖可以单独拉一个“治理”目录，因为这些是跨组件的横向能力。
再说面试评估表。把资料里的追问链抽成评分项，每个岗位选 8 到 10 条，每条给三档描述。以大数据开发为例，可以这样设计：
| 评估项 | 及格 | 良好 | 优秀 |
|---|---|---|---|
| Spark Shuffle | 说出 Hash 与 Sort 两类 | 讲清 bypass 触发条件 | 结合项目说清调优前后参数与收益 |
| Hive 倾斜 | 列出通用方案 | 说清定位方法 | 给出具体 key 分布与最终方案效果 |
| 数仓分层 | 说出四层名字 | 说清各层职责 | 结合拉链表与同步策略讲建模取舍 |
| 手写 HQL | 写出连续 N 天逻辑 | 处理日期格式与空值 | 给出多种写法并比较执行计划 |
这张表的好处是把“感觉还行”变成可对比的档位，几个面试官打完分能快速对齐。我一般还会在每项后面留一栏“追问记录”，把候选人卡在第几层记下来，复盘时很有用。
最后说一个验证方法：拿资料里任意一个组件的“故障”条目，比如“Hadoop 宕机”“Kafka 挂掉”“Flume 采集数据会丢失吗”，假设它明天就发生在你集群上，写出前三个排查动作和对应的命令。写不出来，说明这个知识点还停在阅读层面。从那以后我每次过完一个组件，都强制自己写一遍“如果它今晚挂了，我先看什么”，这习惯比多背十道题管用。希望帮到你。
本文还有配套的精品资源，点击获取
