守株阁

第一阶段把 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 物理存...

一项评测得到的分数，并不只属于模型——它属于 模型 + agent harness + 工具与环境 + 预算 + 任务集 + grader + 运行协议 的完整组合。改变其中任何一项，分数都会变化。这不是 agent 出现以后才成立的道理；但 agent 任务把这个事实从"可忽略的实现细节"变成了"一阶变量"。 本文综合了两份关键资料：OpenAI 发布的第三方评测 playbook（侧重"如何做出可信的能力声明"）和 Anthropic 的 agent eval 工程指南（侧重 task / trial / grader / transcript / outcome 的实操分类体系）。两份文档指向同一个工程事实：评测结果应当绑定到一个有版本号的被测系统，而不仅仅是一个模型名字。在此基础上，本文还补充了两块内容：LLM-as-Judge 的实操落地指南，以及一个知识增强型开发工作流的评测案例。 本文结构：先建立术语共识（§词汇表），再拆解评测体系的三个层次（§全景），然后分别梳理 OpenAI 和 Anthropic 的...

上一篇讲了 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 进程的内存，主要元数据可以分成六块： 1234567891011121314151617181920212223242526┌───────────────────────────────────────────────────────...

上一篇讲了写入路径——客户端通过 Pipeline 把字节推到三个 DataNode。本篇讲读取路径。 HDFS 读文件常被描述成"客户端从 HDFS 把数据读出来"。这个描述和写路径一样把机制掩盖了。准确的说法是：客户端先问 NameNode 拿 block 列表 + 每个 block 的副本所在 DataNode 列表（按距离排序），然后按距离顺序直连 DataNode 拉取数据，读完后切到下一个 block。任何 DataNode 慢或失败时，客户端透明切换到该 block 的下一个副本。 本篇只抓一个问题：客户端怎么挑副本、本地短路与零拷贝怎么工作、Hedged Read 在什么场景下值得打开。 读取路径的五个步骤 一次完整的 HDFS 读展开成五步： 12345671. open(/path) 客户端调用 NameNode 打开文件2. NameNode 返回：[blk-1 副本列表, blk-2 副本列表, ...] 每个 block 的副本按距离客户端由近到远排序3. 客户端按 block 顺序处理： 3a. 取 blk-N 的副本列表第一个...

上一篇把 HDFS 切成 NameNode、DataNode、Client 三层职责。本篇展开 Client 写文件时的具体路径。 HDFS 写文件常被描述成"客户端把数据写到 HDFS"。这个描述把数据传输机制掩盖了。准确的说法是：客户端通过一个由 NameNode 提前挑选的 DataNode 链（Pipeline）以流水线方式逐包写入数据，每个包从链头流到链尾再返回 ACK，写完一个 block 后客户端向 NameNode 申请新 block。这种 Pipeline + ACK 队列的设计是 HDFS 写入路径的核心抽象，决定了 HDFS 写入吞吐、副本一致性和写入失败恢复的全部行为。 本篇只抓一个问题：客户端写到 HDFS 的字节是怎么一步步落到三个 DataNode 磁盘上的，以及为什么 HDFS 选择 Pipeline 而不是客户端并行写三份。 写入路径的六个步骤 把一次完整的 HDFS 写入展开，可以拆成六个步骤： 1234561. create() 客户端调用 NameNode 创建文件元数据2. addBlock() 客户端向 NameNo...

上一篇把 Hadoop 整体压成一句话：以"节点总会失败"为前提，HDFS 切大文件、YARN 切资源、MapReduce 切计算。本篇进入 HDFS。 HDFS 常被介绍为"分布式文件系统"。这个说法没错但不够准确。准确的说法是：HDFS 是一个把元数据、数据块、节点监控切成三层独立职责的分布式文件系统。三层职责分离是 HDFS 设计的核心抽象，决定了 HDFS 的所有后续行为——为什么元数据全内存、为什么写文件要 Pipeline、为什么读文件可以就近选副本、为什么 NameNode 是单点。 本篇只抓一个问题：NameNode、DataNode、客户端这三层职责是怎么切开的，以及这种切法为什么会让 HDFS 长成现在的样子。 三层职责切分 HDFS 的架构可以用一张三层图概括： 1234567891011121314151617181920212223┌─────────────────────────────────────────────────────────────────┐│ NameNod...

Hadoop 常被介绍为"HDFS + YARN + MapReduce 三驾马车"。这个分类把重点放错了位置。把存储、调度、计算切成三件独立的事情，读者很难回答下面这个问题：为什么这三个子系统会一起出现在同一个项目里，而不是像 Spark、Flink、Kafka 那样作为独立组件存在？ 更准确的说法是：Hadoop 是一组关于"如何构建运行在大量廉价节点上的分布式系统"的前提假设在三个不同层面的具体化。这组前提把整个项目串成一条主线——节点总会失败、数据总是巨大、廉价比专用更重要。HDFS、YARN、MapReduce 各自处理这组前提下的一个子问题：HDFS 把大文件切成块并多副本放置，YARN 把集群资源切成容器并按策略分配，MapReduce 把大计算切成任务并按失败重试执行。 本系列只抓一个问题：Hadoop 这套以"节点总会失败"为前提假设的工程化方案，在 HDFS、YARN、MapReduce 三个层面是如何具体实现的，每个实现里有哪些可以迁移到其他分布式系统的设计模式。 GFS 论文留下的设计遗产 要理解...

代码评审、用例设计、算法分析里到处是「XX case」：edge case、corner case、boundary case、happy path、worst case、base case……而且经常被当成同义词换着用。它们其实分布在几条互不相干的轴上，老家也分别在硬件工程、数学、算法分析和需求分析里，没有一个是测试专有的词。把它们各自摆回所属的轴，混淆就散了。 这些「case」大致落在四条轴上：输入空间里的位置、程序执行的场景走向、输入的刁钻程度、递归的收敛结构。 轴一 · 输入空间的位置 把每一个输入参数看成一根坐标轴：数组长度是一根轴，取值范围是一根轴，并发数是一根轴，时间是一根轴……所有参数张成一个高维空间。合法输入落在这个空间内部，被称作正常情况（normal case）。问题往往不出在中间，而出在这个空间的表面、棱和顶点上。 拿一个二维矩形打比方最直观。矩形的内部是正常区域，四条边是它的边界，四个角是两条边的交点。edge 对应边，corner 对应角，这不是巧合。两个术语最早就是从模拟电路和硬件工程的这套几何语言里借来的。 normal case（正常情况） 落...