hadoop

Hadoop 是一个用于分布式存储和处理大规模数据的开源框架，它的架构主要由以下几个核心组件组成：

1. Hadoop 生态系统核心组件

Hadoop 的核心架构主要包括 HDFS（Hadoop Distributed File System） 和 YARN（Yet Another Resource Negotiator） ，以及 MapReduce 计算框架：

1.1 HDFS（分布式文件系统）

HDFS 负责存储大规模数据，采用 主从架构：

• NameNode（主节点）
  • 负责管理 HDFS 元数据（文件目录、数据块位置信息等）。
  • 维护整个 HDFS 的命名空间。
• DataNode（从节点）
  • 存储实际的数据块。
  • 按照 NameNode 的指令执行数据读写操作。

特点：

• 数据会被拆分成 多个数据块（默认 128MB 或 256MB），并存储在多个 DataNode 上。
• 副本机制（默认 3 副本），保证数据可靠性和容错能力。

1.2 YARN（资源管理框架）

YARN 是 Hadoop 2.0 引入的资源管理系统，主要负责任务调度和资源管理。

• ResourceManager（资源管理器）
  • 负责全局资源管理和调度。
  • 包含两个主要组件：
    • Scheduler（调度器）：按照公平性或容量等策略分配资源。
    • ApplicationManager：管理应用程序的生命周期。
• NodeManager（节点管理器）
  • 运行在每个计算节点上，负责管理该节点上的资源（CPU、内存等）。
  • 执行 Container（容器）中的任务。

特点：

• 资源调度更加灵活，支持不同类型的计算框架（如 Spark、Flink）。
• 分布式任务管理，提高 Hadoop 计算效率。

1.3 MapReduce（分布式计算框架）

MapReduce 是 Hadoop 早期的计算框架，采用 "分而治之" 的编程模型：

• Map（映射）：将输入数据拆分成多个小任务并并行处理。
• Shuffle（洗牌）：对 Map 结果进行分组、排序，并传输给 Reduce 任务。
• Reduce（归约）：对分组后的数据进行聚合处理，最终生成结果。

特点：

• 适合批处理任务（如日志分析、数据统计）。
• 计算过程中会大量读写 HDFS，导致 I/O 开销较大。

2. Hadoop 生态系统

除了 HDFS、YARN 和 MapReduce，Hadoop 还衍生出许多组件，形成一个庞大的大数据生态系统：

组件	作用
Hive	SQL 查询引擎，支持类 SQL 语法（HiveQL），适合数据仓库应用。
HBase	分布式 NoSQL 数据库，适合存储海量结构化数据。
Spark	内存计算框架，比 MapReduce 更快，适合流式和实时计算。
Flink	流处理计算框架，适用于低延迟数据处理。
Kafka	分布式消息队列，适用于日志收集、实时数据处理。
Zookeeper	分布式协调服务，管理 Hadoop 集群的元数据和状态。
Oozie	任务调度工具，支持 MapReduce、Spark 等任务的调度管理。

3. Hadoop 架构示意图

+------------------------------------------------------+
|                     Client                          |
|  - 提交 MapReduce 任务 / Hive SQL / Spark 任务       |
+------------------------------------------------------+
|                     YARN                            |
|  - ResourceManager（资源管理）                      |
|  - NodeManager（节点管理）                          |
+------------------------------------------------------+
|                    HDFS                             |
|  - NameNode（元数据管理）                          |
|  - DataNode（数据存储）                            |
+------------------------------------------------------+

4. Hadoop 运行流程

以 MapReduce 任务执行流程 为例：

1. 客户端提交 MapReduce 任务（HDFS 作为数据源）。
2. ResourceManager 分配资源，将任务调度到多个 NodeManager 上。
3. NodeManager 启动 Map 任务，读取 HDFS 数据并执行 Map 计算。
4. Map 任务完成后，Shuffle 过程进行数据分区、排序并传输给 Reduce 任务。
5. Reduce 任务对 Map 结果进行归约计算，最终生成结果并存入 HDFS。

5. 适用场景

适合的场景

• 大规模离线数据分析（如日志分析、用户行为分析）。
• 海量数据存储（如互联网公司的数据仓库）。
• 分布式计算（如机器学习训练）。

不适合的场景

• 低延迟查询（Hadoop I/O 开销大，不适合秒级查询）。
• 事务性操作（HDFS 不支持 ACID 事务）。
• 小文件存储（HDFS 适合存储大文件，不适合大量小文件）。

总结

Hadoop 采用 HDFS 进行分布式存储，YARN 进行资源管理，MapReduce 进行计算 ，构成了一个强大的大数据处理架构。同时，围绕 Hadoop 发展出了 Spark、Hive、Flink、Kafka 等生态组件，使其在 数据分析、机器学习、大数据存储 方面有广泛应用。

并行度

Hadoop 默认是支持并行计算的。Hadoop 的核心组件之一------MapReduce------采用 分布式并行计算 模型来处理大规模数据。其并行度（Parallelism）主要受以下几个因素影响：

1. MapReduce 任务的并行度

• Map 任务并行度
  • 由输入数据的 分片（Input Splits） 决定。
  • 默认情况下，每个 HDFS 数据块（128MB/块，Hadoop 2.x 及以后）对应一个 Map 任务 ，即如果有 1TB 数据，默认会有 1TB ÷ 128MB = 8192 个 Map 任务 并行执行（如果有足够的计算资源）。
• Reduce 任务并行度
  • 由 mapreduce.job.reduces 配置参数控制，默认值一般是 1 ，但可以手动调整（通常是 Map 任务数 ÷ 4）。
  • 任务调度器会根据 数据倾斜 和 计算资源 动态调整 Reduce 任务数。

2. YARN 资源调度影响并行度

• Hadoop 2.x 及以后，Hadoop 使用 YARN （Yet Another Resource Negotiator）作为资源管理器，每个任务（Map 或 Reduce）运行在 一个 YARN 容器（Container） 内。
• 计算并行度受 yarn.nodemanager.resource.memory-mb 和 yarn.nodemanager.resource.cpu-vcores 影响，即：
  • 一个节点能同时运行的任务数 = 节点可用 CPU 核心数 / 每个任务使用的 CPU 核心数。

3. HDFS 数据分布影响并行度

• HDFS 将数据 分块存储 （默认 128MB/块），不同的 Map 任务会在不同节点上处理对应的块数据，多个节点可同时并行执行 Map 任务。

结论

Hadoop 默认是并行计算的，并行度 没有固定值 ，而是受 HDFS 分片数、MapReduce 任务配置、YARN 资源管理、集群节点数量 等因素综合影响。一般来说：

• Map 任务数 ≈ HDFS 数据块数
• Reduce 任务数 ≈ Map 任务数 ÷ 4（可调节）
• 实际并行数 = 受限于 YARN 资源的最大任务数

如果想提高 Hadoop 并行度，可以：

1. 增加 HDFS 数据块数（减少块大小） 以增加 Map 任务数。
2. 增加 YARN 资源（CPU / 内存） 以提高任务调度能力。
3. 优化 Reduce 任务数 以避免数据倾斜。

Checkpoint

Hadoop 中的 Checkpoint

在 Hadoop HDFS（Hadoop Distributed File System） 中，Checkpoint 机制主要用于 管理 NameNode 的元数据（Metadata），防止 EditLog 过大，提高 NameNode 的恢复速度。

1. 为什么需要 Checkpoint？

HDFS 元数据的存储

HDFS 的 NameNode 负责管理文件系统的元数据，主要由以下两部分组成：

• FsImage（文件系统的快照）：包含 HDFS 目录结构和文件元数据的完整快照。
• EditLog（日志）：记录 HDFS 的所有变更（如创建、删除文件等）。

问题：

1. EditLog 过大 ：
   • NameNode 启动时必须重放 EditLog 以恢复状态，如果 EditLog 过大，恢复时间会很长，甚至导致崩溃。
2. 降低 NameNode 恢复时间 ：
   • 需要定期合并 EditLog 到 FsImage，生成新的 FsImage，减少 EditLog 的大小。

Checkpoint 作用

Checkpoint 机制通过定期合并 FsImage 和 EditLog，生成新的 FsImage，减少 EditLog 体积，提高 NameNode 的恢复效率。

2. Checkpoint 由谁执行？

在 非 HA（高可用）模式 下，Checkpoint 由 Secondary NameNode（SNN） 执行。

在 HA 模式 下，Checkpoint 由 Standby NameNode 负责。

Secondary NameNode

• 并不是 NameNode 备份节点 ，而是专门用于 Checkpoint 的辅助节点。
• 定期从 NameNode 获取 FsImage 和 EditLog，合并后生成新的 FsImage 并回传给 NameNode。

Standby NameNode（HA 模式）

• 在 Hadoop 高可用（HA）模式 中，Secondary NameNode 被 Standby NameNode 取代。
• Standby NameNode 通过 JournalNode 读取 EditLog 并执行 Checkpoint。

3. Checkpoint 详细流程

Checkpoint 的完整流程如下：

1. Secondary NameNode 从 NameNode 复制 FsImage 和 EditLog
2. 在本地合并 EditLog 到 FsImage
3. 生成新的 FsImage
4. 将新 FsImage 发送回 NameNode
5. NameNode 用新 FsImage 替换旧的 FsImage，并清空 EditLog

最终结果：EditLog 变小，NameNode 重启时只需重放较少的日志，恢复速度更快。

4. Checkpoint 触发条件

可以通过 hdfs-site.xml 配置 Checkpoint 触发规则：

<property>
    <name>fs.checkpoint.period</name>
    <value>3600</value>  <!-- 默认 1 小时执行一次 Checkpoint -->
</property>

<property>
    <name>fs.checkpoint.size</name>
    <value>104857600</value>  <!-- EditLog 100MB 时触发 Checkpoint -->
</property>

• fs.checkpoint.period：指定 Checkpoint 的时间间隔（单位：秒），默认 3600 秒（1 小时）。
• fs.checkpoint.size：当 EditLog 大于设定的大小（默认 100MB）时触发 Checkpoint。

5. 如何手动执行 Checkpoint？

可以通过重启 Secondary NameNode 手动执行 Checkpoint：

hdfs secondarynamenode -checkpoint

或者使用：

hdfs dfsadmin -saveNamespace

注意：手动触发 Checkpoint 适用于 NameNode EditLog 过大时的紧急情况。

6. Checkpoint 在 Hadoop HA（高可用）模式下

在 Hadoop HA 模式下，没有 Secondary NameNode ，而是由 Standby NameNode 负责 Checkpoint：

• Active NameNode 处理所有 HDFS 请求
• Standby NameNode 通过 JournalNode 读取 EditLog，定期执行 Checkpoint，并同步到 Active NameNode

HA 模式下 Checkpoint 触发方式

hdfs dfsadmin -saveNamespace

或者定期在 hdfs-site.xml 配置：

<property>
    <name>dfs.ha.checkpoint.period</name>
    <value>3600</value>  <!-- 1 小时 -->
</property>

<property>
    <name>dfs.ha.checkpoint.txns</name>
    <value>1000000</value>  <!-- 100 万次事务 -->
</property>

• dfs.ha.checkpoint.period：多久执行一次 Checkpoint
• dfs.ha.checkpoint.txns：事务数达到多少次执行 Checkpoint

7. Checkpoint vs. FsImage & EditLog

名称	作用	存储位置
FsImage	NameNode 的完整快照	dfs.namenode.name.dir
EditLog	记录 HDFS 变更日志	dfs.namenode.edits.dir
Checkpoint	合并 FsImage + EditLog，减少 EditLog 体积	dfs.namenode.checkpoint.dir

8. Checkpoint vs. Spark Checkpoint

对比项	Hadoop Checkpoint	Spark Checkpoint
作用	维护 HDFS 元数据，防止 EditLog 过大	持久化 RDD/Dataset，提高故障恢复能力
执行方式	Secondary NameNode / Standby NameNode	rdd.checkpoint()
存储位置	HDFS（FsImage 文件）	HDFS / 本地磁盘
触发方式	自动（基于时间或日志大小）或手动	代码调用 rdd.checkpoint()

9. 结论

✅ Hadoop HDFS 有 Checkpoint 机制 ，用于 合并 FsImage 和 EditLog ，提高 NameNode 的恢复速度，防止 EditLog 过大。

✅ Checkpoint 由 Secondary NameNode（非 HA）或 Standby NameNode（HA 模式）执行 ，可以定期或手动触发。

✅ Checkpoint 机制主要优化 NameNode 启动恢复速度，而不是数据持久化，与 Spark 的 Checkpoint 作用不同。