hadoop版本
Hadoop 1.x 到 2.x：JobTracker 扛不住了，所以有了 YARN
Hadoop 1.x 能跑，但跑不大。
当集群从几十台扩展到几百台、几千台的时候，JobTracker 扛不住了——它既要管资源分配，又要管任务调度，还要管容错，一个节点撑所有，成了单点瓶颈。
2.x 的核心改进就一件事：把 JobTracker 拆了。
拆成 ResourceManager（管资源）和 ApplicationMaster（管单个作业）。这个拆分，就是 YARN。
1.x 的架构：JobTracker 一身兼两职
Hadoop 1.x 有三个核心模块：
- Common：通用工具库
- HDFS：分布式存储
- MapReduce：计算 + 资源调度，全在 JobTracker 身上
JobTracker 扛了三件事：
- 资源管理：集群里谁有多少 CPU、多少内存，它管
- 任务调度：每个 Map/Reduce 任务怎么分、怎么跑，它管
- 容错处理：任务失败了怎么重试，它还管
这个设计在集群小的时候没问题，集群大了就出事了。
1.x 的三个硬伤
硬伤1：JobTracker 是单点瓶颈
所有任务调度、资源分配都要经过 JobTracker。集群到几百个节点时，JobTracker 的 CPU 和内存就被撑爆了，任务提交变慢、响应变慢，整个集群卡在 JobTracker 上。
硬伤2：JobTracker 挂了，整个集群瘫痪
1.x 的 JobTracker 没有备份机制。它一挂，所有正在跑的任务全失败，新的任务也提交不了。恢复只能重启，重启还要 replay 日志，期间集群不可用。
硬伤3：资源分配僵化，利用率低
1.x 把资源分成固定数量的 Map Slot 和 Reduce Slot：
- Map 任务只能用 Map Slot
- Reduce 任务只能用 Reduce Slot
如果 Map 任务跑完了，Map Slot 空着也不能给 Reduce 用；如果 Reduce 任务多，Reduce Slot 不够就只能排队。资源是固定的，不能灵活调配。
2.x 的解法：拆！
2.x 引入 YARN，把 JobTracker 的职责拆成两块：
Hadoop 1.x: JobTracker（资源 + 调度）
↓
Hadoop 2.x: ResourceManager（资源） + ApplicationMaster（调度）拆完之后各管各的：
| 组件 | 管什么 | 特点 |
|---|---|---|
| ResourceManager（RM） | 集群资源分配（CPU、内存） | 全局只有一个，但支持 HA 热备 |
| NodeManager（NM） | 单节点资源管理 | 每台机器一个 |
| ApplicationMaster（AM） | 单个作业的任务调度 | 每个作业一个，作业结束就销毁 |
一个 MapReduce 作业在 YARN 上的流程：
- Client 提交作业 → RM
- RM 在某个节点上启动 AM（MRAppMaster）
- AM 向 RM 申请资源 → RM 返回 Container 列表
- AM 在 Container 里启动 Map/Reduce 任务
- 任务完成 → AM 向 RM 注销 → 释放资源
RM 只管”给资源”，不管”怎么跑”。 怎么跑是 AM 的事。所以 Spark 有 Spark AM，Flink 有 Flink AM——每个框架自己管自己的调度逻辑。
2.x 解决了什么问题
| 1.x 的问题 | 2.x 怎么解决的 |
|---|---|
| JobTracker 单点瓶颈 | 拆成 RM（轻量）+ AM（分散），压力分散 |
| JobTracker 挂了全挂 | RM 支持 HA（Active/Standby），AM 挂了只影响单个作业 |
| Map/Reduce Slot 固定 | 改用 Container，资源按需分配，不分类型 |
| 只支持 MapReduce | YARN 支持任意框架（Spark、Flink、Tez） |
Container 替代 Slot 是资源利用率的质变：
- Slot：固定大小，不管用不用都占着
- Container：按需申请，用多少申请多少，用完释放
架构演进图
