Hadoop 概述

Hadoop = 存储 + 资源管理 + 分布式计算

集群配置示例：48核CPU / 256GB内存 / 每台24TB存储（36TB总容量）

一、HDFS 高可用架构

HDFS（Hadoop Distributed File System）采用高可用（HA）架构，确保文件系统的持续可用性。

1、NameNode（NN）

主备模式：Active（a）和 Standby（s）

核心职责：

• 管理 HDFS 的目录树与文件元数据
• 元数据以 namespace image（fsimage）和 edit log 文件形式存储在本地磁盘
• 这些文件在 HDFS 每次重启时重新构建

Standby NameNode 功能：不对外提供写服务；持续从 JN 读取 editlog 并回放，保持元数据和 Active 完全一致；定期合并 fsimage 和 editlog，生成新的 fsimage，防止 editlog 过大导致 NameNode 启动时间过长，同时减轻 Active 压力；

NameNode 具体功能：

NN不存真实文件数据，只存元数据（文件名、目录、块位置、权限）

1. 管理文件系统名称空间：维护目录结构和文件元数据
2. 管理客户端对数据的读写请求：处理客户端的数据访问操作
3. 管理数据块到 DataNode 的映射关系：跟踪数据块在集群中的位置
4. 管理副本策略：当某个 DataNode 宕机或数据块损坏时，NameNode 触发数据块的复制
5. 负载均衡：指导数据在集群中均匀分布
6. 心跳机制：通过心跳与 DataNode 保持通信，监控节点状态
7. 元数据持久化：为保障故障后可恢复，NameNode 将元数据保存在本地磁盘

2、DataNode（DN）

存放文件实际数据的节点，会定时将 block 的列表汇报给 NameNode，默认6h。

  2.1 块报告包含：

    2.11 数据块ID（每一个hdfs数据块的唯一编码）；

    2.12 块的版本号（生成戳，用于识别块版本，处理复制、损坏、截断、恢复场景）；

    2.13 块的长度（当前数据块的实际字节大小）；

    2.14 块状态标记（正常完好块、损坏块、正在写入块、已删除但还未清理的块）；

    2.15 存储层信息（DN可以有多块磁盘/多个存储目录，每个存储有唯一的UUID，告诉NN，这个块存放在本DN的哪一块磁盘存储上）；

    2.16 存储类型信息（HDD/SSD 内存存储）；

3、JournalNode（JN）

NameNode 间通信的中间件：

• Active NameNode 命名空间（就是 HDFS 的整个目录树：所有目录、文件名、文件权限、副本数、文件对应哪些块的映射关系）发生变化时告知 JournalNode
• Standby NameNode 从 JournalNode 读取 editlog（只要改动 HDFS 目录树、文件元数据、块和文件的映射关系，就会写事务到 editlog），监控 editlog 变化，并应用于自身状态

4、ZKFC（ZooKeeper Failover Controller）

监控 NameNode 状态：

• 当 Active NameNode 异常时，断开与 ZooKeeper 的连接，释放锁
• Standby NameNode 上的 zkfc 抢锁，完成 NameNode 切换

5、其他 HDFS 组件

• HTTPS：提供安全的通信通道
• Balance：磁盘数据均衡工具

二、YARN 资源管理

YARN（Yet Another Resource Negotiator）是 Hadoop 的资源管理系统。

1、ResourceManager（RM）

主备模式：Active（a）和 Standby（s）

核心职责：负责集群资源管理和调度，接收作业，分配资源

1.1 Application Manager

• 管理监控各个应用系统
• 启动 Application Master（AM）
• 监控 AM 的运行状态
• 跟踪分配给 AM 的进度和状态

1.2 Scheduler

  分配 container 给 application master

  分配算法：

• 公平调度（Fair Scheduler）：动态平衡资源，适合多租户场景
• 先进先出（FIFO Scheduler）：简单队列，存在资源饥饿问题
• 容量调度（Capacity Scheduler）：多用户/部门共享集群，集群资源划分为多个逻辑队列

2、NodeManager（NM）

负责节点资源管理、任务启动、上报资源：

     2.1 资源汇报：定期向 ResourceManager 汇报本节点的资源使用情况，分配资源给 AM

     2.2 任务管理：管理 AM 提交来的 task，例如接收 AM 启动与停止 task 的请求，由 ContainersLauncher 完成

3、Application Master（AM）

用户提交的每个 program 都会对应 1 个 AM：

• 负责监控应用
• 任务容错（重启失败的 task）
• 与 ResourceManager 和 NodeManager 交互
• 向 ResourceManager 申请资源
• 请求 NodeManager 启动/提交 task

4、Container

资源调度的基本单位，是内存、CPU、磁盘、IO 的集合：

• AM 会给 task 分配 Container
• task 只能使用分配给它的 Container 资源

---

5、YARN 调度流程

完整调度流程：

1. Client 提交作业给 Yarn
2. ResourceManager 接收作业，分配 Container 启动 ApplicationMaster
3. ApplicationMaster 向 ResourceManager 注册并申请资源
4. ResourceManager 根据调度策略，分配 Container 给 ApplicationMaster
5. ApplicationMaster 根据资源在 NodeManager 启动 Container
6. Container 中运行具体的 task
7. 全部任务结束，AM 向RM注销，进程退出

简化表示：

client → yarn -> RM → Container → AM →  RM → Container → AM -> NM-> C -> task

重点：✅ 如果 NM 挂了，会发生什么

1. NM 停止向 RM 发送心跳，RM 等待超时（默认 60s）后，将该节点标记为LOST。
2. RM 会杀死该 NM 上所有正在运行的 Container，包括这台机器上的 Task 容器。
3. AM 感知到 Task 容器失败，会重新向 RM 申请新的 Container 资源。
4. RM 把资源调度到其他正常的 NM 节点上，AM 在新 NM 启动容器，重新运行失败的 Task。

区分不同任务类型：

• MapReduce / Spark 批任务：单个 Task 失败自动重试；只要重试次数没超限，整个作业不会失败。
• Flink on Yarn：
  • Per-Job 模式：TM 容器挂掉 → JobManager 检测失败，触发作业重启，从 Checkpoint/Savepoint 恢复。
  • Yarn Session 模式：仅丢失这台机器上的 TM，其余 TM 继续运行，AM 会申请新 TM 容器。

1. 补充关键点：
   • AM 本身如果不在这台故障 NM 上：AM 不受影响，继续申请资源。
   • 如果AM 刚好运行在故障的这台 NM 上：AM 容器被 Kill，RM 会重新分配新 Container，重启 AM，AM 恢复后继续管理任务。
   • 如果该机器同时部署 DN：NM 挂 ≠ DN 挂。DN 正常的话 HDFS 块数据不受损坏。

---

三、📌 精简版

NM 宕机后不再上报心跳，RM 超时标记节点 LOST，杀掉节点上所有 Container。AM 发现 task 失败，重新向 RM 申请资源，调度到其他正常 NM 重试任务。如果 AM 正好在故障 NM 上，RM 会重启 AM。批任务一般不会整体失败；Flink 会触发作业从 checkpoint 恢复。

四、高频Q&A

Q：RM 是直接把 Container 分配给 AM 吗？

A：RM 只分配资源的描述信息（哪台机器、多少内存 CPU），不会启动容器；启动容器是 AM 和 NM 交互完成。

Q：调度器（Capacity/Fair）在哪一步起作用？

A：AM 向 RM 申请资源的时候，RM 内部调度器负责挑选可用节点，分配资源。

补充节点部署部分：Hadoop 集群高可用节点分布-CSDN博客