守株阁

前四阶段把 Hadoop 核心（HDFS / YARN / MapReduce + Common）讲完了。第五阶段展开 Hadoop 周边的生态系统和现代演进。本篇先讲生态——Hive、HBase、Pig 在 Hadoop 之上各自的角色。 Hadoop 生态常被介绍成"HDFS + YARN + MapReduce + 一堆工具"。这个描述对应了组件清单但完全没解释这些工具为什么存在。准确的说法是：Hive 是 SQL 编译器（把 SQL 翻译成 MapReduce/Tez/Spark 执行计划），不是计算引擎；HBase 是把随机读写放上 HDFS 的 LSM-Tree KV 存储，依赖 HDFS 做持久化但通过 RegionServer 提供低延迟访问；Pig 是脚本化的数据流编程语言，曾被 Yahoo 大规模使用；新项目通常转向 Spark，但 Pig 在 2025 年仍发布了 0.18.0，并未进入 Apache Attic。这三个工具各自填补 Hadoop 的一个能力空白——SQL 接口、随机读写、复杂数据流——但底层都跑在 HDFS + YARN...

上一篇讲了安全。本篇讲 Hadoop 的可观测性——Metrics、JMX、日志聚合。这是 HA、安全与 Common 篇的最后一篇。 Hadoop 可观测性常被介绍成"看 Web UI 和日志"。这个描述对应了基本操作但漏了系统化设计。准确的说法是：Hadoop 提供三层可观测性——Metrics V2 是结构化指标系统（Source-Sink 架构，周期性采样暴露给外部采集）、JMX 是运行时 Java 指标暴露接口（Prometheus JMX Exporter 让 Hadoop 接入现代时序数据库）、YARN Log Aggregation 是 Task 日志的集中存储和查询。这三层共同构成 Hadoop 集群的运维可观测性基座。 本篇只抓一个问题：Metrics V2 的 Source-Sink 架构怎么工作、JMX 怎么接入 Prometheus 等现代监控栈、YARN Log Aggregation 的写入和查询流程、生产环境的可观测性最佳实践。 Metrics V2：Source-Sink 架构 Hadoop 2.x 引入了 Metrics V...

上一篇讲了序列化与压缩。本篇讲 Hadoop 的安全机制——Kerberos 认证、Delegation Token、Proxy User。 Hadoop 安全常被介绍成"Kerberos 配置"。这个描述对应了最显眼的部分但漏了完整设计。准确的说法是：Hadoop 安全是一个分层模型——底层用 Kerberos 做初始强认证，中间层用 Delegation Token 减轻 KDC 压力，资源访问层用 Block Token / Container Token 做时间受限授权，最上层用 ACL 做细粒度权限控制。Proxy User 让超级用户代表真实用户访问 Hadoop，是 HiveServer2 / Oozie / Hue 这类网关服务的核心机制。 本篇只抓一个问题：Kerberos 在 Hadoop 里到底起什么作用、Delegation Token 怎么减少 KDC 压力、Proxy User 与 doAs 模型怎么让网关服务代用户访问。 为什么 Hadoop 需要 Kerberos Hadoop 默认是 SIMPLE 认证——客户端声称自己是哪个...

上一篇讲了 RPC。本篇讲 RPC 和数据存储都依赖的两个底层机制——序列化和压缩。 序列化与压缩常被合并介绍。这两个机制其实是不同维度——序列化解决"对象怎么变字节流"（结构化），压缩解决"字节流怎么变更小的字节流"（空间优化）。两者经常组合使用——序列化后的字节流再压缩存储或传输。准确的说法是：Hadoop 提供多种序列化格式（Writable / Protobuf / Avro），与多种压缩格式（Gzip / BZip2 / Snappy / LZ4 / Zstd）正交组合，按场景选择最优组合。 本篇只抓一个问题：Writable 与 Java Serializable 的差别、Protobuf 与 Avro 各自的取舍、Snappy vs Zstd vs Gzip 的压缩比/速度权衡、压缩在 Hadoop 各个环节的具体应用位置。 序列化的本质 序列化（serialization）解决"对象 → 字节流"和"字节流 → 对象"的双向转换。分布式系统的所有跨进程数据交换都依赖序列化——RPC 参...

前三阶段把 HDFS / YARN / MapReduce 三个子系统讲完了。第四阶段展开三个子系统共用的那套基础设施——RPC、序列化、安全、监控。本篇先讲 RPC。 Hadoop RPC 常被介绍成"Hadoop 进程间通信的协议"。这个描述对应了功能但完全没解释机制。准确的说法是：Hadoop RPC 是一个独立的、自研的 RPC 框架，不是 gRPC / Thrift / Dubbo 之类通用框架。它用 Protobuf 做序列化（Hadoop 2.x 起默认），用 SASL 做认证（Kerberos / Delegation Token / Simple），用 NIO + 长连接做传输。整个 Hadoop 项目（HDFS / YARN / MapReduce）的所有进程间通信都走这套 RPC——NameNode 与 DataNode、ResourceManager 与 NodeManager、ApplicationMaster 与 RM、Task 与 MRAppMaster。 本篇只抓一个问题：Hadoop RPC 的六层栈是怎么组织的、Protob...

上一篇讲了 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...