去面大数据岗位，不管是校招还是社招，问来问去其实就那么几类问题。早年大家还在背“Hadoop生态有哪些组件”，现在面试官更爱追问原理、场景题和手写SQL。我在一线做了几年数仓和实时计算，也面过不少人，今天就把大数据面试里最容易遇到、也最能拉开差距的常见问题梳理一遍，顺带说说我当时怎么准备、怎么答才不翻车。
这篇文章适合三类人：刚准备投简历的校招生、想转行大数据开发/数仓的社招同学、以及面试前想快速过一遍核心知识点的在职工程师。我会按照面试官提问的逻辑来组织内容，从基础原理到场景设计，再到实战排查，尽量做到你读完能直接照着查漏补缺。
1. 面试考核全景与准备思路
1.1 面试官到底在考察什么
大数据岗位面了很多轮之后，你会发现面试官并不是真想知道某个API怎么调，而是想看三件事：第一，你对底层原理的理解深度；第二，你在真实场景里做过什么决策、遇到过什么问题；第三，你把一个模糊问题拆解清楚并落地的能力。
举一个最常见的例子：面试官问“HDFS写流程是什么”，初级候选人会背“客户端向NameNode请求，NameNode返回DataNode列表，然后客户端写数据”。但这个答案只能拿及格分。面试官接下来一定会追问：如果某个DataNode写失败了怎么办？副本怎么选？机架感知是什么？有没有读过源码？这些问题才是真正区分有没有实际经验的点。
准备面试的时候，不要只准备“是什么”，要准备“为什么”。比如Spark的宽窄依赖为什么影响Stage划分，Flink的Checkpoint为什么能实现精确一次，Kafka的ISR机制到底解决了什么问题。把每个框架核心机制的背景、解决方案、权衡取舍讲清楚，面试官才会觉得你不是背题，而是真的理解。
1.2 怎么制定自己的复习主线
大数据知识体系太大，如果眉毛胡子一把抓，复习效率会非常低。我建议按照岗位方向来分主线：偏向离线数仓的，重点复习Hive、Spark SQL、数仓建模、调度系统；偏向实时计算的，重点复习Kafka、Flink、状态管理、实时数仓架构；偏向平台开发的，重点复习HDFS/Yarn/K8s的源码级原理和集群调优。
主线定了之后，再用项目经历把知识点串起来。比如你简历上写了“做过用户行为分析”，那就要准备几条线：数据从哪来（埋点/采集）、怎么传（Kafka）、怎么存（HDFS/数仓分层）、怎么算（Spark/Flink）、怎么调度（XX调度平台）、怎么保障质量（数据校验/监控告警）。每一条线都能延伸出两三个面试官常问的技术点。
面试前一周，花两天把每条主线的原理问题写成自己的话，口头复述一遍。不要背原文，要能像跟同事聊天一样讲出来。这个练习会暴露很多你以为懂但其实讲不清楚的地方，趁还没上战场，把这些漏洞补掉比多刷十道题都值。
2. HDFS与Hadoop核心考点：读写流程、安全模式、小文件
2.1 读写流程与副本机制
HDFS的读写流程是大数据面试的送分题，但很多人拿不到满分。我们先说写流程，我建议你按这样的逻辑来答：
客户端要写一个文件时，先向NameNode发起请求，NameNode检查权限和路径后，返回可写入的DataNode列表。客户端把数据分成一个个packet，先把第一个packet写到第一个DataNode，这个DataNode再以流水线方式把数据传给第二个、第三个DataNode。每写完一个副本，DataNode会返回确认消息，客户端收到确认后再写下一个packet。整个文件写完后，客户端调用close，NameNode提交文件元数据。
这里面试官有三个高频追问点。第一个是“副本为什么是3”，这既是对硬件故障的容忍，也是带宽和存储的权衡，第三个副本放在哪里也有讲究。第二个是“如果流水线中间某个DataNode挂了怎么办”，客户端会把这个DataNode从管道里移除，把未确认的packet重新发给下一个DataNode继续写，同时NameNode会安排重新复制副本。第三个是“读流程和写有什么不同”，读的时候客户端先问NameNode要文件块位置，然后按就近原则从DataNode读取，如果读到损坏的块，会换一个副本重新读。
机架感知也是常客。默认情况下，副本策略是第一个副本放在客户端所在节点，第二个放在同机架另一个节点，第三个放在不同机架。这样既能抗机器故障，也能抗机架故障，同时写的时候利用机架间带宽、可能降低跨机架读的概率。回答时如果能把“网络拓扑距离和容错性”这两点一起说，面试官会明显觉得你考虑问题更全面。
2.2 安全模式、小文件、数据倾斜
关于安全模式，面试官一般会问“NameNode启动时为什么一直是SafeMode”。你要答出关键点：NameNode启动时要加载FsImage和EditLog，同时DataNode会汇报自己持有的Block信息。只有当某个文件块的副本数达到最小副本数时，这个块才算安全。当安全块比例超过阈值，NameNode才会退出安全模式。这里有个细节，如果集群里副本数长期不足，NameNode会一直待在安全模式，这时候需要排查是不是有批量宕机或磁盘写满的情况。
小文件问题基本是送命题。小文件多，意味着NameNode内存里要维护大量元数据，一个文件块对象可能占几百字节，上千万个小文件直接能把NameNode内存压爆。另外，无论文件多小，每个Map/Task都要启动一个计算进程，启动开销远大于计算本身，跑批任务会变得非常慢。解决办法要看场景：如果是Hive表产生很多小文件，可以设置Hive的合并参数，或者用Spark的coalesce/repartition统一输出文件数；如果是历史遗留的小文件，可以在不改变数据内容的情况下用HDFS的Concat接口或跑一个临时任务重写数据。
数据倾斜也是面试重灾区。一定要能区分两种情况：GroupBy倾斜和Join倾斜。GroupBy倾斜的常见解法是加随机前缀打散热点Key，先用随机Key做局部聚合，再去掉前缀做全局聚合；Join倾斜则要看是不是大表Join大表，如果是一张大表Join一张小表，可以用MapJoin广播小表，彻底避免Shuffle。如果是两个大表Join且某个Key数量极多，可以先把热点Key拆出来，分别走MapJoin和正常Join，最后合并结果。答的时候最好画一下数据流程图，把“为什么倾斜—怎么发现—怎么解决”讲成一个完整故事。
3. 计算引擎高频题：Spark作业流程与Flink状态一致性
3.1 Spark 调度原理和调优点
Spark最常见的问题就是“Spark作业从提交到运行经历了什么”。我建议按这个顺序答：提交代码后，Driver创建SparkContext，然后根据代码里的RDD算子构建DAG（有向无环图）。DAGScheduler拿到DAG之后，会把整个Graph按照宽依赖切割成多个Stage，每个Stage内部包含一组可以并行执行的Task。每一批Task由TaskScheduler分发到Executor上运行，Executor里的Task线程负责真正的计算。
宽依赖和窄依赖的区别一定要讲透。窄依赖是父RDD的每个分区只被子RDD的一个分区使用，典型的map、filter、union；宽依赖是父RDD一个分区会被子RDD的多个分区使用，典型的就是groupByKey、reduceByKey、join。宽依赖意味着必须发生Shuffle，Shuffle要把父分区数据按Key重新分区并跨网络传输，这就是Stage切割点。实际调优中，减少Shuffle就是减少宽依赖，能用reduceByKey就不用groupByKey再算。
关于Spark内存管理，面试官大概率会问“Executor内存怎么划分”。基本分为Storage内存、Execution内存和保留内存。Storage负责缓存RDD数据，Execution负责Shuffle、Join、Sort等计算。Spark 2.0之后这两块内存是统一管理的，且可以互相借用，这样做的目的是为了提升内存利用率。不过借用有代价，如果某个任务因为Execution抢占Storage导致缓存被驱逐，后续读取缓存数据就可能重新计算。回答时可以把spark.memory.fraction、spark.sql.shuffle.partitions这些参数结合自己的调优案例说，会更有说服力。
我面试别人时，还喜欢问“Spark为什么比MapReduce快”。不是快在内存，而是快在两点：一是DAG可以将多个计算阶段合并成一个Task，减少中间结果落盘；二是Spark尽量把中间结果放在内存里，而MapReduce每个Map/Reduce之间都要写磁盘。如果候选人能提到“Spark的Shuffle是可以优化的，而MR的Shuffle机制基本固定”，那说明他对两个引擎都有对比认识。
3.2 Flink 状态、Checkpoint与精确一次
近两年Flink几乎是实时岗位的必考项。面试官问Flink，最喜欢问“Flink如何实现精确一次语义”。这个问题要从两层讲：第一层是Flink的Checkpoint机制，通过Barrier（屏障）在数据流中周期性插入，Barrier到达某个算子时，该算子把当前状态快照保存到持久化存储；第二层是端到端的一致性，光有状态快照还不够，还要保证数据源和结果存储的原子性，所以Kafka和Flink之间通常要配合两阶段提交协议。
Flink里还有几个容易混淆的概念：状态（State）和状态后端（StateBackend）。状态是算子运行过程中保存的中间数据，比如窗口累加值、KeyedStream每个Key的Count值。状态后端负责决定状态存在哪里、怎么管理，包括内存式、文件式和RocksDB式。面试官如果问“大状态场景用什么后端”，一定要答RocksDB，因为可以把状态落盘到磁盘，而不是无限往堆内存塞。
水位线（Watermark）也是必考。它本质是“事件时间的当前进展”，用来处理乱序数据。需要理解三个点：水位线如何生成（周期性或根据特定事件）、水位线如何传播（取上游的最小值）、触发窗口计算的条件（窗口结束时间小于等于Watermark）。回答时最好给一个具体场景：比如一个5秒的滚动窗口，允许2秒延迟，那么当Watermark推进到7秒时，这个窗口才真正被触发计算。这里面试官还喜欢问“迟到的数据怎么办”，可以答“允许延迟重算或收集到侧输出流单独处理”。
4. 数仓设计与SQL高频考点
4.1 数仓分层和建模理论
数仓方向面试第一题基本就是“你们数仓怎么分层，为什么分层”。通用分层是ODS（原始数据层）、DWD（明细层）、DWS（汇总层）、ADS（应用层）。ODS保持原样落地，DWD做清洗、去重、维度退化，DWS按主题做轻度汇总，ADS面向业务出报表。分层的核心目的不是“好看”，而是为了控制数据流向、减少重复计算、提高数据质量，同时让不同团队在各自层级拥有清晰的权责边界。
建模理论方面，面试官会问“讲一下维度建模”。你需要能说出事实表、维度表、星型模型、雪花模型这组概念的差别。事实表存的是可度量的业务过程，比如订单表、支付表，里面有很多外键和度量值；维度表存的是描述事实的上下文，比如用户维度、商品维度。星型模型是维度表直接与事实表关联，雪花模型是维度表继续做规范化拆开。实际项目里星型用得最多，因为查询性能更好，理解成本更低。
还有一个绕不开的点是缓慢变化维（SCD）。比如用户所在的城市变了，你到底是直接更新旧值，还是保留多条记录？直接更新会丢失历史，保留多条可以追踪历史，但会增加维度表复杂度。实际数仓里用得比较多的是拉链表，它可以记录某条维度记录在某个时间段内有效，既能支持历史回放，查询效率又比全量快照高。回答这类问题时，举一个“用户信息变更”的实际案例，比空谈理论要加分很多。
4.2 手写SQL：窗口函数、去重、留存漏斗
大数据开发岗位的笔试和一面，基本逃不开手写SQL。面试官要的答案不光是结果正确，还要求性能靠谱。很多人在“count distinct”上吃过亏，因为count distinct会引发内存压力大的精确去重，如果数据量非常大，跑得会特别慢。一般面试场景下可以接受用count distinct，但在大表场景要答出“用group by去重再count”的思路，或者提ApproxCountDistinct这类近似去重。这样回答会显得你有大量数据处理的实战经验。
窗口函数是必考。常见场景包括分组TopN、同比环比、连续登录天数、会话内时间差。比如求“每个用户最近3笔订单”，用rank() over(partition by user_id order by order_time desc)就可以解决。要我给个建议的话，把rank、dense_rank、row_number的区别背到滚瓜烂熟：row_number是唯一的1到N，rank会跳过名次，dense_rank不跳名次。面试官特别喜欢在这三个函数上设陷阱。
留存和漏斗是我特别喜欢考的SQL场景。留存计算核心是“用首日用户集合去关联后续每一天的活跃用户”，SQL上通过左连接用户活跃表，日期差作为留存周期天数。漏斗计算则要用到条件聚合或窗口函数，比如“用户从曝光到点击到下单”，可以先给每个用户在每个环节打标记，再用sum(case when ...)一步算出每一层的用户数。如果面试官给了一个很复杂的漏斗场景，不要急着写，先把逻辑分成几步讲清楚，哪怕面试官等你思考，也比直接写一个肯定有Bug的长SQL好。
5. 实时与离线架构设计：选型、链路、一致性
5.1 Lambda架构和Kappa架构怎么选
面实时数据岗位，十次有八次会问“你用过Lambda还是Kappa”。这题没有标准答案，但你要能说清两种架构的代价。Lambda架构同时维护离线批处理和实时流处理两条链路，离线负责全量准确，实时负责低延迟。它的好处是两条链路各自成熟稳定，缺点是同一套逻辑要开发两遍，维护成本高，而且批和流的结果很容易对不上。
Kappa架构只用实时链路，历史数据也通过重放Kafka里的消息来重新计算，避免了双链路开发。但它的前提是消息能长期保存，或者算力足够支撑重新计算。现实里很多公司的Kafka保留时间只有两三天，历史数据重放的可行性就很低。我见过一些团队说用Kappa，实际遇到历史修正需求时还是偷偷把离线链路又拉起来了。回答时可以从“数据量变化频率、消息保留周期、团队人力”三个维度来权衡，这样既客观又有条理。
实时数仓的分层也和离线类似，比如实时明细层、实时汇总层。但要注意，实时任务的运维复杂度和成本比离线高很多，能不用实时就不要硬上实时。我经常跟面试者强调，架构选型的核心是用最小成本解决问题，而不是为了技术迭代而上新框架。如果能报出某个场景下“什么是必须实时的、什么是可以批处理的”，面试官对你的方案能力会非常认可。
5.2 链路一致性、延迟和故障恢复
实时链路里最常被问到的是“怎么保障数据一致性”。一个非常典型的场景是：实时任务凌晨发生故障，重启后怎么把中间丢失的数据补回来？一种方案是Kafka设置更长保留期，任务启动时从最早位点或最近Checkpoint位点重放；另一种方案是先把实时明细写进一个中间存储，再通过离线或补数任务把缺失的那一段补齐。关键是你要能理解“精确一次”不可能单靠Flink本身解决，数据源、计算引擎、目标存储必须同时参与。
再就是背压（Backpressure）。在Flink任务里，如果下游处理速度跟不上上游发送速度，会造成背压，表现出来就是反压。面试官会问“你遇到过背压吗，怎么排查”。可以回答：先看Web UI里的Backpressure状态，看是哪个算子的反压比例高，再检查是Shuffle数据倾斜、目标存储写入慢，还是单并行度瓶颈。如果是因为目标存储HBase或MySQL写入慢，可以尝试增大Sink批次、增加并行度或引入缓冲；如果是数据倾斜，就回到之前说的Key拆分方案。
延迟指标也是区分初级和高级的点。实时任务不能只看“跑起来没报错”，还要看端到端延迟。面试时如果能说出“我们通过埋点监控从数据产生到结果表可见的时间，正常情况下P99延迟控制在X秒以内，超过阈值会告警”，面试官会觉得你不是只会写Flink SQL，而是会做线上稳定性保障。
6. 常见问题排查与面试答题技巧
6.1 现场编程题和方案题的作答套路
手写编程题不要上来就敲代码。尤其是大数据岗位的编程题，重点考察的是“能不能把大问题拆成小步骤”。我建议第一步先和面试官确认输入输出的边界条件，比如“用户表是去重后的吗”“时间字段是什么格式”；第二步用通俗语言描述思路，比如“先按用户分组，再按时间排序，最后相邻行做差”；第三步才是写代码。这样做的好处是，思路错了能及时被面试官拉回来，不会白写一大段。
SQL题也同理。比如“求连续3天登录的用户”，脑子里先想清楚主键是什么、时间粒度是天还是小时、要不要去重。然后选择合适的窗口函数，比如lag或row_number。写的时候尽量把临时表拆开，每个临时表只做一层逻辑，方便调试也方便面试官理解。即使你写出来的不是最优解，但逻辑清晰、能跑对结果，分数也不会低。
方案设计题更要多说一些约束条件。面试官说“请设计一个实时推荐系统”，你不应该直接画架构，而是要反问几个关键问题：推荐结果更新延迟要求是多少？用户量级是多少？算法模型是同步调用还是离线预计算？把这些先问清楚，你的方案才会有的放矢。我面过不少候选人，方案听起来很宏大，但完全没有考虑Kafka分区数、后端存储写入QPS这类现实约束，这种回答我会认为他缺乏真正的系统设计经验。
6.2 我踩过的坑和避坑建议
面试时最容易犯的错是“不会装会”。大数据领域知识面太宽，遇到没接触过的组件很正常。我曾经被问到“你们怎么做数据质量校验”，我当时只答了“每天对一下数量”，面试官没有深究。后来我意识到更好的答法是：直接承认当前项目做得不够完善，然后说出你理想中的校验体系应该包括哪些环节，比如主键唯一性、枚举值校验、波动阈值告警。面试官其实想听的不是你做得有多完美，而是你有没有思考和总结。
第二个坑是只背结论不讲过程。有人答HDFS写流程能说得很顺，但问“你当时遇到过写慢或写失败吗”就卡住了。建议把项目里踩过的任何一个真实问题整理成“现象—排查—解决—复盘”四段式。哪怕是很小的问题，也能证明你有实战经历，比强行说自己做过很难的项目要可信得多。
第三个坑是忽略业务价值。大数据开发和数据分析一样，最终要支撑业务。回答项目时不要只说“我写了多少个Spark任务”，要说“这个报表上线后，运营团队可以每天看到各渠道投放ROI，决策效率从一周缩短到一天”。把技术方案和业务效果挂上钩，面试官对你的整体评价会明显上了一个台阶。这也是我在后几次跳槽面试中按下结论的通用打法，实测下来效果比堆技术名词好很多。
