企业官网建设流程全解析

看到这套2018年秋季校招的Hadoop工程师笔试题，我心里其实挺有感触的。那几年刚好是大数据岗位需求量爆发的阶段，爱奇艺作为头部视频平台，出的题基本代表了当时大厂对Hadoop工程师的能力预期。一套题做下来，你会发现它根本不是在考你是否背熟了某个命令，而是在考察你对整个分布式系统有没有建立完整的、体系化的认知。这篇文章我就以这套题和近年大厂常见的考察方式为引子，把Hadoop工程师校招笔试和面试中那些绕不开的硬核知识点，结合我实际踩坑和后来面试别人的经验，掰开揉碎讲清楚。

1. 这场笔试在考什么：Hadoop工程师校招的隐藏筛选逻辑

1.1 考点模块地图：从HDFS到Spark生态一次全覆盖

结合这套题以及当时大量校招真题的分布情况，Hadoop工程师笔试基本围绕这几个模块展开：HDFS、MapReduce、Zookeeper、Hive、Spark、集群搭建与运维。每个模块的占比其实很能说明问题。

注意看，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收到请求后，会做一系列检查和元数据操作：

1. 权限检查：当前用户对目标路径是否有写权限。
2. 父目录检查：目标父目录是否存在，如果不存在直接报错。
3. 文件存在性检查：如果同名文件已存在且没指定覆盖选项，报FileAlreadyExistsException。
4. 在命名空间（Namespace）中注册新的INode，也就是文件的元数据条目。
5. 返回一个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表的数据标签是"0"，B表的数据标签是"1"，Join的公共字段作为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的HA（High Availability）就建立在ZooKeeper之上。

ZooKeeper最核心的两个机制是：ZAB协议和Leader选举。ZAB协议保证所有节点的数据一致性，Leader负责处理写请求，然后把事务广播给所有Follower，超过半数节点确认后事务才提交。这个"超过半数"的机制是ZooKeeper能容错的关键。

那ZooKeeper又如何服务于HDFS的HA？在Hadoop 2.x之后，NameNode是高可用的，集群里有两个NameNode：Active和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现在的主流方案是QJM（Quorum 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的执行链路是这样的：

1. 用户通过CLI或HiveServer2提交SQL。
2. 解析器（Parser）对SQL做语法分析，生成抽象语法树（AST）。
3. 编译器（Compiler）将AST转换为逻辑执行计划，并做语义分析，比如字段是否存在、表的元数据是否正确。
4. 优化器（Optimizer）对逻辑计划进行优化，比如谓词下推、列剪枝、MapJoin转换、分区裁剪。
5. 执行器（Executor）把优化后的执行计划编译成DAG（有向无环图）任务，提交给YARN运行。

考察Hive时，"分区裁剪"和"谓词下推"是高频词。所谓分区裁剪，就是SQL里的WHERE dt='2024-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生态串起来做一个端到端的解决方案。

一个典型的音乐推荐流程可以这样拆解：

1. 数据采集：客户端上报用户听歌行为（播放、收藏、跳过、分享）。
2. 数据存储：原始日志存HDFS。
3. 数据清洗：用Hive或Spark做ETL，去重、补全字段。
4. 特征计算：用Spark对用户行为做聚合，生成"用户-歌曲"评分矩阵。
5. 模型训练：使用Spark MLlib里的ALS（交替最小二乘）协同过滤算法，训练推荐模型。
6. 结果存储：把推荐结果写回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文件，各自管一部分配置：

有一个坑我印象特别深：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一键拉起一整套HDFS+YARN+Hive，比手动在多台虚拟机里配置快得多。

但用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提交Application，RM启动一个ApplicationMaster，AM再向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这些新工具，你学的速度会快得多。刷题重要，但亲手搭一次环境、跑一个任务、看一遍日志，可能才是让你在面试里脱颖而出的一步。