搞懂 Hadoop 生态，绕不开 HDFS、YARN、MapReduce 这三句话。很多刚接触分布式系统的人，被 NameNode、DataNode、ResourceManager、Container、Shuffle 这些名词砸得晕头转向，面试时被问一句“MapReduce 的 Shuffle 到底经历了什么”就卡壳。这篇不是教科书复读，而是把三者的原理和工作流程拆开揉碎，从架构设计到读写链路，再到作业提交的完整生命周期，中间穿插可直接复制的命令、配置和排障经验。无论你是准备大数据面试、刚开始搭集群，还是已经在写 MapReduce 作业但总感觉哪里没吃透，这篇文章都适合当一份能随时翻出来的实操笔记。
1. 先搞清楚：HDFS、YARN、MapReduce 到底各管什么
1.1 一个比喻：仓库、调度台和流水线
把 Hadoop 集群想象成一家大型快递公司。你需要一个巨大的仓库来放包裹，这是 HDFS；需要一个调度台来分配车辆、人员和装卸工，这是 YARN；还需要一套快递分拣、运输、签收的流水线规则，这是 MapReduce。
HDFS 做的事很简单，就是把大文件切成固定大小的数据块（block），分散存到多台机器的磁盘上。默认一个 block 是 128MB，副本数默认 3，所以一份数据实际上有主副本和额外备份，放在不同节点上。这样单块磁盘坏了，数据不会丢；单台机器瓶颈了，可以从别的机器读取。
YARN 做的事更抽象，它不管数据内容，只关心集群里有多少可用的 CPU 和内存，然后把这些资源切成“容器”（Container），按需分配给作业。它就像调度台，不关心你运的是衣服还是电子产品，只问你几辆车、几个人、几点出发。
MapReduce 则定义了一套分布式计算模型：先把大任务拆成小任务并到集群各节点上并行执行（Map），再把结果规约成一个聚合答案（Reduce）。核心思想是“计算向数据移动”，把处理逻辑下发到数据所在节点，而不是把海量数据搬到一台机器上。
1.2 为什么拆成三块而不是一块
早期 Hadoop 版本里，存储是 HDFS，计算和资源管理却全部打包在一个叫 JobTracker 的进程里。JobTracker 既要负责调度作业，又要监控每个任务的运行状态，还要维护历史数据。集群一上百台节点，JobTracker 就变成瓶颈，而且单点故障直接影响整个集群。
后来把“资源调度”和“作业监控”两条职责拆开，就诞生了 YARN。ResourceManager 只做资源分配，每个作业分配一个独立的 ApplicationMaster 去管理自己的任务，彻底解除单点压力。拆开之后还有个好处：Spark、Flink、Tez 等计算框架只需要对接 YARN 的资源接口，就能跑在同一个集群上。存储、资源、计算三个层面各自独立演进，又通过一套约定协同工作，这是 Hadoop 能长期占据离线处理主流的底层原因。
2. HDFS 原理：存储层的读写闭环
2.1 架构：NameNode、DataNode 与副本机制
HDFS 是典型的 master/slave 架构。主节点叫 NameNode，负责维护整个文件系统的元数据，相当于仓库的账本，记录每个文件的路径、权限、block 列表、block 副本放在哪些机器上。真正存数据的是 DataNode，每台 DataNode 管理本机磁盘上的数据块，并周期性地向 NameNode 上报自己的状态和 block 列表。
还有一个容易被误解的角色叫 SecondaryNameNode。它不是主节点的实时热备，也不承担自动故障转移。它的主要工作是定期合并 NameNode 的编辑日志（EditLog）和镜像文件（FsImage），帮助 NameNode 减少重启时恢复元数据的时间。很多人以为开着 SecondaryNameNode 就高可用了，实际高可用要靠两台 NameNode 加 JournalNode 组成 Active/Standby 模式。
副本放置策略是 HDFS 可靠性的关键。默认 3 副本时，第一副本放在客户端所在节点（如果是集群外部提交则随机选一个负载低的节点），第二副本放在与第一副本不同机架的节点，第三副本放在与第二副本同机架但不同机器的节点。这样既能容忍单机故障，又能容忍整个机架断电，同时保证跨机架读数据时网络开销不至于过大。
2.2 写入一条链路：客户端、流水线与 ack
我一开始以为 HDFS 写入就是把文件“传”给 NameNode，实际完全不是。NameNode 只负责“开单”，不碰数据流。完整流程如下：
客户端先调用 DistributedFileSystem 的 create 方法，向 NameNode 发起“我要创建 /data/xxx 文件”的请求。NameNode 检查路径是否存在、父目录是否存在、客户端权限是否足够，全部通过后创建文件元数据记录，返回一个输出流。
接下来客户端把文件逻辑上切成 block，默认 128MB 一个。拿到一个 block 后，客户端向 NameNode 询问“该往哪些 DataNode 写副本”，NameNode 按机架感知策略返回一份 DataNode 列表，比如 node1、node2、node3。
真正写入时走的是流水线模式：客户端把数据按 64KB 的 packet 切包，每个 packet 又由多个 chunk 组成。第一个 packet 先发给 node1，node1 一边落盘一边把同一个 packet 转发给 node2，node2 转给 node3。每个 DataNode 写完一个 packet 后会向前一个节点返回 ack，最终回到客户端。客户端收到 ack 才继续发下一个 packet。
这个设计很像水管注水，发一个确认一个，保证数据不会丢在半路。如果写入过程中某个 DataNode 故障，客户端会从管线里剔除这个节点，用剩余节点继续完成副本写入，等后续副本数不足时再自动补副本。
所有 block 写完，客户端调用 close 关闭输出流，NameNode 这时才把文件标记为“已完成”，文件对用户可见。所以 HDFS 里“写完”是个最终一次性提交，而不是边写边可见。
2.3 读取一条链路：元数据定位与就近读取
读取比写入简单，但也讲策略。客户端先调用 open 方法拿到输入流，实际是向 NameNode 拿文件的元数据：这个文件有哪些 block，每个 block 在哪些 DataNode 上。
NameNode 返回 block 位置列表时，会按网络拓扑给 DataNode 排序，距离最近的排在最前面。客户端随即跳开 NameNode，直接和 DataNode 建立 TCP/套接字连接读取数据。
读取过程中客户端会做端到端的校验，用每个 chunk 自带的校验和验证数据有没有损坏。一旦发现一个副本有损坏，会立即切换到另一个副本读，同时报告 NameNode 记录损坏 block 并调度新副本。这就是“就近读取 + 自动容错”的基本面貌。
关于“短电路读”值得一提。大多数客户端进程不在 DataNode 上，需要通过 DataNode 的 socket 转发数据；如果客户端和 DataNode 在同一台机器，HDFS 可以开启短电路读，让客户端直接打开本地文件，绕过网络栈和 DataNode 转发，减少一次数据拷贝，延迟和吞吐都能改善。生产集群大量使用计算存储混布时，这个优化非常有效。
2.4 常用命令、fsck 与现实排障
命令行是排障的第一工具。下面这组命令我几乎每天都用：
hdfs dfs -mkdir -p /user/app/logs hdfs dfs -put local.log /user/app/logs/ hdfs dfs -cat /user/app/logs/local.log | head -n 50 hdfs dfs -du -h /user/app/logs hdfs dfsadmin -report hdfs fsck /user/app/logs -files -blocks -locationsfsck 这个名字延续了 Unix 文件系统检查工具的叫法。跑完会输出每个文件的 block 状态，比如“Total blocks”和“Missing replicas”。这里有个经验：fsck 只负责发现和报告问题，它不会修复坏块。发现缺失副本后要人工介入，或者等 DataNode 重新上线后由 NameNode 自动补副本。
如果 fsck 报“Access denied”或权限不足，先确认你是不是操作了别的用户的目录，HDFS 的权限模型默认类似 POSIX，但默认配置甚至不开启强鉴权，生产环境需要配合 Kerberos 或 Ranger 等方案。还有一个高频场景：误删文件。HDFS 默认有一个回收站机制，只要配置了 fs.trash.interval，用普通 delete 删除的文件会先进到 /user/xxx/.Trash 目录，在保留时间内能捞回来。这个配置在生产务必打开，我见过太多手滑 rm 的事故。
3. YARN 原理：从资源调度到作业调度
3.1 MRv1 到 YARN：调度与监控的拆分
旧版 MapReduce 的资源管理把 JobTracker 当全能管家，但它做的事太多，既要管“哪个作业先跑”，又要管“每个 map/reduce 任务跑在哪、失败没”，集群稍大就成单点瓶颈。YARN 的诞生思路很质朴：把“分配资源”和“管理作业”分开。
ResourceManager 只管资源分配和整个集群的全局状态，不关心具体某个 map 任务的死活。具体作业的“项目管理工作”由 ApplicationMaster 承担，每个作业单独起一个。这样 ResourceManager 负载大幅下降，而且坏了某台节点上的任务，不会拖垮整个集群调度。
另一个重要变化是资源模型。MRv1 只按“槽位”（slot）分配，map slot 和 reduce slot 不能互相借用，资源利用不充分。YARN 用 Container 抽象资源，每个 Container 指定 CPU 核数和内存大小，map 任务和 reduce 任务都跑在 Container 里，按需申请，用完即收，细致很多。
3.2 四大角色的职责边界
YARN 的核心角色可以概括为“一主一从、一作业一容器”。
ResourceManager（RM）是全局主节点，它维护整个集群的资源总账，接收新作业的提交请求，启动并监管每个作业的 ApplicationMaster。它不做具体任务监控，这是故意的，目的是把压力降下来。
NodeManager（NM）是每台机器上的从节点，负责启动和管理本机上的 Container，周期性向 RM 汇报本节点的资源剩余情况，并处理来自 AM 的容器启动请求。
ApplicationMaster（AM）是每个作业的专属管理进程。作业提交之后，RM 会在某个空闲节点上启动它。AM 负责向 RM 申请资源，获得资源后通知对应节点的 NodeManager 启动容器，接着跟踪任务进度，处理任务失败重试。作业结束时 AM 注销并释放自己的容器。
Container 表面上是资源描述，包含内存、CPU 核数等，实际执行时是 NodeManager 启动的一个 Java 进程或者一组进程。说白了一个 Container 约等于一台“微型虚拟机”，只不过隔离性弱于真正虚拟机。
3.3 作业提交到 YARN 的完整流程
以hadoop jar xxx.jar 主类 输入输出为例，流程是这样的：
客户端提交作业给 RM，RM 返回一个 application ID。RM 在某个 NodeManager 上启动一个 Container，里面运行 ApplicationMaster。AM 启动后先向 RM 注册自己，然后向 RM 提交资源申请，申请内容通常是“我需要 X 个 map 容器、Y 个 reduce 容器，每个容器多少内存多少 CPU”。
RM 收到申请后，结合当前节点的资源余量和队列配额，把符合条件的 Container 分配给 AM。AM 拿着 Container 列表去和对应 NodeManager 通信，让 NM 启动容器并拉起任务进程。
每个任务进程启动后会反向向 AM 汇报状态，AM 把进度汇总展示。如果某个任务失败，AM 会重新申请容器重试。全部任务完成后，AM 向 RM 注销并释放资源，RM 更新全局资源表，作业结束。这套流程下，RM 完全不需要知道任务具体干了什么，分工十分干净。
这里有个考点：YARN 的“作业”概念不是 Hadoop MR 独有的。Spark on YARN、Flink on YARN 都遵守“RM 起 AM，AM 分配资源”的模式，只是 AM 的角色和心跳协议细节不同。
3.4 三种调度器的选型思路
YARN 提供了三种调度器，个个用途不同。
FIFO 调度器最简单，作业按提交顺序一个一个来，像排队打饭。优点是可控、无抢占，缺点是队首作业只要是大任务，后面作业全部饿死。单用户内部测试时用没问题，多团队共享集群就很不合适。
Capacity Scheduler 是 Hadoop 默认调度器。它按队列划分资源比例，比如 A 团队分 60%，B 团队分 40%。每个队列内部又可以用 FIFO 或公平策略。好处是多团队互不干扰，即使 B 队列的作业很重，也只能使用配额内的资源，不会把 A 队列挤垮。
Fair Scheduler 追求“所有运行作业平均分资源”。新作业一提交，运行中的作业会让出资源腾位置，默认最多等一段时间才强制抢占。它适合交互式查询和批处理混合的场景，但频繁抢占可能导致任务反复失败。
选型不要盲目。日常离线跑批、集群按部门共享，优先用 Capacity；临时试验集群或小团队用 FIFO 足够；如果集群要跑大量短任务并兼顾长任务，再考虑 Fair。
4. MapReduce 原理：分治、Shuffle 与排序
4.1 Map 与 Reduce 的编程模型
MapReduce 把分布式计算抽象成两个阶段。Map 阶段输入是键值对，输出也是键值对，但它不负责汇总，只负责“切碎”和“初步归类”。Reduce 阶段接收同一个 key 下的所有 value 列表，做最终聚合。
这很像流水线作业：仓库收到一批快递（输入分片），分拣员按收件城市分拣（map），把同一城市的快递堆在一起（partition 和 shuffle），再由装车员统计并打包（reduce）。
输入切分由 InputFormat 负责。一个输入分片（split）通常对应一个 block，但不是绝对的一对一。split 过大时 map 数量少并行度低，过小时 map 数量暴增、元数据开销大，所以 FileInputFormat 的切片大小默认等于 block 大小，也就是 128MB。
Map 阶段输出的 KV 不会立即写 HDFS，而是先写到本地磁盘，因为中间结果只有计算过程中的临时状态，不值得三副本存储和网络传输。这是 MapReduce 性能调优的重要概念，很多人想不通为什么 shuffle 数据算 IO 开销，原因就在这里。
4.2 Shuffle 全流程：环形缓冲区、分区、排序、归并
Shuffle 是 MapReduce 的灵魂，也是面试最常追问的部分。Map 端输出的每个 KV 会先进入一个内存环形缓冲区，默认大小是mapreduce.task.io.sort.mb，通常是 100MB。写入比例达到mapreduce.map.sort.spill.percent（默认 0.8）后，一个后台线程会开始把缓冲区数据溢写到本地磁盘。
溢写前不是直接写，而是先做两件事：分区和排序。数据按 key 的哈希值分区，保证相同 key 进同一个 reduce；分区内部按 key 排序。溢写过程中如果配置了 Combiner（也叫本地规约器），会对同一分区的数据先做一次小聚合，减少最终传输量。
一个 map 任务可能溢写多个文件，map 结束时会做一个归并（merge），把多个溢写文件合并成一个输出文件，同时再次做分区和排序。Reduce 端要拉数据时，通过网络按分区位置拉取属于自己那份的中间结果。
Reduce 端收到数据后先放内存，内存不够就溢写本地，最后把所有文件归并排序成一个大文件。归并完成后才进入 reduce 函数，调用一次 reduce 方法处理一个 key 及其 value 迭代器。
刚才提到的排序默认是全排序。map 端按 key 排序，reduce 端对多个 map 输出做归并排序，所以最终每个 reduce 输出的内部数据都是有序的。基于这一点，你才能实现“分组排序”“倒排索引”“Top N”这类复杂逻辑。
4.3 一个能直接复制的 WordCount 实例
绕开所有花哨案例，先从词频统计这个“Hello World”切入。先写 Mapper 类：
public class WordCountMapper extends Mapper<LongWritable, Text, Text, IntWritable> { private final static IntWritable one = new IntWritable(1); private Text word = new Text(); @Override protected void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException { String line = value.toString(); StringTokenizer itr = new StringTokenizer(line); while (itr.hasMoreTokens()) { word.set(itr.nextToken()); context.write(word, one); } } }再写 Reducer：
public class WordCountReducer extends Reducer<Text, IntWritable, Text, IntWritable> { private IntWritable result = new IntWritable(); @Override protected void reduce(Text key, Iterable<IntWritable> values, Context context) throws IOException, InterruptedException { int sum = 0; for (IntWritable val : values) { sum += val.get(); } result.set(sum); context.write(key, result); } }Driver 里设置作业参数并提交：
Job job = Job.getInstance(new Configuration(), "word count"); job.setJarByClass(WordCountDriver.class); job.setMapperClass(WordCountMapper.class); job.setReducerClass(WordCountReducer.class); job.setOutputKeyClass(Text.class); job.setOutputValueClass(IntWritable.class); FileInputFormat.addInputPath(job, new Path(args[0])); FileOutputFormat.setOutputPath(job, new Path(args[1])); System.exit(job.waitForCompletion(true) ? 0 : 1);运行命令：
hadoop jar wordcount.jar WordCountDriver /input /output输出目录不能提前存在，MapReduce 非常忌讳覆盖输出，这是安全机制。Input 路径写的是 HDFS 路径而非本地路径，我见过太多人在本地测试时直接写相对路径导致 “Input path does not exist”。
4.4 自定义排序、倒排索引与分组排序的套路
面试和工作里经常要求排序不是默认的字典序，而是按第二列排、按数值降序排。最简单的做法是自定义 WritableComparable 作为 key。比如日志文件里每行是“时间 用户ID PV”，想按 PV 降序排，就写一个类实现 WritableComparable，比较逻辑里先比 PV，PV 相同再比用户 ID。
倒排索引是搜索引擎基础数据结构。在 MapReduce 中，map 阶段输出 key 是单词，value 是“文档ID:次数”，比如hadoop -> doc1:2, doc2:3。reduce 阶段把这些文档信息合并，最终得到每个单词出现在哪些文档里。核心点在于分割文本时要把当前文件名作为 value 的一部分放进 context，这正好用上 FileSplit 拿文件名。
分组排序（Secondary Sort）用得更隐蔽。比如一份数据有“订单日期 商品类目 销售额”，需求是每个日期下按销售额降序排。这时可以设计复合 key“日期 + 销售额”，设置分区器只按日期分区，设置分组比较器只按日期分组，排序比较器却同时按日期和销售额排序。MapReduce 默认会用同一个比较器做分区后排序和分组，如果你不额外设置分组比较器，分组就会严格等于分区子集内 key 的全字段，导致每个销售额都是一个组，期望的“组内排序”就泡汤了。这个细节点大多数新手都会踩坑。
5. 三驾马车协同：一次作业的完整生命周期
5.1 提交前的准备：数据先进 HDFS
无论用哪种计算引擎，输入数据必须先落到 HDFS 或能通过 HDFS 访问的位置。客户端先用hdfs dfs -put把文件上传到指定目录，随后提交 jar 包。上传过程本身已经触发一次 HDFS 写流程：文件按 block 切分、多副本流水线写入。你跑计算作业拿到的数据，实际上引用的是分布在多台 DataNode 上的 block 集合。
同时，客户端会在本地生成作业的配置、依赖 jar、以及输入分片元数据（job split 文件），提交给 ResourceManager 时把这些信息一并交给集群。split 文件里描述了每个切分对应的文件偏移量和所在 block 的 host 列表，这是 MapReduce 后续实现“数据本地性”的依据。
5.2 RM 启动 AM：资源申请、分配与容器拉起
RM 收到提交请求后先做初始化：生成 application ID，把作业信息写入状态存储，然后挑选一个负载适当的 NodeManager，拉起 Container 并启动 ApplicationMaster 进程。AM 启动后会读取 split 信息，算出需要多少个 map 任务、多少个 reduce 任务。
Map 任务的数量由 split 决定：一个 split 对应一个 map 任务，整个作业有多少 split，map 阶段就启动多少并行任务。Reduce 任务数量一般由用户显式设置，默认是 1。这里有个实际经验：如果 reduce 数量不设，WordCount 会跑大量 map 但只有一个 reduce，输出就只有 1 个 part 文件，数据量一大会非常慢。多数生产作业会按数据规模估算 reduce 数量，通常控制在 map 的 20% 到 30% 之间。
AM 持续向 RM 申请容器。RM 分配后，AM 联系对应 NodeManager 启动任务。真正的优化点在 map 任务调度：AM 查询 split 信息里每个 split 的 host 列表，优先把 map 任务调度到存有对应 block 的 DataNode 所在节点，这样 map 读数据时直接走本机磁盘而不经过网络，能省掉最耗时的一环。这就是“计算向数据移动”的落地形态。
5.3 Map 端到 Reduce 端：中间数据接力
Map 任务启动后，从所在节点本地或就近 DataNode 读取 split 数据，逐行调用 map 方法，输出 KV 进入环形缓冲区，触发溢写、分区、排序，最终在本地产生中间文件。Reduce 任务会持续轮询 AM 拿到的 map 任务状态，发现某个 map 完成后，就通过 HTTP 协议主动去拉取属于自己分区的数据。
这里要看网络 IO。Reduce 拉取数据时可能同时从几十甚至上百个节点抓取，所以集群内网带宽往往比磁盘更容易先成为瓶颈。为减少传输量，可以在 map 端配置 Combiner 进行本地预聚合。Combiner 的逻辑必须满足交换律和结合律，才能放心使用，比如求和没问题，求平均值就不行。
Reduce 端拉完数据后，还要做一次归并排序。所有数据按 key 排好后，reduce 方法开始逐组处理，最终把结果写回 HDFS。注意 reduce 输出默认也切分到多个 part 文件，每个 reduce 写一个单独的 part-r-xxxxx 文件，输出文件数量等于 reduce 数量。
5.4 结果回写与资源回收
所有 reduce 任务完成后，AM 会向 RM 汇报作业完成，同时输出总结信息，包括处理记录数和耗时。用户可以在 YARN 的 Web UI 看到最终状态。随后 AM 所在 Container 被释放，RM 把这次作业占用的资源全部还给集群，NodeManager 也清理临时目录。
这里有个小细节：reduce 输出写 HDFS 时仍要走一次完整的写入流程，即 NameNode 元数据注册、DataNode 流水线写入、ack 确认。因此写 HDFS 的性能和副本策略会影响作业尾延迟。生产上如果只是临时结果，可以把副本数临时调低，或者直接写到本地文件系统再手工合并，能省不少时间。
6. 实操踩坑与调优心得
6.1 新手最容易踩的五个坑
第一个是“Output directory already exists”。这是最经典的低级错误。MapReduce 不允许输出目录存在，目的就是防止误覆盖之前任务的结果。解决办法不是强行删除保护机制，而是每次运行换个新输出路径，或确认结果无需保留时先hdfs dfs -rm -r清掉旧目录。
第二个是“Input path does not exist”。很多人把hdfs dfs -put传完文件后，直接拿本地相对路径当成输入路径跑 jar，当然找不到。运行作业前先hdfs dfs -ls /your/path确认输入目录存在且能看到文件。
第三个是“Container exited with a non-zero exit code 143”。这个常见于内存紧张时节点强制杀掉 Container。别只盯着应用日志，先看 NodeManager 日志，确认是不是物理内存或虚拟内存超限。YARN 默认按虚拟内存算，限制往往要调到物理内存的 2.1 倍，很多集群都是在这里翻车。
第四个是“Incompatible clusterIDs”。当你从文件系统层面复制了 NameNode 的数据目录到新机器，新 NameNode 会认为 data 目录不属于自己，导致 DataNode 拒连。遇到这种问题，确认新环境数据目录确实没历史价值后，清掉 VERSION 文件里的 clusterID 并重启集群，让节点重新生成兼容标记。
第五个是小文件泛滥。每个 block 的元数据大约占用 NameNode 几百字节内存，1000 万个 block 就会吃掉好几个 GB 内存。而且小文件多意味着 split 多，map 任务数量暴增，空转开销全在启动和心跳上。解决方向是合并输入，或者用 Hadoop Archive 把小文件打包，上游产数据时也尽量避免产生大量极小的输出文件。
6.2 常用调优参数与检查命令
调优前先看现状，没有数据支撑的调优都是玄学。常用检查命令是：
hdfs dfsadmin -report yarn node -list -all yarn application -status <application_id> yarn logs -applicationId <application_id>dfsadmin -report能一眼看出版本是否有节点掉了、每节点存储空间余量、总副本数是否异常。yarn application -status能看到当前作业用的队列、AM 地址和运行状态，排障第一步就靠它。
内存相关的核心参数有几组：yarn.nodemanager.resource.memory-mb决定单节点可分配总内存，yarn.scheduler.maximum-allocation-mb决定单个 Container 上限，mapreduce.map.memory.mb和mapreduce.map.java.opts决定 map 进程内存和 JVM 堆。经验是java.opts里的堆内存要略小于memory.mb，因为 JVM 运行本身还需要 Metaspace 和线程栈，堆设满会被 YARN 判定超用内存。
block 大小dfs.blocksize需要权衡。block 太大 map 任务数少，但单任务计算量大，失败后重算成本高；block 太小元数据膨胀和任务启动开销又压不住。顺序读的大日志场景用 256MB 起步，随机读或多租户共享场景 128MB 通常更均衡。
6.3 关于练习环境与学习路径的实在建议
没有真实集群也能学会。单机伪分布模式下载 Hadoop 后，把 HDFS 和 YARN 都开在同一台机器上，足以跑通所有读写流程和 WordCount 这类作业。想更接近生产，用 Docker 搭一个 3 节点的 Hadoop 集群，一个 master 带两个 worker，模拟节点挂掉、副本丢失、YARN 容器重试都完全够用。
练习顺序建议先跑通 HDFS 命令和 fsck，再手动提交一个 MapReduce 作业，然后去看 YARN 的 Web UI，观察 application 从提交到完成各阶段的任务变化。最后尝试修改几个参数，比如调低yarn.nodemanager.resource.memory-mb触发 Container 被 kill，再通过日志定位，这一套走完才谈得上对“原理”有了肌肉记忆。
很多在线实验平台也提供了 Hadoop 相关开箱环境，比如“Hadoop 开发环境搭建及 HDFS 初体验”“MapReduce 基础编程”这类实训关卡，适合用来快速验证某个 API 或命令的行为。关键是做完一个案例后，把代码删了重新从空白写一遍，而不是复制粘贴了事。能用思维导图把“文件上传到 HDFS 的完整链路”“作业提交到 YARN 的完整链路”默写出来，你才算真正掌握。
我个人在实际操作中最大的体会是：调优不要一上来就改一堆参数，先理解一次读写和一次作业要经过哪些节点、哪些网络跳数，再针对最慢的环节下手。很多时候你以为是内存不够，加了内存反而因为 GC 停顿更多而变慢；你以为 reduce 并行度不够，结果瓶颈在 map 端溢写太多。你要做的不是背参数，而是沿着本文的几条链路，一步一步看数据在哪停留、在哪等待、在哪失败。把 HDFS 的读写闭环、YARN 的容器分配、MapReduce 的 Shuffle 排序完全装进脑子里，往后看 Spark、Flink 这些更年轻的框架时，你会发现它们很多设计都在解决同一个问题：让数据在分布式环境下流动得更稳、更快、更省。
