守株阁

上一篇讲了 Shuffle。本篇讲 MapReduce 在 YARN 上的具体实现——MRv2。这是 MapReduce 计算模型篇的最后一篇。 MRv2 常被介绍成"MapReduce 在 YARN 上的版本"。这个描述对应了部署形态但漏了内部架构。准确的说法是：MRv2 把 Hadoop 1.x 的 JobTracker 拆成 ResourceManager（资源管理）和 MRAppMaster（作业编排）两部分，MRAppMaster 是一个普通的 YARN ApplicationMaster，运行在 container 里。每个 Task 也是一个 container（YarnChild），通过 umbilical RPC 与 MRAppMaster 通信。MRv2 的 Speculative Execution、Counter、Task Recovery 等机制都是 MRAppMaster 实现的，与 YARN 基础设施解耦。 本篇只抓一个问题：MRAppMaster 内部是怎么编排 Map / Reduce Task 的、Task Attempt ...

上一篇讲了 MapReduce 编程模型。本篇展开 MapReduce 性能代价最重的环节——Shuffle。 Shuffle 常被介绍成"Map 到 Reduce 之间的数据传输"。这个描述对应了功能但完全没解释 Shuffle 为什么慢。准确的说法是：Shuffle 由 Map 端的 Spill-Sort-Merge、Reduce 端的 Fetch-Merge 和网络 HTTP 传输共同组成，涉及磁盘、网络、内存缓冲和排序算法。在许多 Reduce-heavy 作业里，Shuffle 会成为最主要的延迟来源；调优 Shuffle 往往就是调优 MapReduce 的核心部分。 本篇只抓一个问题：Map 端 Shuffle 怎么从内存缓冲流到本地磁盘分区文件、Reduce 端怎么从所有 Map 拉取并合并、CombineFileInputFormat 在什么场景下能减少 Map 数。 Map 端 Shuffle 的五个步骤 Map Task 输出的 key-value 对不是直接发给 Reduce，而是经过一个六步骤的本地流水线： 1234561. map(...

第一、第二阶段把 HDFS 和 YARN 讲完了。从这一篇起进入 MapReduce——Hadoop 三大子系统的最后一个，也是历史最久的一个。 MapReduce 常被介绍成"Hadoop 的计算引擎"。这个描述对应了功能但漏了 MapReduce 的本质。准确的说法是：MapReduce 是把"分而治之"这个通用算法思路工程化为可运行框架的产物——把大输入切成 InputSplit 给 Map 并行处理，用 Partitioner 把 Map 输出按 key 分发到 Reduce，Reduce 聚合后写 HDFS。三阶段切分（Map / Shuffle / Reduce）和三个用户钩子（Mapper / Combiner / Reducer）是 MapReduce 全部抽象的核心。 本篇只抓一个问题：MapReduce 为什么把计算切成 Map → Shuffle → Reduce 三阶段、Combiner 在什么场景下能省 Shuffle 流量、Partitioner 与 Reduce 个数的关系。 三个阶段的本质 一次 MapRed...

上一篇讲了 YARN HA 和 Federation。本篇讲 YARN Timeline Service v2——YARN 提供的通用应用历史与指标系统，是第二阶段的最后一篇。 Timeline Service 常被介绍成"YARN 的作业历史记录"。这个描述对应了功能但漏了 v2 与 v1 的架构差异。准确的说法是：Timeline Service v2 是 Hadoop 3.0 引入的下一代架构。与 v1 的"集中式 Timeline Server"不同，v2 把写入侧改造成 AM 侧应用级 collector 加 NodeManager 内嵌 collector；读侧改造成独立 TimelineReader + 可扩展 HBase 后端，让 Timeline 系统可以支撑更大的集群。 本篇只抓一个问题：Timeline Service v2 解决了 v1 的什么瓶颈、Per-App Collector 和 TimelineReader 各自怎么工作、为什么 v2 的后端必须用 HBase 而不是直接用 HDFS。 v1 的设计缺陷 T...

上一篇讲了应用程序生命周期。本篇讲 ResourceManager 怎么解决单点问题和集群规模上限问题——YARN HA 和 YARN Federation。 YARN HA 常被介绍成"两个 ResourceManager 互为热备"。这个描述对应了部署形态但漏了几个关键点：RM State Store 怎么持久化作业元数据、Standby RM 怎么与 Active 同步、Active 切换时 NM 和 AM 怎么重连。YARN Federation 常被简化成"多个 YARN 集群"，但漏了 Router、AMRMProxy、SubCluster 这些核心抽象。准确的说法是：YARN HA 通过 ZooKeeper 选主 + RM State Store 共享状态实现 Active/Standby 切换；YARN Federation 通过无状态 Router + AMRMProxy 让多个独立子集群对客户端表现为单一集群，每个子集群内部仍然有自己的 HA。 本篇只抓一个问题：YARN RM HA 的切换流程是怎么工作的、RM Sta...

调度器决定资源分配顺序，应用生命周期决定一个作业怎样用这些资源从提交走到完成。 上一篇讲 FIFO、Capacity、Fair 的取舍，本篇只看一个问题：提交、调度、运行、完成如何映射到 YARN 的公共状态和内部事件。下一篇会继续讲 ResourceManager HA 与 Federation，本篇不会展开 HA、Timeline Service 或 MapReduce 深层机制。 生命周期常被写成“提交 → 运行 → 结束”。这个说法太粗。YARN 里要分成三层状态机看：RM 维护 application，RM 维护 application attempt，NM 维护 container。对外暴露的公共状态很少，对内用于启动、收尾、清理和重试的阶段更细。排障时把三层混在一起，最容易把 AM 重试、container 失败和 application 最终状态误判成同一个问题。 链路固定为 Client → RM → NM → AM → Container。Client 提交应用，RM 持久化 application 并调度 AM，NM 启动 AM container，AM 注...

上一篇讲了资源模型。本篇讲 ResourceManager 怎么把资源分给作业——也就是调度器的选择。 YARN 调度器常被介绍成"Hadoop 集群的资源分配策略"。这个描述对应了功能但没解释设计差异。准确的说法是：YARN 提供三种调度器——FIFO（单队列先进先出）、Capacity（层级队列，每队列有容量保证）、Fair（按权重公平分享），三种调度器在公平性、隔离性、吞吐、抢占代价上各有取舍。生产集群几乎都用 Capacity 或 Fair，FIFO 只在小集群或测试场景出现。 本篇只抓一个问题：三种调度器各自的设计取舍、什么场景应该选哪种、抢占机制是怎么工作的。 FIFO Scheduler：最简单的策略 FIFO 是 YARN 提供的最简单调度器。它不是 Hadoop 3.x 的默认选择；默认调度器是 Capacity Scheduler。FIFO 把所有作业排成一个队列，按提交顺序依次获得资源： 12345678910111213141516队列：[App-A (running), App-B (waiting), App-C (waiting)...

上一篇讲了 YARN 三方契约的整体架构。本篇展开资源模型——Container、Resource、NodeLabel 这些抽象的具体含义。 YARN 的资源模型常被简化成"申请多少内存和 CPU"。这个简化漏了几个关键设计决策：最小分配粒度（避免碎片）、最大分配上限（防止单作业垄断）、多维资源（不只是 CPU/Memory，Hadoop 3.x 起可扩展 GPU/FPGA）、NodeLabel（拓扑约束）、资源超售（Opportunistic Container）。这些机制决定了 YARN 集群的资源利用率和公平性。 本篇只抓一个问题：YARN 怎么把"集群物理资源"切成可调度的 Container 单位，最小分配和最大分配为什么是这样设计的，NodeLabel 怎么让 GPU/HBM/高速网络等异构资源被正确分配，Opportunistic Container 在什么场景下值得打开。 Resource 的两个核心维度 YARN 早期版本（2.x）的 Resource 只有两个维度： 1234class Resource { ...

第一阶段把 HDFS 切完了。从这一篇起进入 YARN，先讲架构。 YARN 常被介绍成"Hadoop 的资源管理器"。这个描述对应了职责但漏了关键点。准确的说法是：YARN 是一个把"全局调度"和"作业内调度"拆开的双层调度系统，引入了 ApplicationMaster 这个新角色承担作业级编排，把 Hadoop 1.x 的 JobTracker 单体拆成 ResourceManager + ApplicationMaster + NodeManager 三个独立契约。Container 抽象是这个拆分的基础——它把"一段资源 + 一段进程"打包成统一的调度单位，让同一套基础设施能同时承载 MapReduce、Spark、Flink、Tez、Storm 等不同计算模型。 本篇只抓一个问题：YARN 的三方契约（ResourceManager、NodeManager、ApplicationMaster）是怎么切开的，Container 抽象的本质是什么，为什么 Hadoop 2.x 必须从 JobT...

上一篇讲了 HA 怎么解决 NameNode 单点问题。本篇讲 HDFS 在 Hadoop 3.x 时代的三个核心演进：纠删码（Erasure Coding）、路由联邦（Router-Based Federation）、Observer NameNode。这三个特性分别解决三个不同的瓶颈：存储成本、NameNode 元数据上限、读吞吐上限。 HDFS 3.x 常被描述成"HDFS 的现代化版本"。这个描述对应了发布节奏但没解释演进逻辑。准确的说法是：HDFS 在 2.x 解决了 HA 和 YARN 之后，3.x 时代面对的核心问题是 PB 级集群的存储成本和元数据瓶颈，所以引入纠删码降存储、引入路由联邦解决元数据上限、引入 Observer NameNode 拆分读写流量。三个特性的设计动机都是"假设集群规模已经超过单 NameNode 上限"。 本篇只抓一个问题：HDFS 3.x 引入的三个主要特性各自解决什么瓶颈、用什么代价、适合什么场景。 纠删码：用 CPU 换存储 HDFS 默认三副本意味着每存 1TB 用户数据要占 3TB 物理存...