守株阁

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

上一篇讲了应用程序生命周期。本篇讲 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...

上一篇讲了调度器。本篇讲一个 YARN 应用程序从提交到完成经历的全部状态变化。 YARN 应用程序的生命周期常被简化成"提交 → 运行 → 完成"。这个简化漏了三个独立状态机的协调——RM 维护 Application 状态机、RM 维护 ApplicationAttempt 状态机、NM 维护 Container 状态机。三个状态机通过 RPC 同步，共同决定一个作业从 SUBMITTED 到 FINISHED 的每一步。理解这套生命周期对调试作业卡住、诊断 AM 启动失败、设计自定义 AM 都很关键。 本篇只抓一个问题：Client → RM → NM → AM → Container 之间的完整 RPC 序列和状态机切换，AM 启动失败时 RM 怎么重试，Container 完成后 NM 怎么回收。 三层状态机的分工 YARN 应用程序生命周期由三个独立状态机协调： 1234567891011121314RMApp（作业级状态机） - 由 RM 维护 - 跟踪整个作业的状态（NEW / SUBMITTED / ACCEPTED / RUNNING ...

上一篇讲了资源模型。本篇讲 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 物理存...

一项评测得到的分数，并不只属于模型。它还属于提示词、工具、执行环境、上下文管理、token 预算、重试策略和评分器。 这不是 agent 出现以后才成立的道理。MMLU、HumanEval 这类单轮评测同样依赖 prompt 模板、采样参数和答案抽取逻辑。变化在于：任务越长、工具调用越多，harness 对结果的影响越难当成可忽略的实现细节。到了 coding agent、computer use 和长程研究任务，报告一个模型名和一个 benchmark 分数，往往不足以说明被测系统是什么。 OpenAI 的 A shared playbook for trustworthy third-party evaluations 讨论的是第三方评测如何提出可解释的能力声明；Anthropic 的 Demystifying evals for AI agents 则从研发流程出发，拆解 task、trial、grader、transcript、outcome 和两个不同的 harness。两份材料并不构成一套联合标准，但它们指向同一个工程事实：评测结果应当绑定一个版本化的 tested ...

上一篇讲了 NameNode 单点的元数据持久化机制——FSImage + EditLog。本篇展开 HDFS HA 怎么解决 NameNode 单点问题。 HDFS HA 常被介绍成"两个 NameNode 互为热备"。这个描述对应了部署形态但掩盖了关键机制。准确的说法是：HDFS HA 把原来由 Active NameNode 独占写的 EditLog 拆出来放到 3 个 JournalNode 组成的多数派集群上，Active NameNode 每次写 EditLog 都要等多数派 JournalNode 确认。Standby NameNode 实时 tail 这个共享 EditLog，与 Active 保持内存同步。Active NameNode 宕机时，Standby NameNode 接管前必须先确保旧的 Active 被隔离，防止两个 NameNode 同时声称自己是 Active（脑裂）。 本篇只抓一个问题：Quorum Journal Manager 怎么工作、ZKFC 怎么检测 NameNode 健康、为什么脑裂是 HA 系统的头号敌人以及...

上一篇讲了读写路径。本篇展开 NameNode 内存里的元数据结构，以及 NameNode 启动时怎么把磁盘上的元数据恢复成内存镜像。 NameNode 常被描述成"HDFS 的元数据节点"。这个描述对应了职责但没解释机制。准确的说法是：NameNode 是一个把全部元数据驻留内存的进程，磁盘上同时维护两份互补的持久化文件——FSImage 是元数据镜像快照，EditLog 是镜像之后的增量操作日志，启动时把 FSImage 加载进内存、重放 EditLog，恢复到宕机前的最终状态。 本篇只抓一个问题：NameNode 内存里到底有哪些数据结构、FSImage 和 EditLog 是怎么配合的、为什么 NameNode 启动要进入 Safe Mode 等待块报告。 NameNode 内存里的六大数据结构 打开 NameNode 进程的内存，主要元数据可以分成六块： 12345678910111213141516171819202122232425┌─────────────────────────────────────────────────────────...