看到这套2018年秋季校招的Hadoop工程师笔试题我心里其实挺有感触的。那几年刚好是大数据岗位需求量爆发的阶段爱奇艺作为头部视频平台出的题基本代表了当时大厂对Hadoop工程师的能力预期。一套题做下来你会发现它根本不是在考你是否背熟了某个命令而是在考察你对整个分布式系统有没有建立完整的、体系化的认知。这篇文章我就以这套题和近年大厂常见的考察方式为引子把Hadoop工程师校招笔试和面试中那些绕不开的硬核知识点结合我实际踩坑和后来面试别人的经验掰开揉碎讲清楚。1. 这场笔试在考什么Hadoop工程师校招的隐藏筛选逻辑1.1 考点模块地图从HDFS到Spark生态一次全覆盖结合这套题以及当时大量校招真题的分布情况Hadoop工程师笔试基本围绕这几个模块展开HDFS、MapReduce、Zookeeper、Hive、Spark、集群搭建与运维。每个模块的占比其实很能说明问题。考察模块大致占比核心考察形式HDFS20% - 25%读写流程、副本策略、NameNode/DataNode职责、小文件问题MapReduce30% - 35%Shuffle过程、Partitioner、Combiner、Join算法、数据倾斜Zookeeper10% - 15%Leader选举、ZAB协议、HA高可用、脑裂处理Hive与Spark15% - 20%SQL执行计划、分区表/分桶表、RDD机制、宽窄依赖集群搭建与运维10%配置文件、伪分布式、Docker部署、故障排查注意看MapReduce占了最大的比重。这很奇怪对吧现在不少人都在说MapReduce已经过时了。但恰恰因为MapReduce是理解分布式计算模型的最佳教材大厂才会拿它来考察一个人的基本功是否扎实。你要是连MapReduce的Shuffle都没搞明白后面学Spark的Shuffle也会学得云里雾里。1.2 爱奇艺这类视频平台出题的背后逻辑爱奇艺这类平台每天会产生海量的用户行为日志比如点播、暂停、拖拽、搜索、弹幕、评论。这些日志数据最终都要汇入大数据平台经过Hive清洗、Spark计算再服务于推荐系统、内容画像、流量分析等业务。所以笔试题看起来在考察各大组件实际上是在模拟一名Hadoop工程师日常要面对的核心场景如何高效地存储海量文件HDFS如何稳定地跑大规模批处理任务MapReduce/YARN如何保证元数据服务不挂Zookeeper/HA如何在数据量膨胀时优化查询性能Hive分区/Spark调优。想明白这一点你就不会对着题目死记硬背了而是会去思考出题人站在业务角度真正需要你掌握什么能力。2. HDFS真题拆解上传下载背后的完整链路2.1 上传文件时NameNode到底做了什么数据分析工作中最常做的一件事就是把日志文件或结果数据上传到HDFS。很多人知道用hdfs dfs -put但可能没想过这条命令背后发生了什么。笔试特别喜欢考这个而且问得特别细。完整链路是这样的。客户端调用FileSystem.create()方法通过RPC协议向NameNode发起创建文件的请求。NameNode收到请求后会做一系列检查和元数据操作权限检查当前用户对目标路径是否有写权限。父目录检查目标父目录是否存在如果不存在直接报错。文件存在性检查如果同名文件已存在且没指定覆盖选项报FileAlreadyExistsException。在命名空间Namespace中注册新的INode也就是文件的元数据条目。返回一个FSDataOutputStream给客户端。这里有一个很重要的点文件刚创建时NameNode只是在内存里创建了元数据条目但并没有任何数据块与之关联。数据块的信息是在后续写入过程中逐个提交的。这个机制是理解为什么HDFS不适合存大量小文件的起点。接下来才是数据写入的核心流程。客户端拿到输出流之后会把数据切分成一个个数据包Packet默认64KB而不是按Block大小来切分。DataStreamer组件会向NameNode申请返回一组DataNode列表这组列表就是数据管道Pipeline的节点。客户端把数据包发送给第一个DataNode第一个DataNode把数据块持久化到磁盘后马上转发给第二个DataNode再转发给第三个。这种方式避免了NameNode参与每一个数据包的转发大大减轻了它的压力。很多人在这一块会混淆NameNode到底管不管数据传输答案是NameNode只管元数据和数据块到DataNode的映射关系不参与实际数据块的传输。客户端直接从DataNode读写数据。把这个搞清楚笔试里那类客户端上传文件时与哪个节点直接进行数据传输的题就不会做错了。2.2 副本放置策略为什么机架感知是必考题副本策略是HDFS设计里非常重要的一环笔试基本每场都会出。默认副本数是3官方推荐的放置策略是这样的第1个副本如果客户端就在某个DataNode上那优先放在这个客户端所在的节点。如果客户端在集群外就随机挑一个节点但要避免太繁忙的节点。第2个副本放在与第1个副本不同机架Rack的某个节点上。第3个副本放在与第2个副本相同机架、但不同节点上。这样放置有什么好处其实是从容错和带宽两个维度权衡的结果。如果是同一机架的两个节点它们的物理距离近数据传输快。但机架级别的故障比如交换机断电、机柜断电会同时挂掉多个节点所以第2个副本必须跨机架保证一个机架挂了数据还能找回来。第3个副本和第2个副本放在同一机架是为了减少跨机架的数据传输量。所以各副本读写时除了第一个是本地读其他都要走网络跨机架传输带宽是宝贵的。这个策略是在Hadoop 2.x之后才作为默认策略完善的。学习的时候可以拿1.x的版本对比一下1.x的策略比较原始副本1和副本2放同一机架副本3放另一个机架网络开销会更大。后来改成了现在的机架感知策略。2.3 小文件问题的两难选择HDFS里面有一种非常经典的设计取舍叫小文件问题。笔试常考面试也常问而且你在真实生产环境里肯定会遇到。为什么小文件这么讨厌因为每个文件和目录在NameNode内存中都要对应一条元数据记录。一个文件、一个目录、一个数据块在NameNode内存里约占150字节左右的Java对象开销实际更大150字节是最佳情况的估计。听起来不多是吧如果文件数达到1亿NameNode光元数据就要吃掉15GB以上的堆内存。更不要说那1亿个数据块分布在1000个DataNode上每次启动、心跳、块汇报都要处理这些信息压力非常大。而且从MapReduce的角度看一个小文件就对应一个InputSplit一个InputSplit会占用一个Map Task。一天来10万个小文件就要起10万个Map Task调度开销远大于实际计算开销。生产环境里解决小文件通常有几个思路用SequenceFile或者ORC/Parquet这类文件格式把小文件合并成大文件。用Hive的STORE AS ORC配合表的SNAPPY压缩文件天然会合并。用Spark或MR任务跑一个合并程序把小文件读取后重新写入少量大文件。对于Hive表可以用ALTER TABLE ... ARCHIVE PARTITION做分区归档。我在实际处理Nginx日志时经常用Spark定期把上一小时的几百个小文件合并成几个大文件这个思路在大数据平台里几乎是日课级别的操作。3. MapReduce重灾区shuffle排序和Join算法3.1 把shuffle流程理清笔试的八成分数就有了MapReduce的Shuffle是笔试和面试的绝对核心没有哪场考试能绕过它。什么叫Shuffle就是从Map输出到Reduce输入之间的数据搬运过程。这个过程隐蔽、复杂但决定了整个任务的性能上限。我先说Map端的流程。Map函数处理完键值对后输出不是直接写到磁盘的而是先写到一个环形缓冲区中。这个环形缓冲区默认大小是100MB里面存放的是序列化后的Key、Value和Partition信息。当缓冲区达到80%默认阈值时后台线程开始执行溢写Spill操作。溢写的过程有几个关键点溢写之前会按Partition分区再按Key对分区内的数据进行排序。你可以理解成先根据你要分给哪个Reduce来分成一拨一拨的每一拨内部再按Key排好序。如果设置了Combiner那么在溢写时可以执行一次局部合并减少写入磁盘的数据量。溢写完成后产生一个Spill文件。Map任务结束前会有多次Spill最终将这些Spill文件合并Merge成一个大的输出文件同时生成一个索引文件。然后是Reduce端的流程。Reduce任务会从所有Map任务的输出中拉取属于自己Partition部分的数据。这个过程叫Fetch是跨节点网络传输也是Shuffle里最耗时的阶段之一。数据拉到Reduce节点后会被放入内存缓冲区同样有阈值。如果内存放不下会溢写到磁盘。所有数据归并的过程中会按Key做一次排序和分组把相同Key的Value归并在一起然后才交给Reduce函数处理。这里有一个特别容易考的细节默认的排序保证的是每个Partition内的Key有序而不是全局有序。如果你用默认的HashPartitioner每个Reduce内部按Key排序但Reduce之间是无序的。只有在用TotalOrderPartitioner时才能保证所有Reduce输出合起来是全局有序。很多初学者会把这两者搞混。3.2 Reduce Join和Map Join的取舍大数据计算中Join操作非常常见。笔试常考Reduce Join和Map Join的区别面试官可能还会追问你生产环境里怎么选。Reduce Join是所有Join操作的兜底方案。思路很简单在Map端给来自不同表的数据打标签比如A表的数据标签是0B表的数据标签是1Join的公共字段作为Key输出。到了Reduce端同一个Key的数据已经聚到一起再去重组合出Join结果。Reduce Join的好处是通用性强两张任意大小的表都能Join。坏处是Join逻辑全放在Reduce端完成中间Shuffle的数据量巨大而且一旦某个Key的数据特别多就容易出现数据倾斜。Map Join是应对一大一小表场景的优化方案。思路是把小的表比如几MB到几十MB提前缓存到每个Map Task的本地内存中Map端读到大数据表的记录时直接从本地查找小表完成Join不需要走Reduce端。在Hadoop 2.x中通过DistributedCache机制来实现把文件分发到每个节点的工作目录。实际生产中怎么选我一直遵循一个原则能Map Join就Map Join一小一大尤其要用。在Hive里如果数据量差距悬殊、小表小于阈值优化器会自动转Map Join但你也可以手动用/* MAPJOIN(t1) */来强制指定。两边都是超大表时别无选择只能Reduce Join。还有一种场景是大表Join大表但可以提前过滤先用子查询或Semi Join把数据按条件裁掉一部分再做真的Join。这个技巧在笔试里也经常出现考察的是你会不会通过剪枝减少计算量。3.3 数据倾斜为什么是面试官的必问点数据倾斜是MapReduce和Spark任务里最让人头疼的问题面试官几乎必问。它的本质很简单不同Reduce处理的数据量差异巨大某个Reduce变成了长尾拖慢整个Job。常见的倾斜原因有几个。第一个是Key分布不均匀比如一段日志里某个接口的访问量是其他接口的100倍。第二个是JoIn时一些Key本身就是脏数据比如为空字符串、值为NULL结果所有的脏数据都分到同一个Reduce。第三个是分组聚合时某些Key天然就大比如北京这个城市的数据量远多于其他城市。解决思路很多按优先级排一下过滤掉脏数据把空Key或无效Key在Map端就剔除最省事。如果业务需要统计空值可以把空值加随机前缀比如NULL-1、NULL-2让它分散到多个Reduce最后再对结果做合并。对于超大Key引起的Join倾斜可以在Map端先把这个Key的数据单独拎出来用两个Job分而治之。调整mapreduce.job.reduces参数增加或减少Reducer数量有时候也能改善。我在实际工作中遇到最多的就是空Key倾斜尤其是在统计用户行为时很多未登录用户传来的是空ID或DevicesId。一开始没注意导致每天凌晨的ETL任务都会有一个Reduce要跑40分钟其他Reduce只要2分钟。后来在SQL层加了WHERE user_id IS NOT NULL做预过滤问题直接消失。所以那些看似基础的知识在真实生产环境中就是能救命的。4. Zookeeper和Hadoop整合HA与脑裂那些坑4.1 ZooKeeper的Leader选举和HDFS的HA有什么关系爱奇艺这套题的热词里明确有hadoop和zookeeper整合实战这个考点必须单独拎出来讲。ZooKeeper在大数据生态里地位很特殊它不是存储系统而是一个分布式协调服务。Hadoop的HAHigh Availability就建立在ZooKeeper之上。ZooKeeper最核心的两个机制是ZAB协议和Leader选举。ZAB协议保证所有节点的数据一致性Leader负责处理写请求然后把事务广播给所有Follower超过半数节点确认后事务才提交。这个超过半数的机制是ZooKeeper能容错的关键。那ZooKeeper又如何服务于HDFS的HA在Hadoop 2.x之后NameNode是高可用的集群里有两个NameNodeActive和Standby。Active节点正常对外服务Standby节点作为热备。两个NameNode通过共享的JournalNodes通常是3个或5个来同步EditLog。Active把每一条元数据变更写入JournalNode的共享存储Standby从JournalNode读取EditLog并应用到自己的内存中保证它与Active的内存元数据保持一致。这里就用到ZooKeeper了。两个NameNode在ZooKeeper中注册一个临时节点谁抢到了这个节点创建成功谁就是Active。同时ZooKeeper客户端与ZooKeeper之间有心跳机制。如果Active的NameNode发生故障心跳断了临时节点自动消失Standby节点通过ZooKeeper的Watch机制收到通知触发故障转移把自己切换成Active。你以为这就完了不是。ZooKeeper在Hadoop生态里还承担了其他职责比如Kafka的Broker协调、HBase的RegionServer的元数据管理。在笔试或面试回答ZooKeeper的用途时最好列举多个场景说明它不仅仅服务于HDFS的HA。4.2 JournalNode和共享存储为什么不能用NFS关于HA的存储共享有一个特别值得追问的知识点Active和Standby两个NameNode既然要共享EditLog能不能用NFS网络文件系统作为共享存储坦白说早期的Hadoop的Backup NameNode方案确实用过NFS但生产环境不推荐。NFS的问题是它本身是一个单点存储服务如果NFS服务器挂了整个NameNode的日志写入就中断了。而且NFS在高并发场景下性能不稳定也不具备严格的一致性保证。如果两个NameNode同时写同一份EditLog就可能发生数据损坏。所以Hadoop现在的主流方案是QJMQuorum Journal Manager也就是部署奇数个JournalNode一般5个。Active NameNode同时把EditLog写入所有JournalNode只要有超过一半的节点写入成功就认为这次日志写入成功。这样既保证了高可用又不会出现双写冲突的问题。我建议你在复习时把这个场景写进笔记里NameNode的HA依赖JournalNode的日志同步和ZooKeeper的选主两者是配合使用的。很多人只记住了ZooKeeper负责选主却忽略了JournalNode的存在这是不完整的。4.3 脑裂和Fencing分布式系统最经典的面试陷阱提到HA就不得不提脑裂Split Brain问题这是分布式系统里公认的难题。笔试不一定直接考但面试官特别喜欢拿来追问。脑裂的场景是由于网络分区两个NameNode之间的通信中断但两个节点都没有宕机。它们都认为对方挂了于是都把自己切换成了Active。这样一来两个Active同时对外服务元数据更新互相冲突会彻底搞乱整个HDFS。分布式系统解决脑裂的思路核心是Fencing也就是隔离策略。当新主节点通过ZooKeeper完成选主后它会执行一个Fencing过程确保旧主节点无论如何都不能再对外提供服务。常见的Fencing手段有对旧主节点执行kill -9强杀进程如果是物理机还可以用SSH登录到旧主节点上执行关机命令或者调用旧主节点的隔离脚本强制释放它持有的共享锁。在ZooKeeper机制里其实可以认为抢到临时节点的那一方是唯一的合法主节点。如果旧主节点因为网络分区暂时无法访问ZooKeeper它仍然不知道自己的锁已经失效所以必须靠Fencing来物理上把它干掉这是防止脑裂的最后一道防线。我在面试别人时通常会先问ZooKeeper的选主流程然后追问两个节点同时认为自己是主节点怎么办。能答出Fencing和隔离的候选人说明是真的理解分布式系统的本质了。4.4 ZooKeeper集群为什么必须奇数台这个笔试常考的基本概念很多答案都一句话带过为了避免平票。但我想补充为什么是这样。ZooKeeper的写操作需要Leader获得大多数超过一半节点的确认。如果集群有3台可以容忍挂掉1台。如果有5台可以容忍挂掉2台。所以容错能力只取决于大多数的边界增加偶数台并不会提高容错上限反而增加了成本。而且如果节点数是偶数比如4台当网络分区变成2台对2台时任何一边都无法凑够3票超过半数整个集群就陷入不可用的状态。奇数台3台或5台则可以保证任何时刻最多只有一个分区能凑够大多数集群总能选出一个合法Leader。这就是奇数台原则背后的数学逻辑。5. Hive和Spark数据仓库SQL和内存计算的必考组合5.1 Hive SQL的执行计划从一条SQL到一堆Jar包Hive的本质是把SQL翻译成MapReduce或Spark/Tez任务。很多人会用Hive写SQL但如果笔试题让你画出执行流程你可能就会卡壳。一条Hive SQL的执行链路是这样的用户通过CLI或HiveServer2提交SQL。解析器Parser对SQL做语法分析生成抽象语法树AST。编译器Compiler将AST转换为逻辑执行计划并做语义分析比如字段是否存在、表的元数据是否正确。优化器Optimizer对逻辑计划进行优化比如谓词下推、列剪枝、MapJoin转换、分区裁剪。执行器Executor把优化后的执行计划编译成DAG有向无环图任务提交给YARN运行。考察Hive时分区裁剪和谓词下推是高频词。所谓分区裁剪就是SQL里的WHERE dt2024-01-01会被翻译成只扫描对应分区目录的文件而不是全表扫描。这个特性要求你在建表时必须合理设计分区键。我在做日志平台时默认以日期作为一级分区小时作为二级分区这样查询某个小时的数据扫描量能减少95%以上。5.2 分区表还是分桶表数据仓库设计的一步之差Hive笔试里还有一对概念特别容易混淆分区表和分桶表。两者的适用场景完全不同。分区表是把数据按分区键的值拆分成不同的物理目录。它是为了减少扫描的数据量。比如按dt分区你查某一天的数据直接读取那一天的目录就行。分桶表是把数据按某个字段的哈希值取模分散到固定数量比如32个的文件中。它是为了抽样、Locality Join和更均匀的负载分布。举个实际例子。假设你要记录每天的用户播放行为总数据量很大。如果你只按日期分区某个日期的数据量非常庞大这时你可以在日期分区下再按用户ID分桶。当用户画像计算需要Join用户表时相同的用户ID会落在同一个桶里桶与桶之间直接关联不用全量扫描效率提升非常明显。笔试时最常考的是给定一个查询场景问该建分区表还是分桶表。我的经验是默认先按分区按查询频率最高的过滤字段做分区键如果分区内数据量依然很大再考虑对高频Join字段做分桶。5.3 Spark和MapReduce不是替换关系是互补关系Spark出现在Hadoop工程师的笔试题里已经是很正常的事了。毕竟Spark在做迭代计算、交互式查询、流处理时比MapReduce高效得多。Spark和MapReduce的本质区别在于计算模型和数据存取方式。MapReduce每个Map和Reduce阶段的结果都要写入磁盘下一个阶段再从磁盘读取。这样一个需要多次迭代的复杂任务磁盘IO开销极大。Spark不一样它把数据抽象成RDD弹性分布式数据集在内存中保存各个RDD的结果通过DAG有向无环图来串联一系列计算步骤尽可能地减少磁盘落盘。笔试里几乎必考的是宽窄依赖窄依赖父RDD的每个分区最多只被一个子RDD分区使用比如map、filter。窄依赖不需要Shuffle可以管道化执行效率高。宽依赖父RDD的每个分区会被多个子RDD分区使用典型的就是groupByKey、reduceByKey、join等必然会产生Shuffle。Spark的Shuffle和MapReduce的Shuffle思路类似但实现细节不同。Spark在Shuffle Write时会先把每个Map任务的数据按Key分区写入内存中的缓冲区然后溢写到磁盘。Shuffle Read时拉取数据并归并排序。不同点是Spark在Shuffle过程中会尽量使用内存缓冲而且Spark可以自定义排序、聚合和分区策略灵活性更高。5.4 基于Hadoop的音乐推荐系统一个典型的项目综合题热词里有一条基于hadoop音乐分析推荐这个其实可以作为笔试的编程题或者面试的项目题来准备。这种题考的不只是某个组件而是你能否把整个Hadoop生态串起来做一个端到端的解决方案。一个典型的音乐推荐流程可以这样拆解数据采集客户端上报用户听歌行为播放、收藏、跳过、分享。数据存储原始日志存HDFS。数据清洗用Hive或Spark做ETL去重、补全字段。特征计算用Spark对用户行为做聚合生成用户-歌曲评分矩阵。模型训练使用Spark MLlib里的ALS交替最小二乘协同过滤算法训练推荐模型。结果存储把推荐结果写回HBase或MySQL供后端服务查询。如果笔试或面试问你如何用Hadoop生态实现一个推荐系统你只要能把这个流程说出来再落到ALS算法、训练数据的格式、冷启动的简单策略就足够让人信服了。如果还能提到数据倾斜如何影响ALS训练那把前面讲的内容也用上了。6. 集群搭建与运维从伪分布式到Docker镜像6.1 三种部署模式的定位新手最容易搞混的一件事热词里hadoop伪分布式搭建、从零开始安装hadoop这种高频搜索说明很多人在入门阶段都在学习环境搭建上卡过壳。Hadoop有三种部署模式很多新手会搞混。本地模式不启动任何Hadoop守护进程MapReduce任务以单机JVM方式运行主要用于调试、跑单元测试。本地模式的文件系统也不是HDFS而是本地文件系统。伪分布式模式在一台机器上启动NameNode、DataNode、ResourceManager、NodeManager等所有守护进程。虽然都在一台机器上但完整的分布式流程都能跑通适合学习和功能验证。完全分布式模式多台机器组成一个集群NameNode和ResourceManager单独部署在一台机器上DataNode和NodeManager部署在计算节点上。这才是生产环境的真正形态。学习阶段我建议直接从伪分布式开始但一定要在虚拟机或云服务器上装而不是在Windows上直接折腾。Windows版本虽然可以调通但会有各种权限和原生库的问题浪费大量时间。6.2 核心配置文件每一项参数背后都是一个问题装过Hadoop的人都知道配置文件是最大的拦路虎。几个关键的XML文件各自管一部分配置配置文件常见配置项作用core-site.xmlfs.defaultFShadoop.tmp.dir指定HDFS的访问入口默认临时目录hdfs-site.xmldfs.replicationdfs.namenode.name.dirdfs.datanode.data.dir数据副本数、元数据存储路径、数据块存储路径mapred-site.xmlmapreduce.framework.name指定MapReduce运行在YARN上yarn-site.xmlyarn.resourcemanager.hostnameyarn.nodemanager.aux-servicesResourceManager地址Shuffle辅助服务有一个坑我印象特别深hadoop.tmp.dir如果不配置默认是/tmp/hadoop-${user.name}。Linux系统在重启后可能会清空/tmp目录一旦清空NameNode的元数据会丢失。你以为你的数据还在结果启动NameNode时直接报错。生产环境中一定要把hadoop.tmp.dir或dfs.namenode.name.dir配置到独立、持久的磁盘目录。还有一个经典坑格式化NameNode。hdfs namenode -format会生成一个clusterID。如果你格式化了一次后来又格式化一次而DataNode的clusterID还是旧的DataNode启动时就会因为ID不一致而注册失败。解决方法要么是把DataNode的数据目录清掉要么手动同步clusterID。我第一次搭集群时在这个问题上卡了一天后来发现就是格式化次数太多导致的。6.3 从裸机到Docker为什么镜像化部署越来越流行近几年Docker容器化部署Hadoop集群变得越来越常见热词里hadoop的docker镜像也非常贴合这个趋势。用Docker部署Hadoop的优势很明显环境隔离、秒级启动、便于扩展。比如要做课程设计或本地学习用docker-compose一键拉起一整套HDFSYARNHive比手动在多台虚拟机里配置快得多。但用Docker跑Hadoop也有需要注意的坑。首先容器重启后元数据会丢所以必须把NameNode的name.dir和DataNode的data.dir挂载到宿主机持久化卷。其次容器网络模式下DataNode会把自己的hostname注册到NameNode上如果hostname在容器重启后发生变化DataNode会无法注册。这就需要在启动容器时固定hostname或使用--network host模式。还有资源限制的问题。Hadoop的守护进程如果不去限制内存默认JVM参数可能是按物理机内存来设置的。在Docker里如果不配-m 4g这类参数容器会无视物理机内存直接OOM。所以搭建容器化集群时一定要同时配置JVM堆内存参数比如HADOOP_HEAPSIZE和容器资源限制。这也是从能启动到稳定运行之间的一道分水岭。7. 复盘后的备战策略给准备校招的同学避避坑7.1 复习顺序先把HDFS和MapReduce啃透再碰Hive和Spark准备Hadoop工程师校招最忌讳的就是贪多嚼不烂。我见过太多同学一上来就研究Spark Streaming、Flink CDC结果问一个HDFS的NameNode职责都说不完整。我的建议是严格按照存储 → 计算 → 调度 → 上层应用的顺序来复习。第一步吃透HDFS。原理、读写流程、副本机制、NameNode/DataNode职责、安全模式SafeMode、小文件问题。第二步吃透MapReduce。执行流程、Shuffle、InputFormat/OutputFormat、Partitioner/Combiner、Join、数据倾斜。第三步理解YARN。ResourceManager/NodeManager的职责、任务提交过程、资源调度Capacity Scheduler/Fair Scheduler。第四步再扩展到ZooKeeper的HA和Hive/Spark。为什么要这样安排因为上层组件的很多问题归根结底都能从前三层找到解释。比如Hive SQL慢可能不是SQL写得不好而是小文件太多导致Map Task数爆炸这本质是HDFS存储策略的问题Spark任务OOM可能不是代码问题而是YARN内存分配参数不合理。7.2 亲手搭一套环境胜过看十遍文档准备校招时我强烈建议你在自己电脑上用虚拟机或Docker从头搭一套完整环境。不是为了在简历里写熟悉Hadoop集群搭建而是为了让你真正理解配置文件里每一项参数的含义。你亲手配过core-site.xml就知道fs.defaultFS是干什么的你亲手踩过NameNode格式化的坑就明白dfs.namenode.name.dir有多重要。搭完集群再跑通几个经典程序WordCount、TopN、倒排索引、分区统计。跑的过程中打开YARN的8088端口页面看每个任务的Map数和Reduce数看提交时间、运行时间尝试用yarn logs -applicationId查看任务日志。这些实操经验是你面对笔试中间接考集群运维的底气。如果求职方向偏数据开发那Hive SQL也一定要练熟。至少做到不看文档能写出建表、分区、加载数据、复杂Join、窗口函数这些常用操作。7.3 面试官追问路径从一条命令一路问到源码最后聊一下面试。很多同学简历上写着熟练使用Hadoop但面试官大概率会从一条命令开始追问然后越问越深。典型的追问路径是这样的面试官你们生产环境是怎么提交MapReduce任务的你用hadoop jar xxx.jar MainClass。面试官这个命令之后发生了什么你客户端向YARN的ResourceManager提交ApplicationRM启动一个ApplicationMasterAM再向RM申请容器在容器里运行MapTask和ReduceTask。面试官AM和RM是怎么通信的如果某个Task挂了AM会怎么处理你Task失败后TaskAttempt会向AM汇报AM会重新申请容器重试默认4次超过则整个Job失败。面试官如果ResourceManager本身挂了怎么办你这就涉及YARN的HA需要依赖ZooKeeper……这一个系列追问下来会覆盖YARN、MapReduce、ZooKeeper三个模块。如果你在每一步都能答出机制是什么以及为什么这样设计面试官对你的评价会非常高。所以不要只背单个知识点要建立起知识点之间的关联。你学MapReduce的容错机制时要联想到YARN的AM学YARN的HA时要联想到ZooKeeper的ZAB协议。真正的高手是把Hadoop当成一个整体来理解的。最后再说一点我个人的体会这套2018年的题放到今天考察的核心框架其实没有变太多变的只是组件的边界和新的工具。只要你能把HDFS、MapReduce、YARN、ZooKeeper这一套底层逻辑吃透面对Hive、Spark、Flink这些新工具你学的速度会快得多。刷题重要但亲手搭一次环境、跑一个任务、看一遍日志可能才是让你在面试里脱颖而出的一步。
