简介《2023年史上最全的大数据面试题》面向大数据开发、运维、云计算、数据治理与架构岗位的求职者围绕面试高频考点梳理知识体系也可用于日常查漏补缺。压缩包内含1个docx文档约491KB按章节编排目录覆盖Linux与Shell、Hadoop、Kafka、Hive、HBase、Sqoop、Scala与Spark等模块便于检索。题目涉及HDFS读写、MapReduce Shuffle、YARN调度、Kafka分区副本与数据重复、Hive窗口函数和数据倾斜、HBase RowKey设计、Sqoop一致性、Spark架构与宽窄依赖、Shuffle机制、缓存与checkpoint、TopN实现并附参数调优和项目经验问答。已有882人学习下载适合搭建答题框架、对照项目细节准备陈述并定位薄弱环节。1. 大数据面试的知识地图四条主线与一张复习底盘大数据面试看着像无底洞实际拆开只有四条主线基础设施Linux/Shell、Zookeeper、存储与采集HDFS、Flume、Kafka、HBase、Sqoop、计算与仓库MapReduce、Hive、Spark、Flink、工程与治理数仓分层、建模、元数据、质量监控。这份资料的价值不在题量而在它按“技术栈 项目架构 开发经验 手写代码”铺了一张地图开发、运维、云计算、数据治理、架构师五个方向共用同一套底盘只是考察侧重不同。适合已经上手过集群、准备系统复盘的人而不是零基础速成。2. 基础设施层Linux、Shell 与 Zookeeper 的复习重点这一层是被最多人跳过的部分却也是面试官判断“你到底有没有在机器上干过活”的入口。基础设施的题不难但答得含糊特别扎眼因为它没有太多可以临场发挥的空间会就是会。2.1 Linux 与 Shell从命令到脚本的得分点Linux 部分要分清两档日常排查命令和文本处理命令。前者是top、free、df -h、iostat、netstat、jps、ps -ef这类定位资源与进程的工具后者是grep、sed、awk、sort、uniq、cut、wc这一套管道组合。面试里常给一个场景日志文件几百 G找出访问量前 10 的 IP。标准答法是管道串起来# 统计访问日志中 top10 来源 IP先切字段再排序去重计数最后按次数倒排 awk {print $1} access.log \ | sort \ | uniq -c \ | sort -k1,1nr \ | head -n 10awk {print $1}取第一列实际字段位置按日志格式改uniq -c必须跟在sort后面否则相同内容不相邻就统计不出来这是最高频的翻车点sort -k1,1nr表示按第 1 列、数值、倒序。回答时把每一步的作用说清楚比背出十条命令更有说服力。Shell 部分的重点是变量、条件、循环、位置参数、退出码以及$?、$#、$的区别。调度脚本里常见的写法是判断上一步是否成功再决定是否继续#!/bin/bash # 数仓调度脚本片段上一步失败就退出避免脏数据往下游走 set -e # 任一命令非 0 退出即终止 DT$(date -d -1 day %F) # 取昨天日期作为分区 hive -e insert overwrite table dwd_log partition(dt${DT}) select ... if [ $? -ne 0 ]; then echo dwd load failed on ${DT} 2 exit 1 fiset -e和手工判断$?是两道保险实际项目里通常只留一种避免逻辑绕。日期用date -d计算而不是写死是调度脚本的基本素养。还有个小考点单引号和双引号的区别——单引号内一切原样输出双引号内变量会被展开这在拼 SQL 时错一次就要排查半天。2.2 Zookeeper选举机制与在集群中的角色Zookeeper 在大数据栈里是“隐形地基”Kafka、HBase、Hadoop HA 都靠它做协调。核心考点是Leader 选举集群启动或 Leader 挂掉时进入选举状态每个节点先投自己然后比较(zxid, myid)zxid 大的优先数据更全zxid 相同则 myid 大的胜出得票过半即成为 Leader。这里容易被追问“为什么是过半而不是最多票”答案指向防止脑裂——两个分区各自选出 Leader 会造成数据不一致过半数保证同一时刻最多一个合法 Leader。常用命令要能脱口而出ls看子节点、get取数据、create建节点、delete删节点、stat看状态。还要知道四字命令如stat、mntr用于快速体检。另外要理解临时节点会话断开即消失和顺序节点自动追加递增序号这两个特性它们正是分布式锁和选主的基础。提示被问到“Zookeeper 能存多少数据”时别答容量要答“它用于协调而非存储单节点数据量应控制在很小范围否则影响选举与同步性能”。3. 存储与采集链路HDFS、Flume、Kafka、HBase、Sqoop这条链路是全篇最厚的一块也是面试区分度最高的地方。它的共同主题只有一个数据从产生到落盘中间每一步的可靠性怎么保证。把这句话记住大部分题都能顺着推。3.1 HDFS 读写流程与 Hadoop 调优参数写流程客户端向 NameNode 请求创建文件 → NameNode 返回可写节点列表 → 客户端建立 pipeline 依次写 DataNode → 每个包带确认ack逆流回传 → 写完关闭。读流程客户端请求 NameNode 获取块位置 → 按“就近原则”选副本读取 → 读完一个块再读下一个。面试时要突出两个细节副本放置策略机架感知第一份本机、第二份异机架、第三份同机架另一节点和pipeline 中某个 DataNode 故障时的处理剔除故障节点、剩余节点继续、NameNode 补副本。调优参数属于必须能报出名字的题参数作用调整方向dfs.blocksize块大小大文件场景调大减少元数据压力dfs.namenode.handler.countNameNode 处理线程数按20*log(节点数)估算上调dfs.datanode.max.transfer.threadsDataNode 传输线程高并发读写时上调mapreduce.reduce.shuffle.parallelcopiesShuffle 并行拷贝数大集群适当提高yarn.nodemanager.resource.memory-mb单节点可用内存按实际物理内存的 70%80% 设小文件问题要会讲成因和手段成因是每个文件在 NameNode 占一份元数据百万小文件直接压垮内存手段是输入端合并CombineFileInputFormat、HAR 归档、写入时攒批Flume 调大 batchSize 与 rollInterval、产出端控制分区数。LZO 压缩这类项目经验题要答出“可切分”这个关键点——压缩后仍能分片并行处理代价是需要建索引。3.2 MapReduce Shuffle 与 Yarn 提交流程Shuffle 是 MapReduce 的心脏阶段划分要背得下来Map 端溢写 → 分区排序合并combiner 可选→ Reduce 端拉取 → 归并排序 → 交给 reduce 函数。能讲清“为什么需要排序”就赢了一半排序让相同 key 相邻reduce 才能顺序处理同时为后续归并提供基础。Yarn 提交流程按角色串起来就好记客户端提交应用到 ResourceManager → RM 分配 Container 并启动 ApplicationMaster → AM 向 RM 申请资源 → RM 返回 NodeManager 上的 Container → AM 通知 NM 启动任务 → 任务向 AM 汇报进度 → 全部完成后 AM 注销。调度器三种FIFO单队列先来先服务生产基本不用、Capacity多队列每个队列保底容量适合多团队共享、Fair按权重动态分配短任务响应快。回答时把“多队列、资源隔离、抢占”这几个词带出来比背定义有用。3.3 Flume 事务机制与数据不丢的完整链路Flume 的得分点在两个事务Put 事务发生在 Source 到 Channel 之间批量 put 成功才提交失败回滚重试Take 事务发生在 Channel 到 Sink 之间先取数据Sink 写成功才提交否则回滚。数据丢失的讨论必须落到 Channel 类型MemoryChannel快但进程挂掉会丢FileChannel落盘可靠但慢需要调checkpointInterval、dataDirs多目录、useDualCheckpoints做优化。Taildir Source 配断点续传能防采集端重复与遗漏HDFS Sink 要调batchSize、rollInterval、rollSize控制小文件。3.4 Kafka 的高可靠ISR、副本与不丢不重Kafka 要按“架构—参数—语义”三层答。架构上说清 Producer、Broker、Consumer Group、Partition、Replica 的关系重点在ISR与 Leader 保持同步的副本集合replica.lag.time.max.ms超时的副本被踢出。生产端acks三档0/1/all直接决定可靠性all配合min.insync.replicas2才能保证写入不丢。消费端enable.auto.commitfalse加手工提交才谈得上“精准一次”的基础。分区数估算按目标吞吐除以单分区吞吐副本数生产一般 23。数据积压的排查顺序是先看消费速率是否跟不上生产再看分区数是否成为并行度瓶颈最后看单条处理逻辑是否阻塞。3.5 HBase RowKey 设计与 Sqoop 一致性HBase 的题几乎必问 RowKey。设计原则是长度短、散列均匀、满足查询前缀。长度短是省存储也省索引开销散列均匀是防热点常用hash(主键) 主键或盐值前缀满足前缀是因为 HBase 只支持按 RowKey 前缀扫描。Phoenix 二级索引要能讲清本质建索引表查询走索引表定位 RowKey 再回主表覆盖索引可免回表。Sqoop 的重点是一致性导出时用--query加WHERE条件分片注意$CONDITIONS必须写Null 存储不一致靠--null-string与--null-non-string统一底层跑的是 Map 任务只有 map 无 reduce。被问“一天导多少数据”这类题要给量级加推导方式而不是硬报一个数。4. 计算与仓库层Hive、Spark、Flink 的递进关系这三者不是并列关系而是批处理 → 内存迭代 → 流批一体的演进链。面试里能把这条链讲顺比单独答对十道题更能体现体系感。4.1 Hive架构、四个 By 与优化套路Hive 架构记四层外部客户端 → 服务层HS2、metastore→ 驱动层解析器、编译器、优化器、执行器→ 存储层HDFS。内部表与外部表的差别就一句话内部表删表删数据外部表删表不删数据生产 ODS 层多用外部表。四个 By 是经典送分题order by全局排序单 reduce、sort by单 reduce 内有序、distribute by按字段分 Reduce、cluster by等于 distribute sort 同字段。窗口函数要能写出典型场景比如求每个用户最近一次登录-- 按用户分组、时间倒序编号取 rn1 即最近一次登录 select user_id, login_time from ( select user_id, login_time, row_number() over(partition by user_id order by login_time desc) as rn from user_login_log ) t where rn 1;partition by决定分组order by决定组内排序row_number不重复不跳号、rank跳号、dense_rank不跳号这三个的差异是常考细节。Hive 优化按“表设计—SQL 写法—引擎参数”三层答分区表 分桶表、ORC/Parquet 列式存储、map join小表广播、group by开启负载均衡、count(distinct)改写为先 group 再 count、数据倾斜用加盐或hive.groupby.skewindata。动态分区要答出“最后一个分区字段来自查询结果、需开启hive.exec.dynamic.partition”。4.2 SparkRDD 血统、宽窄依赖与 Shuffle 演进Spark 的主干是RDD 血统 DAG 划分 Shuffle。血统lineage记录 RDD 之间的转换关系某个分区丢失时按血统重算这是容错的根本配合 checkpoint 切断过长血统。宽窄依赖的判定标准是“父分区是否被多个子分区使用”窄依赖一对一map、filter宽依赖一对多groupByKey、joinStage 按宽依赖切分最后一个 Stage 的 task 数由分区数决定。Spark 的两种 Shuffle 是必答未优化 HashShuffle 每个 task 为每个 reduce 生成一个文件文件数爆炸优化后引入 Conslidator 合并SortShuffle 每个 task 写一个数据文件加一个索引文件reduce 按索引拉取。reduceByKey与groupByKey的区别核心是前者在 map 端先做本地聚合数据量小得多所以优先。提交参数要能报出来并说明为什么--executor-memory、--num-executors、--executor-cores、--driver-memory以及spark.default.parallelism、spark.sql.shuffle.partitions默认 200小数据量要下调。缓存与 checkpoint 的区别cache 存内存、不改血统、不可靠checkpoint 落可靠存储、切断血统、可靠但慢。4.3 Spark Streaming 与 Structured 消费 Kafka要答清消费 Kafka 的两种方式Receiver 方式接收后存到 executor 内存配合 WAL 防丢并行度与分区不直接绑定与Direct 方式直连分区分区即并行度靠 offset 手工管理实现精准一次。背压backpressure是动态限速spark.streaming.backpressure.enabled开启后按处理能力反推拉取速率。优雅关闭用ssc.stop(stopGracefullytrue)配合停调度、等在途批次跑完。4.4 Flink时间语义、窗口、状态与 Exactly-onceFlink 的题按“模型—时间—状态—容错”走。编程模型是 Source → Transformation → Sink运行时角色是 JobManager协调、调度、检查点与 TaskManager执行、Slot 划分资源。Slot 与并行度的区别Slot 是资源单位并行度是任务实例数一个 Slot 可跑多个并行子任务slot sharing。时间语义三类事件时间、处理时间、摄入时间。水印watermark是用来处理乱序的“进度标尺”表示“事件时间小于该值的数据已基本到齐”触发窗口计算。容错靠分布式快照Checkpoint基于轻量级异步快照在数据流中插入屏障barrier对齐实现 Exactly-once端到端精准一次还要 Sink 支持事务或幂等。算子链Operator Chain是把满足条件的前后算子合并到一个线程减少序列化开销条件是同并行度、非 shuffle、非禁用链。反压的排查路径要说得出先看 UI 里的 backpressure 指标定位瓶颈算子再看是否数据倾斜或外部系统写入慢解决手段包括调大并行度、拆分热点 key、异步 IO。5. 数仓建模与数据治理从分层到拉链表技术栈会跑不算完面试后半程基本都在问“你做过什么仓”。这部分答不好前面全白搭。5.1 分层架构与同步策略分层要能说出每层职责ODS 贴源、DWD 明细清洗、DWS 轻度汇总、ADS 应用层。每层用什么压缩和存储格式是高频率追问ODS 常用压缩 行式或列式原样保留DWD 之后多用 Parquet/ORC 加压缩。同步策略分全量同步数据量小、变化频繁的表与增量同步按时间戳或自增 ID 拉取拉链表用来处理缓慢变化维核心是start_time、end_time加一个is_current标记更新时关闭旧链、开新链。5.2 用户行为与业务指标用户行为分析有一套固定问法活跃、新增、留存、沉默、回流、流失、连续 N 天活跃。这类题统一套路是“先定口径再写 SQL”。比如次日留存取当日新增用户集合与次日有行为的用户集合做 join比值即留存率。连续三天活跃则用日期减去行号构造分组标记-- 计算最近 7 天内连续 3 天活跃的用户日期减行号得到连续分组标识 select user_id from ( select user_id, dt, date_sub(dt, rn) as grp from ( select user_id, dt, row_number() over(partition by user_id order by dt) as rn from user_active_log where dt date_sub(current_date, 7) ) t1 ) t2 group by user_id, grp having count(1) 3;逻辑说明同一用户连续日期的dt - rn是常量因此按该常量分组后计数即为连续天数date_sub的第二个参数就是行号。参数上注意current_date与分区字段的时区一致性跨时区场景要统一到同一时区再算。6. 易漏易错点八个高频翻车现场易漏点一Shuffle 排序的目的说不清。漏在只背流程不背动机被追问“不排序行不行”就卡住。补法是记住排序为了 key 相邻与归并以及 reduce 侧有序输入。易漏点二Flume 与 Kafka 的“不丢”混为一谈。漏在把两者可靠性机制当成同一件事。补法是把 Flume 讲成事务 Channel 持久化把 Kafka 讲成副本 acks 手工提交 offset分别落到具体参数。易漏点三数据倾斜只背方案不讲定位。漏在直接甩“加盐、调并行度”却没说过怎么发现。补法是先讲现象个别 task 长时间不结束、某 task 输入量远大于其他再讲查看 key 分布抽样 count 排序最后才给方案且方案要分 map 端聚合、join 小表广播、大表加盐三类。易漏点四Hive 与数据库的区别答成一句话。漏在只答“一个基于 HDFS 一个基于本地”。补法是从延迟、事务、索引、数据规模、更新能力五个维度对比形成表格记忆。易漏点五Spark 缓存与 checkpoint 的关系答反。漏在只说“都存数据”。补法是强调 cache 不改血统不可靠、checkpoint 改血统可靠二者常组合使用先 cache 后 checkpoint。易漏点六Flink 的 Slot 与并行度互换概念。漏在名词相近就混用。补法是一句话锚定Slot 是资源槽并行度是任务份数。7. 复习清单按天推进的查漏补缺路线把这份资料当题库刷效率很低当地图用才有价值。我的做法是先按“基础设施 → 存储采集 → 计算仓库 → 建模治理 → 代码手写”五块画一张表每块填三个格子能一句话讲清的核心机制、能报出名字的关键参数、能现场写出的代码或 SQL。三个格子填不满的就是当天要补的洞。具体节奏可以这样排第一天只做 HDFS 读写流程加 Yarn 提交流程要求能不看资料画出来第二天 Kafka 与 Flume 放一起专攻“数据丢不丢”这条线把 acks、ISR、Channel 类型、offset 提交四个点串成一条因果链第三天 Hive 优化与四个 By配三道窗口函数 SQL 手写第四天 Spark 血统、宽窄依赖、两种 Shuffle再手写 WordCount 与 TopN第五天 Flink 时间语义、水印、Checkpoint第六天专攻数据倾斜与数仓分层把拉链表和连续 N 天活跃各写一遍第七天只做一件事——把前面所有“答不顺”的题重答一遍用手机录音回听。手写代码这块单独练别指望临场发挥。排序、二分、快排、归并这四个属于基本盘Spark WordCount 要能默写HQL 至少练熟连续活跃、留存、TopN、行转列这几类。练的时候强制加注释因为面试写代码时解释思路的分数往往高于代码本身。还有一个习惯值得养成每道题答完追问自己一句“如果面试官再往下问一层我接得住吗”。HDFS 写流程往下是 pipeline 故障处理Kafka 不丢往下是 ISR 收缩条件Spark 调优往下是数据倾斜定位——这一层能接住才算真的会。从那以后我每次复习都强制走一遍“机制—参数—代码”三格自检填不满的立刻回炉绝不靠“大概记得”蒙混过去。希望这份地图帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/27 2:13:12 · 阅读 1.2k 大数据面试复习地图：技术栈、项目架构与手写代码
简介《2023年史上最全的大数据面试题》面向大数据开发、运维、云计算、数据治理与架构岗位的求职者围绕面试高频考点梳理知识体系也可用于日常查漏补缺。压缩包内含1个docx文档约491KB按章节编排目录覆盖Linux与Shell、Hadoop、Kafka、Hive、HBase、Sqoop、Scala与Spark等模块便于检索。题目涉及HDFS读写、MapReduce Shuffle、YARN调度、Kafka分区副本与数据重复、Hive窗口函数和数据倾斜、HBase RowKey设计、Sqoop一致性、Spark架构与宽窄依赖、Shuffle机制、缓存与checkpoint、TopN实现并附参数调优和项目经验问答。已有882人学习下载适合搭建答题框架、对照项目细节准备陈述并定位薄弱环节。1. 大数据面试的知识地图四条主线与一张复习底盘大数据面试看着像无底洞实际拆开只有四条主线基础设施Linux/Shell、Zookeeper、存储与采集HDFS、Flume、Kafka、HBase、Sqoop、计算与仓库MapReduce、Hive、Spark、Flink、工程与治理数仓分层、建模、元数据、质量监控。这份资料的价值不在题量而在它按“技术栈 项目架构 开发经验 手写代码”铺了一张地图开发、运维、云计算、数据治理、架构师五个方向共用同一套底盘只是考察侧重不同。适合已经上手过集群、准备系统复盘的人而不是零基础速成。2. 基础设施层Linux、Shell 与 Zookeeper 的复习重点这一层是被最多人跳过的部分却也是面试官判断“你到底有没有在机器上干过活”的入口。基础设施的题不难但答得含糊特别扎眼因为它没有太多可以临场发挥的空间会就是会。2.1 Linux 与 Shell从命令到脚本的得分点Linux 部分要分清两档日常排查命令和文本处理命令。前者是top、free、df -h、iostat、netstat、jps、ps -ef这类定位资源与进程的工具后者是grep、sed、awk、sort、uniq、cut、wc这一套管道组合。面试里常给一个场景日志文件几百 G找出访问量前 10 的 IP。标准答法是管道串起来# 统计访问日志中 top10 来源 IP先切字段再排序去重计数最后按次数倒排 awk {print $1} access.log \ | sort \ | uniq -c \ | sort -k1,1nr \ | head -n 10awk {print $1}取第一列实际字段位置按日志格式改uniq -c必须跟在sort后面否则相同内容不相邻就统计不出来这是最高频的翻车点sort -k1,1nr表示按第 1 列、数值、倒序。回答时把每一步的作用说清楚比背出十条命令更有说服力。Shell 部分的重点是变量、条件、循环、位置参数、退出码以及$?、$#、$的区别。调度脚本里常见的写法是判断上一步是否成功再决定是否继续#!/bin/bash # 数仓调度脚本片段上一步失败就退出避免脏数据往下游走 set -e # 任一命令非 0 退出即终止 DT$(date -d -1 day %F) # 取昨天日期作为分区 hive -e insert overwrite table dwd_log partition(dt${DT}) select ... if [ $? -ne 0 ]; then echo dwd load failed on ${DT} 2 exit 1 fiset -e和手工判断$?是两道保险实际项目里通常只留一种避免逻辑绕。日期用date -d计算而不是写死是调度脚本的基本素养。还有个小考点单引号和双引号的区别——单引号内一切原样输出双引号内变量会被展开这在拼 SQL 时错一次就要排查半天。2.2 Zookeeper选举机制与在集群中的角色Zookeeper 在大数据栈里是“隐形地基”Kafka、HBase、Hadoop HA 都靠它做协调。核心考点是Leader 选举集群启动或 Leader 挂掉时进入选举状态每个节点先投自己然后比较(zxid, myid)zxid 大的优先数据更全zxid 相同则 myid 大的胜出得票过半即成为 Leader。这里容易被追问“为什么是过半而不是最多票”答案指向防止脑裂——两个分区各自选出 Leader 会造成数据不一致过半数保证同一时刻最多一个合法 Leader。常用命令要能脱口而出ls看子节点、get取数据、create建节点、delete删节点、stat看状态。还要知道四字命令如stat、mntr用于快速体检。另外要理解临时节点会话断开即消失和顺序节点自动追加递增序号这两个特性它们正是分布式锁和选主的基础。提示被问到“Zookeeper 能存多少数据”时别答容量要答“它用于协调而非存储单节点数据量应控制在很小范围否则影响选举与同步性能”。3. 存储与采集链路HDFS、Flume、Kafka、HBase、Sqoop这条链路是全篇最厚的一块也是面试区分度最高的地方。它的共同主题只有一个数据从产生到落盘中间每一步的可靠性怎么保证。把这句话记住大部分题都能顺着推。3.1 HDFS 读写流程与 Hadoop 调优参数写流程客户端向 NameNode 请求创建文件 → NameNode 返回可写节点列表 → 客户端建立 pipeline 依次写 DataNode → 每个包带确认ack逆流回传 → 写完关闭。读流程客户端请求 NameNode 获取块位置 → 按“就近原则”选副本读取 → 读完一个块再读下一个。面试时要突出两个细节副本放置策略机架感知第一份本机、第二份异机架、第三份同机架另一节点和pipeline 中某个 DataNode 故障时的处理剔除故障节点、剩余节点继续、NameNode 补副本。调优参数属于必须能报出名字的题参数作用调整方向dfs.blocksize块大小大文件场景调大减少元数据压力dfs.namenode.handler.countNameNode 处理线程数按20*log(节点数)估算上调dfs.datanode.max.transfer.threadsDataNode 传输线程高并发读写时上调mapreduce.reduce.shuffle.parallelcopiesShuffle 并行拷贝数大集群适当提高yarn.nodemanager.resource.memory-mb单节点可用内存按实际物理内存的 70%80% 设小文件问题要会讲成因和手段成因是每个文件在 NameNode 占一份元数据百万小文件直接压垮内存手段是输入端合并CombineFileInputFormat、HAR 归档、写入时攒批Flume 调大 batchSize 与 rollInterval、产出端控制分区数。LZO 压缩这类项目经验题要答出“可切分”这个关键点——压缩后仍能分片并行处理代价是需要建索引。3.2 MapReduce Shuffle 与 Yarn 提交流程Shuffle 是 MapReduce 的心脏阶段划分要背得下来Map 端溢写 → 分区排序合并combiner 可选→ Reduce 端拉取 → 归并排序 → 交给 reduce 函数。能讲清“为什么需要排序”就赢了一半排序让相同 key 相邻reduce 才能顺序处理同时为后续归并提供基础。Yarn 提交流程按角色串起来就好记客户端提交应用到 ResourceManager → RM 分配 Container 并启动 ApplicationMaster → AM 向 RM 申请资源 → RM 返回 NodeManager 上的 Container → AM 通知 NM 启动任务 → 任务向 AM 汇报进度 → 全部完成后 AM 注销。调度器三种FIFO单队列先来先服务生产基本不用、Capacity多队列每个队列保底容量适合多团队共享、Fair按权重动态分配短任务响应快。回答时把“多队列、资源隔离、抢占”这几个词带出来比背定义有用。3.3 Flume 事务机制与数据不丢的完整链路Flume 的得分点在两个事务Put 事务发生在 Source 到 Channel 之间批量 put 成功才提交失败回滚重试Take 事务发生在 Channel 到 Sink 之间先取数据Sink 写成功才提交否则回滚。数据丢失的讨论必须落到 Channel 类型MemoryChannel快但进程挂掉会丢FileChannel落盘可靠但慢需要调checkpointInterval、dataDirs多目录、useDualCheckpoints做优化。Taildir Source 配断点续传能防采集端重复与遗漏HDFS Sink 要调batchSize、rollInterval、rollSize控制小文件。3.4 Kafka 的高可靠ISR、副本与不丢不重Kafka 要按“架构—参数—语义”三层答。架构上说清 Producer、Broker、Consumer Group、Partition、Replica 的关系重点在ISR与 Leader 保持同步的副本集合replica.lag.time.max.ms超时的副本被踢出。生产端acks三档0/1/all直接决定可靠性all配合min.insync.replicas2才能保证写入不丢。消费端enable.auto.commitfalse加手工提交才谈得上“精准一次”的基础。分区数估算按目标吞吐除以单分区吞吐副本数生产一般 23。数据积压的排查顺序是先看消费速率是否跟不上生产再看分区数是否成为并行度瓶颈最后看单条处理逻辑是否阻塞。3.5 HBase RowKey 设计与 Sqoop 一致性HBase 的题几乎必问 RowKey。设计原则是长度短、散列均匀、满足查询前缀。长度短是省存储也省索引开销散列均匀是防热点常用hash(主键) 主键或盐值前缀满足前缀是因为 HBase 只支持按 RowKey 前缀扫描。Phoenix 二级索引要能讲清本质建索引表查询走索引表定位 RowKey 再回主表覆盖索引可免回表。Sqoop 的重点是一致性导出时用--query加WHERE条件分片注意$CONDITIONS必须写Null 存储不一致靠--null-string与--null-non-string统一底层跑的是 Map 任务只有 map 无 reduce。被问“一天导多少数据”这类题要给量级加推导方式而不是硬报一个数。4. 计算与仓库层Hive、Spark、Flink 的递进关系这三者不是并列关系而是批处理 → 内存迭代 → 流批一体的演进链。面试里能把这条链讲顺比单独答对十道题更能体现体系感。4.1 Hive架构、四个 By 与优化套路Hive 架构记四层外部客户端 → 服务层HS2、metastore→ 驱动层解析器、编译器、优化器、执行器→ 存储层HDFS。内部表与外部表的差别就一句话内部表删表删数据外部表删表不删数据生产 ODS 层多用外部表。四个 By 是经典送分题order by全局排序单 reduce、sort by单 reduce 内有序、distribute by按字段分 Reduce、cluster by等于 distribute sort 同字段。窗口函数要能写出典型场景比如求每个用户最近一次登录-- 按用户分组、时间倒序编号取 rn1 即最近一次登录 select user_id, login_time from ( select user_id, login_time, row_number() over(partition by user_id order by login_time desc) as rn from user_login_log ) t where rn 1;partition by决定分组order by决定组内排序row_number不重复不跳号、rank跳号、dense_rank不跳号这三个的差异是常考细节。Hive 优化按“表设计—SQL 写法—引擎参数”三层答分区表 分桶表、ORC/Parquet 列式存储、map join小表广播、group by开启负载均衡、count(distinct)改写为先 group 再 count、数据倾斜用加盐或hive.groupby.skewindata。动态分区要答出“最后一个分区字段来自查询结果、需开启hive.exec.dynamic.partition”。4.2 SparkRDD 血统、宽窄依赖与 Shuffle 演进Spark 的主干是RDD 血统 DAG 划分 Shuffle。血统lineage记录 RDD 之间的转换关系某个分区丢失时按血统重算这是容错的根本配合 checkpoint 切断过长血统。宽窄依赖的判定标准是“父分区是否被多个子分区使用”窄依赖一对一map、filter宽依赖一对多groupByKey、joinStage 按宽依赖切分最后一个 Stage 的 task 数由分区数决定。Spark 的两种 Shuffle 是必答未优化 HashShuffle 每个 task 为每个 reduce 生成一个文件文件数爆炸优化后引入 Conslidator 合并SortShuffle 每个 task 写一个数据文件加一个索引文件reduce 按索引拉取。reduceByKey与groupByKey的区别核心是前者在 map 端先做本地聚合数据量小得多所以优先。提交参数要能报出来并说明为什么--executor-memory、--num-executors、--executor-cores、--driver-memory以及spark.default.parallelism、spark.sql.shuffle.partitions默认 200小数据量要下调。缓存与 checkpoint 的区别cache 存内存、不改血统、不可靠checkpoint 落可靠存储、切断血统、可靠但慢。4.3 Spark Streaming 与 Structured 消费 Kafka要答清消费 Kafka 的两种方式Receiver 方式接收后存到 executor 内存配合 WAL 防丢并行度与分区不直接绑定与Direct 方式直连分区分区即并行度靠 offset 手工管理实现精准一次。背压backpressure是动态限速spark.streaming.backpressure.enabled开启后按处理能力反推拉取速率。优雅关闭用ssc.stop(stopGracefullytrue)配合停调度、等在途批次跑完。4.4 Flink时间语义、窗口、状态与 Exactly-onceFlink 的题按“模型—时间—状态—容错”走。编程模型是 Source → Transformation → Sink运行时角色是 JobManager协调、调度、检查点与 TaskManager执行、Slot 划分资源。Slot 与并行度的区别Slot 是资源单位并行度是任务实例数一个 Slot 可跑多个并行子任务slot sharing。时间语义三类事件时间、处理时间、摄入时间。水印watermark是用来处理乱序的“进度标尺”表示“事件时间小于该值的数据已基本到齐”触发窗口计算。容错靠分布式快照Checkpoint基于轻量级异步快照在数据流中插入屏障barrier对齐实现 Exactly-once端到端精准一次还要 Sink 支持事务或幂等。算子链Operator Chain是把满足条件的前后算子合并到一个线程减少序列化开销条件是同并行度、非 shuffle、非禁用链。反压的排查路径要说得出先看 UI 里的 backpressure 指标定位瓶颈算子再看是否数据倾斜或外部系统写入慢解决手段包括调大并行度、拆分热点 key、异步 IO。5. 数仓建模与数据治理从分层到拉链表技术栈会跑不算完面试后半程基本都在问“你做过什么仓”。这部分答不好前面全白搭。5.1 分层架构与同步策略分层要能说出每层职责ODS 贴源、DWD 明细清洗、DWS 轻度汇总、ADS 应用层。每层用什么压缩和存储格式是高频率追问ODS 常用压缩 行式或列式原样保留DWD 之后多用 Parquet/ORC 加压缩。同步策略分全量同步数据量小、变化频繁的表与增量同步按时间戳或自增 ID 拉取拉链表用来处理缓慢变化维核心是start_time、end_time加一个is_current标记更新时关闭旧链、开新链。5.2 用户行为与业务指标用户行为分析有一套固定问法活跃、新增、留存、沉默、回流、流失、连续 N 天活跃。这类题统一套路是“先定口径再写 SQL”。比如次日留存取当日新增用户集合与次日有行为的用户集合做 join比值即留存率。连续三天活跃则用日期减去行号构造分组标记-- 计算最近 7 天内连续 3 天活跃的用户日期减行号得到连续分组标识 select user_id from ( select user_id, dt, date_sub(dt, rn) as grp from ( select user_id, dt, row_number() over(partition by user_id order by dt) as rn from user_active_log where dt date_sub(current_date, 7) ) t1 ) t2 group by user_id, grp having count(1) 3;逻辑说明同一用户连续日期的dt - rn是常量因此按该常量分组后计数即为连续天数date_sub的第二个参数就是行号。参数上注意current_date与分区字段的时区一致性跨时区场景要统一到同一时区再算。6. 易漏易错点八个高频翻车现场易漏点一Shuffle 排序的目的说不清。漏在只背流程不背动机被追问“不排序行不行”就卡住。补法是记住排序为了 key 相邻与归并以及 reduce 侧有序输入。易漏点二Flume 与 Kafka 的“不丢”混为一谈。漏在把两者可靠性机制当成同一件事。补法是把 Flume 讲成事务 Channel 持久化把 Kafka 讲成副本 acks 手工提交 offset分别落到具体参数。易漏点三数据倾斜只背方案不讲定位。漏在直接甩“加盐、调并行度”却没说过怎么发现。补法是先讲现象个别 task 长时间不结束、某 task 输入量远大于其他再讲查看 key 分布抽样 count 排序最后才给方案且方案要分 map 端聚合、join 小表广播、大表加盐三类。易漏点四Hive 与数据库的区别答成一句话。漏在只答“一个基于 HDFS 一个基于本地”。补法是从延迟、事务、索引、数据规模、更新能力五个维度对比形成表格记忆。易漏点五Spark 缓存与 checkpoint 的关系答反。漏在只说“都存数据”。补法是强调 cache 不改血统不可靠、checkpoint 改血统可靠二者常组合使用先 cache 后 checkpoint。易漏点六Flink 的 Slot 与并行度互换概念。漏在名词相近就混用。补法是一句话锚定Slot 是资源槽并行度是任务份数。7. 复习清单按天推进的查漏补缺路线把这份资料当题库刷效率很低当地图用才有价值。我的做法是先按“基础设施 → 存储采集 → 计算仓库 → 建模治理 → 代码手写”五块画一张表每块填三个格子能一句话讲清的核心机制、能报出名字的关键参数、能现场写出的代码或 SQL。三个格子填不满的就是当天要补的洞。具体节奏可以这样排第一天只做 HDFS 读写流程加 Yarn 提交流程要求能不看资料画出来第二天 Kafka 与 Flume 放一起专攻“数据丢不丢”这条线把 acks、ISR、Channel 类型、offset 提交四个点串成一条因果链第三天 Hive 优化与四个 By配三道窗口函数 SQL 手写第四天 Spark 血统、宽窄依赖、两种 Shuffle再手写 WordCount 与 TopN第五天 Flink 时间语义、水印、Checkpoint第六天专攻数据倾斜与数仓分层把拉链表和连续 N 天活跃各写一遍第七天只做一件事——把前面所有“答不顺”的题重答一遍用手机录音回听。手写代码这块单独练别指望临场发挥。排序、二分、快排、归并这四个属于基本盘Spark WordCount 要能默写HQL 至少练熟连续活跃、留存、TopN、行转列这几类。练的时候强制加注释因为面试写代码时解释思路的分数往往高于代码本身。还有一个习惯值得养成每道题答完追问自己一句“如果面试官再往下问一层我接得住吗”。HDFS 写流程往下是 pipeline 故障处理Kafka 不丢往下是 ISR 收缩条件Spark 调优往下是数据倾斜定位——这一层能接住才算真的会。从那以后我每次复习都强制走一遍“机制—参数—代码”三格自检填不满的立刻回炉绝不靠“大概记得”蒙混过去。希望这份地图帮到你。本文还有配套的精品资源点击获取