★ FEATURED ARTICLE 做大数据开发这几年出去面试十场里有八场会被问到 Hadoop。很多候选人谈起组件头头是道但一落到 HDFS 写数据、MapReduce 的 Shuffle、YARN 的任务调度就答不到点子上。我梳理了一套围绕 HDFS、MapReduce、YARN 的面试题解不是简单给答案而是把每个问题背后的原理、踩过的坑、面试官想听的重点都拆开讲透。这套内容适合准备中级大数据岗位面试的朋友也适合刚学完 Hadoop 想检验自己理解深度的人。搞懂了这几块Hadoop 面试的第一关基本就稳了。1. HDFS 核心考点从读写流程到元数据管理HDFS 这块面试官最喜欢从“你熟悉的组件入手逐步挖深”。经常是先问“讲一下 HDFS 写文件的流程”然后一环扣一环问下去。所以不要只会背流程每一步的“为什么”才是拉开差距的地方。1.1 HDFS 写数据流程为什么客户端先跟 NameNode 打招呼写文件的完整流程标准答案是客户端调用 DistributedFileSystem.create()NameNode 检查文件是否存在、权限是否足够然后在命名空间里创建一条记录客户端拿到返回的 DFSOutputStream 后开始往 DataNode 写数据数据按 128M 一块切分第一个块写完后客户端向 NameNode 申请下一个块的 DataNode 列表接着写第二个块直到写完所有块最后调用 close()NameNode 确认文件写入完成。面试官在这里不会轻易放过你。他一定会追问“为什么客户端要先跟 NameNode 拿 DataNode 列表而不是客户端自己找 DataNode”答案是NameNode 是全局的元数据管理者它知道所有 DataNode 的存活状态、机架位置、磁盘使用情况。写的目标是要选择“距离客户端网络最近、磁盘空间足够、负载较低”的一组节点这个全局决策只有 NameNode 能做。客户端自己瞎找要么写到离自己十万八千里的节点上要么写到一个快满的磁盘上还会带来严重的网络拥塞。再往下问就是流水线复制。第一个 DataNode 收到数据后不是等客户端写完一个块才往下传而是边收边往第二个 DataNode 转发第二个再往第三个转发。客户端每写完一个 chunk通常是 512 字节的数据加 4 字节校验和就沿 DataNode 链一路传下去最后一个 DataNode 写完并返回 ack逐级往回传客户端收到 ack 后继续写下一个 chunk。这套机制的好处是把一次大文件的网络传输分摊到多个 DataNode 上不用客户端给三个节点各传一遍节省了大量网络 IO。实操中遇到过一个问题如果副本数为 3而集群只有 2 台 DataNode写入会一直报“文件块副本数不足”但不会马上失败而是块显示 UNDER_REPLICATED。刚开始容易慌其实只需要跑一遍 fsck /文件路径就能看到块的实际副本分布情况再决定是加节点还是调低副本数。1.2 HDFS 读数据流程就近读取与容错读文件相对简单客户端调用 open()NameNode 返回文件每个块所在的 DataNode 列表按网络距离排序客户端选出最近的节点建流读取。读完一个块再从 NameNode 拿下一批块的位置。重要细节是读到的数据会用校验和验证完整性如果发现某个块损坏客户端会换一台 DataNode 重新读同时把损坏情况上报给 NameNode。这里有个容易忽略的点也是面试加分项NameNode 返回的 DataNode 列表是按“机架感知”排序的。HDFS 默认副本策略是把第一个副本放在客户端所在节点第二个副本放在同机架另一台节点第三个副本放在不同机架的节点。所以客户端读取时优先找同机架的副本实在找不到才跨机架。这就是为什么躺着不动也会“就近读”——不是客户端主动选而是 NameNode 在列表里就把顺序排好了。1.3 元数据管理fsimage 和 edits 是怎么回事说到 NameNode 的元数据很多人的理解停留在“NameNode 管着数据在哪”但面试官想听的是 fsimage 和 edits 这套机制。NameNode 的元数据包括文件系统的目录树、文件与块的映射关系、块与 DataNode 的映射关系。它不是实时去各个 DataNode 问而是维护在内存里同时持久化到磁盘上的 fsimage命名空间镜像和 edits编辑日志。新写入的操作先追加到 edits 日志内存元数据同步修改。fsimage 是定期合并后的快照SecondaryNameNode更准确叫 CheckpointNode会定期把当前的 edits 和 fsimage 拉到本地进行合并生成新的 fsimage 再传回 NameNode。面试官爱问“SecondaryNameNode 是 NameNode 的备份吗”正确答案是它不是热备只是在做检查点合并NameNode 挂了之后SecondaryNameNode 没法直接顶上数据恢复还是要靠 fsimage edits 重放。我实际维护集群时最怕的是 edits 日志异常增长。有一次某个业务疯狂创建小文件edits 文件涨到几十 GB导致 NameNode 启动时重放日志花了快一小时。后来设定了“单日创建文件数告警”edits 超过阈值就手动触发 checkpoint问题才算可控。面试时能说出这段经历比干背机制有说服力得多。1.4 小文件问题为什么 Hadoop 谈小文件色变小文件问题几乎必考而且实用的场景特别多。它的问题核心不在“文件本身小”而在于每个文件、目录、块都要在 NameNode 内存里占一条元数据记录。一个文件大约占用 150 字节内存看起来不多但一亿个小文件就是 15GB 内存出去了。而且每个小文件至少一个块块的数量直接和 MapReduce 的 Map 任务数挂钩一个小文件一个 Map启动开销比计算开销还大。解决办法要从源头讲写入数据时尽量合并成大文件比如用 SequenceFile 把小文件打包或者用 Hive 的 ORC、Parquet 这类列式存储格式底层本身就是大文件还有定期的文件合并任务比如用 Spark 或 MapReduce 把历史小文件读出来再写回大文件。面试时如果能主动说出“我会用 sequenceFile 或 har 归档方案但 har 其实治标不治本”会显得你真的在集群上处理过这些事。1.5 副本策略与机架感知块大小设计的内在逻辑默认副本数为 3放置策略是第一个副本在客户端节点上第二个副本在同一个机架但不同节点上第三个副本在另一个机架。这样设计兼顾了容错性、写入带宽和读取延迟同机架的第二副本写入速度快跨机架的第三副本保证一个机架整挂时数据不丢读取时优先读同机架数据减少了跨机架的流量。块大小为什么默认 128M这里有个经典推导磁盘寻道时间大约 10ms传输速度大约 100MB/s为了把寻道时间控制在传输时间的 1% 之内块大小至少得 100MB取整下来就定了 128M。块设得太大Map 并行度就低设得太小元数据开销和任务调度开销都变大。面试时把这个“寻道时间 / 传输时间”的比值逻辑讲清楚会比直接说“默认 128M”深刻很多。1.6 安全模式与数据节点下线安全模式是 HDFS 启动时的状态NameNode 在加载 fsimage 和 edits 时还没有拿到 DataNode 上报的块报告此时只读不写。DataNode 启动后会向 NameNode 上报自己持有的所有块信息当达到“最小副本条件”时NameNode 自动退出安全模式。面试官问“集群启动后为什么一直停在安全模式”答案多半是块副本数不达标可能是大量块丢失、DataNode 没起来或者磁盘坏了。可以手动 dfsadmin -safemode leave 强制退出但这是治标根因要看块报告。还有 DataNode 下线流程正规的做法是dfsadmin -decommission 一台节点让 HDFS 把这台节点上的副本慢慢迁移到别的节点迁移完毕再下线。直接 kill 进程拔机器会导致大量块副本数不足后台疯狂复制数据集群负载飙升。这个点我有惨痛教训有一次赶时间直接停了一台 DataNode结果整整一个下午集群都在补副本业务查询性能掉了不少。2. MapReduce 核心考点Shuffle、数据倾斜与 Join 策略MapReduce 考得最多的不是“怎么跑 WordCount”而是 Shuffle 的完整链路、数据倾斜的处理方案、Join 的优化思路。这块内容最多面试官也最容易深挖。2.1 MapReduce 作业执行流程从提交到完成一个都别漏先说整体客户端提交作业后YARN 的 ResourceManager 分配一个容器启动 MRAppMasterMRAppMaster 根据输入数据切片数申请 Map 任务容器Map 跑完再申请 Reduce 容器执行 Reduce整个作业跑完MRAppMaster 注销。面试时要把“谁调度谁”的关系梳理清楚客户端不直接管理任务MRAppMaster 是作业的总指挥。输入分片InputSplit在这里是个关键概念一个分片对应一个 Map 任务分片大小默认等于块大小。所以 HDFS 上一个 128M 块对应一个 Map。很多候选人分不清 block 和 split 的区别面试官最喜欢纠正这一点block 是物理存储单位split 是逻辑计算单位。虽然默认大小一致但 split 完全可以根据压缩格式、计算逻辑动态调整。2.2 Shuffle 到底是干什么的Map 端做了四次“整理”Shuffle 是面试分水岭。Map 端的 Shuffle我习惯拆成四步说分区、排序、溢写、合并。Map 输出的数据不是直接落盘而是先写进内存的环形缓冲区默认 100MB。缓冲写到 80% 时后台线程开始把数据溢写到磁盘。溢写前要做两件事按分区号分区同一个分区里的数据按 key 排序。如果有 Combiner排序后在溢写前先做一次本地合并减少落盘数据量。多个溢写文件在 Map 任务结束前要归并成一个大文件同时给 Reduce 生成索引文件告诉每个 Reduce“你该来取哪个分区的数据”。环形缓冲区的设计很精妙读写是异步的Map 业务线程不停往缓冲区写溢写线程从缓冲区读两者靠“高水位”触发避免冲突。面试时可以顺嘴提一句“如果 Map 输出很大调大 buffer 比例可以减少溢写次数但设得太大又容易 GC 频繁”这就能体现你是真的调过参数。Reduce 端 ShuffleReduce 任务启动后开启多个复制线程从各个 Map 输出里拉取属于自己分区的数据边拉边归并merge内存中的数据先做一次合并放不下的溢写到磁盘最后把多个文件合并成一个同时按 key 分组交给 Reduce 函数处理。Reduce 端最常被问的问题为什么 Reduce 端也要排序答案是Reduce 函数拿到的“同一个 key 的所有 value 是连续的”这个保障靠的就是排序排序不是严格全局有序而是保证 key 相同的记录聚集在一起。2.3 数据倾斜所有面试官都爱问所有集群都可能遇到数据倾斜的表现MapReduce 作业大量 Map 秒完但有一个或几个 Reduce 一直跑整个作业卡在 99%或者 Hive SQL 里 join 的某一边 key 特别集中。根因就一个数据分布不均匀导致某个 Reduce 处理的数据量是别的 Reduce 的几十倍。解决要分层讲。第一层Map 端聚合用 Combiner 或自定义 Reducer 的局部聚合把“能提前合并的先合并”这是最推荐的做法。第二层Join 倾斜如果是大表 join 小表用 map join把维度表分发到每个 Map 任务内存里。如果是大表 join 大表且有大量空值或热点值可以给热点 key 加随机数前缀把数据打散到多个 Reduce跑完再做一次去重聚合。第三层调整并行度把 Reduce 数调大让数据更均匀。但注意Reduce 数不是越大越好每个 Reduce 处理的数据量太小反而会浪费调度开销。面试时能把倾斜问题讲到“先定位再解决”就很加分倾斜的定位靠 counter 看每个 Reduce 处理的数据量或者看任务日志里某个 Reduce 的输入字节数是平均值的多少倍。不要说“我遇到倾斜会加几个 Reduce”就完事那是最笨的解法。2.4 Combiner 的坑求平均值为什么不能用 CombinerCombiner 可以理解成 Map 端的局部 Reducer。它能用的场景是聚合操作满足交换律和结合律比如求和、计数、最大值、最小值。反过来求平均值不能用 Combiner——假设两个 Map 分别算出 (求和 10, 计数 2) 和 (求和 25, 计数 5)Combiner 合并是把求和相加得到 35计数相加得到 7平均是 5。单看每个 Map 内部的局部平均是对的但 Combiner 并不知道局部平均只是一个中间结果它没有权重信息直接平均就会错。这个坑我知道不少人都踩过。面试时把上面这个“平均值的反例”讲出来基本就能证明你真的理解 Combiner 的本质而不是背了一个“用 Combiner 之前要慎重”的结论。另外 Combiner 的输入输出类型要和 Reducer 一致但 Combiner 输出其实是 Reducer 的输入所以类型配对一定要检查这个细节很多实战项目里会出编译错误。2.5 Join 的三种方式什么时候用 Map Join面试对 Join 的考察很直接两张表怎么关联Reduce Join 是最基础的方式以关联 key 作为 reduce 的 key不同表的数据打上标签作为 value在 Reduce 端做笛卡尔积式关联。但这种方式每个 reducer 只处理一组 key大表小表都全量参与 shuffle效率很低。Map Join 的思路是把小表放进每个 Map 任务的本地内存DistributedCache 分发Map 端直接拿着大表的每行去内存小表里匹配不走 Shuffle大大减少网络 IO。适用条件是小表足够小能放进内存。实际经验是在 Hive 里小表小于 10M 会自动转 map join但手动设置 mapjoin hint 往往更可控。Semi Join 是中间方案先从小表里提取所有关联 key去重后分发到大表Map 端先过滤掉不可能关联上的行再走 Reduce Join。它能减少大表在 Shuffle 阶段传输的数据量适合小表虽小但无法完全放入内存的场景。面试讲 Join如果能分清“Map Join 省的是 Shuffle”“Semi Join 省的是传输量和 Reduce 压力”就已经超出大部分候选人的深度了。2.6 MapReduce 参数调优为什么不能照搬默认值MapReduce 有几个高频调优参数mapreduce.map.memory.mbMap 容器内存默认 1G 左右、mapreduce.reduce.memory.mb、mapreduce.map.java.optsJVM 堆内存一般是容器内存的 75% 左右、mapreduce.task.io.sort.mb环形缓冲区大小、mapreduce.map.sort.spill.percent溢写阈值、mapreduce.reduce.shuffle.parallelcopiesReduce 拉取 Map 数据的并发数。调优的逻辑不是越大越好。容器内存设得大意味着同时运行的任务数少因为节点可用内存是固定的缓冲区设得大Map 端溢写次数少但单任务内存开销大有可能导致容器分配不出来。实际调优要先看监控确定 Map 阶段是不是频繁溢写、Reduce 阶段是不是在空等、GC 是不是很严重再动手改参数。一个常见的面试追问是你设置的 Map 内存为 2G那么 JVM 堆应该设多少正确思路是 JVM 堆要小于容器内存一般留 25% 给非堆内存和系统开销所以 java.opts 设 1.5G 左右是合理的。如果堆设到 1.8G内存很容易超限容器被 NodeManager 杀掉任务反复失败日志里全是 Container killed。3. YARN 核心考点调度器、容器与任务提交流程YARN 这块面试官关心的是架构理解层次尤其是任务提交流程和资源调度。很多人会把 YARN 和 MapReduce 混在一起实际上 MapReduce 只是跑在 YARN 上的计算框架YARN 解决的通用资源管理问题。3.1 YARN 架构ResourceManager、NodeManager、ApplicationMaster 各管什么YARN 的核心是一个两级架构ResourceManagerRM管全局资源NodeManagerNM管单个节点资源。RM 里有两个关键组件调度器Scheduler负责给应用分配资源ApplicationsManager 负责管理每个应用的 ApplicationMasterAM。这里特别容易搞混的地方是AM 和任务不是一回事。AM 是每个应用自己的“总协调人”负责向 RM 申请资源、和对应的 NodeManager 通信启动任务、监控任务进度、处理任务失败重试。拿 MapReduce 举例第一个启动的容器是 MRAppMaster它根据分片数算好需要多少个 Map 任务再向 RM 申请这些任务所需的容器拿到资源后再通知 NM 启动任务。任务跑完了AM 再申请 Reduce 容器。NodeManager 的工作主要是启动容器、监控容器资源使用、上报心跳给 RM。它还顺带做日志聚合——任务日志从各个容器汇总到 HDFS 上排错全靠它。面试时把 NM 和“就是个跑容器的节点代理”说清楚就已经及格了。3.2 YARN 任务提交流程一个作业从提交到跑完中间发生了什么我曾经用“你点一份外卖”来类比 YARN 提交流程你客户端下单给外卖平台RM平台分配一个骑手AM骑手根据订单去餐厅取餐申请资源、启动 Map再逐家配送Reduce 到指定分区。这个类比在面试中很好用因为面试官一听就能看出你是真正的理解而不是背流程。完整流程是客户端向 RM 提交作业RM 在某个 NM 上启动一个容器跑 AMAM 启动后向 RM 的调度器申请资源调度器把可用的容器列表返回给 AMAM 拿着容器信息去对应的 NM 上启动任务任务间有数据依赖的AM 负责协调。整个过程中 RM 是不直接管理具体任务的失败处理由 AM 负责。追问方向通常是AM 挂了怎么办答案是RM 会重新拉起一个 AM新的 AM 从作业的历史状态恢复进度但 Map 任务如果没持久化状态可能要从头跑。所以 AM 的稳定性很重要而 NodeManager 突然挂了RM 会把它上面的所有容器标记为失败相关任务由 AM 重新调度到别的节点。3.3 三种调度器FIFO、Capacity Scheduler、Fair Scheduler调度器是 YARN 最容易考死人的地方。FIFO 就是先来先服务作业按提交顺序排队队头作业占满所有资源后面作业只能干等。单用户场景没问题多用户共用集群时体验极差。Capacity Scheduler 是多个队列每个队列预留一部分集群资源队列内部还是 FIFO。核心思想是“隔离 共享”一个队列出问题不影响其他队列的正常运行。生产环境基本都用它Hadoop 默认也改成它了。我之前维护的集群就分了“生产队列”和“测试队列”测试任务再乱也抢不走生产队列的全部资源。Fair Scheduler 是动态公平分配所有运行中的作业动态共享资源每个作业获得的资源配额会随着作业增减而变化。它适合多租户场景能让所有人都有资源用但缺点是单个大作业的完成时间不可控因为资源是动态浮动的。面试官常问作业 A 占满资源作业 B 刚提交Capacity Scheduler 下 B 怎么办答案是A 用不超它的队列上限B 在自己队列的配额里排队如果 B 和 A 在同一个队列B 只能等 A 释放资源。多队列的价值就是允许 B 在另一个队列里立刻跑哪怕整个集群已经没有空余资源。3.4 容器YARN 里的“资源盒子”是怎么工作的Container 是 YARN 资源分配的最小单位里面封装了 CPU、内存和环境变量。一个作业由多个容器组成每个容器就是任务运行的“小隔间”。一个容易踩坑的点容器内存不只有任务进程堆还包括 JVM 的非堆内存、用户代码开销和系统开销。所以设置容器内存时要预留 buffer我一般按“容器内存 JVM 堆 15%~25%”来配。如果容器被 NM 杀掉日志里出现“Container is running beyond physical memory limits”第一反应不是给代码瘦身而是检查是不是内存配小了。CPU 隔离方面YARN 用 CPU vCore 来抽象但 vCore 不是绝对的 CPU 核数可以超卖。调度器分配的 vCore 只是逻辑概念实际跑起来靠操作系统的调度。有些集群把 16 核的机器配了 32 个 vCore就是允许超卖前提是任务之间错峰使用 CPU否则会互相拖慢。3.5 资源调优一个节点该配多少个容器怎么算节点资源配比是个常见面试场景题。假设一台机器 64GB 内存、16 核 CPU操作系统预留约 8GB 和 2 核剩余 56GB、14 核给 YARN。如果每个容器 4GB、2 vCore理论上最多可以同时跑 28 个容器吗不对因为还要考虑 AM 的容器、磁盘 IO 和网络的开销。实际经验是不要卡着上限配置给每个容器留出足够余量同时限制 NM 的最大可用内存和 CPU 比例yarn.nodemanager.resource.memory-mb 和 cpu-vcores避免一个节点把所有资源吃满导致整机卡死。面试时讲调优千万不要说“我设置了 yarn.scheduler.maximum-allocation-mb8192”而是要讲出“为什么设这个值”single-container 的内存上限不能超过节点可用内存否则调度器会给单容器分配整个节点的资源导致其他任务无法启动。同理maximum-allocation-vcores 也不能太大不然一个容器占满整机 CPU其他容器全部排队。4. 面试中的高频追问与答题技巧Hadoop 面试不只是知识点的罗列。很多候选人知识点都背了但坏在答题没有层次或者被一个问题带偏之后接不住追问。这节整理几个真实面试场景里的问答套路。4.1 “讲一下 Hadoop 读写流程”这个问题的正确打开方式很多候选人上来就背“客户端向 NameNode 发起请求”这样答很容易答碎。面试官的注意力会落在几个点NameNode 决定什么、DataNode 之间如何协作、失败时怎么处理。答题建议按“发起-写入-确认-失败处理”四步来讲先讲正常路径再主动带一句“如果某个 DataNode 写入失败HDFS 会剔除这个节点并重新复制副本”这句话就能拦截住一半的追问。还有一个常见的追问“客户端是不是要先等第一个块成功写入再写第二个块”答案是不一定。第一个块写完返回 ack 后客户端继续写第二个块同时 NameNode 会异步复制副本。也就是说只要有一个副本成功写入并确认客户端就能继续不必等三个副本全部写完。这里能答出“pipeline ack 是逐级返回的”面试官基本满意。4.2 “MapReduce 为什么慢你怎么优化”是个综合题目这个问题表面问性能实际上考的是对整个计算框架的理解。答法建议从“数据本地性、Shuffle 开销、资源分配”三个维度展开。数据本地性Map 任务的输入尽量在本地磁盘避免跨机架读数据于是调度器优先把任务分配到持有数据的节点Shuffle 开销如果 Map 输出很大Reduce 拉取数据的网络开销就很高思路是减少 Shuffle 数据量和减少溢写次数资源分配如果集群资源紧张任务是排队等的可以考虑把作业切小、提高优先级。优化要从代码和参数两个层面说。代码层面减少无意义的 Map 端输出尽早过滤数据在 Map 端做 filter 而不是到 Reduce 端才过滤能用 Combiner 就一定要用。参数层面调整缓冲区大小、内存配置、并行度。这里如果只说“我调了并行度”基本等于没答。4.3 反问环节怎么表现最加分面试快结束时面试官会让你提问。很多候选人问“你们公司用什么技术栈”“加班多不多”这类问题本身没毛病但缺乏区分度。如果前面 Hadoop 聊得不错建议问跟 HDFS/YARN 相关的构建问题比如“集群规模多大NameNode 的堆内存怎么设置的”“YARN 调度器用的哪种队列划分怎么设计的”“有没有做小文件治理的自动化流程”。这种问题能让面试官觉得你真的做过集群运维同时还能顺势聊出更多信息判断这个岗位的日常重点是什么。注意别问太宽泛的问题比如“大数据平台怎么搭建”这种问题既暴露你自己没思路也会让面试官答着反胃。要问就问到具体决策点某个参数在你们这一千节点集群上调了多少、为什么。5. 从面试真题到系统复习Hadoop 知识树怎么搭刷了很多面试题之后会发现一个规律知识点不是孤立的而是层层嵌套。HDFS 的块设计影响 MapReduce 的分片分片影响 Map 并行度并行度又影响 YARN 的资源申请。面试里 80% 的难题都是跨组件的联动问题。5.1 把三块知识串成一条线建议自己画一张“数据从落地到计算完毕”的流转图数据写入 HDFSNameNode 记录元数据DataNode 存储实际数据作业发起时客户端把作业提交给 YARNYARN 启动 AMAM 根据输入分片申请 Map 容器每个 Map 读取 HDFS 上的一个分片Map 输出经 Shuffle 进入 ReduceReduce 结果写回 HDFS。把这五步问一遍“如果失败怎么办、如果数据大怎么办、如果节点少怎么办”整个 Hadoop 的知识体感就出来了。画图的时候不要用工具手绘都行。我每次准备面试都会在白板上画一遍这个流转过程画完再闭上眼睛讲一遍哪里卡顿就是哪里没学透。比刷题效率高得多——因为面试官让你“讲一下数据流转”时你脑中已经有图了顺着图讲不会乱。5.2 实操实验建议在小集群复现关键场景有条件的话起一个 3 节点的 Hadoop 集群做几个实验比看十遍文档都管用。实验一写一个能生成大量小文件的程序观察 NameNode 堆内存变化和 Map 任务数量配合 jstat 看一眼 GC能直观感受小文件问题的杀伤力。实验二故意把 Reduce 数设成 1跑一个数据量很大的任务观察完成时间再改成 8 个对比效果感受并行度的意义。实验三在写入过程中直接 kill 一个 DataNode 进程观察 HDFS 的块复制任务和副本数恢复过程这是面试里“节点挂了怎么办”的最佳素材。这些实验不用特别复杂的脚本用自带示例包和命令行就能完成。关键是记录截图和数据面试时拿“我在测试集群观察过……”开头说服力比背诵强很多。5.3 面试前一周怎么复习最高效建议做一个“三层过滤”复习法。第一层看面经和博客把所有高频题目过一遍目标是“每道题都能说出标准答案”。第二层把标准答案用自己的话重新组织目标是“能针对追问展开”。第三层挑 10 道最核心的题目比如 HDFS 读写流程、Shuffle 流程、YARN 提交流程、数据倾斜解决方案自己对着墙或者假想的面试官讲一遍目标是“不卡壳、有层次、带案例”。复习时重点关注“计数器”和“日志排查”这两个容易被忽略的工具。很多候选人知道数据倾斜怎么解决但被问“你怎么发现倾斜的”就懵了。其实只要说“通过 Job 页面看每个 Reduce 处理的输入字节数或者看 Reduce 的任务日志里最后一个阶段的耗时”就已经是一个很完整的答案了。我个人复习时有个习惯把每道题的答案限制在“1 分钟讲完主流程30 秒讲关键细节10 秒总结一句话”这个节奏里。面试官一天面很多人能听到结构清晰的回答是一种享受。如果你讲得太散就算结果是对的也会被扣掉很多“表达分”。Hadoop 这块内容多但考的其实是同一套底层逻辑分布式系统怎么解决“元数据管理、数据冗余、任务调度、故障恢复”这四个问题。不管题目怎么变着花样问把这几条主线记牢读写的异常情况、任务的失败重试、资源的动态调度都能顺藤摸瓜答出来。面试前把 HDFS 的读写流程、MapReduce 的 Shuffle、YARN 的完整提交流程画一画再对照本文里的这些追问点过一遍这个板块基本就稳了。
阅读完成 · 觉得有帮助？
