Hadoop期末复习卷深度解析：HDFS、MapReduce、YARN核心考点与实战

1. 从课程名到复习卷：这份Hadoop期末资料到底在考什么

看到“Hadoop大数据处理技术”这个课程名，很多人的第一反应是：这不就是教你怎么装个Hadoop、跑个WordCount吗？如果你真这么想，那期末复习卷可能会让你措手不及。我翻过不少高校的大数据课程资料，也跟一些带过这门课的讲师聊过，发现一个很普遍的规律：课程名字叫“Hadoop”，但期末卷子上纯考Hadoop安装和API调用的比例，通常只占三成左右，剩下七成全是围绕HDFS、MapReduce、YARN这三大件展开的原理、调优和场景分析题。

这份复习卷的标题里有个关键信息——“2021春”。2021年春季学期是个比较特殊的时间节点，那时候Hadoop 3.x已经稳定了好几年，很多高校的实验环境从Hadoop 2.x升级到了3.x，但教材和讲义往往还停留在2.x的架构描述上。这就导致复习卷里经常出现“请对比Hadoop 2.x与3.x在YARN资源调度上的差异”这类题目，如果你只看了老版本的资料，很容易答偏。

那这份复习卷到底适合谁看？我把它拆成三类人群：第一类是正在修这门课、马上要考试的学生，你需要的是考点梳理和答题框架；第二类是想系统补Hadoop基础的后端或数据开发，你可以把这份卷子当成自测清单，看看自己是不是只会用不会讲；第三类是做大数据平台运维的，卷子里关于HDFS副本机制、YARN容器分配、MapReduce shuffle过程的题目，其实都是日常排障的理论底子。

我见过太多人复习Hadoop的方式就是背命令、背配置参数，结果考试一考“为什么HDFS默认块大小是128MB而不是64MB”就懵了。所以这篇博文不会给你一份标准答案，而是把复习卷背后真正要考的能力拆开，告诉你每个模块的复习重点应该放在哪里，以及那些看起来像“送分题”实际上最容易丢分的坑。

2. HDFS模块：从“存文件”到“块、副本、元数据”的三层追问

2.1 块大小为什么是128MB而不是随便定的

复习卷里但凡涉及HDFS，几乎必考块大小。很多人的复习方式就是记住“Hadoop 2.x默认128MB，1.x默认64MB”，但考试如果只考这个数字，那就太没水平了。真正拉开差距的题目是：“请从寻址开销和磁盘传输速率两个角度，解释为什么128MB是一个合理的默认值。”

这里面的逻辑其实不复杂。HDFS的块大小设计要平衡两个矛盾：块太小，NameNode需要维护的元数据条目就多，每个块对应一条元数据记录，块数量爆炸会直接压垮NameNode的内存；块太大，MapReduce任务并行度上不去，因为一个块通常对应一个map任务，块太大导致任务数太少，集群利用率低。

那128MB是怎么算出来的？业界的经验公式是：块大小 ≈ 磁盘平均寻址时间 × 磁盘传输速率。假设一块机械硬盘的寻址时间约10ms，传输速率约100MB/s，那么10ms内能传输的数据量大约是1MB，但为了让寻址开销占比降到1%以下，块大小需要是寻址传输量的100倍左右，也就是100MB上下。128MB就是在这个基础上取了一个2的幂次方值，方便内存管理和计算。

注意：现在很多实验环境用的是SSD，寻址时间大幅缩短，理论上块大小可以调小，但HDFS的默认值并没有因此改变，因为集群环境往往是混合存储，而且改默认值会带来兼容性问题。

复习的时候，你不能只记数字，要能把“寻址开销占比”这个推导过程讲清楚。考试如果出计算题，比如“某磁盘寻址时间8ms，传输速率200MB/s，请计算理论最优块大小”，你要能套用这个逻辑算出80MB左右，然后说明实际会取64MB或128MB。

2.2 副本机制：三副本不是随便定的，机架感知才是考点

副本数默认是3，这个数字也是复习卷的高频考点。但考试不会只问你“默认副本数是多少”，而是会问：“为什么是3而不是2或者4？请从可靠性、写入带宽和存储成本三个维度分析。”

从可靠性看，假设单块磁盘年故障率是5%，三副本情况下数据丢失概率是0.05³=0.000125，也就是万分之一点二五，已经足够低了。如果降到2副本，丢失概率变成0.25%，虽然看起来也不高，但对于PB级集群来说，每天都有块丢失的风险。从写入带宽看，副本越多，写入时需要同步的数据量越大，三副本的写入放大是3倍，四副本就是4倍，对网络带宽的消耗是线性增长的。从存储成本看，三副本意味着实际存储利用率只有33%，四副本降到25%，对于动辄上千节点的集群，这个成本差异非常可观。

但真正容易丢分的是机架感知的细节。HDFS的副本放置策略是：第一个副本放在客户端所在节点（如果客户端在集群外，则随机选一个节点），第二个副本放在不同机架的节点上，第三个副本放在与第二个副本同机架但不同节点的机器上。这个策略的核心目的是兼顾可靠性和写入带宽——跨机架写入的带宽开销大，所以只让一个副本跨机架。

复习卷里常见的变形题是：“如果集群只有一个机架，副本放置策略会怎么变？”答案是：所有副本都会放在同一机架的不同节点上，因为机架感知逻辑会退化为节点级别的分散。这时候如果整个机架断电，数据就全丢了，所以生产环境至少要有两个机架。

2.3 NameNode的元数据管理：内存估算题是送分还是送命

NameNode的元数据管理是HDFS模块里最容易出计算题的地方。复习卷里经常出现这样的题目：“一个集群有1000万个文件，每个文件平均1.5个块，每个块的元数据占用150字节，请估算NameNode需要多少内存。”

这道题看起来简单，但很多人会漏掉几个关键点。首先，每个文件除了块信息，还有文件本身的元数据（文件名、权限、修改时间等），通常按150字节估算。其次，每个块除了块ID，还有副本位置信息，但副本位置信息不持久化在内存里，而是通过块报告重建的，所以内存估算时只算块的基本元数据。

正确的估算逻辑是：文件元数据 = 1000万 × 150字节 = 1.5GB；块元数据 = 1000万 × 1.5 × 150字节 = 2.25GB；合计约3.75GB。但实际生产环境还要留出30%左右的余量给JVM堆外内存和GC开销，所以NameNode的堆内存至少要给到6GB以上。

提示：考试如果问你“NameNode内存不足时有哪些解决方案”，不要只答“加内存”。标准答案应该包括：联邦HDFS（Federation）横向扩展多个NameNode、归档冷数据减少文件数、调小块大小增加单文件块数但减少总文件数（这个要权衡）、使用HDFS存档（HAR）合并小文件。

复习这个模块的时候，我建议你拿一张纸，自己画一遍NameNode的内存结构图，把文件元数据、块元数据、副本位置信息分别标出来，然后自己出几道计算题算一遍。这个知识点一旦理解透了，不管题目怎么变，你都能拆解成“文件数×单文件元数据 + 块数×单块元数据”这个基本框架。

3. MapReduce模块：shuffle过程是分水岭，能讲清楚的人不多

3.1 Map任务的数量到底由谁决定

复习卷里关于MapReduce的第一道坎通常是：“一个MapReduce作业的map任务数量由什么决定？”很多人会答“由输入数据大小决定”，这个答案只对了一半。准确地说，map任务数量由输入分片（InputSplit）的数量决定，而分片数量又由输入格式（InputFormat）和块大小共同决定。

以最常用的FileInputFormat为例，默认情况下，分片大小等于HDFS块大小（128MB）。如果一个文件是500MB，那么会被切成4个分片（128+128+128+116），对应4个map任务。但如果文件是100MB，虽然小于一个块，仍然会作为一个分片，对应1个map任务。

这里有个容易被忽略的细节：如果文件中有大量小文件，每个小文件都会单独形成一个分片，导致map任务数量爆炸。比如1000个1MB的小文件，会产生1000个map任务，每个任务启动和销毁的开销可能比处理数据本身还大。考试如果出“小文件问题怎么解决”，你要能答出：使用CombineFileInputFormat合并小文件、在入库前用HAR归档、或者用Spark等支持更细粒度调度的框架。

还有一个反直觉的点：map任务数量并不是越多越好。如果分片太小，任务调度和启动的开销会占比过高；如果分片太大，单个任务运行时间过长，集群的并行度上不去。生产环境通常会把分片大小控制在128MB到256MB之间，根据集群规模和作业特性微调。

3.2 shuffle的六个阶段：从环形缓冲区到归并排序

Shuffle是MapReduce的灵魂，也是复习卷里最能区分“背过”和“懂了”的考点。很多教材会把shuffle一笔带过，但考试往往要求你详细描述从map输出到reduce输入的完整数据流。我把它拆成六个阶段，你按这个框架答，基本不会漏点。

第一阶段是map端写入环形缓冲区。map任务处理完一条记录后，输出键值对不是直接写磁盘，而是先写入一个内存中的环形缓冲区，默认大小100MB。缓冲区的作用是批量写入，减少磁盘I/O次数。

第二阶段是溢写（spill）触发。当缓冲区使用率达到80%（默认阈值）时，一个后台线程会开始将缓冲区数据溢写到磁盘。溢写过程中，map任务可以继续往剩余的20%空间写入，这就是“环形”的设计意图——读写不冲突。

第三阶段是分区与排序。溢写之前，数据会按照reduce任务数量进行分区（partition），每个分区对应一个reduce任务。分区内部再按照key进行排序。排序是shuffle的核心，因为reduce端需要按key分组处理。

第四阶段是溢写文件合并。每次溢写都会生成一个临时文件，map任务结束后，这些临时文件会被归并（merge）成一个最终输出文件。归并过程是多次归并排序，保证最终文件整体有序。

第五阶段是reduce端拉取（fetch）。reduce任务启动后，会通过HTTP协议从各个map任务的输出文件中拉取属于自己分区的数据。拉取是并行的，默认有5个拉取线程。

第六阶段是reduce端归并排序。拉取到的数据先放入内存缓冲区，缓冲区满了就溢写到磁盘，最后对所有溢写文件和内存中的数据进行一次归并排序，形成最终的reduce输入。

注意：考试如果问“shuffle过程中哪些操作会写磁盘”，你要能答出：map端溢写、map端归并、reduce端溢写、reduce端归并，一共四次磁盘写入。这也是为什么shuffle被称为MapReduce性能瓶颈的原因。

3.3 Combiner和Partitioner：两个容易被混淆的优化组件

复习卷里经常把Combiner和Partitioner放在一起考，因为这两个组件名字里都有“combine”或“partition”的意思，但作用完全不同。Combiner是map端的局部聚合，Partitioner是决定数据去哪个reduce的分配器。

Combiner的本质是一个“迷你reduce”，它在map端对相同key的value进行合并，减少shuffle阶段传输的数据量。比如WordCount作业中，map输出（hello,1）（hello,1）（hello,1），Combiner会合并成（hello,3），这样传输到reduce端的数据量就减少了三分之二。但Combiner不是万能的，它只适用于满足结合律和交换律的操作，比如求和、求最大值，不能用于求平均值。

Partitioner决定了map输出的每个键值对应该去哪个reduce任务。默认的HashPartitioner是“key的hashCode对reduce数量取模”。这个默认策略在大多数情况下没问题，但如果数据分布不均匀，会导致某些reduce任务处理的数据量远大于其他任务，出现数据倾斜。考试如果出“如何解决数据倾斜”，Partitioner层面的答案就是：自定义Partitioner，把热点key打散到多个reduce任务中。

我见过一道很经典的复习题：“Combiner能否替代Partitioner？”答案是绝对不能。Combiner改变的是数据量，Partitioner改变的是数据流向，两者解决的是不同层面的问题。如果你在卷子上把这两个搞混了，基本就告别高分了。

4. YARN模块：资源调度不是“先到先得”那么简单

4.1 三种调度器的适用场景对比

YARN的调度器是复习卷的必考内容，但很多人只记住了FIFO、Capacity、Fair这三个名字，却说不清楚它们分别适合什么场景。我整理了一个对比表，你复习的时候可以直接对照记忆。

FIFO调度器最简单，但生产环境基本不用，因为一个大的ETL作业可能跑几个小时，后面排队的交互式查询全被堵死。Capacity调度器把集群资源划分成多个队列，每个队列有最低容量保证和最大容量上限，适合“多个部门共用集群但需要资源隔离”的场景。Fair调度器则是动态调整，谁的作业缺资源就给谁分配，适合“多个用户提交短查询”的场景。

考试如果问你“某公司有实时查询和离线批处理两类作业，应该选哪种调度器”，标准答案是Capacity调度器，因为可以给实时查询队列分配较高的优先级和最低容量保证，同时给离线批处理队列分配剩余资源。Fair调度器虽然也能用，但实时查询对延迟敏感，Fair的动态抢占可能导致查询作业被频繁打断。

4.2 Container的资源分配：内存和CPU的博弈

Container是YARN里的资源抽象单位，每个Container包含一定量的内存和CPU资源。复习卷里经常考“一个Container默认分配多少内存”和“如何调整Container大小”。

默认情况下，YARN的单个Container最小内存是1024MB，最大内存是8192MB。但这两个值在实际生产环境几乎一定会被调整，因为不同作业对资源的需求差异很大。比如一个简单的日志过滤作业，可能只需要512MB内存；而一个复杂的机器学习特征工程作业，可能需要16GB甚至32GB。

这里有个容易踩的坑：YARN的内存分配是“向上取整”的。假设你设置Container最小内存为1024MB，作业请求1500MB，YARN会分配2048MB（2个Container单位），而不是1536MB。所以调小最小Container内存可以提高资源利用率，但会增加调度开销。

CPU资源的分配更复杂。YARN默认使用DefaultResourceCalculator，只考虑内存，不考虑CPU。如果要让CPU也参与调度，需要切换到DominantResourceCalculator，它会同时考虑内存和CPU的“主导资源”。比如一个作业请求4GB内存和1个CPU，另一个作业请求1GB内存和4个CPU，DominantResourceCalculator会根据集群的CPU和内存总量，计算每个作业的“主导资源占比”，然后按比例分配。

提示：考试如果出“为什么我的作业提交后一直处于ACCEPTED状态”，你要能答出：可能是队列资源不足、可能是AM（ApplicationMaster）等待Container分配、也可能是调度器配置了最大AM数量限制。排查思路是先看队列容量，再看AM日志。

4.3 ApplicationMaster的生命周期：从提交到完成的完整链路

ApplicationMaster（AM）是YARN里最核心的组件，但很多复习卷只考“AM的作用是什么”，而不考它的完整生命周期。我建议你按“提交-启动-运行-完成”四个阶段来复习。

提交阶段：客户端向ResourceManager（RM）提交作业，RM返回一个ApplicationID，并分配第一个Container给AM。这个Container的分配是“特权”的，不受队列容量限制，因为AM是作业的“管理者”，必须先启动起来。

启动阶段：AM在分配的Container中启动，向RM注册自己，然后根据作业的输入分片数量，向RM申请运行map和reduce任务的Container。AM会持续向RM发送心跳，汇报进度和资源需求。

运行阶段：RM根据调度器策略分配Container，AM收到Container后，在对应的NodeManager上启动任务。AM负责任务的监控、重试和推测执行。如果某个任务运行过慢，AM会启动一个“推测任务”并行运行，谁先完成就用谁的结果。

完成阶段：所有任务完成后，AM向RM注销自己，释放所有Container，作业状态变为SUCCEEDED或FAILED。如果AM本身失败，RM会尝试重启AM（默认最多2次），重启后AM需要从之前的作业状态中恢复。

复习这个模块的时候，我建议你画一张时序图，把Client、RM、AM、NM四个角色的交互按时间顺序标出来。考试如果出“描述一个MapReduce作业从提交到完成的完整流程”，这张图就是你的答题框架。

5. 复习卷里那些“看起来超纲”的题，其实都在考同一个能力

5.1 数据倾斜的排查与解决：从现象到根因

数据倾斜是Hadoop考试里的“压轴题”，因为它同时考察HDFS、MapReduce和YARN三个模块的知识。复习卷里常见的问法是：“某作业运行缓慢，发现大部分reduce任务早已完成，但有几个reduce任务卡在99%不动，请分析原因并给出解决方案。”

这道题的答题逻辑应该是：先定位现象（少数reduce任务处理的数据量远大于其他任务），再分析根因（某个或某几个key的数据量特别大，导致HashPartitioner把这些key都分到了同一个reduce），最后给出解决方案。

解决方案要分层次答。Map端优化：使用Combiner做局部聚合，减少传输到reduce的数据量。Partitioner优化：自定义Partitioner，把热点key加上随机前缀打散到多个reduce任务中，但这样需要二次聚合。参数优化：调大reduce端的内存缓冲区，减少溢写次数；开启reduce端的并行拉取，加快数据拉取速度。业务优化：如果热点key是已知的（比如某个大客户的ID），可以在ETL阶段单独处理，或者给这个key加盐（salt）。

我见过一道更狠的题：“如果热点key是未知的，你怎么在作业运行过程中动态发现并处理？”这个问题的标准答案是：在map端维护一个计数器，统计每个key的输出记录数，作业运行一段时间后，通过JobTracker或YARN的Web UI查看计数器，找到top N的key，然后手动调整Partitioner或加盐策略。虽然不能完全自动化，但这是生产环境最实用的排查手段。

5.2 小文件问题的连锁反应：从NameNode到MapReduce

小文件问题是Hadoop的“慢性病”，复习卷里经常把它和NameNode内存、map任务数量、作业执行效率串在一起考。一道典型的综合题是：“某集群有500万个平均大小10KB的小文件，请分析这会带来哪些问题，并给出至少三种解决方案。”

问题分析要分三层。NameNode层面：500万个文件，每个文件元数据约150字节，仅文件元数据就占用750MB内存，加上块元数据（假设每个文件1个块），总内存占用超过1.5GB，NameNode压力很大。MapReduce层面：如果直接对这些文件跑作业，会产生500万个map任务，每个任务处理10KB数据，任务启动和调度的开销远超数据处理本身，作业可能跑几个小时都跑不完。存储层面：每个小文件占用一个HDFS块，但实际只用了10KB，存储利用率极低。

解决方案要分场景。入库前合并：在数据采集阶段就用Flume或Logstash的聚合功能，把多个小文件合并成128MB左右的大文件再上传。使用HAR归档：HDFS提供了HAR（Hadoop Archive）工具，可以把多个小文件打包成一个HAR文件，NameNode只需要维护HAR文件的元数据，但HAR文件不支持修改，适合冷数据。使用CombineFileInputFormat：在MapReduce作业中，自定义InputFormat把多个小文件合并成一个分片，减少map任务数量。迁移到支持小文件的存储：比如HBase或对象存储，它们对小文件的处理更友好。

注意：考试如果问你“HAR归档后文件还能被MapReduce直接读取吗”，答案是能，但需要指定InputFormat为HarInputFormat，而且HAR文件的读取性能比普通文件略低，因为需要额外的索引查找。

5.3 推测执行的触发条件与副作用

推测执行（Speculative Execution）是MapReduce的“双刃剑”，复习卷里经常考它的触发条件和潜在问题。默认情况下，如果一个任务运行速度比同阶段其他任务慢很多（比如慢20%以上），AM会启动一个推测任务，两个任务处理同样的数据，谁先完成就用谁的结果。

触发条件有两个关键参数：mapreduce.job.speculative.slowtaskthreshold（默认1.0，表示任务进度低于平均进度的比例）和mapreduce.job.speculative.speculativecap（默认0.1，表示同时运行的推测任务比例上限）。如果集群资源紧张，推测任务会抢占其他作业的资源，导致整体吞吐量下降。

副作用主要有三个。资源浪费：推测任务和原任务同时运行，消耗双倍资源，如果原任务只是暂时变慢（比如GC停顿），推测任务就是纯浪费。数据竞争：如果任务有副作用（比如写数据库），两个任务同时写会导致数据重复或冲突。作业延迟：推测任务启动需要时间，如果原任务在推测任务启动后很快完成，推测任务反而增加了作业的总运行时间。

考试如果问“什么情况下应该关闭推测执行”，标准答案是：作业中有非幂等的写操作、集群资源紧张、任务运行时间短（推测任务来不及启动就结束了）。关闭方式是在作业配置中设置mapreduce.map.speculative=false和mapreduce.reduce.speculative=false。

6. 从复习卷到实战：那些考试不考但工作必用的技能

6.1 用Web UI定位作业瓶颈：比看日志快十倍

复习卷里很少考Web UI的使用，但实际工作中，YARN的ResourceManager Web UI和MapReduce的JobHistory Server是你排查问题的第一入口。我分享几个最常用的排查路径。

ResourceManager UI（默认8088端口）：首页可以看到集群的资源使用率、活跃节点数、运行中的作业列表。点击某个作业，可以看到它的AM日志、Container分配情况、每个任务的运行状态。如果作业卡在ACCEPTED状态，看队列的已用资源和容量上限；如果作业卡在RUNNING状态但进度不动，看AM日志里有没有“Waiting for AM container to be allocated”之类的信息。

JobHistory Server UI（默认19888端口）：这里可以看到已完成作业的详细统计，包括每个map/reduce任务的运行时间、输入输出记录数、shuffle的字节数。如果某个reduce任务的处理记录数远大于其他任务，基本可以确定是数据倾斜。如果某个map任务的运行时间远大于其他任务，可能是输入分片不均匀或者节点性能差异。

提示：考试如果出“如何判断一个作业是否存在数据倾斜”，除了看reduce任务的处理记录数，还可以看shuffle阶段的字节数分布。如果某个reduce的shuffle字节数占比超过50%，而reduce任务数有10个，那倾斜就很明显了。

6.2 参数调优的“最小必要集”：别背几百个参数，先搞懂这五个

Hadoop的调优参数有几百个，但复习卷和实际工作中真正高频使用的就那么几个。我按优先级排个序，你先把这五个搞懂，再去看其他的。

第一个是mapreduce.map.memory.mb和mapreduce.reduce.memory.mb，控制map和reduce任务的内存上限。默认是1024MB，但如果你的任务处理大量数据，需要调到2048MB或4096MB。调这个参数的时候要同步调mapreduce.map.java.opts和mapreduce.reduce.java.opts，把JVM堆内存设置为容器内存的80%左右，留出空间给堆外内存。

第二个是mapreduce.task.io.sort.mb，控制map端环形缓冲区的大小，默认100MB。如果map输出数据量大，可以调到200MB或300MB，减少溢写次数。但不要调太大，否则会挤占map任务的堆内存。

第三个是mapreduce.reduce.shuffle.parallelcopies，控制reduce端拉取map输出的并行线程数，默认5。如果map任务数量多、网络带宽充足，可以调到10或20，加快shuffle速度。

第四个是mapreduce.job.reduces，控制reduce任务数量。默认是1，但生产环境通常设置为集群reduce槽位的70%到90%。如果设置为0，表示不需要reduce阶段，map输出直接写入HDFS。

第五个是dfs.replication，控制HDFS副本数。默认3，但如果集群存储紧张且数据可重新生成，可以降到2。如果是关键业务数据，建议保持3甚至提高到4。

6.3 从单机伪分布式到集群：环境搭建的坑比考试题还多

复习卷不会考你怎么搭集群，但如果你要真正跑通一个Hadoop作业，环境搭建是绕不过去的。我踩过的坑包括：SSH免密登录没配好导致启动脚本卡住、core-site.xml里的fs.defaultFS写成了localhost导致DataNode注册不上、hdfs-site.xml里的dfs.datanode.data.dir指向了不存在的目录导致DataNode启动即退出。

最隐蔽的一个坑是时间同步。Hadoop集群要求所有节点的时间偏差不能超过30秒，否则会出现“Clock skew”错误，导致任务失败。我见过一个集群因为某台节点的时间慢了5分钟，导致该节点上的所有任务都失败，但日志里只报“Container exited with a non-zero exit code”，排查了半天才发现是时间问题。

还有一个坑是主机名解析。Hadoop用主机名来标识节点，如果/etc/hosts里没有配置所有节点的IP和主机名映射，或者配置了但和实际IP不一致，会导致节点之间无法通信。我建议在搭建集群之前，先用ping和ssh命令确认所有节点之间的连通性，再开始安装Hadoop。

注意：如果你只是应付考试，环境搭建可以跳过。但如果你想真正掌握Hadoop，我强烈建议你在本地用虚拟机搭一个三节点集群，把NameNode、DataNode、ResourceManager、NodeManager都跑起来，然后提交一个WordCount作业，观察整个流程。这个过程会让你对复习卷里的所有知识点有更直观的理解。

7. 复习策略：三天时间怎么分配才能覆盖80%的考点

如果你现在距离考试只有三天，我建议你按这个优先级复习。第一天上午把HDFS的块大小、副本机制、NameNode内存估算过一遍，下午把MapReduce的shuffle六个阶段和Combiner/Partitioner的区别搞清楚。第二天上午复习YARN的三种调度器和Container资源分配，下午做三到五道综合题，重点练数据倾斜和小文件问题的分析。第三天上午把之前做错的题重新做一遍，下午看Web UI的使用和常用调优参数，晚上早点休息。

如果你有更多时间，我建议你找一份真实的Hadoop作业日志，从JobHistory Server里导出来，自己分析一遍每个阶段的耗时和资源使用情况。这个练习比做十套复习卷都管用，因为考试考的是知识点，但工作考的是你从数据中定位问题的能力。

最后说一个我自己的体会：Hadoop这门课，考试分数高不代表你真的会用，但考试分数低通常说明你对基本原理的理解有漏洞。复习卷的价值不在于押题，而在于帮你把零散的知识点串成一条线。当你看到“数据倾斜”能立刻想到Partitioner、Combiner、reduce数量、内存缓冲区这一串关联，看到“NameNode内存不足”能立刻想到联邦、归档、小文件合并这一套方案，那这门课你就真正学明白了。