1. 这门课到底在考什么：从一张复习卷看Hadoop知识体系的全貌
每年到了期末季，总有一批同学在群里哀嚎：“Hadoop这东西，课上听懂了，一到做题就懵。”我当年带过几届大数据方向的课程助教，也帮不少朋友梳理过复习思路，发现一个很普遍的现象：大家把Hadoop当成了一个“要背的东西”，而不是一个“要理解的东西”。这门课的核心从来不是让你默写某个类的全限定名，而是考察你对分布式存储和分布式计算这两大基石的认知深度。
一张典型的期末复习卷，通常覆盖这么几块内容：HDFS的架构与读写流程、MapReduce的编程模型与执行机制、YARN的资源调度逻辑、以及围绕它们展开的调优和故障处理。有些卷子还会涉及Hive、HBase这些上层组件的原理。看起来知识点很散，但它们之间有一条清晰的逻辑线——数据怎么存、怎么算、怎么调度、怎么优化。你把这条线抓住了，复习效率至少翻一倍。
这篇文章适合谁看？如果你正在准备大数据相关的期末考试，或者刚入职需要快速补齐Hadoop基础，再或者你是个自学者想检验自己对Hadoop的理解是否到位，那接下来的内容应该能帮到你。我会按照复习卷常见的出题逻辑，把每个模块的核心考点、容易踩的坑、以及答题时怎么组织语言，都掰开揉碎讲清楚。
2. HDFS架构与读写流程：考试最爱出大题的地方
2.1 NameNode和DataNode到底怎么分工
HDFS的架构问题几乎是每张卷子的必考题。很多同学能说出“NameNode存元数据，DataNode存数据”，但一到细节就含糊了。我建议你从职责边界的角度去记。
NameNode管的是“目录树”和“数据块映射关系”。具体来说，它维护三样东西：文件系统的命名空间（也就是目录结构）、每个文件被切成了哪些块、每个块存在哪些DataNode上。注意，NameNode不存实际数据，它存的是“数据的索引”。你可以把它理解成一个图书馆的检索系统——它告诉你哪本书在哪个架子上，但书本身不在它手里。
DataNode管的是“实际的数据块”。HDFS默认把文件切成128MB的块（这个值在较新版本是128MB，老版本是64MB，考试时要注意题目给的是哪个版本），每个块默认存3份副本。DataNode负责读写这些块，并定期向NameNode发送心跳和块报告。
注意：考试中如果问“NameNode宕机了会怎样”，不要只答“集群不可用”。要分情况说：如果是单点NameNode且没有HA机制，那整个集群确实无法写入新数据，但已缓存的读操作可能还能继续；如果有HA配置，则Standby节点会接管。这个细节能体现你对架构的理解深度。
2.2 写数据流程：pipeline机制是得分关键
HDFS写数据的流程是高频考点，我见过太多同学在这里丢分。核心在于理解pipeline（管道）机制。
当客户端要写一个文件时，大致经历这些步骤：
- 客户端向NameNode发起创建文件的请求，NameNode在命名空间中创建文件条目，并返回一组可用的DataNode列表（通常3个，按机架感知策略选）。
- 客户端把数据切成块，先写第一个块。它把数据发给列表中的第一个DataNode。
- 第一个DataNode收到数据后，一边写入本地磁盘，一边把数据转发给第二个DataNode。
- 第二个DataNode同样一边写本地，一边转发给第三个。
- 第三个DataNode写完以后，沿着管道反向发送ACK确认，最终客户端收到确认。
这个pipeline的设计好处是什么？并行传输。数据不是等第一个节点写完再发第二个，而是像水流一样在管道里同时流动，大大提高了写入效率。
考试中常问的变体包括：“如果pipeline中某个DataNode挂了怎么办？”答案是：客户端会收到异常通知，然后重新向NameNode请求新的DataNode来替换故障节点，pipeline会重建，继续传输剩余的块。已经写入的数据不会丢失，因为其他副本还在。
2.3 读数据流程：短路读和机架感知
读流程相对简单，但有几个细节容易被忽略。客户端向NameNode请求读文件时，NameNode返回的是数据块列表以及每个块所在的DataNode地址，而且这些地址是按“距离客户端由近到远”排序的。所谓“近”，在网络拓扑中指的是同一个机架优于跨机架。
客户端拿到地址列表后，会优先选择最近的DataNode读取。如果读取失败，它会自动切换到下一个副本所在的节点。这里有个概念叫短路读（Short-Circuit Read），指的是当客户端和DataNode在同一台机器上时，可以直接读本地文件系统，绕过网络传输。这个机制在考试中偶尔会作为加分项出现。
实操心得：复习时不要死记“先怎样再怎样”，而是画一张图，把客户端、NameNode、多个DataNode之间的箭头标清楚。考试时即使文字描述不完美，逻辑对了就能拿大部分分。
3. MapReduce编程模型：从WordCount到执行全流程
3.1 Map和Reduce的本质是什么
MapReduce的考题通常从“写一个WordCount”开始，但真正的考点在于执行流程和shuffle机制。先说Map和Reduce的本质：Map是“分而治之”中的“分”，把一个大任务拆成多个小任务并行处理；Reduce是“合”，把小任务的结果汇总。
但这里有个容易混淆的点：Map的输出并不是直接给Reduce的，中间还有一个Shuffle阶段。Shuffle是MapReduce的灵魂，也是考试中最容易出难题的地方。
3.2 Shuffle机制：分区、排序、合并、归并
Shuffle的过程可以拆成Map端和Reduce端两部分。
Map端：Map任务输出键值对后，先写入一个环形缓冲区（默认100MB）。当缓冲区用到80%时，会触发溢写（Spill）。溢写之前，数据会按照分区（Partition）进行划分，每个分区内的数据再按照key排序。溢写可能产生多个文件，最后这些文件会被合并（Merge）成一个大文件。
Reduce端：Reduce任务会从各个Map任务所在的节点拉取属于自己分区的数据。拉取过来的数据先放入内存缓冲区，不够就溢写到磁盘。最后对所有拉取的数据进行归并排序，形成最终的有序输入给Reduce函数。
考试中常问：“为什么Shuffle是MapReduce的性能瓶颈？”答案要围绕磁盘I/O和网络I/O来说：溢写涉及大量磁盘读写，拉取涉及大量网络传输，而且排序本身也消耗CPU。调优的手段包括调整缓冲区大小、使用Combiner减少数据量、开启压缩等。
3.3 Combiner和Partitioner：两个容易被低估的组件
Combiner本质上是一个“迷你Reduce”，它在Map端就对输出进行局部汇总。比如WordCount中，Map输出（hello,1）（hello,1），Combiner可以合并成（hello,2），这样传输给Reduce的数据量就减少了。但要注意：Combiner不适用于所有场景，只有满足结合律和交换律的操作才能用，比如求和、求最大值可以，求平均值就不行。
Partitioner决定Map输出的键值对分配给哪个Reduce。默认是HashPartitioner，用key的hashCode对Reduce数量取模。考试中如果让你自定义Partitioner，通常是为了实现“按某个字段分组输出到不同文件”的需求。
常见问题：有同学问“Combiner和Partitioner能一起用吗？”当然可以，而且经常一起用。Combiner减少数据量，Partitioner控制数据流向，两者不冲突。
4. YARN资源调度：集群的“操作系统”
4.1 ResourceManager和NodeManager的职责划分
YARN的架构是“一主多从”：ResourceManager（RM）是全局资源管理者，NodeManager（NM）是每个节点上的代理。RM负责整个集群的资源分配，NM负责单个节点上的资源管理和任务监控。
RM内部又分两个核心组件：Scheduler和ApplicationMaster（AM）管理模块。Scheduler只负责资源分配，不关心任务状态；AM管理模块负责监控AM的运行状态，并在AM失败时重启它。
考试中常问：“YARN和MapReduce 1.0的区别是什么？”核心答案是：MapReduce 1.0中JobTracker既管资源又管任务，压力大且单点故障风险高；YARN把资源管理和任务调度拆开了，RM只管资源，AM管任务，扩展性和容错性都更好。
4.2 调度器类型：FIFO、Capacity、Fair
YARN内置了三种调度器，考试中经常让你比较它们的优缺点。
| 调度器类型 | 核心思想 | 优点 | 缺点 |
|---|---|---|---|
| FIFO | 先提交先执行 | 实现简单 | 大任务会阻塞后续小任务 |
| Capacity | 划分队列，每个队列分配固定容量 | 资源隔离好，适合多租户 | 队列容量配置不灵活时利用率低 |
| Fair | 动态调整，所有任务公平共享 | 小任务响应快 | 配置复杂，调优门槛高 |
实际生产环境中，Capacity和Fair用得比较多。考试时如果问“哪种调度器适合多用户共享集群”，优先答Capacity或Fair，并说明理由。
4.3 ApplicationMaster的作用与生命周期
AM是YARN中最“忙”的角色。每个应用程序（比如一个MapReduce作业）都有一个AM，它负责：向RM申请资源、与NM通信启动Container、监控任务进度、处理任务失败、最后向RM注销自己。
AM的生命周期是：提交应用 -> RM分配第一个Container -> NM启动AM -> AM向RM注册 -> AM申请资源并启动任务 -> 任务完成 -> AM注销 -> Container释放。
注意：AM本身也可能失败。如果AM挂了，RM会尝试重启它（默认最多2次）。如果重启次数超限，整个应用就失败了。这个细节在故障处理题中经常出现。
5. 调优与故障处理：从“能跑”到“跑得好”
5.1 小文件问题：NameNode的噩梦
HDFS设计之初是为了存大文件，但实际场景中经常产生大量小文件。每个小文件都会在NameNode中占用一条元数据记录（大约150字节），如果有一亿个小文件，NameNode的内存就会被撑爆。
考试中常问的解决方案包括：合并小文件（用MapReduce或HAR归档）、使用CombineFileInputFormat、或者在数据写入时就做聚合。我个人的经验是，在数据采集阶段就做合并是最省事的，等到存储后再处理，成本会高很多。
5.2 数据倾斜：Reduce阶段的“堵车”
数据倾斜是指某些key的数据量远大于其他key，导致个别Reduce任务跑得特别慢，拖累整个作业。典型表现是：大部分Reduce任务都完成了，就剩一两个卡在99%不动。
解决方案有几种：加盐（给key加随机前缀打散）、自定义Partitioner、使用Combiner做预聚合、或者在业务层面预处理数据。考试中如果让你设计一个方案，建议先分析倾斜原因，再给出针对性措施，不要一上来就写“加盐”。
5.3 常见故障速查表
| 故障现象 | 可能原因 | 排查思路 |
|---|---|---|
| 作业卡在Map 0% | 输入分片有问题或资源不足 | 检查InputFormat配置和RM资源队列 |
| Reduce卡在99% | 数据倾斜或Shuffle慢 | 查看各Reduce任务处理的数据量差异 |
| NameNode启动失败 | 元数据损坏或端口占用 | 检查fsimage和edits文件，确认端口 |
| DataNode频繁掉线 | 磁盘满或网络抖动 | 检查磁盘使用率和心跳日志 |
| 作业报OutOfMemory | 内存参数配置不合理 | 调整Map/Reduce内存和JVM堆大小 |
实操心得：排查故障时，先看日志，再看监控，最后才改配置。很多同学一上来就调参数，结果越调越乱。日志里通常有明确的错误信息，比如“Connection refused”就是网络问题，“Disk space exceeded”就是磁盘问题，对症下药才有效。
6. 复习策略与答题技巧：怎么把知识变成分数
6.1 构建知识框架比刷题更重要
我见过很多同学复习时疯狂刷题，但遇到新题型就懵了。根本原因是脑子里没有框架，知识点是散的。建议你花半天时间，画一张Hadoop生态的全景图：底层是HDFS，中间是YARN和MapReduce，上层是Hive、HBase、Spark等。每个组件解决什么问题、核心机制是什么、和其他组件怎么交互，都标清楚。
这张图一旦画出来，你会发现大部分考题都能定位到某个模块，然后顺着框架去回忆细节，比死记硬背高效得多。
6.2 答题时先给结论再展开
考试时间有限，阅卷老师也不会逐字逐句看。答题时建议用“总-分”结构：先一句话给出核心结论，再分点展开。比如问“HDFS为什么适合存大文件”，先答“因为HDFS的块设计减少了NameNode元数据压力，且流式读取适合大文件顺序访问”，然后再展开解释块大小、元数据比例、吞吐量等细节。
6.3 计算题不要跳步骤
如果卷子里有计算题，比如“给定块大小和副本数，计算某文件占用的总存储空间”，一定要把每一步写清楚。即使最后结果算错了，步骤分也能拿到不少。常见的计算包括：块数量、副本总大小、NameNode内存估算、Map/Reduce任务数量等。
最后分享一个小技巧：复习卷中如果出现“简述XXX原理”这类题，字数不要太多，控制在200字以内，把关键词都点到即可。如果出现“详细描述XXX流程”或“设计一个方案”，那就要展开写，最好配上一个简单的例子，让答案更具体。
我个人在实际教学和项目中的体会是，Hadoop这门技术，入门容易精通难。考试考的不是你背了多少，而是你能不能把各个模块串起来理解。把HDFS、MapReduce、YARN这三块的核心流程吃透，再辅以调优和故障处理的常识，应付期末复习卷绰绰有余。真正到了工作中，你会发现这些原理性的东西才是支撑你解决复杂问题的底子。
