5.1 经典架构 v1

5.1 经典架构 v1

本节摘要：经典 MapReduce v1 由一个 JobTracker 与一组 TaskTracker 构成主从结构：JobTracker 一肩挑资源管理与作业管理，TaskTracker 按心跳汇报并领取任务在固定槽位中执行。这套架构简单可靠，但单点内存上限、心跳风暴与槽位粗粒度三重瓶颈，决定了它撑不过数千节点规模，也直接催生了 YARN。

进程拓扑：一个大脑加一群手脚

v1 集群只有两种守护进程：

• JobTracker：部署在一台 master 节点。大脑，管两件事——把作业拆成任务并安排给谁跑（作业管理），以及记录整个集群有多少空闲算力（资源管理）；
• TaskTracker：每台 slave 节点一个。手脚，定期心跳汇报"我活着、我有几个空槽位"，领到任务后在槽位里 fork 一个子 JVM 执行，并在后续心跳里带回任务进度。

槽位是 v1 的资源计量单位，且一开始就分 Map 槽与 Reduce 槽：一台机器配 4 个 Map 槽加 2 个 Reduce 槽，是典型配置。任务只能进对应类型的槽——Map 任务不能住进空着的 Reduce 槽，反之亦然。

图 5.1-1 v1 进程拓扑与一次任务下发

一次作业提交的旅程

驱动代码调用提交接口后：

1. 作业的配置、jar、分片信息打包提交到 JobTracker；
2. JobTracker 生成分片列表（第 2 章的全部内容在此发生），把每个分片变成一个待调度的 Map 任务，加上预设数量的 Reduce 任务，构建任务图（Reduce 依赖 Map 输出，但如第 4 章所述，拷贝可提前重叠）；
3. 各 TaskTracker 心跳到达时，JobTracker 按调度策略从队列里挑任务塞进心跳响应——优先满足数据本地性（第 2.2 节的延迟调度就在这一步做取舍）；
4. TaskTracker fork 子 JVM 跑任务，通过心跳回传进度、计数器；
5. 全部任务成功，JobTracker 把作业标记完成，客户端拿到通知。

注意决策的完全集中：每个任务的每次状态变化都要过 JobTracker 的内存与线程。这是它一切瓶颈的总根源。

三重瓶颈

瓶颈一：单点扩展上限。 数千节点、每节点秒级心跳、每作业成千上万任务——JobTracker 的内存与处理能力线性吃紧。实践中四千节点左右就逼近极限，再大集群只能拆多个小集群，运维成本翻倍。

瓶颈二：心跳风暴与调度延迟。 集群越大心跳越密，JobTracker 的响应稍有迟滞，TaskTracker 会因心跳超时被误判死亡，触发任务重派，重派又加剧负载，形成恶性循环。故障恢复同样昂贵：JobTracker 重启后要等所有节点重新注册、所有任务重新汇报，期间全集群停摆。

瓶颈三：槽位模型的资源浪费。 Map 槽与 Reduce 槽静态划分，而作业的 Map 段与 Reduce 段是错峰的：Map 段满载时 Reduce 槽大量闲置，反之亦然。槽位也不区分任务实际需要多少内存与 CPU——一个轻任务与一个重任务各占一槽，粗粒度计量天然失衡。集群整体利用率低，是 v1 时代普遍的痛点。

还有一条架构性的死穴：JobTracker 只认识 MapReduce。想再跑一个流式或迭代计算框架，就得另起一套自己的资源管理系统，各框架把集群切成相互隔绝的资源孤岛。数据本来在一处，计算引擎却要分家。

v1 值得继承的设计

批评之余，v1 留下三条被后辈全盘继承的遗产，读架构史时值得指认：

1. 心跳驱动的状态汇报：节点用周期心跳证明存活并携带状态，这套健康检查范式延续到 YARN 的 NodeManager；
2. 移动计算而非数据：调度时优先本地性，延迟调度换命中率的思路原样平移；
3. 拉取式 Shuffle：Reduce 主动到 Map 端取数据（而非 Map 推送），解耦了两端节奏，如今仍是各家引擎 Shuffle 的基本形态。

本节要点回顾

• 主从两角色：JobTracker 集中负责资源与作业双重管理，TaskTracker 心跳领活、槽位执行。
• 提交旅程：分片成任务、心跳带任务下行、进度上行、全成即完。
• 三重瓶颈：单点内存上限、心跳风暴与恢复停摆、Map 与 Reduce 槽错峰闲置。
• 框架死穴：资源系统与 MapReduce 绑定，多框架只能裂集群。
• 三条遗产：心跳健康检查、本地性优先调度、拉取式 Shuffle，全部延续到 YARN 时代。

下一节看 YARN 如何把 JobTracker 拆成三角色，把集群变成所有计算框架共用的操作系统。